What TollRelay has built to protect your data, and what is still planned.
TollRelay is not certified yet. It is preparing for an independent SOC 2 audit, and the auditor's report will be published on this page. Until then, no one outside TollRelay has checked these controls.
Controls
Checked against the code on 4 October 2026.
| Control | Status | Implementation | Proof |
|---|---|---|---|
| Tenant isolation | Built | The database refuses to show one organisation's rows to another, in the EU and US databases and for the receipts the central database keeps. The services connect with a database login that cannot get round that rule. | A test, run on every change, that one organisation cannot read or write another's rows. Each deploy refuses a database login that could get round the rule. |
| Data residency | Partial | Each organisation chooses the EU or the US once, and every id it holds carries that choice. An EU organisation's passes, spending limits and spend are kept in Frankfurt, and a US organisation's in Virginia. The central list of organisations and their receipts is kept in Frankfurt and holds no personal data. Nothing yet raises an alarm if data crosses between the EU and the US. | A test, run on every change, that places each EU database in Frankfurt and each US database in Virginia. |
| No money held | Built | No code holds a balance, pays a seller, takes payment for what an agent buys or enforces a spending limit on its own: the seller and the wallet do. Amounts are stored as exact whole numbers, never rounded. | Tests, run on every change, that refuse a request to pay a seller and keep every amount exact. |
| Signing keys | Partial | One signing service for the EU and one for the US. Their private keys are to be held by the hosting provider, readable by the signing service only. Only the public halves are published, and the service that publishes them cannot sign. No signing key has been created yet. | The published key list and a revocation drill, once keys exist. |
| Agent keys | Built | An agent's private key is shown once, when its pass is issued, and never stored. Only the public half is kept. | A test, run on every change, that refuses any database column for a private key. |
| Change control | Built | Every change to an organisation, a pass or a spending limit writes a receipt. A receipt is never edited or deleted. | A test, run on every change, that receipts cannot be edited or deleted. |
| Refused by default | Built | A request with a missing or malformed key is refused. A change sent without an Idempotency-Key is refused. A service missing one of its secrets stops before it answers anything. | Tests of the API and of sign-in, run on every change. |
| Personal data in errors | Built | An error names the field that is wrong, never its value. No email, name, wallet or key is written into an error or a log line. | A test, run on every change, that an error never repeats the value it refused. |
| Transport and headers | Built | HTTPS only, with HSTS preload, nosniff, frame denial and a content security policy on the site and the dashboard. | The response headers of any page, which anyone can read, and a test of the site's policy on every change. |
| Secrets | Built | No secret is kept in code, in the build or in an environment file. A scan for secrets runs on every change and fails when it finds one. The build signs in with one short-lived identity, and each service reads only its own secrets. | The scan's result on every change. |
| Access control | Partial | Four roles (owner, admin, finance, support) and memberships that expire are stored. Checking a person's role before each action, confirming it is you before a sensitive change, and an export of who has access are planned. | The access export, once it exists. |
| Incident and availability | Partial | Customers affected by an incident are told within twenty four hours of it being confirmed. The status page shows whether the API is answering. It has no incident history yet. | The written incident procedure and the status page. |
| Backups | Partial | Every database has a daily snapshot, kept for 35 days. A nightly encrypted copy, kept in the EU or the US beside the data, is set up but not yet working. | The restore test log, once a restore has been tested. |
| Sub-processors | Built | Six named suppliers, each with what it sees. | The list on this page. |
| Accessibility | Built | WCAG 2.2 AA, checked on every change: the contrast of every colour pair and an automated scan of every page, in both themes. | The checks' results on every change. |
Public keys
A seller checks that a pass came from TollRelay against the public keys published at https://api.trlay.dev/.well-known/jwks.json.
SOC 2 and ISO 27001 mapping
TollRelay's own reading, not yet confirmed by an auditor.
| Control | SOC 2 | ISO 27001:2022 Annex A |
|---|---|---|
| Tenant isolation | CC6.1, CC6.3 | A.5.15, A.8.3 |
| Data residency | CC6.1, P4.1 | A.5.31, A.8.10 |
| No money held | CC2.2 | A.5.34 |
| Signing keys | CC6.1, CC6.7 | A.8.24 |
| Agent keys | CC6.1, CC6.7 | A.8.24 |
| Change control | CC8.1 | A.8.32 |
| Refused by default | CC6.1, CC6.6 | A.8.5 |
| Personal data in errors | CC7.2, P6.1 | A.8.15 |
| Transport and headers | CC6.7 | A.8.20, A.8.24 |
| Secrets | CC6.1 | A.8.24 |
| Access control | CC6.2, CC6.3 | A.5.16, A.5.18 |
| Incident and availability | CC7.3, CC7.4, A1.2 | A.5.24, A.5.26, A.5.30 |
| Backups | A1.2 | A.8.13 |
| Sub-processors | CC9.2 | A.5.19, A.5.21 |
Sub-processors
Six suppliers handle data for TollRelay. No other company receives customer data. Each supplier publishes its own certifications.
Checked against the code on 4 October 2026. Next review 15 December 2026.
| Sub-processor | What it sees | Where |
|---|---|---|
| Cloudflare | Every request to every TollRelay address, and what is sent back. Runs every service, and is to hold TollRelay's signing keys once they are created. | Global network. Request logs are not yet held to the EU or the US. |
| Neon | All stored data. The central database holds the list of organisations and sellers. The sign-in databases hold people. The EU and US databases hold each organisation's passes, spending limits, spend and receipts. | EU data and the central database in Frankfurt. US data in Virginia. |
| Infisical | Secrets only. It never sees customer data. | EU. |
| Didit | The business check: the organisation's legal identity, its beneficial owners and the sanctions screen. TollRelay keeps the result, never the documents. | EU. |
| Stripe | Subscription and invoice details for a paying organisation or seller: the customer's name, email, billing address and card, which TollRelay never holds itself. | Global. |
| Resend | Every sign-in email: the address it goes to, its subject and body, and whether it was delivered. | EU. |
What none of them see
The private half of an agent's key. It is shown once to the organisation that issues the pass and is not stored anywhere.
Retention
| What is kept | How long | How |
|---|---|---|
| The key that stops a change being applied twice | Used for twenty four hours | Not yet deleted after that. A job to delete expired keys is planned. |
| An emailed sign-in code or link | Five minutes | The sign-in service refuses it after that. |
| A purchase in the history | As long as the organisation | Never edited, and exported from the dashboard. Deleting an organisation and its history is not built yet. |
| A business check | As long as the organisation | Kept as a result and a reference, never a document. |