The page your security reviewer actually wants.

You choose your data region at signup, and your tenant's data stays in that region. A region is a self-contained deployment: one database is one region, nothing is global, and there is no cross-region service key, so the separation is structural rather than a policy applied on top. Because the app you sign into is your region, the choice is settled before signup rather than asked for on the form, and it is permanent afterwards. Residency commitments are only real if they cannot be quietly changed later. India is the region live today and the list in the footer of every page is the whole of it; the marketing copy never lists a region before it is real.

One caveat travels with that, and we would rather you read it here than discover it in a questionnaire. Stored data for the India region is in India. Compute is not yet: requests are served from South-East Asia, so data in transit, data in memory while a request runs, and application logs are handled there. Nothing is copied out of the region's own environment and the database does not move, but "your data stays in India" would be doing more work than the facts support, so we are splitting it. Compute moves in-country when our infrastructure vendor offers an India location.

If a region we operate becomes unavailable to us, our stance is stated plainly: your export works, and we give you the maximum notice the situation allows, your data is never a hostage to our infrastructure choices. Cross-region backup is a tenant choice, not a default we make for you. The region list this site displays is a versioned file in the site's own repository, updated by pull request when a region goes live, the marketing site queries nothing to render it.

The marketing site you are reading is static by design: it has no database connectivity of any kind, holds no product credentials or API keys, and stores no client information. Sign-up is a pure redirect into your chosen region's app, so the form you fill never lives here: the only thing this site ever collects is which region you are heading to, and it does that by linking out rather than by asking. Marketing sites are the most attacked surface a company operates, and ours has nothing to take.

In transit, everything is TLS 1.2 or higher. At rest, sensitive fields, compensation, national IDs, bank details, carry per-tenant envelope encryption: an AES-256-GCM data key per tenant, wrapped by a region master key, and rotatable. Here is the part that matters: the master key lives only in the API service, never in the database and never in the browser, so the database cannot decrypt its own contents a database dump is ciphertext. Each ciphertext is bound to its tenant, table, person and field, so a value can never be replayed onto another row. We do not yet claim bring-your-own-key as a shipped control, the per-tenant key is already the unit of ownership that makes it possible, but we would rather under-promise than list it before it is verified in production.

Tenant isolation is enforced in the database with row-level security, not just in application code, with a default-deny posture for non-member identities such as contractors and alumni, they reach only what is explicitly granted, nothing by default. Sign-in is passwordless: a one-time code to your email. There is no password stored anywhere in Capstan, nothing to forget, phish, leak or breach. Admins can add MFA. SSO/SAML and IP restriction are not built today, so treat them as where the product is going rather than as a control you can switch on now. What does exist, on every plan, is the tenant activity log: your own admins filter it by action, record type and date, and export it. It is append-only in the database itself, update and delete are revoked on the table and a trigger rejects any mutation that gets past that, so a record of a change cannot be quietly edited away afterwards, by anyone, us included.

Until recently only our staff console could read an audit trail. Now a workspace admin reads their own, inside the product, at Administration then Activity log: filter by action, record type or date, page through it, and export it. Actor ids resolve to a person's name, and a change made by the system rather than a person shows as exactly that. The endpoint checks for a workspace admin in its own handler rather than leaning on the broader read policy, and the rows stay tenant-scoped whoever is asking, so an admin can never read across workspaces. It is deliberately a read surface: entries are written at the point each change actually happens, never from this screen. The practical result is that you can answer your own auditor from your own workspace, without opening a ticket with us and without taking our word for what happened.

Our support staff have no standing access to your data. They belong to no tenant, so row-level security denies them your records by default. To help with a ticket, they need a consent you grant from inside the app: time-boxed (seven days by default), scoped to read-only or read-with-sensitive, tied to a stated reason, and revocable by you instantly, access ends the moment it expires, with no sweep job to wait for. Sensitive fields stay masked unless you granted the sensitive scope and the specific staff member is authorised for it, and every consented read is logged on both sides. Break-glass emergency access is deliberately not built as a button, it is a sealed, manual, audited procedure, not a shortcut anyone can click.

Most vendors describe their internal controls in a policy document you cannot inspect. Two of ours are worth stating because they are written into the database functions, where nobody at Capstan can route around them from a screen.

Granting the platform administrator role, the most privileged staff role we have, takes two distinct people: one platform admin requests it, a second and different platform admin approves it, and the grant lands only on approval. A direct grant is refused outright. Revocation is deliberately the opposite. Any platform admin can pull any staff role, that one included, alone and immediately, because taking power away fast is a safety property and a quorum on revocation would defeat it. The asymmetry is the point. One honest exception, recorded rather than hidden: the first platform admin comes from fixtures, because there is no first approver until one exists.

The same shape governs money. What a staff member can refund or credit is capped by their role, held as data rather than as a habit. Above that ceiling the act does not execute at all; it becomes a pending request that a second, distinct staff member of the authorising role has to approve, and the function refuses to let a request be approved by the person who raised it. Both actors are recorded in the internal audit log by the function itself, so the record cannot be forgotten by whoever made the call.

Export everything, any time, in open formats, in one click: a single archive of decrypted JSON and CSV, taken by the workspace owner, which is a stricter check than admin on purpose. It works while an invoice is unpaid, it works while a workspace is suspended for non-payment, and it works on your way out. Deletion is a cryptographic erase: we destroy the tenant's keys, so the data is unreadable even from a backup taken before you left, not merely flagged, and not recoverable by us. It happens on your instruction or your configured retention schedule, after a cooling-off window you can cancel, and a residue scan proves no row survived outside the statutory-records allowlist. On data-subject requests you are the controller and we are the processor, so the request reaches you rather than us; our job is to make answering it executable in minutes with the export and deletion tooling already in the product, rather than a support ticket to us.

Former employees keep self-serve access to their own payslips, letters, tax documents and settlement summary on their personal email, long after the work address is gone, no HR ticket, no re-request queue. It is a paid module, charged flat per workspace, and it is minimal by construction: a former employee sees only their own documents, in the categories your tenant allows, and nothing else. It is a DPDP-positive answer to post-employment data access, self-serve, scoped, and provable against the document catalogue.

Nothing, for thirty days. When a term ends the workspace enters a grace period and access is uninterrupted. A paying customer who is late is still a customer, and we do not hold a workspace hostage over an invoice while the grace period we ourselves granted is still running. Admins see an honest in-grace banner rather than a locked door.

You are reminded on a ladder rather than ambushed: sixty days before the term ends, thirty days before, on the day the invoice is issued, and a final warning five days before access actually stops. Those notices are a mandatory category. A workspace cannot mute the one message telling it that it is about to be suspended. Each rung is sent once, so a clock that runs twice does not mail you twice.

Thirty days past due, the subscription lapses and the workspace is suspended. Be clear about what that is and is not. It is not read-only, it is closed: sign-in returns a refusal, and the refusal says the workspace is held rather than that you are. It is also not a data event. Suspension is a reach decision taken at one guard in front of the tenant surface, and not one row of your data is touched, which is why reinstating is a restore and not a recovery.

Your export keeps working the entire time. The export endpoints deliberately sit outside the suspension check, so a suspended workspace can still take everything and leave. Holding your records against an unpaid invoice is the specific thing this company exists not to do.

Coming back is a person here recording that your payment arrived, against its reference. There is no automatic un-suspension, and the ordinary manual reinstate path refuses a billing lapse outright, precisely so a lapse cannot be waved away without recording that the money actually came in.

If you are on the free core, none of this can reach you, and not because we promised. A workspace paying for nothing has no subscription row at all, so it yields nothing to the billing clock on any date and can never be suspended for non-renewal. That is the absence of a record rather than a rule someone has to remember to write, which is why it cannot rot.

An invoice here is a document rather than a total. Each carries its own sequential number, allocated so two invoices issued at the same instant cannot collide, and each is a clean self-contained HTML document you can print, not a spreadsheet you have to reassemble. Your billing page shows the whole breakdown behind the amount: every plan and module line with its quantity, its unit price and its amount, and once the invoice is settled, the receipt details too, meaning the date it was paid, the rail it came in on and the gateway reference. You see what an amount is made of and how it was paid, not a total and the word paid. One gap, stated rather than glossed: there is no tax-amount line on it yet, because that needs real rate tables, and a number we cannot source is worse than a gap.

If you overpay, we do not keep it. The excess becomes an entry in an append-only credit ledger, reconciled against the invoice that caused it, shown to you on your own billing page rather than sitting quietly on our side, and consumed at your next renewal. A credit is not a payment and never a gateway call: it reduces what is payable, so a renewal fully covered by credit reads as paid with no money moving at all. Being honest about the boundary: credits are consumed at renewal, and applying one to something else is not built, because a speculative version would be worse than an absent one.

There is also no auto-debit mandate stored anywhere. Every invoice carries a hosted checkout link that you follow when you decide to. A renewal amount that has moved because your headcount moved is therefore always shown to you before it is paid, and there is no standing recurring authority sitting on your account for anyone to misuse.

Every entitlement, every access decision, every approval route and every generated letter in Capstan comes from a rule you can read and audit, never a model's guess, so nothing hallucinates onto a person's record. Payroll numbers are not ours to hallucinate either: your payroll partner computes them, and Capstan records what comes back, unchanged. Two commitments sit under that. First, your people's data is never sent to a third-party AI model and never used to train one, and there is no AI vendor in the stack to send it to: we struck the one AI credential our deployment still required, because a check confirmed nothing in production ever read it. Second, no AI here scores, ranks or infers things about your people, no attrition-risk ratings, no sentiment analysis, no algorithmic screening. This is architecture, not a promise on a slide: the analytics engine is built so a dashboard can only ever narrow who can see what, never widen it, and small groups are suppressed so no individual is re-identified. If we ever add optional assistance at the edges, such as search or drafting, it stays opt-in, region-controlled and clearly labelled, and it never touches this system of record, so these two commitments hold. Any feature that would falsify this section changes the section first.

Some promises are only as good as the policy behind them; these are enforced by the way the data is stored, so they hold even if someone wanted to break them. Engagement surveys keep who answered and what they answered in separate tables with no key between them, and results never render below a minimum group size, the anonymity is structural, not a setting. Advanced Analytics runs every report as the person viewing it, so a shared dashboard can only ever narrow what someone sees, never widen it, sharing can't become leaking. And no customer money ever moves through Capstan: payroll and contractor payouts are compiled, recorded and handed to your bank or partner, so there is no balance to misdirect.

The card question has the same shape, and it is worth stating at full strength rather than as a reassurance. Capstan has no card field, no PAN-adjacent column and no payment form. There is nowhere in this system for a card number to live, which is a stronger guarantee than a policy saying we would not store one. Our payment provider is the merchant of record: the card is entered on their hosted checkout, they take the payment, and they issue the tax receipt for it. What Capstan holds is a gateway reference and an amount, which is to say an event id, a payment id, a status, a figure and a currency. That is the entire footprint, and it is a property of the schema rather than a promise about our conduct.

This site claims a lot of things are built. Two of the checks that run before any change reaches you are what stand behind those claims, and both exist because reading code was not enough.

The first is a runtime call-coverage gate. It takes every function the database defines, subtracts everything the database, API and end-to-end suites actually execute, subtracts a list of exclusions that each have to be named in a file with a reason and a review marker, and fails the build on whatever is left, by name. It exists because of a specific failure, three times over: code shipped that was registered, applied, and then never called once, including fifteen report sources that were an error for any customer who clicked them. Every check that read the code missed all three. This one runs it instead.

The second is a module boundary audit. It checks the shipped code and the live data against a declared manifest of what belongs to which module, and it fails if any paid surface, at any level from a whole module down to a single field, is reachable without the entitlement that pays for it. A violation emails the person who owns that governance. It is the packaging argument made mechanical: not a policy saying paid things stay behind their gate, but a build that stops when one does not.

Internally, each control names two things: the document that defines it, and the artifact that proves it, meaning a test suite, a build gate, a migration, a generated inventory or a committed record. The standing goal is that an auditor given read access to the repository needs nothing else to trace any control from policy to proof. The register at the foot of this page is that index, written out for a reader who does not have that access. The repository is private, so each row names the mechanism rather than the file it lives in.

The mark on this section is deliberately commitment rather than enforced, and the distinction is the honest one. The controls in the register hold because of how the system is built. The register itself holds because a row is updated in the same change that moves a control, and nothing in the software forces that. Read the register for the controls, and treat its maintenance as one more thing you are taking on trust.

The live, dated sub-processor register is at /legal/sub-processors. Changes are announced before they take effect.

One of the two. N53 Techworks LLP, the entity behind Capstan, holds an ISO/IEC 27001:2022 certificate for its information security management system, issued on 13 August 2025 by QFS Management Systems LLP, a certification body accredited by the Standards Council of Canada. The certificate number is SCC/2508NE/2897 and it runs to 12 August 2028. The first surveillance audit, due 12 July 2026, has been completed and the certificate continued; the second falls due 12 July 2027.

The scope is the half worth reading, because a badge without one tells a reviewer nothing. The certificate covers information security applied to software development, business consulting and digital transformation services, assessed against a Statement of Applicability at version 1.1 dated 1 February 2025. That is the management system this company builds under: how access is granted and taken away, how a change reaches production, how an incident is handled, how a supplier is assessed. It is not a penetration test of the product, and it does not make any single claim on this page true by itself. Write to security@usecapstan.com and the certificate is sent to you, unredacted and without a form.

No SOC 2 report is held, and no target date is published for one, because a date nobody has committed to is an intention wearing the clothes of a plan, and this page does not carry those. If a report is ever issued, it will be linked here, ungated, with the date and the firm on it.

The certificate is still not the strongest thing on this page. That is the register at the foot: every control, the document that defines it, and the artifact that proves it, followed by a plain list of what those proofs deliberately do not cover. An audit says a competent outsider examined the system on a date. The register says what runs. A reviewer who reads both reaches their own conclusion, which is more than either would have told them alone.

Found something? Write to security@usecapstan.com. We acknowledge within two business days, we don't sue good-faith researchers, and we credit fixes if you want the credit.