We run StandardOS on StandardOS

Infrastructure & hosting

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 every record is hash-chained and the daily roots are published, a restored database can be checked against a copy we do not control — 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

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. 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; there is no delete path for anyone.

Daily anchors

Each night we record the head of every chain, and email it to that organization's owners and admins the following morning (07:00 UTC). 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 →

Verifiability

Exports carry the hashes and the content they are computed over, plus the exact hashing rule. 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 — not in application code — and tested in CI (pgTAP) on every change.

Authentication

Password sign-in with modern hashing, or SSO via Microsoft and Google. Sessions are short-lived and refreshed.

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 — 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, 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 — every customer, every plan, 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-07-28.

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.