//Security

Last updated September 20, 2026

Security and Trust

What we do to protect your data, what we do not claim, and how to get what your procurement process needs.

This page replaces an earlier Security & Compliance statement that claimed things we cannot evidence. Where it touches international transfers it agrees with, and is the shorter form of, International Transfers — both were corrected on the same day and neither asserts a certification any more.

1. What We Do Not Claim

This comes first, because it is the part a security questionnaire actually turns on, and because a trust page that buries it is not a trust page.

  • We do not hold a SOC 2 report. Not Type I, not Type II. An earlier version of this page said "SOC 2 Type II: Audited annually", and we have no audit and no report to give you. If your process requires one, we do not have it today — tell us, because knowing who needs it is how it gets scheduled
  • We are not ISO 27001 certified. An earlier version said this was "planned 2025", which has passed
  • We do not claim end-to-end encryption. An earlier version of this page listed it. Nothing encrypts customer content end to end, and Section 2 states what we do encrypt instead
  • We do not operate a 24-hour security operations center. An earlier version said we did. What we have is automated monitoring and alerting, described in Section 2
  • We do not have just-in-time access provisioning, geographic redundancy of the running service, or automated incident remediation. All three appeared on an earlier version of this page and none of them exists. The service runs in one region; only backups are replicated across regions
  • We do not run a published bug bounty. An earlier version of this page advertised a "Bug Bounty" address, which contradicted our own Vulnerability Disclosure Policy — that document says plainly that we do not run one, and it is the one that is correct
  • We do not assert a Data Privacy Framework certification. A separate page previously stated "Certification Status: Active" for the EU-US DPF, the UK Extension and the Swiss-US DPF. Section 4 states the transfer mechanism we actually rely on

We would rather you found this list here than found it out later. Everything below is meant to be checkable, and where it is not checkable from outside we say so.

2. What Is Actually in Place

Encryption

  • In transit — TLS for every connection to the platform, terminated at our edge
  • At rest — the volumes holding the platform database and its backups are encrypted, and secrets and credentials are encrypted under a managed key service separate from the application
  • Connected-account credentials are encrypted; Integrations and Connected Accounts states that mechanism and its current limits, including where it is weaker than we want

Access control

  • Multi-factor authentication for any account, and an organization can require it of all its members
  • Single sign-on through your own identity provider, SAML or OIDC, with group mapping and an audit record of SSO events
  • Role-based access inside an organization, with administrative functions restricted to administrative roles
  • Passwords are stored as bcrypt hashes. The half of a session-refresh credential we store is itself hashed, so a copy of our database does not yield a usable session
  • Our own password rule is a minimum of eight characters, with no complexity requirement and no setting for an organization to raise it. A questionnaire will ask, so we answer it here
  • Automated provisioning from your directory, so joiners and leavers arrive and depart without a second list to maintain. A directory-driven join goes through the same admission check as an invitation from a person, rather than bypassing it
  • The credential that survives a browser reload is held in a cookie your page's scripts cannot read, scoped to one endpoint

Separation between customers

  • An app we deploy for you gets its own database and its own login, and that login is permitted to open only that database — another customer's app is refused at the connection, not filtered afterwards
  • Inside the platform's own records, data is scoped to the organization that owns it and a request is resolved against the organization you are acting in rather than an ambient default. That scoping is enforced in code rather than by the database, and we are in the middle of moving it onto a stricter footing; we would rather tell you which of the two protections you are relying on than let the stronger one stand for both
  • Untrusted workloads — the build sandboxes that run customer code — are network-isolated from the platform's own services, enforced rather than assumed
  • Where you use a dedicated database, your data is in that database

Every outbound transfer is recorded

This is the control we would point at first, because it is unusual and it is verifiable by you rather than by us.

Data leaving the platform to a third party — an AI model provider, an email or messaging provider, a service you connected — passes through a single gateway that classifies the payload, applies redaction where your policy requires it, checks the destination against the ones your organization has approved, and writes an append-only, hash-chained receipt.

The receipt records what category of data crossed, to which provider, when, what was removed before it left, and whether it succeeded. You can read that ledger; it is not an internal log we describe to you. A regulated customer uses it to demonstrate what left, and a change that introduces an ungoverned outbound call fails our build rather than shipping.

Backups

  • Continuous transaction-log archiving to object storage, replicated to a second region. A log segment is shipped at least every 60 seconds even under no load, so the most work that can be at risk is on the order of a minute
  • A complete copy taken every six hours, kept for about 7 days, with archived logs kept up to 90 days
  • Volume snapshots taken hourly, expiring after 7 days
  • A restore is tested automatically on the first of every month. The test rebuilds the database from the latest backup into a throwaway instance and asserts that the databases, the tables, and real user and organization records all come back. A failure alerts rather than passing silently
  • Backup freshness and job failure both alert into an on-call channel

Two things we would rather state than have you assume. The platform database runs as a single instance — there is no automatic failover, so a hardware loss means restoring from a backup rather than switching over. And because copies are kept for up to 90 days, data you have deleted can still exist inside a backup for that long.

We publish no recovery time objective. No measured figure exists, and a number we had not measured would be a commitment rather than a fact; if you need one, it belongs in an agreement with us.

Monitoring

  • Error and performance monitoring, and infrastructure monitoring, through the providers named in our Subprocessor List
  • Automated scanning of our cloud configuration against security baselines
  • Alerting into an on-call channel, including for backup failures
  • Audit records of administrative actions and access changes, attributed to the actor

Two limitations worth naming rather than leaving you to discover. Where platform staff sign in as a user to support them, that session is not yet distinguished in the audit trail from the user's own actions; we are fixing it, and until we have, treat our audit trail as complete for customer actions and incomplete for ours. And an administrator cannot yet end a member's already-open session from the admin screen — removing someone revokes their access at their next request rather than instantly, so for a suspected compromise, tell us and we will act.

The platform's own edge

  • A content delivery and security layer in front of every hostname, which provides denial-of-service protection and bot mitigation
  • Certificates issued and renewed automatically
  • A machine-readable security contact at /.well-known/security.txt

3. Privacy Regulations

We state these as what we do, not as a certificate:

  • GDPR and UK GDPR — we act as processor for the data you put into the platform and as controller for your account and usage records, and our Data Processing Addendum sets out both, with annexes covering the processing, the security measures, and the subprocessors. Data subject rights are described in Your Data Rights
  • CCPA and CPRA — we do not sell personal data and we do not share it for cross-context behavioral advertising
  • HIPAA — a Business Associate Agreement is a separate instrument and the DPA is not one. Our Subprocessor List marks which providers may receive protected health information. If HIPAA applies to you, speak to us before putting protected health information into the platform
  • FERPA and data about children — the obligations and the configuration both differ; tell us before you start

None of the above is a certification, and we are not going to describe self-assessed compliance as though a third party had confirmed it.

4. International Transfers

We are established in the United States and the platform operates from there, so using it involves a transfer of personal data out of the EEA, the UK, and Switzerland.

The mechanism is the Standard Contractual Clauses, incorporated and completed in our Data Processing Addendum — module selection, the docking clause, governing law and forum, the UK International Data Transfer Addendum for UK transfers, and the Swiss reading for Swiss ones. That document is where the detail lives, and it is the operative one.

An earlier page asserted a Data Privacy Framework certification as the first-named mechanism. We are not relying on it here. If we hold a current certification we will say so on this page, name the independent recourse mechanism, state that we are subject to the enforcement powers of the Federal Trade Commission, and link to the public register entry — because those are the things a participant is required to publish, and a certification claim without them is not one.

5. If Something Goes Wrong

Where a security incident affects personal data we process for you, we will tell you without undue delay and in any event within 48 hours of becoming aware. Notice goes to your organization's administrators and to any security contact you have given us.

The notice will say what we know at the time — what happened, which categories and roughly how many records and people are affected so far as we know, the likely consequences, what we have done or propose to do, and who to talk to. We will not delay a first notice to make it complete, and we will update it as we learn more.

Where you must notify a regulator or the people affected, that assessment and that notification are yours as controller. We will help you make them; we will not make them for you.

6. Reporting a Vulnerability

Send it to [email protected], and read our Vulnerability Disclosure Policy first — it is a real authorization for good-faith research on our own systems, it states what is in and out of scope, and it is explicit that we cannot authorize testing of a customer's application because those are not ours.

On rewards, that policy is the one to trust: we do not run a published bounty with a fixed schedule of payments, and where a report is materially valuable we discuss recognition directly.

7. What We Can Give Your Procurement Team Today

Being specific is more useful than an invitation to "contact us":

  • A completed security questionnaire, answered against this page rather than against an aspiration
  • The Data Processing Addendum, with its annexes, including the technical and organizational measures
  • The subprocessor register, with locations, purposes, and 30 days' notice before a new one starts
  • The outbound-transfer ledger for your own organization, which is the strongest evidence we have and is yours to read. It exports in the shape a health, student-records or European privacy request asks for, across the whole range with no row limit, and it carries an integrity check that reports whether any record was altered or removed and exactly where
  • The result of the most recent monthly restore test
  • A conversation about what you need that we do not have — an audited attestation being the obvious one

What we cannot give you is a SOC 2 report, an ISO 27001 certificate, or a penetration-test report by a third party.

8. Related Documents

Security: [email protected] · Compliance: [email protected] · Privacy: [email protected]