For most of the last decade, data residency was handled in procurement. A clause in the contract said the data would stay in a region, the vendor confirmed it did, and the matter was closed.
That approach has stopped working, and not because anyone decided to be stricter about geography. It stopped working because the newer regulations ask a different question. They are less interested in where a database sits and more interested in whether you could keep operating if your provider could not.
What actually changed
Two European regimes set the tone, and their reach extends well past Europe because they bind the supply chain, not just the regulated entity.
The Digital Operational Resilience Act applied from 17 January 2025, a date set in Article 64 of the regulation itself. DORA's subject is operational resilience in financial services, and a substantial part of it concerns ICT third-party risk — which in practice means your cloud providers and the software you run on them.
NIS2 had a transposition deadline of 17 October 2024, though adoption has been uneven: as of mid-2025, only 14 member states had fully transposed it, with infringement proceedings continuing against others. The uneven rollout is itself a planning problem, because a group operating in several countries faces several timelines for the same obligation.
The important shift in both is from location to continuity. A clause promising data stays in Frankfurt does not answer the question either regulation actually asks, which is what happens to your operations on the day that provider is unavailable, compromised, or legally unable to serve you.
The four questions that replace "where is the data"
| Question | What it is really testing | Where the answer lives |
|---|---|---|
| Where is it processed, not just stored? | Backups, logs, telemetry, support tooling and AI features often leave the region when the primary data does not | Architecture diagrams and vendor sub-processor lists |
| Who can access it, from where? | Support staff and administrators in other jurisdictions are an access path regardless of storage location | Identity and privileged access design |
| What happens if the provider stops? | Exit and continuity, which is the core of the ICT third-party provisions | A tested exit plan, not a clause |
| Can you prove any of this? | Evidence on demand, repeatedly, not once at audit | Logging and control monitoring |
The second row catches more organisations than the first. A European-resident workload administered by a follow-the-sun support team is making cross-border access decisions every night, and that is usually discovered during an audit rather than during design.
Sovereign cloud is a spectrum, not a product
Every major provider now sells something with "sovereign" in the name, and the offerings differ enormously. They sit on a spectrum:
- Regional deployment. Data in-region, operated globally. Satisfies simple residency wording, answers none of the access or continuity questions.
- Operational controls. In-region data plus restrictions on who may administer it and from where, usually with logging of privileged access.
- Legally separated operation. A locally incorporated operator, local staff, local control over keys and support.
- Disconnected or air-gapped. No dependency on the global control plane. Expensive, slow to adopt new features, and genuinely necessary for a narrow set of workloads.
Most organisations need different points on this spectrum for different systems, and the costly mistake is uniformity in either direction. Putting everything at the strictest tier buys latency, cost and a permanent feature lag. Putting everything at the loosest tier means one regulated workload drags the entire estate into scope.
A workable sequence
Start by classifying data by obligation rather than by system. The unit that matters is the obligation — statutory, contractual, or sector-specific — not the application it happens to live in. One ERP commonly holds three different classes of data with three different constraints.
Then map the real processing path for each class, including the parts nobody draws: backup destinations, log aggregation, monitoring, support access, and any AI or analytics feature that sends content to a shared service. These are where residency assumptions usually fail, because they were configured by different teams at different times.
Then decide the tier per class, and write the exit plan for each provider dependency. Not a clause — a plan, with the data format, the timeframe, who executes it, and evidence it has been tested.
Finally, instrument it. The obligations in both DORA and NIS2 are continuous, so a point-in-time assessment has limited value. What is needed is monitoring that tells you when a control has drifted, which is the same capability as posture management and should not be a separate programme.
Key takeaways
- DORA applied from 17 January 2025; NIS2 transposition was due 17 October 2024 but remains uneven across member states.
- Both regimes ask about continuity and third-party dependency, not only about storage location.
- Processing paths — backups, logs, telemetry, support access, AI features — are where residency assumptions usually break.
- Treat sovereign cloud as a spectrum and assign a tier per data class, not per company.
- An exit plan is a tested procedure with a format and a timeframe, not a contract clause.