Multi-jurisdiction compliance and data residency

WASSLA LTD operates under UK GDPR (because we are UK-incorporated), EU SCCs (because our infrastructure runs partially in the EU), and Saudi PDPL (because many of our customers serve Arabic-speaking users in Saudi Arabia). This page details our multi-jurisdiction compliance posture.

The current production deployment stores customer data on Supabase Postgres in the ap-northeast-1 (Tokyo) region and runs the application tier (Vercel serverless and Fly.io workers, including the Python voice agent) in Frankfurt, Germany (fra1). Data is encrypted at rest with AES-256 and in transit with TLS 1.3, every staff action is recorded in an immutable audit log, and customer records can be exported or deleted on request within the response window required by each applicable regime. EU-resident, UK-resident, and KSA-resident single-tenant deployments are available as custom engagements for customers with hard region-pinning requirements.

This page explains how the platform meets the practical requirements of all three regimes — UK GDPR / DPA 2018 (data-subject rights, security, cross-border transfer), EU GDPR (via SCCs for transfers out of the EU), and Saudi PDPL Articles 11–22 (lawful processing, security, data-subject rights, and cross-border transfer) — so your privacy team can sign off with full visibility into where data sits.

WASSLA LTD is a private limited company registered in England and Wales (Companies House registration in Mildenhall, Suffolk, UK). Our registered office is at Unit A, 82 James Carter Road, Mildenhall, IP28 7DE. We build and operate Wassla.io — an AI customer-support platform for high-volume customer teams worldwide.

Because WASSLA LTD is UK-incorporated and processes personal data across multiple jurisdictions, our processing is subject to:

  • UK GDPR (the post-Brexit retained version of EU GDPR) + the Data Protection Act 2018 — primary, by virtue of incorporation. Applies to UK-resident data and our internal company data.
  • EU GDPR — via Standard Contractual Clauses (SCCs) for data transfers between our UK legal entity and our Tokyo (Supabase) + Frankfurt (Vercel/Fly) infrastructure, and for any EU-resident end-user data our customers process through the platform.
  • Saudi PDPL (Personal Data Protection Law) — applicable where our customers serve Arabic-speaking users in Saudi Arabia and process Saudi-resident personal data through the platform.
  • Other emerging regimes — added as we expand. The same platform controls (RLS isolation, AES-256, TLS 1.3, append-only audit) carry across all jurisdictions.

The ICO (UK Information Commissioner's Office) is our supervisory authority for UK GDPR; customers and end-users in Saudi Arabia are protected by Saudi's data protection authority for PDPL claims; EU data subjects retain their GDPR rights through the SCC chain.

Where your data lives

Primary regions today

The multi-tenant SaaS deployment runs across two regions. The Supabase Postgres database, storage buckets, and Edge Functions live in ap-northeast-1 (Tokyo). The application tier — React SPA delivered through Vercel's edge, serverless functions, and the Fly.io workers that host the Python LiveKit voice agent and the k6 load-test rig — runs in Frankfurt, Germany (fra1). Voice media routes through LiveKit's nearest point of presence to the caller, with control-plane state living alongside the database.

This split is honest and documented: the database region is Tokyo today, the app tier is in Frankfurt, and no part of the deployment lives in the United States. There is no cross-region replica in the US, no failover that would land your data outside the documented regions, and no developer tooling that pulls production rows to local machines.

Cross-border transfers require a documented legal basis under all three regimes — UK GDPR (via Article 46 transfer mechanisms), EU GDPR (Article 46 SCCs / IDTA from the UK), and Saudi PDPL Article 29. Because the current deployment involves transfer between Tokyo (data tier) and Frankfurt (app tier), and may transfer data through the UK and KSA where Wassla staff and end customers connect from, your transfer assessment should reference the current sub-processor list and the documented Standard Contractual Clauses in our DPA. If you need a region map, a current sub-processor list, or a single-tenant deployment pinned to the EU, UK, KSA, or another jurisdiction to satisfy a regulator, our security team can scope it on request to [email protected].

Sub-processors

A short, audited list of sub-processors handles parts of the workload that we do not run ourselves — Meta (WhatsApp Business API, Instagram), Twilio (SMS and voice fallback), Anthropic and OpenAI (LLM inference), ElevenLabs (voice synthesis), Groq (speech-to-text), and Paddle (billing). The current list, the data each one touches, and our pre-change notification policy live in the Privacy policy and the Data Processing Agreement.

Encryption at rest and in transit

All traffic between your end users, your team's browsers, and the Wassla backend is encrypted in transit using TLS 1.3. The TLS configuration disables weak ciphers and old protocols across every customer-facing endpoint (web app, API, channel webhooks, widget).

Data at rest in our Supabase Postgres database and storage buckets is encrypted with AES-256. Voice recordings and transcripts are written to a private call-recordings storage bucket that has no public read access — every download requires a signed, expiring URL that the backend mints only after verifying the requester is a member of the right workspace. Uploaded knowledge-base files (PDF, DOCX, CSV) sit in the same private storage layer.

Database access is locked down further by Postgres row-level security. Every tenant table carries an RLS policy that pins reads and writes to the caller's workspace, so even a compromised application token cannot pull another tenant's rows. RLS is enforced by the database itself, not by application code, which makes the isolation provable.

The staff audit trail

Every consequential action by a Wassla staff operator or a workspace teammate is recorded in audit_events. The table is append-only — there is no UPDATE or DELETE policy on it, and that constraint applies to owners and platform admins too. Once written, an event cannot be edited or removed.

What lands in the audit log includes team-membership changes, role promotions, channel configuration, billing and plan changes, dual-control approvals, impersonation sessions (which auto-expire after one hour), and every data export or deletion request. Each entry captures the actor's identity, the IP address, the action type, before-and-after values for any change, and a request id you can correlate with backend logs.

Workspace owners and auditors can read the audit log from Settings, Audit log — see the dedicated Read the Wassla audit log guide for how to filter, inspect, and export entries. Auditors and external compliance reviewers typically download a CSV of the filtered view for offline review.

Data export on request

Data-subject access rights apply across all three regimes — UK GDPR Article 15, EU GDPR Article 15, and Saudi PDPL Article 17 — giving data subjects the right to access their personal data in a usable form. Wassla supports this in two ways.

For an individual customer record, open the customer's profile from the inbox, click Export, and the platform emails you a JSON file containing every message, voice transcript, tag, note, and conversation linked to that customer. The export captures the same data the AI agent and your team see, in a structured form your privacy team can hand to the data subject. The step-by-step flow is documented in Delete or export customer data.

For a workspace-wide export — for example during a regulator inquiry or a corporate due-diligence review — email [email protected] with the workspace identifier and the scope of the request. We respond within whichever of the UK GDPR (one calendar month), EU GDPR (one calendar month), or Saudi PDPL (30 days) windows applies to the data subject. The export is delivered as a signed download link that expires after a short window.

Deletion requests follow the same pattern. The customer profile has a Delete action that queues a full erasure; workspace-wide erasure is a [email protected] request. Both paths write a record to the audit log so you can prove the request was honored.

No third-party data sharing

Wassla does not sell, rent, or share your data with third parties for advertising, profiling, or any commercial purpose unrelated to running the platform. The only outbound data flows are to the named sub-processors above, and each one is bound by a written data-processing agreement and operates strictly under our documented instructions.

We do not train shared AI models on your conversations, knowledge base, or customer data. The LLM providers we use (Anthropic, OpenAI) are configured against training on customer inputs, and our contractual terms with them reflect that. If you enable a custom model integration in the future, the same default applies unless your workspace explicitly opts in.

If a sub-processor changes — for example we add a new transcription provider — we notify customers in advance through the updated sub-processor list and an in-app banner, giving you time to object before the change takes effect.

What you can do today

If your privacy review needs more than this page, request a security packet from [email protected]. The packet covers our encryption posture, sub-processor list, vulnerability-management process, and the current DPA with SCC and IDTA terms pre-signed. We respond within two business days under NDA.

You can also tighten the workspace yourself: review who has the owner role (see Wassla team roles and permissions), turn on alerts for sensitive actions in the audit log, and confirm that customer-facing voice agents announce recording at the start of every call.

Future migration to EU residency

Migrating our primary Supabase project from ap-northeast-1 (Tokyo) to eu-central-1 (Frankfurt) is a tracked pre-launch engineering item (see plan.md PRE-LAUNCH-DB-MIGRATE-TO-EU epic). Once complete, all customer data will reside in the EU and the Tokyo + Frankfurt SCC chain will simplify to a single EU residency. Target timing: before customer #1 in the live Paddle phase.