DRAFT — pending legal review
This page is a starting draft written from standard B2B SaaS templates plus Adoomi-specific facts. It has NOT been reviewed by a qualified lawyer or a paid legal-template service. Do not rely on it for compliance until the draft banner is removed. Karim is in the process of engaging counsel (or a service like Termly / iubenda) to sign these off.
Security Overview
How we protect Adoomi customer data
Last updated: 18 May 2026
This page summarises the technical and operational controls Adoomi uses to protect customer data. Compliance certifications referenced here are roadmap items where stated; we’ll update wording once audits complete.
Data residency + isolation
All primary data (accounts, conversations, vector indexes, billing) lives in EU regions by default — Frankfurt for Supabase Postgres + Cloudflare worker compute, Ireland for Stripe + Sentry + Resend (where applicable). A UK regional data plane is provisioned but inactive for current customers. See the sub-processor list for per-vendor regions.
We do not transfer customer data to the United States by default. LLM inference (Claude via Anthropic API, optionally OpenAI) may briefly transit US infrastructure at inference time — these calls do not retain content for training per the providers’ API terms. Customers acting as controllers can review this in our DPA.
Tenant isolation
Every database table that holds customer data has row-level security (RLS) enabled with policies that restrict access by tenant ID. Migrations that introduce a table without RLS are blocked at review time. The chat worker re-validates tenant ownership on every request via short-lived JWTs scoped to the workspace.
Encryption
In transit: TLS 1.2+ for every customer-facing endpoint (dashboard, widget, APIs). HSTS preload pending. Internal service-to-service traffic between Cloudflare workers + Supabase is TLS.
At rest: Supabase Postgres provides AES-256 disk encryption by default. Vercel and Cloudflare object stores encrypt at rest. Secrets (API keys, webhook signing secrets) are stored as Cloudflare Worker secrets / Vercel environment variables, never in the codebase.
Authentication + access control
Customer sign-in uses 6-digit one-time codes via email (passwordless). Codes expire in 60 minutes and are single-use. We removed clickable magic-link URLs from the email body to prevent email-scanner prefetch from consuming the token before the user clicks.
Adoomi staff access to production data uses least-privilege Supabase service roles, with access logged via Supabase audit logs. Staff cannot read conversation content via normal application surfaces; raw-row access is restricted to documented incident response workflows.
Logging + observability
Structured logs ship to Sentry (errors) and Better Stack (application logs). Per repo convention: logs contain IDs and metadata, never message bodies or PII. Every request carries a correlation ID that flows through the chat worker, database, and Sentry breadcrumbs.
Data retention + deletion
Conversation transcripts: configurable per workspace (default 90 days). IP addresses on chat traffic: anonymised after the window you set (default 30 days). Anonymous demo sessions: 24 hours. Account deletion triggers an asynchronous purge worker that removes customer data from primary storage, vector indexes, and downstream sub-processors we control. Workspace owners receive a confirmation email once purge completes.
Backups + disaster recovery
Supabase provides automated daily backups with point-in-time recovery within the standard retention window (Supabase Pro plan: 7 days). Worker code and configuration are versioned in git. Operational runbooks for rollback are documented internally and rehearsed periodically.
Vulnerability management + secure development
Dependency scanning runs continuously via Dependabot. Adversarial code review (via the Codex Review process) is required for changes touching auth, billing, migrations, cron workers, and the chat worker. Pull requests must pass typecheck, lint, unit, and integration tests before merge.
We do not currently hold SOC 2, ISO 27001, or HIPAA certifications. SOC 2 Type II is on the post-PMF roadmap; we’ll publish progress updates on this page as we move through the audit.
Responsible disclosure
If you believe you’ve found a security vulnerability in Adoomi, please report it to security@adoomi.ai. We acknowledge reports within 5 business days and work with reporters in good faith. Please give us reasonable time to remediate before public disclosure. We do not have a paid bug bounty programme today but appreciate responsible reports and will credit reporters in release notes where they wish to be named.
A machine-readable security.txt at the well-known path is a pending follow-up.
Incidents
We’ll notify affected customers without undue delay if we discover a personal data breach that is likely to result in risk to their rights and freedoms (GDPR Art 33-34 obligation). Notification will include the nature of the breach, the categories of data affected, likely consequences, and the measures we’ve taken or propose to take.
Compliance posture
In place today: GDPR-compliant data processing (lawful basis mapping per email path documented internally, opt-out flows in dashboard), EU data residency by default, RLS-enforced tenant isolation, encrypted transport + at rest, structured-logging discipline (no PII in logs), credit-metering and rate-limiting, asynchronous purge worker for deletion.
Roadmap: SOC 2 Type II audit; published security.txt; cookie consent banner; List-Unsubscribe header on transactional email; expanded PII redaction policy across notification outbox.
For specific compliance questions (SOC 2 timeline, audit reports under NDA, customer security questionnaires), email security@adoomi.ai.