Sub-processor register

What this register is

You put your people's data into Capstan. To run the service we use a small number of other companies: somewhere to keep the database and the documents, somewhere to run the software, something to send email. Those companies are sub-processors, because they process your data on our behalf while we process it on yours. You do not have a contract with any of them. We do, and we stay responsible for what they do with your data.

This page names every one of them, and for each says what it is for, what data actually reaches it, where it processes that data, and what is relied on if the data leaves your region. It exists so that you can check the answer rather than accept a general assurance that we use "industry-standard providers". It is the live register, not a summary of one: it is compiled from what the software actually does, and it is updated in the same change as the provider it describes.

It has two tables, and the distinction between them is the point. A vendor can be admitted by policy, meaning reviewed, contracted and permitted, and still be unengaged, meaning no credential, no code path and no data. Publishing an admitted-but-unengaged vendor on a customer-facing register overstates the data footprint. Omitting an engaged one understates it. Both are wrong, so both states are listed.

Every entry is per region. A vendor engaged in one region is not thereby engaged in another, because each region is a self-contained stack with no runtime path to any other. The region in scope for this register is India (in), in.app.usecapstan.com.

Engaged today

These five vendors are engaged, meaning a credential is set, a code path exists, and data flows. The third column is what actually reaches the vendor, read from the outbound call rather than inferred from the vendor's category. The fifth is what is relied on where that data leaves the region, and the section under the table explains why only one of the five needs a safeguard at all.

What happens when data leaves the region

Two of the five rows hold data inside the region's own project: the database, storage and identity provider, and the compute provider. Ordinary use of the service does not move personal data out of the region, because each region is a self-contained stack with no runtime path to any other.

Three rows are vendor-operated, which means the vendor decides where it runs. Two of those three receive no personal data from us at all. The source-code and continuous-integration provider holds code, build logs and test fixtures. The payment provider receives a product identifier, an amount, a return address and two opaque identifiers, and what a payer types into its hosted checkout is that provider's own processing as controller, not a transfer by us. In both cases there is no personal data to transfer, so there is no transfer to safeguard.

That leaves one row where personal data genuinely goes to a vendor-operated service: the transactional email provider. A recipient's address and the rendered message reach it, and sign-in one-time codes travel the same path. The safeguard relied on there is contractual. No vendor touches data until it has signed a processing agreement carrying obligations equivalent to the ones we owe you, and until a residency-impact statement has been written for the region. That gate is the same one every row on this page has passed.

Notes that belong on the register rather than in a footnote

Payments run in test mode

Dodo Payments is deployed in test mode. No live customer payment has been taken, and live onboarding is gated on an open decision about our entity structure, because a merchant of record is onboarded as a specific legal entity. The row stays on the register because the integration is deployed, not because money has moved.

There is no card data anywhere in Capstan

No card field, no column adjacent to a card number, no payment form. That is a property of the database schema, not a promise about our behaviour. The card is entered on Dodo's hosted checkout, where Dodo is the merchant of record and the controller of that transaction.

Log hygiene is enforced at the seam

Personal data in traces, spans and logs is suppressed where the instrumentation is emitted rather than left to a reviewer to catch. That is what keeps the compute vendor's row honest: request data passes through memory, application logs do not carry the contents of it.

Admitted by policy, not engaged

Each of these is permitted by policy and has no credential set, no code path and no data flow in the live region. If one is switched on it moves to the table above, and the 30-day notice obligation below applies before it does.

The first row is the one worth reading twice. We say elsewhere that no AI evaluates your people. The register's version of that claim is narrower and more checkable: the AI vendor's credential was struck from the required set at launch as unused, and no production code path reads it.

One thing that is not a sub-processor

File scanning is done by an engine we would run ourselves, so nothing leaves the region and no vendor is involved either way. The current posture is content validation: agreement between a file's magic bytes and its declared type, a blocklist for executables and scripts, size ceilings, and detection of the standard antivirus test file. That is deliberately not full antivirus, and it is recorded internally as an accepted residual risk rather than described as something it is not.

The standing controls that apply to every row

• Onboarding gate. Before a vendor touches data: a security review, a data processing agreement carrying obligations equivalent to ours, a residency-impact statement per region, the data classes enumerated, an exit and portability plan, a named owner, a register entry drafted, and the tenant notice scheduled. No checklist, no vendor.
• No cross-region service keys exist at all. The per-region architecture eliminates them rather than governing them. Internal staff access is region-scoped and enforced by row-level security in the database.
• Credential placement is checked by machine, not asserted. The environment matrix is verified in continuous integration: the secret tier exists only in a region's own API service, never in the browser bundle, and no variable may carry another region's value.
• Annual reassessment of every engaged vendor, recorded.
• A new region does not accept customers until its own row of this register, its records of processing, its breach contacts and its jurisdiction assessment are complete.

How a change is announced

Workspaces get 30 days' advance notice before a sub-processor change takes effect. The notice names the vendor, the purpose, what data will reach it and where it will rest, which is the same four things the table above carries. This page is updated in the same change as the provider itself, so the register and the software cannot drift apart between a decision and its announcement.

What you can do if you object is set out in the Data Processing Agreement. That clause is one of the items still with counsel, and it is listed as such on the DPA rather than paraphrased here.

How each row is verified

Every row is checked against the shipped code rather than against a list someone maintains by hand: the set of credentials the software requires to boot, the provider bindings the service actually loads at startup, and the launch decisions recorded in the founder's decision log. That is why a vendor can appear here as admitted and unengaged: the check can tell the difference.

Three questions are answered before any new row is added, and they are the questions the table asks. What is the purpose. What personal data actually reaches the vendor, read from the outbound call rather than from the vendor's category. Where does it rest.

Published and last reviewed

17 August 2026

Review cadence

Annually per vendor, and in the same change as any provider, credential or launch-posture change

Change notice

30 days' advance notice to tenants before a sub-processor change takes effect

Region in scope

India (in), in.app.usecapstan.com

If a vendor you expected is missing, or a row does not match what you were told in a security review, write to privacy@usecapstan.com and we will correct the page or explain the row.

Open items in this document

Every place this document stops short, and why. These are listed rather than drafted because a clause invented to fill a gap is worse than the gap. Each row names what is missing and who has to supply it. Every reference is a link: where the document marks the gap in its own body it lands on that clause, and where it does not it lands on the section the gap belongs to.

Version history

What changed, and when. Entries are added, never edited: if a statement in this document stops being true, the document changes before the product does, and the change is recorded here. The date at the top of the page is the date of the newest entry.

17 August 2026 The version you are reading

First publication. The register was compiled against the shipped code and published here unchanged, replacing the placeholder page that /security had been linking to. Each engaged row also states what is relied on when data leaves the region, and the transfer instrument is published as pending rather than named.

The other documents

Four documents cover the relationship, all published in full and none behind a form. You are reading the Sub-processor register. The rest:

• Privacy Policy Roles, categories, retention, deletion as cryptographic erasure, export, consented access, rights and transfers.
• Data Processing Agreement Processor obligations, sub-processor change notice, the security annex, breach notification, deletion and return of data.
• Terms of Service Service, plans and entitlements, billing and the grace period, acceptable use, your data, and termination. Commercial clauses are with counsel.

Questions about this document go to privacy@usecapstan.com. Privacy and data-protection questions, including requests about personal data, go to privacy@usecapstan.com.

Sub-processor register, N53 Techworks LLP. This copy is the version dated 17 August 2026. The canonical version is at usecapstan.com/legal/sub-processors and supersedes any printed copy.