Security and data protection

What happens to a document after it reaches us — whether you upload it, send it to a mailhook address, or connect a folder in your own document store — and who touches it. This page is written for a security review, so it states what we do not have as plainly as what we do.

Data Protection Registration: ZC013758

Where your data is stored

Your documents, the page images we generate from them, and your account, billing and extraction records are held in the European Union. Our database and our document storage are provisioned as EU-restricted resources, which is a property set when they are created and cannot be changed afterwards. Document processing and the search index run on servers in Finland.

Two things are deliberately not covered by that sentence, because they are not true of them. Our application code runs on Cloudflare’s global network, at the location nearest the person making the request — so while your data is stored in the EU, it is processed in transit wherever you are. And a small internal lookup table, holding references to stored files rather than the files themselves or any personal information, is replicated globally.

Where you connect a folder in your own document store, its files are copiedinto that same EU storage rather than read from where they sit. Your own store may be anywhere; what we hold is in the EU, and the connection moves documents inwards only.

We do not train on your content

Your documents and the answers extracted from them are not used to train our models or our providers’ models. That is not only a contractual position: every request our extraction engine sends to a language model carries a routing policy that restricts it to providers which do not retain or train on the content. Where no such provider is available for a model, the request fails rather than falling back to one that would.

We do not read your documents to improve the product, and our own product analytics receive account and organisation identifiers only — never document content, and never extracted values.

Who else processes your documents

Running the service means a small number of providers handle document content on our behalf: hosting and storage, the processing pipeline, embedding generation, and routing to language models. Each is named, with what it is used for and where it processes data, in the sub-processor table in our Privacy Notice. That table is the single list we maintain, and it is updated before a new provider begins processing.

Where a provider is outside the UK or EEA, transfers are made under the UK International Data Transfer Addendum or the EU Standard Contractual Clauses.

Access and separation

Access is granted per workspace — Read, Read & Write, or Manage — and a new workspace starts either readable by the whole organisation or reachable only by its creator and the organisation’s owners and admins, whichever its creator chooses. Every request resolves your access to the specific workspace before it touches any data; there is no ambient trust from being signed in.

API keys inherit the access of the person who created them and can never exceed it. If that person’s access is reduced, their existing keys narrow with it, without anyone editing the keys. Keys are stored only as a hash: the value is shown once, at creation, and cannot be recovered from us afterwards.

An AI client connected over the Model Context Protocol is a third way in, and is bounded the same way. It is authorised by you signing in rather than by a key you hold, it reaches one organisation and only the workspaces already shared with you, and it is read-only. Your organisation’s owners and admins additionally choose which tools each role may call, which can only narrow that access and never widen it. Your access and role are resolved fresh on every request, so disconnecting a client — or removing someone from the organisation — takes effect on its next call rather than when a cached credential expires.

There is no support impersonation feature and no administrative route into your workspace content. Nobody here can open your documents from a support console, because no such console exists.

Documents from your own systems

As well as uploading, your organisation can connect a folder in its own document store — Google Drive or Microsoft SharePoint — so that the files in it become documents. The connection uses an account you create in your own cloud tenant and share that folder with, so the boundary around what we can reach is one you set and can change without asking us.

The consequence is that we hold a credential to a system we do not run, and it is the most sensitive thing we keep on your behalf. It is stored encrypted in our EU database, under a key held in a separate managed store, and it is bound to your organisation — the same encrypted value moved into another organisation’s records will not decrypt. Deleting the connection deletes it. You also hold a revocation we cannot override: the account is yours, so disabling it in your own console ends our access whatever we do at our end.

Two things are worth knowing before connecting a folder. Folder and file names are copied along with the contents and become labels shown across the product, so a folder named after a person puts that name into the interface rather than only into a document. And a connected folder brings in what it holds without anyone reading it first — the choosing happens when you pick the folder, not file by file afterwards.

Google and Microsoft do not become processors of ours through this. They process that data for you, under your own agreement with them; we are a client reading from your tenant, and documents move from them to us rather than the other way about.

Deletion

You can delete a document or a table at any time, and archiving a workspace can delete its documents with it. Deletion is not instantaneous: the document is withdrawn from the service immediately, and a clean-up process running twice daily then removes the stored file, the page images and the search index entries. Deletion of the database record happens last, and only once every other store has confirmed clean — so a partial failure retries rather than reporting success.

Copies can survive in routine backups for a short time after that: up to 30 days for related records in our database, and up to 7 days for the search index, before each is overwritten in the ordinary course. Backups are used for recovery only, and what you delete from the service is not restored from them.

We do not delete your documents on a schedule of our own. Nothing expires on a timer on any plan. A document you leave in place stays available to you until you remove it or close your account.

Encryption and credentials

Data is encrypted in transit over TLS on every external endpoint, and encrypted at rest in our database, document storage and internal lookup tables. Passwords are hashed, never stored. Email verification is required to sign up, and authentication endpoints are rate limited.

Monitoring and detection

We record authentication and authorisation events: every API key accepted or refused, every request refused for reaching outside the organisation it belongs to, changes to API keys, every time a shared document link is opened, every connection from an AI client that is refused, rate limited, or denied a tool, and every email delivered to or refused at a mailhook address. Each entry keeps the network the request came from — a full address for IPv4, the network prefix for IPv6 — and is deleted automatically after 180 days.

An automated check reads that record every hour and raises the patterns worth a look: one credential used from unusually many networks, a burst of rejected keys from one place, one key reaching for several resources it has no access to, or a burst of email to mailhook addresses that do not exist. It is read-only — it tells us to look, and blocks, revokes and refuses nothing on its own.

Separately, every document read is checked against the workspace that asked for it: if a query ever returned a record belonging to a different organisation, that mismatch is recorded and raised immediately rather than waiting for a pattern. Access separation is already enforced when the data is fetched — this is a second, independent check that the first one worked.

Three limits decide what this can honestly tell you, and we would rather state them than let the paragraphs above be read for more than they say. The thresholds are provisional and have not been calibrated against real traffic yet, so for now a quiet week is not evidence of much — and not everything recorded is matched by a rule: an AI client’s refusals are all written down, but only its authorisation refusals are pattern-matched today. The separation check currently observes rather than blocks — it is new, and a check that refuses on its first day can turn a false alarm into a customer unable to open their own document; it starts blocking once it has run quietly for a period. And what the record holds is access that was refused — see what we do not have for what that leaves out.

Incidents

We maintain a personal data breach register, as Article 33(5) of the UK GDPR requires, recording every incident assessed — including those assessed as not notifiable, with the reasoning. We have a documented procedure setting out how an incident is contained, assessed against the 72-hour notification deadline, and reported.

We first walked that procedure end to end as a tabletop exercise in August 2026, against a scenario of a customer reporting they could see another organisation’s data. It is a rehearsal, not an incident record — and it is how we found the limit described in the last bullet below.

If you are a customer and an incident affects data we process for you, we will tell you within 72 hours of becoming aware of it.

One case is worth stating separately, because the usual shape does not fit it. If the credential for a connected folder were exposed, it authenticates against your cloud provider rather than against us — so deleting our copy would not close it, and revoking the account at your end is what would. We would tell you, and what we could tell you about what had been read would be limited, because those reads happen inside your tenant rather than in anything we log.

If you believe you have found a security vulnerability, please report it to security@subworkflow.ai rather than raising it publicly, and give us a reasonable opportunity to fix it.

What we do not have

Stated because a security review will establish it anyway, and because a page like this is worth less when it only lists strengths.

• No security certification. We are not SOC 2 audited, not ISO 27001 certified, and hold no equivalent attestation. We have not committed to a timeline for obtaining one.
• No independent penetration test or security audit. The service has been reviewed internally against its own threat model; that is not the same thing and we do not present it as such.
• No record of what was read, and no log of staff access. We do not keep a log of which documents were opened, by whom, over time — so if you asked us to reconstruct exactly what a compromised credential had reached, we could not. The separation check described above narrows this: a read that crossed between organisations would be recorded and raised. It does not close it. That check covers document reads rather than every surface, and it cannot catch a fault in how the workspace itself was determined, because both halves of the comparison would be wrong together. The same limit applies to AI clients: what a connected client was refused is recorded, what it successfully read is not. It applies again to connected folders: each sync is recorded as a run you can see in the product, listing what it added, but none of it reaches the security record described above and no automated check watches it. Separately, the product has no impersonation or support-access feature, so there is no staff access to log today — and equally, nothing would record one if it were added.
• No data processing agreement in force yet. One is drafted but not finished, so we cannot offer it for signature, and we would rather say so than send you a document we are still working on. If your procurement process needs one, write to legal@subworkflow.ai and we will tell you where it stands.
• Not certified for regulated data. Ragextract must not be used for payment card data governed by PCI DSS, protected health information governed by HIPAA, classified or government-restricted material, or material subject to export control. See our Acceptable Usage Policy.

Extraction is not a decision

Ragextract uses automated systems, including machine learning models, to produce answers from documents, and those answers can be wrong. Every answer carries a citation back to the page it was read from and a confidence indicator, so it can be checked against the source. It does not score, rank or make decisions about people, and it is not a substitute for reading the document where the answer matters.

Your data protection rights

Where we are the controller — your account, billing and usage data — the rights available to you, and how to exercise them, are set out in our Privacy Notice. Where you upload documents containing other people’s personal data, you are the controller of that data and we process it on your instructions.

Questions from a security or procurement review that this page does not answer: legal@subworkflow.ai.

This page describes our practice as at the date above. It is not a contractual commitment and is not incorporated into our Terms of Use; where it and the Privacy Notice address the same subject, the Privacy Notice governs.