The security page an auditor would read.
The home page names six layers in a sentence each. This is the same material at working depth: what a control covers, which record proves it ran, where the keys sit, which region holds your ledger, and which report answers for all of it.
Four controls, and the day each one fails.
A control nobody has tested is a paragraph. Each one below lists the scope it covers and the record it writes, and then says what the platform does on the day the control does not hold. The third line is the one worth reading.
-
Access control
Production access is requested, approved by someone who is not the requester, and expires on its own rather than waiting for a person to remember it.
- Scope
- Every human session against production data, plus any payout approval above the desk limit.
- Record
- An access register holding requester, approver, window and the tables actually read. Sessions record what was seen, not only who connected.
- On failure
- A session without an approval behind it is closed by the platform and opened as an incident in the same hour. The approver, not the requester, is asked to explain it.
-
Key custody
Keys are generated inside a hardware module and never leave it. The application asks the module to decrypt; it never asks for the key.
- Scope
- Per-tenant data keys, the tokenisation key for card data, and the signing key that seals every export.
- Record
- A rotation log naming the service that requested each use. Two people are needed to authorise a rotation, and both names stay on the entry.
- On failure
- A key under suspicion is retired first and investigated afterwards. Re-encryption runs against live traffic, so the ledger stays open while it happens.
-
Audit logging
The log is append only and hash chained, and the reporting layer reads from the same record the payment wrote to.
- Scope
- Administrative actions, rule changes, exports, and every payout instruction with the rule version that produced it.
- Record
- Each entry carries the hash of the one before it. The head of the chain is published daily, so a reader can check a year of history against a value they already hold.
- On failure
- A gap in the chain stops exports until the gap has an explanation attached to it. Nothing is edited to close it; a correction is a new entry that points at the old one.
-
Anomaly detection
Rules watch behaviour rather than thresholds alone, and every alert arrives with the query that raised it.
- Scope
- Authorization patterns by scheme, payout destinations that have not been seen before, and administrative access from outside a customer's usual regions.
- Record
- An alert history holding the rule version that fired, the population it compared against, and the analyst who closed it.
- On failure
- A payout to a destination the ledger has never paid before holds automatically while the alert is open. The hold names the rule, so nobody has to guess why the money stopped.
Three states of a record, one custody.
A payment record is in flight, at rest, or in use. Each state needs a different primitive, and each primitive needs a key that the application layer cannot read. The keys live in the module on the right, and rotation runs through the same path.
| Layer | Primitive | Key material | Rotation |
|---|---|---|---|
| In flight | TLS 1.3 with forward secrecy | Session key, discarded when the connection closes | Per connection |
| At rest | AES-256-GCM on records and backups | Per-tenant data key, wrapped by the module | 90 days |
| In use | Format-preserving tokens for card data | Tokenisation key, never exported | 90 days, dual control |
| Exports | Signed and encrypted archive | Signing key with an offline backup | Annual, dual control |
You pick the region, and it does not move.
Residency is a procurement question long before it is an engineering one. The region is chosen when the account is created, backups stay inside it, and a change of region is a migration with an export at the front of it rather than a setting.
| Region | Ledger of record | Backups | Leaves the region | Retention |
|---|---|---|---|---|
| European Union | Frankfurt | Dublin, same legal area | — | 10 years |
| United States | Northern Virginia | Oregon | — | 7 years |
| Asia Pacific | Singapore | Singapore, second zone | — | 7 years |
| Dedicated | Your cloud account or site | Agreed in the contract | Only where you name it | Agreed in the contract |
Support access
An engineer working a ticket from outside your region reads a masked view and cannot export from it. The session is logged the same way a production session is, and the ticket carries the reference, so the access shows up in your register rather than only in ours.
Sub-processors
The processor register lists every sub-processor, the region it operates in and the transfer mechanism behind it. It is versioned and dated, and a new entry is published before it starts processing rather than after. Objections have a window, and the window is in the contract.
Empty slots, shaped for your own reports.
Tessen is a template, so nothing sits behind these entries. Each slot holds the four fields an assurance page has to answer anyway: the standard, the scope it covers, the window it was observed over, and the firm that signed it. Fill them in from your own report, or delete the block until you have one.
Send us the standard you answer to.
Tell us which framework your auditor works from and we return the report references, the sub-processor register and the architecture note that matches it. A call is optional and comes after, not before.