Trust

Security, compliance and AI governance

What is implemented today, what is committed at first production tenant, and what is not in place yet. Stated as facts so a procurement review can be answered from this page rather than from an email thread.

Current status

Service stage	Pre-launch. The marketing site is in production; the authenticated platform is in development and holds no client data.
Production tenants	None yet. No client data has been processed on this platform.
What this page describes	The controls implemented in the codebase today and the commitments that apply at first production tenant. Where a control is designed but not yet operating, the row says so.
Independent assurance	None held. No SOC 2, no ISO 27001, no completed penetration test. Controls below are mapped to the SOC 2 CC series; no audit has commenced.

Maintained in docs/deployment.md

Authorisation and tenant isolation

Isolation model	PostgreSQL Row Level Security. Every tenant table has RLS enabled and a deny-by-default policy; access is added per audience, never assumed.
Tenant key	Every tenant row carries org_id, set by database trigger and frozen by trigger. It cannot be supplied or altered by the caller.
Client-side checks	Not used for authorisation. A role value in the interface controls what is displayed, never what is readable.
How isolation is verified	Every table ships with a policy test asserting positive, negative and privileged cases. CI fails a schema change with no matching test, and a cross-org read must return zero rows.
Retrieval isolation	Vector search runs through a SECURITY INVOKER function so row-level policies apply to retrieval itself, not only to the tables behind it.

Maintained in docs/rls.md

Encryption and access

In transit	TLS 1.3, HSTS enabled, HTTP redirected to HTTPS.
At rest	AES-256, provided by Supabase at the storage and database layer.
Database roles	Routine server and Edge code connects as a least-privilege role (job_worker or ledger_writer). service_role is break-glass only.
Secrets	Held in the platform secret store, never in the repository. The JWT signing secret and database password are in no environment file; CI scans every commit for leaked credentials.
Administrative access	Named accounts only, no shared logins. Privileged actions write an append-only audit row at the database, so a new code path cannot bypass the trail.

Maintained in docs/security.md

Subprocessors and data residency

Published list	Every provider touching personal data is listed with purpose, data categories, region and DPA status: Supabase, Vercel, Anthropic, Google, OpenAI, ElevenLabs, Twilio, Meta, Stripe, Razorpay, Resend, Sentry, Axiom, PostHog, Documenso, Cal.com, Wise.
Change notice	The list is versioned and clients are notified before a new subprocessor is added.
Primary data region	Fixed per project at creation and recorded in the contract. Data residency is a contractual claim, and an unrecorded one cannot be honoured.
Model providers	Requests may be processed outside the primary region. Where that is unacceptable for a workload, the model routing for it is restricted in configuration, not by policy statement.

Maintained in docs/compliance.md

AI governance

Training on client data	Not permitted. This is enforced as a provider setting, recorded with the setting name and re-verified quarterly. A provider that cannot offer zero-retention does not receive client data.
Labelling	Every AI-authored external message is labelled as AI in the interface and recorded in the audit log with model, prompt version and cost.
Commitments	No agent can commit to a price, scope or date. The constraint is structural — the write path does not exist — rather than an instruction in a prompt.
Human oversight	Required wherever an output reaches a client or a record. Generated content remains a draft until a named person accepts it, and the acceptance is logged.
Sensitive data	Personal data flagged sensitive is redacted before any third-party model call.
Generated media	Labelled as generated wherever it appears. We do not publish AI-generated imagery depicting real people, clients or events.
Untrusted content	Uploads, inbound messages and scraped pages are treated as data and never enter a system prompt as instructions.
EU AI Act	Transparency obligations for systems interacting with people are met by the labelling above and by voice self-identification. Higher-risk classifications are not currently assessed as applying; this is re-assessed at each phase gate.

Maintained in docs/ai-agents.md

Data protection rights

Regimes	UK and EU GDPR, and India's DPDP Act.
Erasure	Supported, with a documented runbook. Financial records carry a legal retention obligation that overrides erasure; the rest of the subject's data is removed.
Export and portability	Subject data is exportable in a machine-readable format on request.
Consent	Recorded in a consent registry with the basis, the timestamp and the version of what was consented to. Consent is provable, not asserted.
DPA	Available on request and signed before any client data is processed.

Maintained in docs/compliance.md

Retention schedule

Financial records, invoices, ledger	7 years (legal obligation)
Contracts and signature audit trails	Life of contract plus 7 years
Audit log	7 years
Call recordings	12 months, then transcript only
Chat transcripts	24 months from last activity
Anonymous sessions and touchpoints	13 months
Marketing engagement events	24 months
Application logs	90 days
Backups	Point-in-time recovery 7 days; encrypted cold storage 35 days
Enforcement	A scheduled job with a dry-run mode, not intention. Each stored file carries a retention class and every deletion is logged.

Maintained in docs/compliance.md

Incident response

Notification commitment	Affected clients are notified without undue delay and within 72 hours of becoming aware of a personal data breach, per GDPR Article 33 timing.
Process	A documented runbook covering detection, containment, assessment, notification and post-incident review.
Post-incident review	Written for every incident, with the corrective action tracked to completion.
Status	The runbook exists and is rehearsed against restore drills. It has not yet been exercised against a real production incident, because there has not been one.

Maintained in docs/runbooks/incident.md

Availability and recovery

Uptime history	None published. There is no production tenant history to report. Publishing a figure we have not measured would make every other row on this page less credible.
Target at first production tenant	99.9% monthly for the authenticated platform.
Backups	Point-in-time recovery for 7 days; nightly logical dump to encrypted cold storage for 35 days.
Restore testing	Restore drills are run from the documented runbook, which is what makes a backup a recovery.
Database migrations	Run from CI only, never from a workstation, and every migration must be backward compatible with the deployed application.

Maintained in docs/deployment.md

Accessibility

Target conformance	WCAG 2.2 Level AA.
Current status	Not independently audited and no conformance report published. Components are built to the target — keyboard completeness, visible focus, colour never the only signal, named regions — and automated checks run in CI.
Known gaps	No formal audit has been carried out, so gaps found only by assistive-technology testing are unknown rather than absent.
Reporting a barrier	Through the contact route on this site. Accessibility defects are triaged as defects, not as requests.

Maintained in docs/design-system.md

Something here out of date, or a question this page does not answer? Ask, and the answer becomes a row on this page rather than a reply only you can see.