Data processing addendum

The short version. When your team puts data into a workspace, you decide what it is and what it is for; we just run the machine. This document says so formally. We process your data only to provide the service and only on your instructions, we keep the security measures listed below, we tell you before we add a sub-processor, we tell you within 72 hours if there is a breach, and we delete everything when you delete the workspace. It applies automatically to every customer — you do not need to sign anything, though we will sign a copy if your procurement process needs one.

1. How this fits with the terms

This addendum forms part of the terms of service and applies whenever we process personal data on your behalf. Where it conflicts with the terms on a data protection matter, this document wins. Definitions borrowed from the GDPR — controller, processor, personal data, processing, data subject, supervisory authority — carry their GDPR meanings here.

2. Roles

• You are the controller of everything in your workspace: messages, files, tasks, documents, contact records, and whatever your agents read from the applications you connected. You decide the purposes and the means.
• We are the processor of that data, and we act only on your instructions.
• We are the controller of a narrow set of our own records: your account email, sign-in and security events, invoices, and support correspondence. Those are covered by the privacy policy, not by this addendum.
• If you are a member of a workspace someone else owns, that owner is the controller and we take instructions from them.

3. What we process, and why

4. Your instructions

Your documented instructions are: this addendum, the terms of service, and the actions you and your workspace members take in the product. We will not process your data for any other purpose. In particular, we will not sell it, will not use it for advertising, and will not use it to train any AI or machine learning model.

If we are ever legally compelled to process your data in some other way, we will tell you before doing it, unless the law forbids us from telling you.

5. Confidentiality

Access to production systems is limited to the operator of the service. Everyone with access is bound by confidentiality obligations. Nobody reads your workspace content except where you ask us to as part of a support request, where it is strictly necessary to investigate a security incident or abuse, or where the law requires it.

6. Security measures

These are the technical and organisational measures actually in place:

• Encryption in transit. All traffic reaches the service over HTTPS through Cloudflare.
• Password storage. Passwords are hashed with scrypt (N=2¹⁵, r=8, p=1) with a 16-byte per-password salt and a 64-byte digest. Plaintext passwords are never stored.
• Session security. Session tokens are 192 bits of cryptographically secure randomness, stored only as a SHA-256 hash, expiring after 30 days and revoked server-side on password reset.
• Rate limiting. Sign-in, password reset, join code and email verification endpoints are rate limited; anonymous forms are protected by Cloudflare Turnstile.
• Secret storage. Stored AI provider keys and connector tokens are encrypted at rest. Provider keys are never returned by any read path in the product, masked or otherwise.
• Attachment access control. Files are served through signed URLs with a limited time to live, not from a public bucket.
• Connector write policy. Each connection has a write policy set by a workspace administrator: writes wait for approval by a person (the default for a new connection), run without approval, or are refused. A delete always requires approval, and each change to the policy is recorded in the audit log. Inside the workspace, work that is sent for review, such as a message draft, a document update or a merge, waits for a person to approve it.
• Tamper-evident audit log. Significant workspace actions are written to a hash-chained log, so an earlier entry cannot be altered without breaking the chain.
• Isolation. Each workspace is a separate permission boundary, and each connector its own boundary within it.

We hold no third-party security certification. We do not have SOC 2 or ISO 27001, and we will not claim otherwise. What we offer instead is a short, published list of exactly what we do, and a named sub-processor for every party that can touch the data.

7. Sub-processors

You give us general authorisation to use the sub-processors listed on the sub-processors page. Before adding a new one we will update that page and email workspace owners at least 30 days in advance. If you object on reasonable data protection grounds, tell us within those 30 days; if we cannot offer you a workable alternative, you may terminate the affected part of the service and we will refund the unused prepaid period.

Every sub-processor is bound by terms no less protective than this addendum, and we remain responsible to you for their performance.

8. Helping you meet your own obligations

• Data subject requests. Most of them you can answer yourself: the product lets you find, export, edit and delete workspace content directly. Where you need us, write to privacy@utilityspaces.com and we will help within 30 days. If a data subject contacts us directly about your workspace, we will refer them to you rather than act on it.
• Breach notification. If we become aware of a personal data breach affecting your data, we will notify you without undue delay and in any event within 72 hours, with what we know about what happened, what data was involved, and what we are doing about it.
• Impact assessments. We will give you the information you reasonably need for a DPIA or a prior consultation with a supervisory authority. Much of it is already on this page and the sub-processors page.
• Audits. On reasonable notice, once a year, we will answer a written security questionnaire and provide the documentation we have. On-site audits are not practical for a service of this size; if that is a blocker, say so and we will tell you plainly whether we can work around it rather than leaving it open.

9. Deletion and return

While a workspace exists, its owner can export its data from Settings: one archive of all of the workspace's data and its uploaded files (up to 250 MB of files), as JSON with a manifest and a README, prepared in the background and downloadable for 24 hours. One export can be requested per workspace per day, and stored credentials such as connector secrets, API keys, tokens and password hashes are left out. When you delete a workspace it moves to a recycle bin and is purged after 30 days — 7 days for demo workspaces. Deletion cancels agent tasks still in flight and immediately frees the workspace address. After the purge, copies remaining in routine backups age out on the backup rotation and are not restored to serve traffic. We keep invoices and payment records afterwards because we are legally required to be able to account for money received. The data deletion page has the procedure.

10. International transfers

The service runs on our own servers. Because Cloudflare and the AI providers operate global networks, data in transit may be processed in other regions, including the EU and the US. Where a transfer of EEA or UK personal data requires a transfer mechanism, the Standard Contractual Clauses apply and are incorporated into this addendum by reference, with you as data exporter and us as data importer. Supplying your own AI provider key, with a provider in your own region, narrows this considerably.

11. Signing a copy

This addendum applies automatically and does not need to be signed. If your procurement process needs a countersigned document, or your own DPA template, write to legal@utilityspaces.com and we will deal with it.

12. Changes

We may update this addendum to reflect what the service actually does or a change in the law. Material changes are emailed to workspace owners at least 30 days before they take effect, and the date at the top of this page always shows the last substantive revision.