Document data residency: what UK and EU buyers should actually verify

This is not legal advice. If you’re subject to UK GDPR, EU GDPR, or other data protection rules, speak to your Data Protection Officer or solicitor about your specific obligations.

When you ask a cloud document-extraction vendor about data residency, you’ll often get a reassuring answer: “Yes, we store data in the EU” or “Yes, UK-only hosting is available.” This feels like a complete answer. It is not.

Data residency is a convenient fiction that hides several uncomfortable truths. Storage location is just one variable. Processing location is another. Backup location. Log location. Who can access the data, and where. A vendor can honestly say “UK-only storage” and still send your documents to a US inference endpoint, store logs in Germany, and back up to Ireland.

Before you sign a document-extraction contract, you need to understand what the vendor actually means.

What “data residency” actually means

Data has many lives. It lands in the vendor’s systems, sits in storage, gets processed (extracted), gets cached or indexed, gets backed up, gets logged, and eventually gets deleted. Each of these stages could happen in different places.

• Storage location: Where files are stored at rest. “We store in the EU” might mean AWS Frankfurt or Google Cloud Belgium.
• Processing location: Where the AI inference runs — where your document is actually sent to be extracted. This could be the same region or completely different. A UK vendor might do all UK storage but send documents to a US model endpoint.
• Backup location: Where redundant copies are kept. Often replicated to a different region for disaster recovery. A vendor storing in Frankfurt might back up to N. Virginia.
• Log location: Where request logs, access logs, error logs are stored. These might contain document metadata or, in careless setups, document snippets.
• Cache or index location: If the vendor caches intermediate results, where are they kept? For how long?

A vendor saying “data residency: EU” could mean any combination of these. It’s a promise about one thing (storage) that feels like a promise about everything else.

Why this matters under UK GDPR

Chapter V of the UK GDPR (Articles 44-50) covers international data transfers. If you’re processing UK residents’ personal data and that data leaves the UK or EEA without an adequacy decision (like UK-US GDPR Adequacy, which doesn’t exist), you need appropriate safeguards.

The appropriate safeguards for B2B SaaS are typically:

• UK IDTA (International Data Transfer Agreement) — for transfers to countries with non-adequate protections.
• EU Standard Contractual Clauses — still the workhorse for EU processors.
• A processor’s binding internal rules (BCRs) — rare for SaaS vendors.

If your documents contain any personal data — names, email addresses, identification numbers, financial details, health information — and they leave UK/EEA without one of these safeguards, you’re exposed.

The UK ICO doesn’t tolerate this. Their guidance is clear: data transfers need a mechanism. Storage location alone doesn’t satisfy Article 44.

What to actually ask the vendor

Forget the marketing claim. Here’s a checklist of real questions:

Storage and processing:

• “Where is my document stored at rest? Which AWS region, or which cloud provider?”
• “Where does the AI inference run? Is the extraction model hosted in the same region, or is it sent elsewhere?”
• “If processing happens outside the UK/EU, what transfer mechanism do you have? UK IDTA? SCCs?”

Backups and logs:

• “Where are backup copies stored? In which region(s)?”
• “Where are request and access logs stored, and what do they contain? File metadata only, or document content?”
• “For how long are logs retained?”

Access and security:

• “Who at your organisation can read my documents? Only engineers on the extraction team, or support staff too?”
• “If support staff can read documents, is that access logged? How?”
• “Are your engineers or support staff in the UK/EU, or US, or elsewhere?”
• “Do you use any documents for AI model training or improvement? Can you guarantee my documents are not used?”

Subprocessors:

• “What subprocessors do you use? Cloud provider, inference endpoint, backup services, log aggregation?”
• “Where are each subprocessor’s systems located?”
• “How much notice do you give if you add a new subprocessor?”

Common gotchas in vendor claims

• “EU data centre” often means EU storage but US inference. The vendor stores the file in Frankfurt (true) but sends it to an OpenAI or Anthropic API endpoint in Virginia to run the model (also true). The story sounds like data stays in the EU. It doesn’t.

• “No training on customer data” might not mean what you think. The vendor might not use your documents in training data, but engineers might still read them during support escalations. “Not used for training” is not the same as “not accessible to humans.”

• “GDPR-compliant” is a marketing claim, not a certification. No vendor is officially GDPR-certified. The ICO doesn’t issue compliance certificates. A vendor saying “we’re GDPR-compliant” is self-assessed. Ask for the Data Processing Addendum (DPA) and read it. Read the subprocessor list. Read the security audit report.

• “Data residency available on Enterprise” is a red flag. If the default is not residency-compliant and they only fix it for Enterprise contracts, it means their architecture doesn’t support it easily. That suggests they might not be serious about it for Enterprise either.

What Beaqua does (with named regions)

Transparency here:

• Default: EU residency. Documents and extraction happen in AWS Frankfurt (EU, Ireland secondary for backups). We don’t send documents to third-party AI endpoints; we run our own models in-region.
• UK-only residency available on Enterprise. Documents and processing both stay in AWS eu-west-2 (London). We back up within the UK region or, if you request EEA-only, to eu-west-1 (Ireland).
• No training on customer documents. Customer documents are never used in our model training or improvement.
• Engineers have role-based access, logged. Support staff can read documents if you ask them to (e.g., during a support incident), and every access is logged with timestamp, user, and reason. You can request access logs.
• Full subprocessor list at /security. Currently: AWS (hosting), Cloudflare (CDN), Anthropic (not used in our current inference pipeline), Stripe (billing), Sentry (error logging — logs contain metadata, not document content), Resend (email).

The regulated industries Beaqua serves — finance, legal, insurance, healthcare — made data residency a table-stake. So we built it in from the start, not added it as a £50k Enterprise add-on.

Before you sign

Ask your potential vendor these questions. Don’t accept “data residency” as a complete answer. Don’t let marketing claims substitute for a DPA and subprocessor list. If a vendor gets defensive or vague, that’s a signal.

For Beaqua customers handling sensitive documents, see our Data Processing Addendum and Security page for the complete picture.