The Cloud and AI Development Act, CADA, proposed in June, would require European public bodies in the categories it singles out to buy cloud at a recognised assurance level set by a risk assessment. How that assessment should be done is not in the proposal. It is left to follow-up rules that do not exist yet.
The Cloud Sovereignty Framework the Commission published in October 2025 leaves the same gap. It runs to six pages, defines eight sovereignty objectives, and grades a tenderer’s cloud services on each using Sovereignty Effectiveness Assurance Levels, from SEAL-0 (“No Sovereignty”) to SEAL-4 (“Full Digital Sovereignty”). The buyer sets a minimum level for each objective. Miss one, and the tender does not qualify. The framework never says how a buyer is to arrive at the minimums. It is already in use: in April 2026 the Commission awarded the first contracts assessed under it, grading three bidders building their own technology at SEAL-3 and a fourth, whose service runs on Google Cloud technology, at SEAL-2.
In those six pages, exactly one sentence concerns which of the buyer’s own systems can go where. It says the results “may also be used”, by the buyer’s own technical services during the contracts that come out of the same tender, “to determine the nature of systems that can be deployed at a specific provider, different risk profiles requiring different assurance levels”. That is the whole of it, and it presupposes the risk profiles already exist.
Meanwhile the labelling goes on. Across Europe, organisations are sorting their applications into “sovereign” and “standard”, one row at a time, and filing the result. The file records what each application is, never what it stands on.
What the file misses shows up the first time a boundary closes.
What breaks when you disconnect, and how fast
At 02:00 the order is to close the sovereign zone, as a drill or for real. Every trade has a name for that state: enterprise IT calls it restrictive mode, power and industrial control call it island mode, and classified work runs air-gapped. In restrictive mode, nothing new crosses the boundary in either direction unless a rule allows it, and the sessions already open drain out on their own. For one application, the question is whether it keeps running. For a portfolio, it is how many of the applications you classified sovereign stop anyway, because something they depend on is outside the boundary you just closed.
Take a case-processing system, classified sovereign, its servers inside the zone. Its users sign in through the organisation’s identity platform, which also sits inside the zone, but that platform doesn’t make the final sign-in decision itself. It brokers that decision out to a cloud tenant, an account with an outside provider, and that tenant issues the tokens. The setup dates from 2021, and it is ordinary: brokering sign-in to a cloud identity service has been the default enterprise pattern for a decade.
Each signed-in session carries a token good for about an hour, and every refresh goes back through the tenant. At 02:00 the zone goes restrictive. No one already working loses anything at first, and their sessions hold while the tokens last. Each client that tries to refresh fails. Some sessions drop inside the hour. Others hold longer on a session cookie that outlives the token, and a few hold until the user closes the browser. Fresh sign-ins never start. By the morning shift, nobody can get into the case system, and the failures arrived over several hours instead of all at once. It was classified sovereign, and so was the identity platform, and both were right. The dependency on the tenant was no secret either. It sits in the platform’s configuration, in an egress rule, on an invoice somebody pays every month. None of those is a place the classification reads, and the form never asked.
An operator will object that the real mistake was the brokering: an identity platform that hands its sign-in decision to a tenant outside the boundary was never going to survive being cut off. Correct, and nothing in the classification would have surfaced it. An architecture diagram shows one box labelled “identity platform”. Whether that box holds up when the zone closes comes down to a configuration choice the classification never asked about. And 02:00 is the expensive place to find it: the diagnosis takes an hour, but the fix is an identity migration, and under a real cut you run without sign-in for the weeks that takes. The drill exists to move that discovery to a Tuesday afternoon.
The token is only one clock among many. Most of what an application borrows from across a boundary is held on a lease: it gets to keep using what it already has, a ticket, a licence, a cached DNS answer, without asking again for a while. Call the dependency behind each of these a crossing, an edge with one end inside the boundary and one end outside. When a boundary closes, every crossing is cut at the same moment. Only the applications that call out in real time fail at once. The rest keep running on what they borrowed, minutes on one clock, weeks or months on another.
So run the same night forward. A records system in the same zone never noticed the cut: its licence check calls a server outside the boundary, but the vendor built in an offline grace period, and nothing happened at 02:00, or that week, or that month. Six weeks on, the grace period runs out, the system drops to read-only, and the ticket says licence problem. Nobody connects it to a boundary change six weeks old. The system failed for the same reason the case system did, on a slower clock.
Vendors document the grace period. The gap it opens between the change and the failure appears in no manual. Every crossing raises two questions the classification never asks. Who holds authority at the far end? And if it is cut, how long until something stops? For the sign-in, straight away. For the licence, six weeks. The first question is at least familiar. The second decides whether anyone will connect the failure to the cause.
Put both to whoever sells you the next service as sovereign. Data residency answers neither, which is how everything you run can sit in-country and still fail both.
After the cut, every stopped application resolves to one of three findings: a crossing that was known, a label that was wrong, or, as with the case system, a correct label with a dependency underneath it that no one had connected to the label. One surprise is enough to show the inventory was wrong, and the count tells you how badly. In most portfolios the third case will be the common one.
Spreadsheet sovereignty
Sovereignty used to cover everything an organisation ran. It all sat behind one boundary, the way classified systems still do, and the boundary was a fact of the infrastructure. The new instruments land differently: an assurance level per procurement, a sovereignty grade per service. Few can afford that isolation across an entire portfolio, so the requirement concentrates on the systems that must hold, standing in the middle of everything else. The moment the sovereign boundary is smaller than the whole, every dependency chain that wanders across it becomes a crossing. A per-system requirement gets a per-system answer, and that answer is a classification column.
The classifying is necessary. You need to know what data each application holds, because every placement decision downstream depends on it. The mistake is treating the label as the answer.
Call it spreadsheet sovereignty: taking sovereignty as a property of the application alone, something you assign once and file. An application’s real sovereignty depends on everything it stands on, and any one of those can break the label.
Per-application classification always completes, because the form only asks questions that can be answered from the application alone. What data it holds and who uses it can be read at a desk. What it stands on, what stands on it, and how they connect can’t be. The spreadsheet has a row for each application because each application has an owner: somebody pays for it, patches it and answers for it. A connection between two systems has no owner, so it was never anybody’s job to write one down. Where a form does ask for integrations, it gets what the owner remembers, which is a different thing from what the traffic shows. So every application gets a label, the spreadsheet has no empty cells, and the steering group sees green. Nothing was skipped. The people who built that spreadsheet did the job they were asked to do. It looks finished, right up until someone runs a dependency trace: start from one application, follow what it stands on, then what those stand on, until every chain ends inside the boundary or crosses it.
Here is a claim I am prepared to be professionally embarrassed by: I doubt any ordinary application portfolio above roughly two hundred applications has a classification that would hold up against a dependency trace. I can’t prove it. If your portfolio is the counterexample, I want to hear about it.
Hasn’t someone done this already?
Yes, mostly. Regulators, vendors and migration teams have each built a piece of it. None of them holds the two answers, recorded together for each crossing.
My background is datacentre exits and platform migrations, portfolios of several hundred applications at a time. In January I argued that sovereignty is an operating capability rather than a location claim, in “Sovereignty Is a Control Boundary, Not a Location”; this piece is about the map underneath.
The frameworks grade the service; the vendor guidance sorts the workloads. EUCS, the EU’s draft certification scheme, grades cloud services. It is still unadopted, and still contested, the argument being whether sovereignty requirements belong in a certification scheme at all. France’s SecNumCloud qualifies service offerings. Microsoft’s sovereign-cloud documentation tells you to “assess workloads individually”, by data sensitivity and criticality. SUSE’s June “Application Trust Hierarchy” sorts applications into four tiers and maps each tier to a SEAL level. Microsoft’s guidance and SUSE’s tiers are reasonable answers to a question the regulators left open, and I have recommended versions of them myself. Neither grades an application by what it reaches for while it runs.
DORA, the EU’s digital-resilience regulation for financial firms, comes closest, twice. Financial entities keep a register of information on their ICT contractual arrangements. The template records the provider’s headquarters, the country the service is provided from, the governing law and where the data sits. Separately, they map their assets and what depends on what. Article 28(8) goes further. Any service supporting a critical or important function needs an exit strategy, the exit plan has to be written down and tested, and how much testing counts as enough scales with the entity’s size and risk profile. But exit testing asks whether you can leave a provider. The question here is what still runs when the boundary closes and nobody is leaving anything. In practice someone assembles the register from the contracts and draws the map at a desk, and nobody routinely checks either against the actual traffic. The register’s rows follow the contracts, so a token refresh has no row to live in. NIS2, the EU’s wider cybersecurity directive, obliges essential entities to manage supply-chain risk; it too asks neither who holds authority at the far end nor how long an application runs without it.
GDPR transfer impact assessments already carry the jurisdiction question. Since Schrems II, if you send personal data out of the EEA on standard contractual clauses or another Article 46 transfer tool, you have to assess, transfer by transfer, whether the law and practice at the far end let those clauses hold. Adequacy decisions lift that duty for some destinations, the United States included, for recipients certified under the Data Privacy Framework. That is the authority question, and where the duty applies it’s already law. It covers personal data and nothing else. It is built from records of processing and legal analysis, not from watching what the systems do.
Migration programmes already draw the graph. If you have ever moved a datacentre or carved a business unit out of a group, you drew this map to plan the work, and a well-kept configuration database holds much of it. I have built those maps. They answer a different question: what must move together, and in what order.
One authority has already made the demand outright. NSM, Norway’s national security authority, wrote in 2023 that if a service needs national control, every layer of it has to be operated by personnel working in Norway, and that it is not sufficient for the machines to stand in Norway. By operated NSM means the access rights: read, write and system rights on each layer, held by whoever does the patching, configuration and access management. Those rights work from anywhere. They can read, change or stop the service, and personnel exercising them from abroad answer to another state’s law. Buy the service rather than run it yourself, and the operating rights on the layers underneath can sit abroad. Run it yourself and the exposure narrows but does not close: the software on each layer is still written and updated by its vendor, and support cases still go to the vendor’s engineers. Checking one platform’s layers is a short exercise: however many applications sit on it, the virtualisation layer underneath is one fact, checked once. What NSM leaves open is the portfolio half: which stacks each application in a whole portfolio actually touches, because every crossing an application makes puts it on somebody else’s layers as well. That mapping is what this piece is for. A management session from another country is a crossing, sitting plainly in the flow logs. The duty roster behind it never appears in the traffic; that part is settled in contracts.
So the jurisdiction column is not the new part. Nor is the clock, quite. Business impact analysis has kept a clock for twenty years; ISO 22301 calls it maximum tolerable period of disruption. But that is one clock per business process, and it measures how long you can stand the outage, not how long the outage takes to arrive. I cannot find the two answers written down together for each crossing: who holds authority at the far end, and how long the application keeps running without it. The nearest academic neighbour I have found is a preprint from June. It argues that digital sovereignty qualifies as an architectural quality attribute, and it proposes composite ratios for vendor lock-in and foreign-jurisdiction reach. Even time-to-migrate, it concedes, is hard to assess in practice.
The traffic is the test
A flow in the boundary logs settles the question in one direction: the crossing exists, whatever the inventory says. The absence of a flow settles nothing. Licence checks fire monthly, certificate renewals a few times a year, and a failover path carries nothing until the day it is needed. A crossing can be real and send no traffic for months.
A dependency audit therefore needs three things. Flow logs at the boundary, together with the egress proxy’s own access logs, catch the active crossings. Reading egress rules, proxy configs and licence documentation lists the declared ones. Drills catch the dormant ones: pull the plug and watch what breaks. Scope the cut to one crossing or one application, with a bounded window and the rollback ready. Cutting a licence crossing spends its grace period, so that one is budgeted, not repeated. Logs and drills both end in observed traffic. A declaration on its own clears nothing. To attribute a flow to an application you need a first-cut inventory, and that is the same inventory whose gaps you are testing. So you go round more than once. Raw endpoints first, better attribution each round.
The flow logs have to cover a full business cycle, a quarter at minimum and a year if you run year-end batches. And if the flow collector sits outside the zone, restrictive mode cuts the feed for exactly the window you are trying to record. Keep the collector inside.
It’s fair to ask whether this is zero-trust segmentation governance with a sovereign label on it. The mechanics are shared; what differs is which boundary you’re watching. A network zone boundary, a control boundary and a jurisdiction are three different objects. A vendor appliance managed from another jurisdiction sits inside the network zone and outside the control boundary. Replicate to a standby site in another country and the traffic stays inside your network the whole way, while the copy in the other country sits under another state’s law. Zone governance can log both; nothing in it flags the jurisdiction question, because a GeoIP lookup reads where the far end sits, not who has authority over it.
The closest working model for what to do next sits in mergers and acquisitions, M&A. When a company divests a business unit, the separation trips on the same mechanism: entanglements, systems that looked self-contained turning out to lean on parent-owned identity, core business systems and licensing. The separation is never complete by closing, so the buyer pays the parent to keep each remaining dependency running under a contract with a named owner, a price and an expiry date. The M&A world calls these transition service agreements, TSAs, and carve-out practice has priced the discipline in real deals for years.
A register of crossings does for jurisdiction what a TSA does for ownership: every chain traced to where it ends, and each crossing recorded with who holds authority at the far end. A TSA has two things the register lacks: a price, and an expiry with teeth. When a TSA expires the parent switches the service off, while a register entry that expires does nothing until someone acts on it. A TSA makes a dependency visible to a CFO, which is why it gets exited. The register has no lever like that, and no closing date to force the tracing to finish. The rest of the form copies straight over: a named owner and an expiry date on every entry, and numbers that go to whoever signs off the zone.
Some crossings will never terminate inside the boundary: vendor patch and update supply, threat intelligence, and public certificate trust for anything facing the outside world. Time synchronisation is the cheap exception: a domestic time source exists and pointing at it is a configuration change. Revocation for public certificate trust stays with the certificate authority; the most you can do is cache the revocation lists and status responses inside the boundary. For the rest the answer is contractual and operator-side, carried in the register as named exceptions.
Two numbers for the steering group
First agree what counts as one crossing: one system of yours talking to one service at the far end. However many addresses and proxies it hides behind, whichever way the traffic runs, it is one line in the register.
Then give each line an effect grade and a clock. The effect of cutting it: blocking, like the sign-in; degrading, like an address lookup that falls back to manual entry; cosmetic, like a font fetched from outside, where the page swaps in a plainer one and nothing stops. The clock is how long until the first thing stops: fresh sign-ins fail at 02:00, the licence holds six weeks. Authority at the far end, whose law the operator answers to, is its own column. The clock sets what to fix first, because the crossings with the shortest clocks are the ones that fail on the night.
The two numbers come from the register as a whole. The first number is unresolved blocking crossings, counted once each, target zero. Resolved means one of two things: the dependency now terminates inside the boundary, so it is no longer a crossing, or it stands as a named, accepted exception with an expiry date. Keep crossings-per-application as a second view of the same data, because it shows the blast radius of the shared crossings, but do not steer on it: it counts transitively, so one crossing on a shared identity platform lands on every application above it, and a single platform fix moves four hundred applications at once. The fix is real, but it is one fix, counted four hundred times.
The second number is the unexplained share. These are the flows nobody can yet account for. A well-run zone has already authorised most of its flows, but authorisation only records permission. To account for a flow, someone has to know its purpose and what breaks if it stops. Expect this number to rise before it falls: every newly captured flow arrives unexplained, so honest deeper inspection in month four looks like regression, the same way the vulnerability count jumps the first time a better scanner runs. Weak capture flatters you. Unwarned, the rise will be read as failure at exactly the point it is working. Once capture has settled, what matters is its direction. It has no target.
Together they are what a steering group actually holds: the unexplained share is the case for keeping the tracing funded, and the exceptions behind the first number are the risks it accepts by name.
Both can be gamed, so the register needs its own checks. Risk acceptances expire and carry a named owner. An exception that outlives its expiry counts as unresolved again and goes back into the first number. Moving an application out of the zone is reviewed by name, because pushing your worst application across the boundary improves both numbers without a single crossing being fixed. A falling crossing count alongside rising proxy traffic means the flows have moved behind a proxy whose logs you do not collect. And explanations are sampled and challenged by someone who did not write them. How many fail the challenge gets reported alongside the unexplained share.
What the numbers cannot see
The two numbers are built from traffic, and your capture stops at the edge of your own networks. Below them sits the provider’s infrastructure: the physical datacentres and the lines between them, the hardware and its firmware, the virtualisation layer your machines run on, the storage your data sits on, and the management network its staff work through. Two things happen in that stack that matter for sovereignty. The provider copies your data between its own sites for redundancy, and that copying runs on the provider’s network, so if one of those sites answers to another country’s law, your data crosses a border without a packet showing in your logs. And the provider’s administrators work through the provider’s own network, so their access never shows in your logs either. Two more things never appear as traffic at all: who holds the encryption keys, and what the contract lets the provider do. None of this can be found by watching the boundary. It is governed by choosing the supplier, writing the contract and reading the audits. The two numbers measure your dependencies. The provider underneath them has to be governed another way.
Neither number is the size of the sovereign zone. Law, the data involved and whatever national control is required decide what sits in it. The numbers tell you whether the boundary around it is real.
The map and the terrain
The dependency map is the part nobody wants to fund when no deadline forces it. It’s slow, it produces nothing you can demo, and its raw material is an owner spreadsheet last saved years ago, full of people who have since left. Zone design takes weeks; the tracing takes months. But the zone design, the policy, the attestation, everything above the map, is only as true as the map underneath.
The map is what you believe the portfolio stands on. The terrain is what it actually reaches for while it runs, and the terrain shifts: vendors flip defaults, integrations get built, a platform quietly changes how it signs people in. However good the map was the day it was drawn, the traffic is the only live view of the terrain.
If you recently came through a datacentre migration, you have a head start. Somebody traced most of these crossings when they planned the waves, and the discovery data is still sitting there. That data is a list of addresses your systems talk to. It does not say what is behind each address: which company runs the service, and which country’s law that company answers to. Somebody has to look that up, address by address, before the list becomes a register. The data has also been going stale since cutover. But it beats starting blank by months. Keep the flow logs running and it stays current instead of decaying into the next stale spreadsheet.
Buying your way out does not work. A discovery product, an external assessment, lately an AI that promises to read your systems for you: each can log the flows and guess at the owners. Only the people who run the applications know which flows were meant to be there.
Nothing mandates the clock. DORA asks for interdependency maps and tested exit plans; CADA would ask for an assurance level. Neither asks how long an application keeps running once something it depends on is gone. The follow-up rules CADA leaves open could ask the two questions per crossing. Until they exist, a buyer setting minimum levels is setting them blind. Norway’s parliament had a proposal in front of it to order continuous mapping of the country’s digital dependencies abroad. On 7 May it voted the proposal down, 54 to 47.
An audit will not catch it either. An audit checks that the classification is complete, not that it is true. The sovereign label says the application keeps running when the boundary closes. The spreadsheet cannot tell you whether that is true. The crossings can. The claim is made about the whole; it is decided on the edges.
Defence digital estates are designed from day one to keep working with the outside gone. Banks, agencies, hospitals and ordinary companies were built assuming the outside stays reachable. The line between the two is moving: estates that were never asked the sovereignty question are being asked it now, at a pace geopolitics sets. It has already forced the exercise twice in recent memory. Companies moving their operations out of Asia as tensions rose had months to work out what could be disentangled. The companies that had to pull their operations out of Ukraine when the invasion came had weeks.
Go and find out what your applications depend on, and give your own people the months the tracing takes, before an event hands them weeks.
Written in a personal capacity, from public sources and general patterns. Next in this series: the exit strategy. What to do with the crossings once you have found them, and who can lock you out of your own infrastructure.
References
- European Commission, Proposal for the Cloud and AI Development Act (CADA), 3 June 2026. digital-strategy.ec.europa.eu
- European Commission (DG for Digital Services), Cloud Sovereignty Framework, Version 1.2.1, October 2025. commission.europa.eu
- European Commission, Cloud Sovereignty Framework: Implementation guidance, 1 June 2026. commission.europa.eu
- European Commission, Commission advances cloud sovereignty through strategic procurement, 17 April 2026. commission.europa.eu
- European Parliament and Council, Regulation (EU) 2022/2554 (Digital Operational Resilience Act), 14 December 2022. Article 8 on mapping ICT assets and interdependencies; Article 28 register of information; Article 28(8) on exit strategies and tested exit plans. eur-lex.europa.eu
- European Commission, Implementing Regulation (EU) 2024/2956 (register of information templates), 29 November 2024. Jurisdiction fields: headquarters country, country of provision, governing law, country of data at rest. eur-lex.europa.eu
- Court of Justice of the EU, Data Protection Commissioner v Facebook Ireland and Schrems (C-311/18), 16 July 2020. eur-lex.europa.eu
- European Parliament and Council, Directive (EU) 2022/2555 (NIS2), 14 December 2022. eur-lex.europa.eu
- EDPB, Recommendations 01/2020 on measures that supplement transfer tools, version 2.0, 18 June 2021. edpb.europa.eu
- EPRS, Cybersecurity Act review: What to expect, January 2026. europarl.europa.eu
- SUSE, Application Trust Hierarchy: A Practical Guide to Applying Sovereignty Where It Matters Most, 16 June 2026. suse.com
- Microsoft Learn, Sovereign design and implementation considerations, March 2026. learn.microsoft.com
- NSM, Nasjonal kontroll av IKT-tjenester (temarapport), October 2023. nsm.no
- Ruohonen, Stark, Wilkie and Kjærgaard, Digital Sovereignty as a Quality Attribute for Software Architectures, arXiv, 30 June 2026. arxiv.org
- Stortinget, sak 200036 (Representantforslag om digital suverenitet i en urolig tid), Innst. 225 S (2025–2026), rejected 7 May 2026 (54–47 against). stortinget.no
- Sovereignty Is a Control Boundary, Not a Location, LinkedIn, January 2026. linkedin.com
Ulv Bjørnsson 