Where Does Your WhatsApp Message Data Actually Live?

"Is it hosted in the EU?" is the first question on most procurement forms and the one WhatsApp vendors answer least precisely. The honest answer needs two halves, because there are two separate data planes and only one of them is yours to place.

Plane one: Meta's transport

When a message moves between your business and a customer, it travels through Meta's WhatsApp infrastructure, which is global. Transfers outside the EEA are covered by Standard Contractual Clauses under Meta's terms. This is fixed. It does not vary by Business Solution Provider, it is not something a reseller can configure, and any vendor implying they keep Meta's transport inside Europe is describing their own servers rather than the network the message actually crosses.

It is also transient. Meta is a processor for delivery; the message does not become your system of record until it lands on your side.

Plane two: your application data

Everything downstream of delivery is ordinary application data and can sit in a single EU region:

  • Conversation history and the agent inbox — the full text of every thread, indefinitely.
  • Contact and CDP records — profiles, custom fields, segments, tags, lifecycle state.
  • Consent and opt-out ledger — the evidence you produce when someone asks why you messaged them.
  • Audit trails — who opened which conversation, who exported what, who changed a template.
  • Media, templates, campaign data and backups.

This is the accumulating, auditable, subject-request-bearing dataset. In volume and in risk, it dwarfs the transport leg — which is why placing it well answers most of the questionnaire.

The control plane most people forget

A multi-tenant SaaS platform has a third layer: its own control plane. Even when customer data is stored in an EU region, the orchestration, admin tooling, search indexes, analytics pipelines, log aggregation and support access are frequently global — and support staff in other jurisdictions can often read tenant data to do their jobs. That is a transfer, and it belongs in your records whether or not the marketing page mentions it.

On a single-tenant instance, the application and its database are deployed for you alone, in a region you name. There is no shared control plane spanning other customers, no cross-tenant index, and access is whoever you grant it to. The residency claim becomes a fact about your own deployment rather than a promise about somebody's architecture. The same reasoning applies to the underlying platform — see data residency on Lovable.

What to write in a DPIA or Article 30 record

  1. Name the region and provider for your application data, plus the backup region and retention window.
  2. List the categories held in-region: conversations, contacts, consent, audit, media.
  3. State the Meta transfer explicitly — processing outside the EEA for message delivery, SCCs as the transfer mechanism, referencing Meta's terms.
  4. List every sub-processor that can reach the data, including hosting, any AI provider, and support access.
  5. Describe your access controls and audit trail — who can read conversations, and how that is logged.
  6. Describe deletion, including how it reaches backups; see DSARs and the right to erasure.

The short version

Nobody can move Meta's transport into the EU, and a reviewer who knows the market does not expect you to claim it. What you can control is where the record of the relationship lives, who touches it, and how precisely you can describe that. For the broader framework, read the GDPR position on WhatsApp.

Next step

Apply this to your own deployment

This guide describes decisions we make on live instances. Tell us your channels, systems and region and we will map it to an architecture outline, a provisioning plan and an indicative commercial model — usually within one business day.