Every claim on this page corresponds to code we run today. Where a control does not yet exist, §06 says so explicitly.
Each card states a control plus the one specific fact about it that you can verify against the source if you become a design partner.
Every audit row carries the hash of the previous row plus its own. Twenty-plus event types — reads, writes, deletes, logins, customer-data access, config changes, flow execution. Append-only by convention: only INSERT and SELECT, never UPDATE. Default retention 7 years (the SOC 2 minimum); auditors don’t wait on us — every tenant queries its own audit history through GET /admin/compliance/audit.
Customer API credentials are encrypted at the application layer with AES-256-GCM. The encryption key is a deployment-held secret, kept outside the database. Plaintext is zeroized on drop. Other data relies on storage-layer encryption — see §04 for the honest two-tier picture.
Every data query is scoped by client_id at the query layer. RBAC middleware extracts the client id from the request path and validates it against the JWT claims before the handler runs — a token issued for tenant A cannot read tenant B’s data even if the path is forged. Logical isolation in a shared database; physical separation available on request.
Per-tenant retention windows in data_retention_policies. A RetentionEnforcer actually runs scheduled purges (interval and batch size both configurable), so retention isn’t just a written policy — it’s enforced. Defaults seeded conservatively; every row is overridable. Full table in §03.
Subject access request (Article 15) exports cases, interactions, emails, voice calls, auto-response log, and audit entries. Erasure (Article 17) anonymizes by SHA-256 hash replacement of email, phone, and name in a single transaction. Both endpoints are SuperAdmin-only and write an audit row of their own.
JWT auth with HS256 (RS256 also supported), default 24-hour expiry, configurable per environment. Audience is configured per environment, not per tenant. Rate limits are configurable per API client and per dashboard user.
Auditors don't have to wait on us to pull a report — every tenant queries its own audit history through GET /admin/compliance/audit.
Six categories shown. Full event taxonomy (~25 types covering data access, identity, configuration, customer-data lifecycle, and security signals) is provided to design partners under NDA.
Defaults are seeded into data_retention_policies on tenant provision. Override any row through the admin API or console; RetentionEnforcer picks up changes on its next run.
Exports the subject's cases, interactions, emails, voice calls, auto-response log entries, and audit trail. SuperAdmin-only. The export itself writes a CustomerDataExported audit row.
Anonymizes by SHA-256 hash replacement of email, phone, and name. Wrapped in a single transaction so a partial failure rolls back. SuperAdmin-only; writes a CustomerDataDeleted audit row.
"Encryption at rest" is the most over-claimed control on every Trust page on the internet. Here are the two tiers we run and exactly which data sits in each.
Rows in client_api_credentials are encrypted in our application before they hit the database. The encryption key is a deployment-held secret — it lives outside the database, not in any column.
Transcripts, recording URLs, email bodies, audit rows, case data — protected by whatever your storage layer provides (database TDE, object-store SSE, etc). Our application doesn’t add a second layer on top.
Most tenants will only touch the default-tier providers. Premium providers are gated by API-key configuration; if a key isn't set, the provider isn't called.
We publish the full subprocessor list — vendors, regions, data-flow diagrams — to design partners under NDA. The shape, in plain prose:
Managed LLM provider with a self-hosted fallback. Active route is a deployment-held config, not a per-tenant choice.
Self-hosted STT and TTS by default. Optional premium SaaS providers for either side, gated by API-key configuration.
OAuth-integrated Google and Microsoft. Customer-provided IMAP/SMTP also supported — that mailbox isn’t our subprocessor in the GDPR sense.
Deployment-managed. Provider choice depends on the engagement; we adapt rather than mandate.
DPA negotiated per engagement during pilot onboarding. Drop a line and we'll send the current draft.
These are the things we deliberately do not claim today. If any of them are blocking for your security review, that's a real conversation worth having before pilot.
No active audit in flight. We’ll say something here when there’s something honest to say.
Customer email, phone, and booking ref are stored in plaintext under audit and transcript surfaces. Configurable redaction is on the roadmap.
TLS is terminated at the deployment layer. We don’t pin a minimum version in application code; the operational answer depends on the reverse proxy your deployment runs.
Two-factor enrolment isn’t surfaced as a verified end-to-end flow today. We’d rather omit it than claim a control we can’t yet point at in full.
Per-user and per-API-client rate limits exist (§01.06). Account lockout after failed logins, IP-bucket rate limiting, and behavioural anomaly detection are not implemented today.
Application-layer encryption uses our deployment-held key. BYOK / KMS-backed customer keys are on the roadmap; not in production today.
No third-party pen test report to share today. When that changes we’ll publish the executive summary here.
Deployed in eu-west today; additional regions on request. Note that egress to LLM, STT and TTS providers can cross regions depending on configuration — operational, not code-grounded.