For years, sovereign cloud was basically a data center pin on a map. A vendor would point at Frankfurt or Paris and call it a day. That pitch doesn’t work anymore, and it stopped working fast.
Between late 2024 and late 2025, the EU passed three separate rules that turned sovereignty from a talking point into something organizations now have to prove, on a schedule, with documentation, to a specific regulator. If your compliance team hasn’t fully absorbed what that means yet, you’re not behind. Most haven’t – at least not yet.
Three rules, one direction
DORA came first. Fully applicable to financial entities since January 2025, it requires banks, insurers and their technology suppliers to manage third-party ICT risk with real paperwork behind it: a register of every provider a firm depends on, mapped dependencies, a demonstrated exit plan. Regulators now call out reliance on a single hyperscaler for critical workloads as a concentration risk in its own right. Not a hypothetical – a finding.
NIS2 followed close behind, extending cybersecurity obligations across energy, healthcare, transport and digital infrastructure starting in October 2024. It goes further than most rules before it: management is personally accountable, the obligations reach through an organization’s entire supply chain instead of stopping at the primary vendor, and incidents have to be reported within 24 hours. Twenty-four hours isn’t enough time to reconstruct who had access to what after something goes wrong. That has to already be known.
Then, in October 2025, the European Commission published something with real teeth: the Cloud Sovereignty Framework. Eight named Sovereignty Objectives, each scored on a five-level scale, rolled into a single weighted score out of 100. This isn’t theoretical, either. The Commission is already using it, backed by a €180 million tender for sovereign cloud services. One of those eight objectives, Legal and Jurisdictional Sovereignty, scores a provider specifically on exposure to foreign legal reach, including the U.S. CLOUD Act. A provider can run a beautiful EU region and still score poorly here, because the framework cares about who can be legally compelled to produce the data, not where the servers happen to sit.
Why "where the data sits" stopped being the right answer
Schrems II already settled this for anyone still leaning on standard contractual clauses alone. A data processing agreement doesn’t override a foreign government’s legal reach into its own companies. If a provider is headquartered in the United States, the CLOUD Act follows that provider’s corporate structure, not the address of the data center it runs in Frankfurt. A real Transfer Impact Assessment has to document that exposure, along with the specific technical measures in place to offset it. Not assert it away in a contract clause and move on.
DORA and NIS2 push in the same direction from a different angle. They don’t really ask where data lives. They ask whether you can produce evidence: a documented provider registry, an exit procedure that’s actually been tested, an audit trail that’s ready before the regulator asks for it. A pin on a map was never going to satisfy an auditor asking for a signed key management architecture and a monitoring commitment.
The part most compliance programs still miss
Every one of these frameworks eventually arrives at the same question, even when it doesn’t use the word "identity" to ask it. NIS2’s 24-hour reporting clock only works if access logs already exist in a form someone can search under pressure. DORA’s ICT risk management pillar explicitly covers access controls as part of third-party risk, not as a separate workstream bolted on later. And the Cloud Sovereignty Framework’s jurisdictional scoring doesn’t stop at storage. An identity provider hosted outside the EU, governing access to data that itself never left the country, is exactly the kind of gap the framework was built to catch.
That’s the piece a lot of sovereignty planning still leaves out. An organization can pass every storage and residency requirement on this list and still fail an audit, because the system deciding who gets into that data sits somewhere the framework doesn’t recognize as sovereign.
What this actually means for procurement
Evaluating a vendor against this stack now means asking for evidence rather than a location. In practice, that means asking for:
-
A documented ICT third-party register with mapped dependencies and a tested exit procedure, for DORA
-
Incident reporting workflows that can meet a 24-hour window, including who had access and when, for NIS2
-
A Transfer Impact Assessment covering the specific technical measures that offset CLOUD Act or FISA exposure, not just a signed SCC
-
In-region key custody (ideally customer-managed) with hardware security module records available on request
-
A straight answer on where the identity and access management layer is hosted, and under whose legal authority it operates – not just the data
None of this is theoretical anymore. It’s what a Cloud Sovereignty Framework scoring exercise or a DORA audit actually asks for, in writing.
A cloud region in the right country doesn’t pass a sovereignty audit on its own. The identity system governing who can reach that data has to pass the same test.
Where identity fits
This is the argument One Identity makes with its on-premises product line: governance, privileged access and directory administration that run entirely on infrastructure an organization owns, inside the same jurisdiction as the data itself, without falling behind the capability a cloud-first product gets. For a compliance team building the evidence file this stack now requires, that’s not a nice-to-have. It’s the difference between a sovereignty score that holds up under a real audit and one that doesn’t.
Three products carry that argument, and each one closes a specific gap in the evidence file:
-
Identity Manager by One Identity governs who has access to what, with risk-based decisions that reflect real behavior rather than an assigned role, continuous certification instead of an annual scramble, and one governance model across cloud and on-premises so there’s a single evidence trail to hand a regulator.
-
Safeguard by One Identity controls privileged access for human and non-human identities (NHI’s), and AI agents alike, granting it just-in-time and revoking it the moment a task ends, with session activity recorded down to the keystroke and every trail cryptographically signed and audit-ready on demand.
-
Active Roles by One Identity, simple governance for Microsoft environments, cleans up the identity sprawl across Active Directory, Entra ID, and Microsoft 365 that most sovereignty conversations skip past, enforcing policy the moment it matters instead of chasing it down after, from one console instead of a different tool for every domain.
And they’re not siloed from each other, either. Active Roles keeps the Microsoft directory clean and current. Identity Manager governs access on top of that same directory, plus everything else across the environment. Safeguard secures the privileged accounts both of them depend on to do their jobs. An auditor pulling evidence for a DORA or NIS2 review isn’t stitching together exports from three unrelated tools. It’s one connected system, with one audit trail, across every layer this compliance stack actually checks.
Download this eBook for a more detailed walkthrough.
