Two different questions
When an organisation says it has solved data residency, it almost always means one thing: the data is stored in a specific region, and the cloud provider's regional guarantee covers it. That is a real control and it answers a real question.
It does not answer the second question, which is where the data was accessed from. A dataset can sit entirely within an EU region and be read every day by an operations team in a third country, through a support tool, a shared console, or a break-glass credential. Nothing about the storage location prevents this, and in many architectures nothing records it in a form the compliance function can query.
For GDPR transfer analysis, for Gulf data-localisation regimes, and increasingly for sector-specific supervisory expectations, the access question is the one that determines the answer.
Why the access question is getting harder
Three things have made this worse over the last few years, none of them a security failure.
Distributed teams mean support and engineering functions genuinely span jurisdictions. Managed services mean a provider's staff may touch your environment from wherever that provider operates. And AI systems mean data is increasingly read by processes whose execution location is an implementation detail of someone else's platform.
Each of these is a legitimate operational choice. Together they mean the set of places from which your regulated data is reachable is larger than the set of places you would name if asked, and larger than the set your data protection impact assessment described.
Enforcement and evidence are separate problems
There are two distinct capabilities here and organisations frequently buy one while believing they bought both.
Enforcement means the system refuses access from origins outside an approved set. It is preventive, it is testable, and it is what most people mean when they say geofencing.
Evidence means you can demonstrate, months later, that access from unapproved origins did not occur, or occurred on specific dates for specific reasons that were authorised at the time. It is retrospective, and it is what a supervisor or a data protection authority actually asks for.
Enforcement without evidence leaves you asserting a control worked. Evidence without enforcement leaves you documenting a problem you did not prevent. A residency programme needs both, and the evidence half is usually the one missing, because it requires retaining access-origin records for the full regulatory period rather than a rolling operational window.
Designing residency controls that produce evidence
- Define the approved origin set per data classification level rather than organisation-wide - most organisations legitimately need broader access to low-sensitivity data than to restricted data
- Record every access attempt with its origin and its disposition, including the allowed ones, since proving absence requires a complete record rather than an exception list
- Log the break-glass path explicitly, with the authorising person and the reason, because unplanned cross-border access is a normal operational event and pretending otherwise makes the record less credible, not more
- Retain origin records for the regulatory period applicable to the underlying data, not the retention default of your logging platform
- Make the record independently verifiable, since access-origin evidence is exactly the category a regulator has reason to treat sceptically when the organisation produces it about itself
The Gulf dimension
For organisations expanding into the UAE and Saudi Arabia, the access question is often more consequential than the storage question. Localisation expectations in the region tend to be framed around control and jurisdiction rather than physical location alone, and the practical test a regulator applies is frequently about who can reach the data and from where, not only which datacentre holds it.
Organisations that arrive with a residency story built purely on storage region find the conversation moves somewhere they have not prepared for. Those that arrive with access-origin evidence find it moves quickly. Our jurisdiction-level analysis is in UAE PDPL and the ADGM cyber risk framework and Saudi Arabia's PDPL and SDAIA.
- Ask your team where your most sensitive dataset was accessed from last month, and see how long the answer takes
- Check whether your access records include allowed attempts or only blocked ones
- Confirm the retention period on access-origin data against the retention obligation on the data itself
- Tie the approved origin set to classification level rather than applying one policy everywhere
Origin-based access rules with a per-classification scope and a full record of allowed and blocked attempts are available in ROOTKey now. You can set up a country allowlist on one vault and see the traffic view, or read how the controls fit together on the ROOTKey GDPR page.
Recevez nos analyses sur la cyber-résilience par e-mail
Des conseils pratiques et prêts pour l'audit sur l'intégrité des données, la conformité et la continuité - dès leur publication.