Security
Controls, objectives and the incident record
A security page that lists only certifications is a security page written for procurement. This one lists what is enforced, what the recovery objectives are, and what has gone wrong.
Report a vulnerability to [email protected]. We acknowledge inside one business day and we do not require an NDA to receive a report.
Access
- SAML and OIDC single sign on, SCIM seat provisioning
- Enforced separation of the review seat from the despatch seat
- Least privilege internal access, with a break glass path that is itself audited
Data
- Encryption in transit and at rest
- Consumer identity fields encrypted separately from case history and resolvable only by the seat that opened the case
- Tenant scoped keys, with a sandbox tenant that holds no production data
Change
- Two person review on every change to a control
- Control changes ship in a numbered release and appear on the changelog
- Signed, hash chained exports so a gap in the record is detectable
Operations
- Structured logging with the rule reference carried on the entry
- Backups tested by restore, not by checksum alone
- Recovery objectives published below rather than quoted on request
Objectives
These are commitments, not aspirations. Where an objective is missed, it appears in the incident record below with the duration written down.
- Recovery time objective
- 4 hours
- Recovery point objective
- 15 minutes
- Vulnerability acknowledgement
- 1 business day
- Critical patch window
- 72 hours
- Backup restore test
- Quarterly
- Access review
- Quarterly
Incident record
Every incident that affected a tenant in the last twelve months, including the ones nobody reported. An incident that only we noticed is still an incident.
- Resolved
Export chain verification returned a false negative for tenants created before 4.8.0
Resolved in 4.11.2. No data was affected. Verification for four tenants was reissued.
- Resolved
Elevated latency on document generation, 41 minutes
A queue backlog behind a template compile. No clock was affected because generation is not a clock start event.
- Planned
Scheduled maintenance, 22 minutes, announced 9 days ahead
Region failover exercise. Cancellation holds continued to count during the window.
No incident in this period affected a statutory clock. If one ever does, the affected cases are listed by identifier in the incident entry, because a clock that moved without a rule is the only kind of outage that matters here.
Reporting a vulnerability
Mail [email protected]. Include the affected endpoint or surface, the reproduction steps and the impact you believe it has. We acknowledge inside one business day, we will tell you what we are doing about it, and we will credit you unless you ask us not to.
- Testing against the sandbox tenant is welcome. Testing against another operator's tenant is not.
- Do not access, modify or retain consumer data. If you encounter it, stop and tell us.
- We will not pursue a researcher who follows this policy in good faith.
