Adfinia. ← Back to adfinia.com
Legal · Data Residency

Data residency & regions

Version1.0 (draft)
Last updated2026-05-16
Primaryeu-north-1 (Stockholm)
Backupeu-west-1 (Ireland)
This is a working draft, pending external legal review. The current region set and migration paths are operationally accurate as of the last-updated date; jurisdictional descriptions and the Sovereign onboarding sequence are pending review by external counsel and may change before commercial publication. For a residency commitment in writing, write to support@adfinia.com with subject "Residency".

Where your data lives by default

Adfinia operates a single primary region for the demo window and a single backup region in the same regulatory jurisdiction. Sovereignty upgrades pin to a different jurisdiction with documented migration paths.

Every tenant is provisioned to eu-north-1 (Stockholm) as the primary processing region. Encrypted, point-in-time backups replicate to eu-west-1 (Ireland). Both regions are within the EEA, so the default tenancy pattern carries no cross-border-transfer obligation under the GDPR.

Enterprise customers may pin a tenant to a Sovereign region (in-country inference and data plane) at sign-up or via a contractual migration; see §3.

Current region table

Region Role Jurisdiction & framework Available to Status
Stockholm AWS eu-north-1 Primary control plane and data plane Sweden / EEA · GDPR · EU SCCs for any outbound transfer All tiers, all geographies Primary
Ireland AWS eu-west-1 Cross-AZ backup & disaster-recovery target Ireland / EEA · GDPR All tiers (automatic, no opt-in) Backup
Abu Dhabi UAE in-country Sovereign control plane and AI inference UAE · PDPL · in-country processing Enterprise + Sovereign tier Sovereign
Mumbai India in-country Sovereign control plane and AI inference India · DPDP · in-country processing Enterprise + Sovereign tier Sovereign
Riyadh KSA in-country Sovereign control plane and AI inference (via local partner) KSA · SDAIA framework Enterprise on contract Roadmap H2 2026
Nairobi Kenya in-country Sovereign control plane and AI inference Kenya · ODPC framework Enterprise on contract Roadmap H2 2026
Customer cluster On-prem / private cloud Full data plane inside the Customer's own Kubernetes cluster As designated by the Customer Enterprise on contract Sovereign

Pinning is sticky. A Sovereign pin survives all internal operational changes — including failover, maintenance, and minor-version upgrades. Moving a Sovereign tenant back to a multi-region default requires written authorisation from the Customer and a 30-day cooldown, as described in /features/sovereign-ai.

Migrating to a Sovereign region

Customers select the Sovereign region at sign-up or as a contractual upgrade. The migration sequence is:

  1. Order Form. The selected region is recorded on the Order Form. Sovereign is Enterprise-only — pricing and capacity sized to the Customer's contact volume and AI workload.
  2. Provisioning window (typically 4 weeks). We stand up a tenant-isolated control plane in the target region, provision the AI inference service, configure the audit-log destination, and verify zero outbound calls to the default cloud AI provider.
  3. Cutover. Data export from the default region, encrypted transfer to the Sovereign region, validation of row counts and audit logs, and the tenant flag flips. Customer-facing downtime: typically < 30 minutes within the published maintenance window for the relevant region.
  4. Verification. Customer sign-off on a 14-day verification window — every AI invocation must show a destination URL inside the Sovereign region; the platform fails closed otherwise.
  5. 30-day cooldown. The flag is locked for 30 days post-cutover. Reverting requires Customer authorisation and another 30-day cooldown.

During the provisioning window the Customer remains on the default EU region with no service interruption.

What stays in the default region even for a Sovereign tenant

A small number of administrative artefacts continue to be processed in the default EU region even when the data plane is pinned Sovereign, because they are operational to Adfinia rather than to the Customer's processing:

  • Billing records and invoices (Stripe / accounting).
  • Aggregated, de-identified service-level telemetry (uptime, latency histograms; no personal data).
  • Customer-success contact details for the named Adfinia account team.

None of these contain Customer Data uploaded to the platform. If a Customer requires these artefacts to be processed in-country as well, that is a separate contractual conversation under the Sovereign Plus track.

Cross-border transfer mechanisms

Where Personal Data is transferred across borders, Adfinia relies on the transfer mechanism required by the source jurisdiction:

  • From the EEA — EU SCCs (Commission Decision 2021/914), Module 2 or Module 3 as applicable. Set out in the DPA.
  • From the UK — UK IDTA or UK Addendum to the EU SCCs.
  • From India — DPDP Section 16 transfer safeguards; transfers only to non-restricted jurisdictions.
  • From the UAE — PDPL Article 22 mechanisms (adequacy, contractual safeguards, or explicit consent).

The Sovereign tier eliminates outbound cross-border transfer for AI inference and the primary data plane; remaining transfers (billing, telemetry) are minimal and described in §4.

Contact

Residency questions — including written commitments for procurement records — go to support@adfinia.com with subject "Residency". For new region requests, include the workload size, jurisdiction, and the regulatory driver behind the request; we use that to prioritise the roadmap.