Security

1. Platform architecture

• Hosting & data residency: your data — the Postgres database, authentication, file storage, and the Edge Functions that run KlarvoEngine — is hosted in the EU, in Frankfurt, Germany (Supabase, AWS eu-central-1). It does not leave the EU in the course of normal operation. The marketing and app front-ends are static assets served from Cloudflare's global edge; they hold no customer data. (Klarvo's legal entity is UK-incorporated — see About — but your compliance data lives in the EU.)
• Tenancy: single shared database with row-level security on every table. Cross-organisation reads are not possible — RLS is the floor, not a UI convention.
• Auth: Supabase Auth with email-password and OAuth flows; PKCE for the SPA; bearer tokens for the WordPress widget endpoints.

2. Data protection

• In transit: TLS 1.2+ everywhere. HSTS on klarvo.io and app.klarvo.io.
• At rest: AES-256 on the database and storage layer (provider-managed keys).
• Evidence storage: private bucket, no direct public links. Access flows through an Edge Function with an RLS-equivalent check on every request.
• Secrets: never in client code or git. Supabase Edge secret store + GitHub Actions secrets only.

3. Access control

• Least-privilege roles for staff. Production database access is broken-glass only and audit-logged.
• Five-role permission model inside the product (admin, compliance owner, system owner, reviewer, viewer).
• Reviewer-role approvals route through SECURITY DEFINER RPCs, not direct table writes.

4. Engineering practices

• Single-PR-per-phase build with a hard gate: typecheck, lint, unit tests, end-to-end tests, branding grep, secret-shape check.
• Automated dependency scanning on every PR.
• Migration-driven schema changes; no out-of-band SQL.
• Code review on every change to billing, auth, RLS, or the engine handler.

5. Audit & retention

• Every meaningful action writes an immutable audit-log row pinned to the actor (Article 12 / 13 / 30 GDPR support).
• Audit logs retained 12 months in identifiable form, pseudonymised at 12 months, hard-deleted at 7 years.
• Stripe webhook events written to a separate idempotency ledger so billing actions are independently verifiable.

6. Sub-processors

See the DPA for the current list and the SCC mechanisms used for transfers outside the EEA.

7. Incident response

Suspected incidents are triaged, contained, and investigated by the founder. Affected customers are notified within 72 hours of awareness per GDPR Article 33 / 34. A post-incident report is shared on request and a remediation plan is logged.

8. Responsible disclosure

If you find a security vulnerability, please email hello@klarvo.io with the details. We commit to:

• Acknowledging your report within 2 working days.
• A status update within 7 working days.
• Not pursuing legal action against good-faith researchers who don't degrade the service, don't access data they shouldn't, and don't publicly disclose before we've remediated.

We are happy to credit researchers publicly with their consent.

9. Status

Service status is currently communicated by email and via the in-app banner. A public status page is planned post-launch.