Data Processing Agreement

1.Scope and status

1.1 This document sets out the terms on which Capstan processes personal data on behalf of a customer in the course of providing the Capstan service. It applies to all personal data a customer or its people put into a Capstan workspace.

1.3 Everything in clauses 2 to 12 describes what the software and the operating practice actually do today. Where a clause states a control, that control is built and tested, and Annex 2 names it. Where something is not built, the clause says so.

2.Roles of the parties

2.1 The customer is the controller, or data fiduciary, of the personal data in its workspace. It determines the purposes and means of the processing.

2.2 Capstan is the processor, or data processor, of that data, and acts only on the customer's documented instructions.

2.3 Capstan is a controller in its own right, outside this document, for its own data: the contact details of the people who administer and buy the service, billing records, and correspondence with us. That processing is covered by the privacy policy.

2.4 The payment provider named on the sub-processor register is the merchant of record and the controller of the payer's transaction data. Card details are entered on that provider's hosted checkout. No card data exists anywhere in Capstan: there is no card field and no adjacent column in the schema, which is a property of the data model rather than a promise about behaviour.

3.Processing on documented instructions

3.1 Capstan processes personal data only to provide the service, and only on the customer's instructions. The customer's use of the product is the instruction: creating a record, enabling a module, configuring retention, requesting an export or a deletion.

3.2 Capstan does not process the customer's personal data for any purpose of its own. In particular it is not used to train any model, is not sent to any third-party AI service, and is not read by staff except under clause 4.3. No AI capability is built into the product, no AI credential is required or read by any production code path, and the standing commitment is that no AI evaluates a customer's people.

3.3 Product instrumentation and business dashboards carry a hard constraint that no employee personal data enters an emitted event. This is enforced by an automated test over the emission helpers, not by review.

4.Confidentiality and personnel

4.1 Access to customer personal data is limited to staff who need it, under least-privilege roles granted per region. Multi-factor authentication is mandatory. There are no shared accounts. Granting the highest privilege role requires two distinct administrators, one requesting and a second approving, enforced in the database rather than by convention; revocation is deliberately single-actor, because removing power must never wait for a quorum.

4.2 Access is reviewed quarterly across every region. A leaver is not considered offboarded until every region, the source-code organisation and every vendor console confirms revocation, on the same day.

4.3 Support does not mean database access. Staff belong to no workspace, so row-level security denies them customer rows by default. A staff member reaches a customer's operational data only while a consent the customer granted is live: requested with a mandatory reason, a stated scope and a bounded duration within a seven-day platform maximum; granted, and revocable at any time, by a customer administrator in their own screen; with sensitive fields masked unless both the grant's scope and the staff member's role permit otherwise; ending at the instant of expiry, because expiry is a comparison rather than a cleanup job; and audited to the customer's own trail as well as ours.

4.4 Emergency access outside clause 4.3 is a documented, sealed, manual procedure that is audited when used. It is deliberately not built as a feature, and it is named here so that its absence from the product is not mistaken for its absence from the operating practice.

5.Security measures

5.1 Capstan implements the technical and organisational measures set out in Annex 2. Those measures are described at the level of the mechanism that enforces them, because a measure named at the level of intent cannot be checked.

5.2 Measures may change as the service changes. A change that materially weakens a measure in Annex 2 will not be made; a change that replaces a measure with an equivalent or stronger one is recorded in the version history of this document.

5.3 Annex 2 also states plainly what we do not have. The certification we hold is named there with its scope, and what it does not cover is named beside it: there is no independent test report of the product, and this document does not imply one.

6.Assistance to the customer

6.1 Capstan assists the customer in meeting its own obligations, taking into account the nature of the processing and the information available to us. In practice the assistance is mostly built rather than performed: the export in clause 7.2, the deletion in clause 10, the audit trail the customer reads in-product, and the consent records in clause 4.3.

6.2 For impact assessments, we name the capabilities that warrant one rather than leaving the customer to work it out: attendance location and selfie capture, geo-fencing, biometric device data, 360-degree feedback, and engagement mood data. Starter text for each ships in the product documentation, and the product's disclosure surfaces and small-group suppression thresholds are the standing mitigations.

7.Requests from individuals

7.1 Requests from data subjects, or data principals, are directed to the customer as controller. Capstan does not action an individual's access or erasure request directly against a customer's workspace, because the customer decides what must be retained for employment, tax or legal-hold reasons. If such a request reaches us we tell the person to approach their employer and, where we can identify the workspace, we tell the customer.

7.2 The mechanisms the customer answers those requests with are self-serve. A workspace Owner can export the whole workspace at any time as a plain tar archive of documented JSON and CSV plus the original document files, with a manifest whose row counts are asserted against the files, sensitive values decrypted under the customer's own authority, and a signed, short-lived download link. The export contains the per-person subset a subject-access request needs. It is audited, and it is never blocked by billing state.

7.3 Person-scoped export and erasure endpoints are named future work. We have built the workspace-level primitives those requests are answered with, and we record the boundary rather than implying a surface that does not exist.

8.Sub-processors

8.1 The customer gives a general authorisation for Capstan to engage sub-processors. The current list, per region, is published at /legal/sub-processors, dated, and distinguishes vendors that are engaged from vendors that are approved but carry no data. As at the date of this document the engaged sub-processors are Supabase, Railway, Resend, GitHub and GitHub Actions, Dodo Payments.

8.2 Before a sub-processor is engaged it passes an onboarding gate: a security review, a written agreement imposing obligations equivalent to those in this document, a residency-impact statement for the region, the data classes enumerated, an exit and portability plan, a named owner, and an annual review date. Every engaged sub-processor is reassessed annually, recorded. Capstan remains responsible for its sub-processors' performance of those obligations.

8.3 Capstan gives customers 30 days' advance notice before a sub-processor change takes effect. The notice states the vendor, the purpose, the data categories that will reach it and where they will rest. The register is updated in the same change as the provider itself, so the published list cannot lag the software.

9.Personal data breach

9.1 On becoming aware of a personal data breach affecting a customer's data, Capstan notifies the affected customers without undue delay, targeting within 24 hours of assessment. Assessment itself begins within four hours of detection under a documented runbook with named owners.

9.2 The notification states the facts as known, the categories of data involved, guidance the customer can act on, and a named contact, and it names the region. Where the customer needs a per-customer impact extract in order to notify an authority or affected individuals, we produce it.

9.3 The customer, as controller, owns any notification to an authority or to individuals. Where Capstan is itself the controller of affected data, its own obligations apply to it directly.

9.4 Two standing rules. Every notification decision is recorded with its reasons, including a decision not to notify. And no public statement about a security incident is made until affected customers have been told directly: a public statement never precedes customer notification.

9.5 Containment never destroys evidence. Logs are preserved and a snapshot is taken before isolation or revocation.

10.Deletion and return of data

10.1 The customer can take its data out at any point during the relationship and on the way out, under clause 7.2, without asking us and without our involvement. There is no proprietary format to escape from.

10.2 On the customer's instruction, Capstan deletes the workspace in four ordered steps. Cryptographic erasure first: the workspace's encryption keys are destroyed, so the ciphertext is unrecoverable and even a database backup taken beforehand is ciphertext without a key. Then every stored document and export archive is deleted. Then every table carrying a workspace identifier is purged, except the allowlist in clause 10.3. Then a residue scan, which discovers every workspace-bearing table from the database catalogue, subtracts the allowlist and counts what is left, returns zero. A failure at any step leaves the request retryable rather than declaring a dirty deletion done.

10.3 What survives is a tested allowlist, and it is financial: invoices and their lines, payments, refunds, credit notes, usage meters, the subscription record and its events, held to the statutory floors in the retention schedule. The workspace record itself survives as a tombstone so those records keep their reference. A completion certificate is written to a staff-side log that outlives the workspace.

10.4 Deletion is scheduled by the workspace Owner behind an explicit typed confirmation and a second confirmation, and sits in a cancellable cooling-off window of seven days by default. Within the window it can be cancelled. After the keys are destroyed it cannot be reversed, and the system refuses to pretend otherwise. Deletion is never blocked by billing state.

10.5 When a module is disabled, its data is retained for a stated window so that re-enabling within the window restores it, and is then purged with the same discipline and the same residue check.

11.Evidence and audit

11.1 Capstan makes available the information needed to demonstrate compliance with this document. What that means concretely today: this document and its annexes; the dated sub-processor register; the privacy policy; a written trust and security questionnaire response covering the areas a reviewer normally asks about; and an internal evidence index that traces each control from the policy that states it to the test, migration or committed record that proves it. That index is published, in the form a reader without repository access can use, as the control register on the security page, together with a plain statement of what each proof does not cover. Ask at security@usecapstan.com and a reviewer is walked through it.

11.1.1 What we hold and what we do not, stated here so nobody discovers either late in a review. N53 Techworks LLP holds an ISO/IEC 27001:2022 certificate for its information security management system, issued 13 August 2025 under certificate number SCC/2508NE/2897 by a certification body accredited by the Standards Council of Canada, valid to 12 August 2028, first surveillance audit completed. Its scope is information security applied to software development, business consulting and digital transformation services, and it is a certification of that management system rather than a test of the product. There is no SOC 2 report, we will not imply one, and we publish no target date for one. The certificate is sent on request, and its scope and dates are stated in full on the security page.

12.International transfers

12.1 Each region is a self-contained stack: its own database, storage, compute and identity store. There is no global control plane, no shared database and no cross-region service key exists anywhere. There is no runtime path between regions, so ordinary operation of the service does not transfer personal data out of the region the customer chose. Moving a workspace between regions is a deliberate, manual, ticketed procedure, on request only: export, import, verify, then cryptographically erase the origin.

12.2 Sub-processor locations are stated per vendor on the register: some hold data inside the region's own project, some are vendor-operated.

13.What this document does not cover

Liability, warranties, indemnities, term, governing law and dispute resolution are not in this document and are not in the Terms of Service either. They are with counsel, and both documents say so in the same words. Nothing in this document should be read as settling any of them by implication.

Annex 1: details of the processing

Subject matter and duration

Provision of the Capstan human resources platform to the customer. The processing lasts for as long as the customer's workspace exists, and ends as described in clause 10, subject to the retention floors in clause 10.3.

Nature and purpose

Hosting, storage, structuring, retrieval, display, transmission by email where the customer's configuration calls for it, backup, export and erasure, for the purpose of the customer administering its own workforce.

Categories of data subject

• The customer's employees, including joiners before their start date and people serving notice.
• Former employees, including those the customer chooses to keep reachable after they leave.
• Contractors the customer records in the platform.
• Candidates, where the customer uses the recruitment capability.
• The customer's own administrators and other users of the workspace.

Categories of personal data

• Identity and employment: names, contact details, employment records, organisation structure, legal entity, location, position, reporting lines, employment status and its history.
• Time: leave requests, balances and ledger entries; attendance days, punches and corrections; and, where the customer enables it, attendance location and selfie images.
• Documents: uploaded files, generated letters and acknowledgements.
• Custom fields the customer defines, including ones the customer marks sensitive.
• Sensitive classes, handled under the strictest tier: compensation, national identifiers, bank details, performance feedback, the existence of a performance improvement plan, health-adjacent fields and biometric-derived data.
• Activity: the workspace's own audit trail of changes and sensitive reads.

Categories excluded by construction

• Card and payment credentials. There is no card field and no adjacent column in the schema, and no payment form in the product.
• Customer money. No customer funds move through Capstan. Payroll and contractor payouts are compiled and handed to the customer's bank or partner, so there is no balance held and nothing to misdirect.
• Personal data in telemetry. Emitted product and business events carry no employee personal data, enforced by test.

Sub-processors

As published, per region and dated, at /legal/sub-processors.

Annex 2: technical and organisational measures

Each measure is named at the level of the mechanism that enforces it. A measure described only as an intention cannot be checked by a reviewer, and cannot be relied on by a customer.

Isolation between customers

• Row-level security is enabled and forced on every application table, so isolation is a database property rather than something application code has to remember. The one exception is the migration runner's own bookkeeping table, which holds no application data and grants nothing to any application role. The generated inventory of every table's posture is regenerated on every build and fails the build if it drifts from the schema.
• Dedicated isolation, completeness and privilege-escalation test suites run on every change, including proving that non-member identity classes such as contractors and alumni are default-deny.
• Staff status is anchored to a database record rather than read from a token claim, so a forged claim cannot escalate a customer identity into a staff one.

Encryption

• In transit: TLS, with strict transport security in production.
• At rest: storage-level encryption from the platform, plus field-level envelope encryption for the sensitive classes. Each workspace holds its own AES-256-GCM data key, wrapped by a region master key.
• The database never holds a key and cannot decrypt. The region master key exists only in the API service's environment, never in the browser bundle and never in a migration, and that placement is asserted by a machine-checked environment matrix in continuous integration. A database dump restored without the key is ciphertext.
• Each encrypted value is bound cryptographically to its workspace, table, person and field, so a ciphertext cannot be replayed onto another row, person or workspace: the authentication tag fails and the decryption throws.
• Both the master key and per-workspace keys are rotatable under a documented overlap-window procedure, staff-triggered and audited. Customer-managed keys are not offered, and this document does not claim them.

Access control

• Passwordless sign-in by emailed one-time code. There is no password stored anywhere in the product.
• Multi-factor authentication with a customer-set policy of off, required for administrators, or required for everyone, enforced at a single chokepoint on the assurance level of the session.
• Staff access is per region, least privilege, mandatory multi-factor, no shared accounts, reviewed quarterly.
• Consented, time-boxed, masked and audited support access as in clause 4.3.

Auditability

• Audit tables are append-only, protected by a trigger that rejects mutation and by revoked update and delete privileges, so a record cannot be quietly edited.
• Customers read their own trail in the product, including a record of every support access granted against their workspace.
• Staff actions are written to a separate internal log from inside the database functions that perform them, so the audit cannot be forgotten by a caller.

Application and platform security

• One untrusted-bytes ingress, which quarantines by default: an uploaded file is undownloadable until scanning clears it, and an infected file is permanently blocked and recorded in both audit trails. The current scanner posture is content validation, agreement between magic bytes and declared type, an executable and script blocklist, size ceilings and standard test file detection, which is not full antivirus and is not described as such.
• Inbound payment webhooks are verified by HMAC-SHA256 over the exact bytes received, with a timestamp tolerance that rejects both stale and future deliveries, constant-time comparison, and rotation-friendly multi-signature acceptance. A forged request receives a flat refusal that leaks nothing.
• Rate limiting on authentication-adjacent and expensive surfaces, plus an enumeration-safe limiter on signup.
• Security headers on both the API and the application, with a strict content security policy, framing denied, and strict transport security in production.
• Static analysis, secret scanning, container scanning and a lockfile vulnerability gate on every run, plus a weekly dynamic baseline scan. Accepted findings sit on a dated, expiring allowlist, so an accepted risk cannot become permanent through inattention.
• Change management: one ordered migration line applied to every region in a fixed order, a pipeline that halts on divergence, and a nightly schema comparison that pages on drift.

Resilience

• Platform backups per region, with a documented restore drill whose executed record is committed.
• A restore without the encryption master key yields ciphertext, so backup verification includes confirming key availability.
• No recovery-time or recovery-point objective is stated, because none has been derived from an executed drill. We do not publish numbers we have not measured.

What is not claimed

• No SOC 2 report. The ISO/IEC 27001:2022 certificate that is held covers the information security management system of N53 Techworks LLP, not a test of the product.
• No customer-managed encryption keys.
• No published availability, recovery-time or recovery-point commitment.

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. Where a reference is a link, it lands on the clause or 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.

18 August 2026 The version you are reading

Clause 1.2 names the processor: N53 Techworks LLP, the same entity named in clause 1.1 of the Terms of Service. What stays pending there is narrower than it was, being the execution mechanics and the order of precedence between the two documents.

17 August 2026

First publication, replacing the placeholder page. Clauses 1 to 13 and both annexes are drafted from the internal privacy framework, the operational policies and the security and compliance control documents. Four clauses are published as pending: the sub-processor objection remedy, audit rights, the transfer instrument, and the execution mechanics.

The other documents

Four documents cover the relationship, all published in full and none behind a form. You are reading the Data Processing Agreement. The rest:

• Sub-processor register Who else touches your data, what reaches them, and where it rests. Includes the vendors admitted but not engaged.
• Privacy Policy Roles, categories, retention, deletion as cryptographic erasure, export, consented access, rights and transfers.
• 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.

Data Processing Agreement, N53 Techworks LLP. This copy is the version dated 18 August 2026. The canonical version is at usecapstan.com/legal/dpa and supersedes any printed copy.