Trust center

We run StandardOS on StandardOS

The strongest claim a compliance product can make is that its makers trust it with their own compliance. Our ISO 27001 management system, covering scope, risks, controls, audits and reviews, lives inside StandardOS itself. Rather than ask you to take a badge on trust, here is exactly how the service is secured and operated, and how to check the part that matters most without us.

The subprocessor list below last changed on 2026-09-27; everything else on this page is checkable from the links it carries.

Check it without us

Infrastructure & hosting

Availability

Monitored continuously from outside our own infrastructure, and the result is public, including when it is bad.

We would rather you saw an incident here than heard about it from us afterwards.

Live service status

Data residency

All customer data is stored in the EU (Supabase, Ireland region).

We choose EU regions wherever the service touches customer records.

Delivery

Applications are served over TLS 1.2+ only; HSTS enforced.

Static assets via CDN; no customer records at the edge.

Backups

Managed daily backups of the primary database, held in the same EU region, with automated alerting if a scheduled backup does not appear.

A weekly encrypted copy is also held outside the database provider, so a failure of that provider's account does not take every copy with it.

Recovery

Verifiable rather than asserted. Because your compliance records are hash-chained and the daily roots are published, a restored database can be checked against a copy we do not control, which is the same check we hand your auditor.

A restore that had been altered would not match, and we would know rather than assume.

Record integrity, our differentiator

1. Tamper-evident audit trail
Every change to your ISMS records (documents, risks, the SoA, evidence, nonconformities, audits, reviews, and who was granted access) is written to an append-only, hash-chained log.
Read more
Each entry seals the one before it, along with who made the change, so rewriting or reattributing history breaks the chain visibly. Signed-in users hold read-only access to that log at the database level; update and delete are revoked on it even for the service role we run the platform with, so there is no delete path for anyone. Coverage is attached table by table rather than schema-wide: the records listed above are in the chain, and the platform's own operational tables are not.
2. Anchors, at least weekly
Each night we record the head of every chain.
Read more
At least weekly (Monday by default; daily or monthly if your owners choose) we email it to that organization's owners and admins with the count of records added since the last receipt; a week in which the chain did not move brings no mail. Once a receipt is in your mailbox it is on a server we do not run, so a later rewrite would produce a head that no longer matches the one you already hold. The daily roots are also published openly, for anyone to archive. This does not make tampering impossible. It makes it detectable by someone who kept their mail.
The published daily roots
3. Verifiability
Exports carry the hashes and the content they are computed over, plus the exact hashing rule.
Read more
You can recompute the whole chain yourself, in any language, without StandardOS running. The specification and a dependency-free script that does it in about a hundred lines are published, and that script is the one our own CI runs against a real chain on every push. We have not found another tool in this market that lets a customer check the history without trusting the vendor. If you know one, tell us and we will correct this page.
The specification and the script

Access control

Tenant isolation

Row-level security on every table, enforced in the database itself rather than in application code, and tested in CI (pgTAP) on every change.

Authentication

Password sign-in with modern hashing, sign-in via Microsoft and Google, or SAML 2.0 single sign-on through the organization's own identity provider, which an owner sets up on the Security page and can make mandatory for every member.

Sessions are short-lived and refreshed. Anyone can enrol a second factor (TOTP) on their own account, and an owner can require one: for password sign-ins, or for every sign-in regardless of provider. Both requirements are enforced in the database, not in the interface: a session that does not meet them sees no organization data at all.

Our own access

Least-privilege staff roles. Every operator action on a tenant is written to an append-only ledger that we cannot edit or delete, and that the tenant reads on their own Audit trail page, under “Actions by StandardOS staff”.

Which of our staff acted is withheld, because that is our employees' personal data, so the entry says what happened, when, and what it changed. It is append-only rather than hash-chained: the chain and its anchors protect your records, not our access log, and we would rather say which is which.

Development practices

Change control

Every change ships through CI: type checks, tests, database policy tests, and secret scanning on every commit.

Verified outside the product

Every push builds a real hash chain in Postgres, exports it, and re-verifies it with the same dependency-free script we publish, run with plain Node and no StandardOS involved.

A change to the hashing rule that forgot to update the specification fails our build rather than your audit.

Isolation tested in the database

Row-level security is asserted with pgTAP against a live Postgres on every push.

The policies are tested where they are enforced, not reviewed by eye in application code.

Secrets

Scanned in CI and again by a git hook before code leaves a developer machine, with the full repository history scanned clean.

Dependencies

Locked and reviewed; automated vulnerability alerts on the full dependency graph.

AI discipline

AI-assisted output in the product is always a labeled draft until a human confirms it.

The same rule applies to how we build.

Privacy & data protection

GDPR

Danish controller. Our Article 28 data processing agreement is published in full at getstandardos.com/legal/dpa for every customer on every plan, with no signature and no sales call required.

Details of what we process and why are in the Privacy Policy.

No tracking

No analytics or advertising trackers on this site; no cookie banner because there is nothing to consent to.

Diagnostics

Email addresses, IP addresses, record identifiers, cookies and authorization headers are stripped from error reports before they leave our servers.

Configured in code and reviewed on every change, rather than promised in a policy.

Exit

Full one-click export in open formats at any time: during trial, while subscribed, and for 90 days after cancellation.

Lock-in is not a retention strategy.

Subprocessors

Deliberately few. Changes are announced here with prior notice to customers. This list and the one in our Privacy Policy are the same list, rendered twice. Last changed 2026-09-27.

Supabase
Database, authentication, file storage
Processing location: EU (Ireland)
Vercel
Application hosting & delivery; cookieless traffic analytics (no cookies, no cross-site identifiers)
Processing location: EU serving; global CDN for static assets
Sentry
Error monitoring, diagnostics only; email addresses, IP addresses and record identifiers are stripped before events leave our servers
Processing location: EU region (Frankfurt)
Paddle
Merchant of record: checkout, payment, VAT & invoicing (card data never touches our servers)
Processing location: UK, under the EU adequacy decision
Resend
Transactional email
Processing location: EU region

Announced changes

These are decided and announced but not yet in use. Each processes nothing until we switch it on, and this notice comes before that.

ZeroBounce
Announced 2026-09-27, applies once enabled
Email address verification for outreach prospects: a company role address is checked for deliverability before a first letter is sent, so the sending domain is not spent on dead mailboxes and spam traps. Only the address is sent, never a name, and the answer we keep is the service's own status word
Processing location: EU. ZeroBounce states it hosts its servers in the EU and that data sent for processing is transmitted, stored and processed only on servers in the EU, on its own hardware rather than a public cloud, and it offers an EU data processing addendum incorporating the Commission's standard contractual clauses (zerobounce.net/gdpr and its EU DPA, read 2026-09-27). We call the EU-only endpoint api-eu.zerobounce.net, which its documentation describes as the endpoint where validations occur only within the EU; the global endpoint is not used

Responsible disclosure

Found a vulnerability? Tell us at security@getstandardos.com and we'll acknowledge within two business days.

We won't take legal action against good-faith research, we'll keep you informed as we fix, and we credit reporters who want credit. Please avoid accessing other organizations' data. The row-level security should make that impossible, and we'd genuinely like to know if it doesn't.

For a security review

Our data processing agreement is published in full, so there is nothing to request. Anything else a security review needs, questionnaires or architecture detail? Email security@getstandardos.com. Answered within one business day by StandardOS itself, so the answer comes from the code rather than from a brochure.

This page in:Deutsch Français Nederlands Español Dansk