Privacy Policy

1.Who is what

Almost all of the personal data in Capstan is not ours. It is an employer's record of its own people, and the employer decides what goes in it and why. That is not a disclaimer, it is the structure that determines who you should ask for what.

• For workspace data, meaning employee records and everything derived from them, the customer company is the controller, or data fiduciary in Indian terms, and Capstan is the processor. We act on the customer's documented instructions. We never decide the purposes for which employee data is processed.
• For our own data, meaning workspace administrator contacts, billing records, support correspondence and visitors to this website, Capstan is the controller in its own right, with its own records of processing.
• For payments, the payment provider is the merchant of record and the controller of the payer's transaction data. Card details are entered on their hosted checkout and never reach us.

The practical consequence: if you are an employee of a company that uses Capstan, most requests about your data go to your employer, not to us, and we help them answer you. Section 9 sets out how that works and what we do directly.

2.This website

The marketing site you are reading holds nothing. It has no database connectivity of any kind, no product credentials, and stores no client information. It sets no cookies and stores nothing in your browser, so there is no cookie banner because there is nothing to consent to. Signing in and signing up happen in your region's application, not here.

Our web host necessarily processes the requests that serve you these pages. Beyond that, this site runs no analytics and no tracking scripts.

3.What we process

3.1 As processor, for a customer's workspace

Whatever the customer puts in it. In practice that is the employee master record and everything built on it: people and their employment records, organisation structure, legal entities, locations and positions, leave requests and balances, attendance days and punches, uploaded and generated documents, letters, custom fields the customer defines, and the workspace's own audit trail. Where a customer enables the relevant capability it can also include attendance location and selfie images.

Data is classified internally, and the classification decides the handling. The most protected class is a short, named list: compensation, national identifiers, bank details, performance feedback, the existence of a performance improvement plan, health-adjacent fields, and any biometric-derived data. Those fields are held encrypted with a per-workspace key, permission- gated at field level, masked when rendered to anyone without the permission, banned from logs and from product analytics, and flagged in exports.

3.2 As controller, for ourselves

The contact details of the people who administer and buy Capstan, billing records and invoices, support correspondence, and operational telemetry. Product instrumentation and business dashboards carry a hard constraint that no employee personal data enters an event, which is what keeps this second category small.

4.Why we process it

For workspace data we process because a customer instructs us to, under a data processing agreement, and for no purpose of our own. Specifically: your people's data is not used to improve our product by inspection, it is not sent to a third-party AI model, and it is not used to train one. There is no AI capability built in the product, no AI credential is required or read by any production code path, and the standing commitment is that no AI evaluates your people. The lawful basis for that processing is the customer's to determine, because the customer decides the purpose.

5.How long we keep it

Defaults, with floors. A customer can configure retention above a floor but never below it, because the floors exist for evidential and statutory reasons rather than operational ones.

Application logs are a separate thing from audit events and are kept hot for 90 days and then deleted, with no cold archive by default. Minimisation beats nostalgia. Audit events are not logs and follow the schedule above.

6.Deletion

Deletion in Capstan is not a status flag. It is key destruction followed by row destruction, and then a scan that proves the rows are gone.

1. Cryptographic erasure first. The workspace's encryption keys are destroyed. The ciphertext of every sensitive value is still briefly on disk, but there is no key to unwrap it and the region master key cannot conjure one. Even a database backup taken before the next step is ciphertext without a key.
2. Stored files. Every document and every export archive is deleted from storage.
3. Hard deletion. Every table carrying a workspace identifier is purged except a tested allowlist of financial records held to their statutory floors: invoices and their lines, payments, refunds, credit notes, usage meters and the subscription record.
4. Proof. A residue scan discovers every table carrying a workspace identifier from the database catalogue, subtracts the allowlist, and counts what is left. After a deletion it returns zero. The workspace record itself survives as a tombstone so the retained financial records keep their reference, and a completion certificate is written to a staff- side log that outlives the workspace.

Before any of that: the workspace Owner schedules the deletion, typing the workspace name back and then confirming a second time, and the request sits in a cancellable cooling-off window of seven days by default. It can be cancelled at any point in that window. Once the keys are destroyed it cannot be undone, and the system refuses to pretend otherwise.

Deletion is never blocked by billing state. A suspended workspace can still leave.

When a customer turns off a module, that module's data is kept for a stated retention window so that re-enabling inside the window restores it, and is purged with the same discipline afterwards.

7.Export

A workspace Owner can export everything, at any time, without asking us. The archive is a plain tar file containing a manifest, one JSON and one CSV file per entity, and every stored document as its original bytes. JSON is the authoritative copy and the CSV is a convenience view of the same rows. The manifest states the format, a schema version, the generation time and a row count per entity, and the row counts are asserted against the files in an automated test.

Sensitive values are exported decrypted, because the export runs under the customer's own authority over the customer's own data. A value that cannot be decrypted is exported absent rather than as unusable ciphertext.

The export is Owner-only, the download link is signed and short-lived, the request is written to the workspace's own audit trail, and, like deletion, it is never blocked by billing state. A customer who has not paid can still take their data and leave. There are no proprietary formats to escape from: tar, JSON and CSV open anywhere.

8.Support access to your data

Our staff have no standing access to a customer's data. They belong to no workspace, so the database's row-level security denies them every workspace row by default, before any application code runs.

To help with a ticket, a staff member must ask, and a customer administrator must grant:

• The request carries a mandatory reason, a scope of either read-only or read-with-sensitive, and a bounded duration within a platform maximum, which is seven days.
• The request notifies the workspace's administrators through a notification category that cannot be muted, so nobody can quietly ask for access.
• An administrator approves, denies, or revokes a live grant at any time, from their own screen.
• Sensitive fields stay masked unless the grant's scope allows them and the staff member's own role permits it. Masking happens in the database read path, and the interface has no reveal control at all. Documents are presence-only under consent: a staff member can see that a document exists and its category, never its title and never its contents.
• Access ends at the instant of expiry, because expiry is a comparison made on every query rather than a cleanup job that runs later. There is no window after expiry in which an old grant still works, and a revocation takes effect on the next query.
• Every step, and every consented read, is written to both our internal log and the workspace's own audit trail, so a customer can see it too. The read log is honestly endpoint-level: it records that a named person read a named surface of a named workspace at a given time, not which individual rows.

Emergency access outside this path is a documented, sealed, manual procedure that is audited when it is used. It is deliberately not built as a button, and it is named here rather than left as an unstated exception.

9.Your rights, and how to use them

If you are an employee, a former employee or a candidate of a company that uses Capstan, your employer holds the relationship and the obligations. A request to access, correct or erase your data goes to your employer, who fulfils it using the tools described in sections 6 and 7. That is not us deflecting: your employer decides what is in the record, what has to be kept for employment or tax reasons, and what is under a legal hold, and we are not entitled to second-guess any of that.

What we do. We give the employer the machinery, and we assist. The export contains a per-person subset. Record deletion is driven by the employer. We answer their questions and provide impact extracts when they need them. We are building this deliberately at workspace level: person-level export and erasure endpoints are named future work, and we would rather say so than ship a surface that implies we can bypass the employer.

If we are the controller, which is the case for administrator and billing contacts and for correspondence with us, write to privacy@usecapstan.com and we handle it directly.

10.Where data lives, and what crosses a border

A customer chooses a region at signup and it is permanent. Each region is a self-contained stack, its own database, its own storage, its own compute, its own identity store. There is no global control plane, no shared database, and no cross-region service key exists anywhere. Residency is a property of the architecture, not a configuration flag someone could change.

There is no runtime path between regions, so ordinary operation transfers nothing across a border. Moving a workspace from one region to another is a deliberate, manual, ticketed procedure: export, import, verify, then cryptographically erase the origin. It happens only on request.

The sub-processors listed on the register are a separate question, and the register answers it per vendor: some hold data in the region's own project, and some are vendor-operated. That column is on the register for exactly this reason.

Which legal instrument would govern a transfer, where one is needed, is a jurisdiction-matrix question and is listed in the open items below and in the DPA.

11.If something goes wrong

We run a documented breach procedure with owners and clocks: detect from any source, assess within four hours, contain without ever destroying evidence, notify, recover, and hold a post-incident review within five business days that feeds the risk register.

If personal data is confirmed or likely affected, we notify affected customers without undue delay, targeting within 24 hours of assessment, with the facts, the data classes involved, guidance the customer can act on, and a named contact. As controllers, customers own any notification to an authority or to individuals, and we assist with per-customer impact extracts. Where Capstan is itself the controller, our own obligations apply to us directly.

Two standing rules that we will keep to. Every notification decision is recorded with reasons, including a decision not to notify. And no public statement about a security incident goes out ahead of the people it affects: affected customers are told directly first, whatever channel the public statement later uses.

12.Sub-processors

The live, dated register is at /legal/sub-processors. It names each vendor, its purpose, what data actually reaches it and where that rests, and it also lists the vendors we have approved but do not use, marked as such.

Before a vendor touches data it passes an onboarding gate: security review, a data processing agreement with obligations equivalent to ours, a residency-impact statement, enumerated data classes, an exit plan, a named owner and an annual review date. Customers get 30 days' advance notice before a change takes effect.

13.Security measures

The full set, control by control, is in the DPA's security annex, and the narrative version is on the security page. The four that matter most to this document:

• Per-workspace envelope encryption of sensitive fields. Each workspace has its own AES-256-GCM data key, wrapped by a region master key that lives only in the API service's environment. The database never holds a key and cannot decrypt its own contents, so a database dump is ciphertext. Each encrypted value is cryptographically bound to its workspace, table, person and field, so a value cannot be replayed onto another row.
• Row-level security on every application table, enforced in the database rather than in application code, with a default-deny posture for non-member identity classes.
• Consented, time-boxed, masked and audited support access, as set out in section 8.
• Append-only audit logging, protected by a trigger that rejects mutation and by revoked update and delete privileges. Customers read their own trail inside the product.

14.Impact assessments

Some capabilities warrant a data protection impact assessment by the customer before they are turned on, and we name which ones rather than leaving a customer to guess: location and selfie capture on attendance, geo-fencing, biometric device data, 360-degree feedback, and engagement mood data. For each of those the product's own disclosure surfaces and its small-group suppression thresholds are the standing mitigations, and we ship starter text a customer can use in their own assessment.

Biometric templates from devices are treated as sensitive by default: processed only as vendor-hashed templates where the device permits, and never held as raw images beyond the customer's configured image retention.

15.Contact, and how to raise a grievance

15.1 Data protection contact

For privacy questions, requests about personal data, and anything about how we handle it, write to privacy@usecapstan.com. If you are an employee of a company that uses Capstan, please read section 9 first: your employer is usually the right first stop, and telling you that quickly is more useful than a slow reply from us.

15.2 Grievance officer, India

Under India's Digital Personal Data Protection Act you can escalate a grievance to our grievance officer. The Act requires that officer to be identified as a named person with a postal address, not only a mailbox.

Grievance officer

Kapil Mohan Gupta

Email

kapil@n53tech.com

Postal address

19th Floor, Tower-B, Alphathum, Sector-90, Noida, Uttar Pradesh 201305, India

On behalf of

N53 Techworks LLP

You can also reach us at grievance@usecapstan.com, which is monitored and reaches the same person. Use the named address if you want the statutory route specifically; either arrives.

15.3 Changes to this notice

This document is versioned and dated, and the version history at the bottom records what changed. If a statement in it stops being true, the document changes before the product does.

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.

18 August 2026 The version you are reading

The grievance officer is published. Section 15.2 names the officer, the postal address for grievances and the entity they act for, replacing the two fields that were published as pending. Both are rendered from the site's single entity record, so this document and the other three cannot disagree about them.

17 August 2026

First publication, replacing the placeholder page. Written from the internal privacy and data-protection framework v0.2 (9 July 2026) and the compliance control documents for deletion, export and consented support access. Two fields are published as pending rather than filled: the named grievance officer and the postal address for grievances.

The other documents

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

• Sub-processor register Who else touches your data, what reaches them, and where it rests. Includes the vendors admitted but not engaged.
• 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.

Privacy Policy, N53 Techworks LLP. This copy is the version dated 18 August 2026. The canonical version is at usecapstan.com/legal/privacy and supersedes any printed copy.