Everything we do to keep your data safe.

The control program

Certifications and roadmap

SOC 2 Type IIPlanned

Not yet certified. The control program above is designed around the Trust Services Criteria. When the audit observation window opens, we will say so here.

ISO/IEC 27001Planned

Not yet certified. The controls above map to Annex A, referenced under each domain. Certification will follow the SOC 2 work.

InfrastructureCertified

The subprocessors that host and process data on our behalf hold their own SOC 2 Type 2 and ISO 27001 attestations. Each is listed, with its safeguards, on the Subprocessors page.

What we have not done yet

The honest other half of the list. Security you can verify is worth more than security you have to take on faith, so this is where we would rather under-claim.

• ·We are not SOC 2 or ISO 27001 certified. A company that is not audited cannot truthfully say it is SOC 2, and we would rather be precise than borrow the claim.
• ·Independent penetration testing by an external firm is planned alongside the SOC 2 audit, not yet completed.
• ·Formal, third-party-attested management-system documentation is being built toward the audit, rather than finished today.
• ·Operator-only key custody, where not even our own systems can read a slice, is on the roadmap. Today our automated systems decrypt data under an audited background key so your Chief Data Officer can work while you sleep, with every access logged.
• ·Zero-retention terms with our language model providers are a planned upgrade, not a control we hold today. We run on paid API terms that contractually forbid training on our data, and prompts sit in the provider's standard 30-day abuse-monitoring window before deletion. Direct identifiers are stripped from forwarded email bodies, pasted text, and voice transcripts before they are sent. PDFs are a deliberate exemption and go to the vision model as rendered pages: masking a scan before it is read destroys extraction on invoices and estimates, so that content is sent unmasked. We name the exemption rather than implying blanket masking. It is a retention window either way, and we will not describe it as zero.
• ·Column-level encryption is still rolling out per column, which means encrypted columns currently coexist with their plaintext originals rather than having replaced them. Dropping the plaintext is gated on full coverage and happens column by column. Until each cutover completes, that column's defense-in-depth benefit is partial, and we would rather say so than imply the rollout is finished.

The commitments, with numbers

A control program without timelines is a statement of intent. These are the operational commitments we hold ourselves to, taken from the internal policies named beside each one. They are real targets rather than aspirations, which also means we will say plainly where one is not yet proven.

Incident response times

Severity drives the clock. SEV-1, an active breach, data loss, or exposure of operator data, is picked up immediately and within the hour. SEV-2, a suspected but unconfirmed breach, a single-operator outage, or a subprocessor incident touching our data, within four hours. SEV-3, a control failure with no confirmed exploit, within twenty-four hours. SEV-4, a hardening finding, the next business day. Containment comes before investigation in the first hour: we would rather take a feature offline and understand it afterward. Every incident gets a written post-incident review within fourteen days.

Incident Response Runbook

Breach notification

For personal data of EU residents, the supervisory authority is notified within 72 hours of us becoming aware, per GDPR Article 33, and affected individuals without undue delay where the risk to them is high. Under PIPEDA, which governs us in Ontario, there is no fixed hour count: once a real risk of significant harm is determined we report to the Privacy Commissioner and notify affected individuals as soon as feasible, and we keep a record of the breach for 24 months whether or not it was reportable. US residents are notified per the applicable state statute. Affected operators are contacted directly, and a SEV-1 is posted publicly on the status page.

Breach Notification Procedure

Vulnerability disclosure

A report to [email protected] is acknowledged within one hour of disclosure, validated within twenty-four hours, and, if confirmed, patched within seventy-two hours along with notification if any data exposure occurred. We would rather hear it from you than from an incident.

Incident Response Runbook

Key and secret rotation

Every application secret, including database service-role keys, model provider keys, webhook secrets and payment keys, is rotated quarterly as routine hygiene, immediately on any suspected compromise, and on personnel change. Rotation is not conditional on an incident; the quarterly cycle runs regardless.

Encryption and Key Management

Recovery objectives

The database carries a one-hour recovery time objective and a five-minute recovery point objective, backed by continuous point-in-time recovery across a rolling seven-day window. The application carries a four-hour recovery time objective and a one-hour recovery point objective. Separately, a weekly encrypted export leaves the primary provider entirely and lands in a different vendor, a different country, and a different set of credentials, held for ninety days: a backup sharing a failure domain with the primary is not a backup.

Business Continuity Plan

Disaster recovery, and what is not yet proven

The external encrypted backup has been verified end to end: re-downloaded, checksum-matched against its manifest, decrypted with the escrowed key, and restored into a clean database that loaded with every record intact. What that does not yet cover is a full drill into a fresh live environment with formally measured recovery-time and recovery-point figures, which is the step that would close this, and it is scheduled quarterly rather than finished. Until one has run and been logged, treat our recovery objectives as targets rather than as demonstrated figures. Restoring a backup also requires the escrowed encryption keys, because encrypted columns restore as ciphertext; the backup program and the key escrow are a set, and either without the other fails the actual disaster.

Business Continuity Plan

Access review and privileged access

Six roles, each with an explicit capability set, and multi-factor authentication required on the owner role. Sessions expire after thirty days idle. Enterprise customers federate identity through SSO with directory provisioning, so joiners and leavers are driven by their own identity provider rather than by us remembering. Removing a team member invalidates their session on the next request. Every authentication event, including every failure, is written to an audit log and to an external append-only sink, so the record survives even the database it describes.

Access Control Policy

Change management

Any change that touches security or the database schema gets a documented second-pass review the following day rather than shipping on one pair of eyes, and deployment is verified in production within twenty-four hours. Rollback is immediate at the application layer. Database migrations are forward-only, so a reversal is itself a reviewed migration, and a destructive migration requires explicit approval and a verified backup beforehand. An emergency fix may skip the next-day review, and then gets a retroactive one within twenty-four hours of resolution.

Change Management Policy

Deletion, and verifying it reached everywhere

A deletion request is processed within thirty days. Deletion has to hold across backups and processors to mean anything, so backup copies age out on a fixed ninety-day retention with automatic expiry rather than being pruned by hand, and processors that hold content are bound by executed agreements requiring the same. Where a subprocessor agreement is still being executed, our subprocessor page says so on the row rather than leaving the vendor off the list.

Data Retention Schedule · Vendor Risk Management

Encryption, stated by scope rather than in general

In transit: TLS 1.2 at minimum and TLS 1.3 in practice on every external connection, with HTTPS forced by HSTS across all subdomains and no plain HTTP accepted on production. At rest: AES-256 across the database, file storage, and logs. On top of that, the most sensitive personal fields are separately column-encrypted with AES-256-GCM under an encryption key unique to each operator, so a single compromised key does not span operators. Which columns are covered is an explicit registry in the codebase, not a general assurance.

Encryption and Key Management

The detailed control matrix

The full matrix, every control above mapped to its SOC 2 Trust Services Criteria and ISO 27001 Annex A reference with the evidence behind it, is available under NDA to members and prospective members in active evaluation, including as part of a vendor security review. Request it at [email protected].

Related

• ·Data Use Policy. The binding commitment on what we may and may not do with operator data.
• ·Subprocessors. Every third party that processes data on our behalf.
• ·Privacy Notice and Data Subject Request. Your rights and how to exercise them.

Contact

Security questions, control-matrix requests, and vulnerability disclosures: [email protected]. Data-subject and privacy requests: [email protected].