Data regionality in practice: a non-technical guide for boards and regulators

Every board I've sat in front of eventually asks some version of the same question: where's our data, actually? It's usually asked after a procurement challenge, a customer's due-diligence questionnaire, or a headline about someone else's regulator fine. The honest answer is rarely as simple as "the UK" or "the EU," and getting to a real answer, one that would survive a regulator's scrutiny rather than just a board's comfort, means asking a more precise question than most contracts are written to answer.

Regionality is three questions, not one

"Where's our data" is really three separate questions wearing one coat. Where is it stored at rest? Where is it processed, which is often a different country from where it's stored, especially with cloud platforms that route compute to wherever capacity is available? And who can access it, and under what legal basis, including a vendor's support engineers, subprocessors several layers down the supply chain, and anyone with break-glass emergency access? A contract can answer the first question cleanly and be silent or vague on the other two. Most data incidents that end up in front of a regulator involve the second or third question, not the first: data stored in the right country but processed or accessed somewhere the contract didn't clearly anticipate.

What changed under UK law this year

The Data (Use and Access) Act 2025 brought its main data protection reforms into force in February 2026, and one change matters directly for regionality: a reformulated test for international transfers. Where the old approach asked whether a destination country's protections were "essentially equivalent" to the UK's, the new "data protection test" asks whether the standard of protection is "not materially lower" than the UK's own standard. That's a real shift in the analysis, not just different wording, and it applies both to the government's own adequacy decisions about third countries and to the assessment an individual organisation has to make before relying on contractual safeguards like standard contractual clauses for a transfer.

It arrives alongside a visibly harder enforcement posture. The ICO's record fine to date, £14 million against Capita over cybersecurity failures that exposed millions of people's data, and its continuing scrutiny of cookie and international-transfer practices across major UK organisations, are the kind of enforcement actions that get quoted in board packs. The regulatory bar for "we have a data processing agreement on file" as a sufficient answer has moved up, not down.

Contracts describe intent; architecture describes reality

The gap I see most often isn't bad intent, it's drift between what the contract says and what the architecture actually does. A data processing agreement signed two years ago may faithfully describe a subprocessor list that's since changed twice as the vendor scaled or was acquired. A cloud region selected for storage may not constrain where a managed AI or analytics feature within the same platform actually runs its processing, particularly with the newer generation of embedded AI features that some platforms have added without updating the underlying regional guarantees. Reading the contract tells you what was promised. Reading the architecture, and asking the vendor directly where the current subprocessor chain sits, tells you what's actually true today.

The fourth-party layer most contracts miss

Most data processing agreements are written with a clear first party (your organisation) and a clear second party (the vendor). Third parties, the vendor's own subprocessors, usually get a named list in a schedule. What the schedule rarely captures well is the fourth-party layer: the subprocessors of your subprocessors, the specialist infrastructure or AI model providers a platform vendor quietly relies on underneath their own service. A UK-headquartered SaaS vendor with a UK data residency guarantee can still be routing a specific feature, often a newer AI-powered one bolted onto an older platform, through a model provider whose processing happens somewhere the original contract never anticipated. The guarantee at the top of the stack can be entirely accurate and still not describe what's happening two layers down.

This is worth asking about explicitly rather than assuming the headline data residency claim covers everything the platform now does. Vendors add AI features faster than they update their data processing documentation, and a feature enabled by default in a recent release can quietly change where data flows without anyone on your side making an active decision about it.

Where AI adds a second regime to check

For any system that also falls under the EU AI Act's high-risk provisions, data regionality questions don't stand alone; they sit alongside a separate set of obligations about data governance, training data quality and documentation that the AI Act imposes directly. The two regimes ask related but not identical questions: UK and EU data protection law asks where personal data goes and on what legal basis, while AI-specific rules ask additional questions about the data used to train and validate the system itself. A board that's confirmed its data protection position for a system still needs to confirm, separately, that its AI-specific data governance obligations are covered too. Treating one as automatically covering the other is a common and avoidable gap.

What a board actually needs to ask

Board members don't need to become data engineers to ask the right questions, but the questions need to be specific enough that a vague answer is itself informative. For each system handling regulated or sensitive data: where is it stored, where is it processed, and has that changed since the contract was signed? Who has access beyond our own staff, including vendor support and any subprocessors, and under what legal basis? If we needed to demonstrate the current transfer mechanism meets the new UK data protection test, could we produce that evidence today, or would we be reconstructing it under pressure? A board that can get a confident, specific answer to those three questions from its technology leadership is in a materially stronger position than one that receives a reassurance about "GDPR compliance" in general terms, because general reassurance is exactly what regulators have stopped accepting at face value.

Why this belongs on the board agenda now

None of this is really new territory conceptually, but the standard of proof just moved, and the enforcement environment has demonstrated it will use fines that register at board level. The organisations that will handle a due-diligence questionnaire, a regulator's request or a customer's procurement challenge comfortably are the ones that already know the answer to where their data sits, rather than the ones who find out by being asked.

← Back to Insights