Security

Tenant data — your organisation, RoPAs, DPIAs, evidence files, dossiers, audit log — is stored exclusively in Frankfurt, Germany (eu-central-1). The Postgres database, the object storage bucket, and the auth subsystem are all Supabase-hosted in that region.

Application compute runs on Vercel functions pinned to fra1. No US- or non-EU CDN holds tenant data. Cross-border flows to Germany are conducted under standard data protection clauses with our infrastructure providers, as contemplated by NDPA s.43, and rely on the recognition under NDPA s.41 that the European Economic Area provides an adequate level of protection. We can produce the current clause sets for NDPC submission on request.

Every tenant-scoped table in Klari has an organization_id column and an RLS policy gating SELECT, INSERT, UPDATE, and DELETE on membership of that org. The membership check goes through a SECURITY DEFINER helper so it cannot be tampered with from user-scoped queries.

A two-org cross-tenant harness runs on every CI commit and asserts dozens of isolation invariants: user A cannot read, write, or count rows in org B via any DAL function. The harness has grown to over 50 assertions and is the source of truth for the tenant-isolation contract.

Every state-changing action in Klari writes a row to audit_events through a single chokepoint. UPDATE and DELETE are RLS-denied — the table is append-only by construction. Event types come from a closed enum maintained by migrations; arbitrary string literals fail at write time.

The audit timeline is a first-class product surface: DPOs read it as part of the normal compliance workflow. Each row carries the actor, the resource, the before / after snapshot, the IP and user-agent, and an idempotency key for de-duplication.

Every uploaded file — evidence, DPO appointment letters, generated dossier PDFs — lands in a private Supabase Storage bucket. Browsers never see object URLs; they fetch via signed download URLs with a 15-minute TTL that re-sign on every click.

Path scheme is {organizationId}/{path} for live objects, {organizationId}/_deleted/{ts}/... for soft-deleted ones. Object UPDATE and DELETE are RLS-denied; soft-delete renames via a server-side admin client that re-checks org membership inside the call.

Every state-changing Server Action in Klari calls a single composition: auth check → rate limit → mutation body → audit append. Bypassing it means editing the chokepoint module itself, not slipping a new write past it. The chokepoint is the reason the audit log can't miss an event: if the mutation succeeds, the event is written; if the event fails, the mutation is rolled back.

Rate limiting goes through Upstash Redis (per-user + per-IP keys, sliding window). The service-role Supabase key is server-only and never shipped to the browser.

Every PDF Klari generates — RoPA, DPIA, NDPC submission, DPO appointment letter, CAR dossier — carries two SHA-256 hashes: one over a canonical JSON of the source data (regulator-verifiable from the audit log) and one over the rendered file bytes (recorded in the audit event metadata). The hashes appear on the cover page in grouped hex and again in the footer of every page.

Klari uses a small, EU-resident set of sub-processors:

• Supabase — Postgres, Auth, Storage (Frankfurt, eu-central-1)
• Vercel — application hosting (Frankfurt, fra1)
• Resend — transactional email (Ireland, eu-west-1)
• Upstash — rate-limit cache (Ireland, eu-west-1)
• Cloudflare — DNS + inbound email routing (global, no tenant data)
• Sentry — error monitoring (Frankfurt ingest)

We notify customers of any addition that materially changes data location or category of access at least 14 days in advance. The canonical version-tracked sub-processor list is published in the Trust Centre at /trust/sub-processors with a SHA-256 hash so a customer can verify the exact list in force on any given date.

We aim to acknowledge security reports within one business day at security@klari.ng. For data-breach reporting aligned to the NDPA 72-hour clock, write to privacy@klari.ngand we will route the notification to the customer's DPO of record.

Klari is honest about what is and isn't in place today. The items below are signposted here so an enterprise procurement team can plan around them; nothing is hidden behind a paywall or a "request access" form.

• SOC 2 Type II — target audit window FY2027. We will engage an auditor once a Tier-1 customer requires it and we have a 12-month operations history. The five hardening rules above are designed to map cleanly onto the SOC 2 common criteria.
• ISO 27001 — sequenced after SOC 2. Same evidence base, different standard.
• SAML / OIDC SSO — built when the first customer requires it. Supabase Auth supports SAML on its Pro tier, so this is a low-risk add.
• 2FA / TOTP — same trigger; Supabase Auth supports it.
• Customer-managed encryption keys — will be implemented if a customer requires BYOK as part of contracting.
• Object Lock / WORM evidence storage — interface is in place; AWS S3 with Object Lock is the swap target when a bank-tier customer requires it.
• Penetration test — annual; first engagement scheduled before signing a Tier-1 customer.

If your procurement requires any of these before signing, write to security@klari.ng with your timing and we will discuss a delivery commitment as part of the contract.

Klari publishes its uptime commitment and service-credit schedule in the Trust Centre at /trust/sla. Target availability is 99.5% measured monthly; the credit schedule reaches 25% of monthly fees at the worst tier. The SLA document carries its own version number and SHA-256 hash so a customer can verify the terms in force on any given date.

A standard MSA template is downloadable at /trust/msa. Negotiated counterparts are encouraged for any procurement that requires bespoke terms — write to hello@klari.ng with redlines.