This guide is for foreign parent companies, group CISOs and English-speaking compliance teams with a Dutch entity. The Dutch-language source of truth, which we keep current, is Cyberbeveiligingswet per 15 augustus 2026. Last updated: 16 August 2026.

This is practical guidance, not legal advice.

What is the Cyberbeveiligingswet?

It is the Dutch NIS2 implementing law, in force since 15 August 2026, and it is not a single document.

Four instruments took effect on the same day, with a further layer of ministerial regulations underneath them. Anyone reading only the Act itself is missing most of the operative detail.

Each ministry has also issued a sector regulation setting, among other things, the thresholds at which an incident becomes reportable. The consolidated statutory text is at wetten.overheid.nl.

Who is in scope?

Organizations in one of the listed sectors with 50 or more employees, or with annual turnover or balance sheet total above €10 million, plus several entity types that are in scope regardless of size.

One note if you check the sources: the NCSC page words the financial test more strictly, as both turnover and balance sheet (NCSC). The SME definition the law relies on uses "or". If you sit close to the threshold, have it checked.

Sectors are set out in two annexes: Annex 1 covers high-criticality sectors (energy, banking, financial market infrastructure, transport, drinking water, wastewater, health, digital infrastructure, ICT service management, space, government); Annex 2 covers other critical sectors (waste management, postal and courier services, chemicals, food, manufacturing, digital providers, research, and (once its regulation exists) higher education) (NCSC brochure, PDF).

In scope regardless of size: providers of public electronic communications networks and services, (qualified) trust service providers, top-level domain name registries, DNS service providers, domain name registration service providers, and all government organizations.

Two further routes matter for group structures:

• Article 9 Cbw allows designation irrespective of size where the entity is the sole provider of a service essential to critical activities, where disruption would significantly affect public safety, security or health, or where there is significant systemic risk.
• Article 8 Cbw makes any entity designated critical under the Wwke an essential entity under the Cbw by operation of law.

Note that providers of domain name registration services sit in a third category, neither essential nor important, with a lighter regime of their own (art. 43).

What do we have to register, and where?

Registration runs through Mijn.NCSC.nl using eHerkenning at assurance level 3, it has applied since 15 August 2026, and changes must be reported within two weeks.

Foreign parents should note that eHerkenning is a Dutch national authentication scheme; obtaining it for a Dutch entity takes time and is a common cause of delay. Government bodies use SSOnRijk instead (RDI).

Changes to registered information must be reported "without delay and in any event within two weeks" (art. 44(2) Cbw).

No deadline for initial registration has been published. We could not find one on the NCSC, RDI or NCTV websites; the obligation simply applies from 15 August 2026. Treat any page quoting a specific Dutch registration deadline with suspicion. The practical position is unchanged: there is no transition period, so there is nothing to wait for.

What are the security obligations?

Appropriate and proportionate technical, operational and organizational measures on an all-hazards basis, set out in ten categories in article 21(2).

The ten categories transpose Article 21(2) of the Directive: risk analysis and information system security policies; incident handling; business continuity, backup management and crisis management; supply chain security; security in acquisition, development and maintenance including vulnerability handling; policies to assess the effectiveness of measures; cyber hygiene and training; cryptography and encryption; human resources security, access control and asset management; and multi-factor authentication and secured communications.

"All hazards" is meant literally: physical risk to server rooms is in scope, as is your supply chain. The full ten-row breakdown, with the evidence each category typically produces, is in the Dutch hub.

What is the reporting timeline?

24 hours, 72 hours, one month: one submission, reaching both the sectoral CSIRT and the supervisor.

Sources: NCTV, NCSC.

Two details worth carrying into a group incident-response plan: trust service providers file the incident notification within 24 hours rather than 72; and the receiving CSIRT is the sectoral CSIRT, which is NCSC for most but not all sectors. The clock starts on awareness, not on the incident.

Who supervises us?

Seven authorities, split by sector. And how closely they watch depends on whether you are an essential or an important entity.

RDI covers digital infrastructure, energy, ICT service management (including managed service providers), government, space, postal and courier services, non-medical manufacturing, digital providers and research. ILT covers transport, drinking water, wastewater, water management, waste management, chemicals and meteorology. DNB supervises banking and AFM supervises financial market infrastructure. NVWA covers food, ANVS nuclear, and IGJ health and medical device manufacturing (NCSC).

Essential entities get proactive supervision; important entities are supervised largely after the fact, typically following an incident (RDI). The full sector-by-sector table is in Which supervisor regulates your organization?.

What are the penalties, and what must the board do?

Up to €10 million or 2% of worldwide annual turnover for essential entities, €7 million or 1.4% for important entities. And the board must approve the measures itself and complete training.

On the amounts: they are widely reported and consistent with the Directive, but we were unable to retrieve the verbatim text of the penalty articles: the later chapters of the Dutch Official Gazette resist automated access. The chapter structure is confirmed from the official table of contents: enforcement against essential entities sits in §15.2 (art. 70–80), against important entities in §15.3 (art. 81–87). The figures are attributed to Houthoff, a law firm, and should be verified against Stb. 2026, 187 before being relied on in a board paper.

The Directive also allows supervisors to temporarily ban an individual from managerial functions (art. 32(5)(b)). We could not establish whether the Cbw transposed that power, and prefer to say so rather than assume.

What is unambiguous is article 24(1): "De maatregelen, bedoeld in artikel 21, behoeven de goedkeuring van het bestuur" (the article 21 measures require the approval of the management body). Not noting, not delegating: approving. Board members must also complete training within two years of entry into force, so by roughly 15 August 2028, and new appointees within two years of appointment (Digitale Overheid). Enforcement of these duties has its own paragraph, §15.5.

Note that Dutch sources distinguish verantwoordelijkheid (responsibility) from aansprakelijkheid (liability), and that the NIS2 liability provisions do not apply to public sector organizations.

How does the Dutch transposition differ from Germany and Belgium?

The Netherlands is late but comprehensive, Germany centralised its supervision, and Belgium is the outlier: it made certification compulsory.

If you run a group across these three countries, the differences below are the ones that change your operating model, not just your paperwork.

Three things stand out for a group compliance function.

The Netherlands split supervision where its neighbours consolidated it. Germany routes almost everything through the BSI; Belgium through the CCB. A Dutch group operating across, say, manufacturing and healthcare answers to two different Dutch regulators with different postures, while its German sister company answers to one. Budget for that.

Belgium made conformity assessment mandatory, and the Netherlands did not. Under the Royal Decree of 9 June 2024, Belgian essential entities must obtain certification against CyberFundamentals (CyFun®) or ISO/IEC 27001, or submit to CCB inspection, with an 18 April 2026 milestone and full certification due by April 2027. The CCB calls it "a binding regulatory obligation, not a procedural formality." The Directive left this optional (art. 24); Belgium took it, the Netherlands and Germany did not. If your group standardized on the Belgian approach, do not assume it discharges the Dutch duty of care, and if you standardized on the Dutch one, your Belgian entity has a deadline you may have missed.

Germany writes personal liability into statute; the Netherlands is quieter about it. § 38(2) BSIG states that management bodies breaching their duties "haften ihrer Einrichtung für einen schuldhaft verursachten Schaden" (they are liable to their own entity for culpably caused damage). The Dutch Act imposes an approval duty and a training duty; how far personal liability extends is less clearly published, and we have not asserted more than the sources support.

One caution on Germany: the European Commission's own country page still describes Germany as having failed to notify full transposition. That page is out of date: the BSI announced entry into force on 6 December 2025. Do not cite the Commission tracker as current status for Germany.

Where Soveryne fits

Groups operating across NL, DE and BE end up maintaining three near-identical control sets with different evidence expectations attached. Soveryne Command maps controls to assets and to framework requirements once, so the same control can evidence NIS2, ISO 27001 and DORA obligations rather than being re-documented per jurisdiction. Counsel, our compliance assistant, answers questions against these frameworks with citations to the source, running on a platform we operate ourselves inside the EU.

Frequently asked questions

Does our foreign parent company need to register in the Netherlands? The obligation attaches to the entity established in the Netherlands, not to the group. A parent without Dutch establishment does not register in the Netherlands, but the Dutch entity does, and it needs eHerkenning to do so, which takes lead time.

We already comply with NIS2 in Germany. Is that enough for the Netherlands? The security obligations derive from the same Directive article, so the substance largely carries over. The procedure does not: registration, the reporting portal, the supervisor and the board training deadline are all Dutch-specific.

Which supervisor applies to a group active in several sectors? Supervision follows the sector of the activity, so a group active in two sectors can face two supervisors with different postures. See the supervisor guide.

Is there a transition period? No general one. The obligations applied from 15 August 2026. The board training duty runs to roughly August 2028, and higher education is not yet in scope.

Does ISO 27001 satisfy the Dutch duty of care? It is strong evidence for much of it, but not a substitute for registration, the reporting process or board approval. And unlike Belgium, the Netherlands does not accept certification as a route to presumed conformity. Our full analysis is in Dutch: Telt ISO 27001 als bewijs?

Sources

Primary: Netherlands

• Cyberbeveiligingswet, Stb. 2026, 187 · consolidated text
• Rijksoverheid: entry into force
• NCSC: scope · brochure (PDF) · supervision
• RDI: registration · supervision
• NCTV: reporting
• Digitale Overheid: obligations

Primary: Germany and Belgium

• BSI: NIS2UmsuCG in force · BSI portal · BGBl. I 2025 Nr. 301
• CCB: NIS2 · Safeonweb@Work · 18 April 2026 deadline · CyberFundamentals
• NIS2 Directive (EU) 2022/2555

Secondary (used as such)

• Houthoff: Dutch fine ceilings
• German fine ceilings and § 38 BSIG text via lxgesetze, corroborated by Greenberg Traurig
• Belgian fine ceilings via PwC Legal and Freshfields

Further reading

• The Next 90 Days: NIS2 & CRA for security officers
• Which supervisor regulates your organization under the Dutch NIS2 law?
• DORA in Depth
• Cybersecurity Laws and Their Control Baselines

Last verified: 16 August 2026.

Which supervisor applies to my sector?

Sources: NCSC: supervision, RDI: sectors under supervision, ILT, NCSC brochure (PDF). Last verified 16 August 2026.

Two caveats we would rather state than paper over:

• The essential/important labels are published by the supervisor itself only for the RDI sectors. For the others we infer the column from the annex in which the sector sits. That is a strong indication, not an official classification by that authority.
• Water boards (waterschappen) fall under ILT on our reading. RDI lists them there, and the government-sector regulation explicitly excludes them. Note a common confusion: CERT-WM is the water boards' CSIRT, which is a different role from supervisor. A CSIRT receives reports and assists; a supervisor enforces.

Registration runs through the same portal for everyone: Mijn.NCSC.nl, with eHerkenning at level 3. The supervisor differs; the register does not.

Why is supervision split across seven authorities?

Because the Netherlands chose to place cyber supervision with the authorities that already know each sector, rather than with one new agency.

That is a genuine policy choice and not the only one available: Germany routes almost everything through the BSI, Belgium through the CCB. The Dutch model produces supervisors who understand the sector, but it also means a group active in two sectors deals with two regulators, each with its own emphasis, questionnaires and timetable.

What is the difference between proactive and reactive supervision?

Essential entities can be visited without an incident; important entities are generally looked at only after something has happened.

The RDI is explicit: "Voor essentiële entiteiten geldt proactief toezicht. De RDI kan bijvoorbeeld om informatie vragen of bij u langskomen." (proactive supervision applies to essential entities, and the RDI may request information or visit). For important entities, supervision "vindt … voornamelijk achteraf plaats", largely after the fact (RDI).

The Act mirrors the split: enforcement against essential entities sits in §15.2 (art. 70–80), against important entities in §15.3 (art. 81–87), with a separate paragraph for domain name registration service providers (§15.4).

What does that mean in practice for essential entities?

That your evidence has to be presentable at any moment, not only after an incident.

Under reactive supervision you get a trigger and some time. Under proactive supervision the request itself is the trigger. The difference is not in what you need (the duty of care is identical) but in how quickly you can show it. Organizations that reconstruct their evidence once a year for the auditor feel this most.

What if we operate in two sectors?

You may face two supervisors, and each activity is governed by its sector's regime.

A hospital that also manufactures medical devices sits with IGJ twice, in two different classes. An energy company running its own data center service sits with RDI twice. It gets harder across authorities: a transport operator (ILT) with an in-house MSP arm (RDI), for instance. In practice the heaviest classification and the strictest supervision style set your pace.

If you are designated a critical entity under the Wwke, article 8 of the Cbw makes you an essential entity by operation of law, whatever the sector table suggests.

Where Soveryne fits

Two supervisors rarely means twice the security work, but it does mean twice the evidencing work. Soveryne Command maps controls once to assets and to the requirements of NIS2, ISO 27001 and DORA, so the same evidence answers more than one questionnaire. That is precisely the problem split supervision creates.

Frequently asked questions

What if my organization is active in two sectors? Each activity follows its sector's regime, so you may deal with more than one supervisor. In practice the heaviest classification sets your pace.

What does the RDI do proactively versus reactively? Proactively for essential entities: information requests and visits, with no incident required. For important entities it generally acts after an incident or signal.

Who supervises MSPs and MSSPs? The RDI. ICT service management sits in Annex 1 and the RDI classifies the sector as essential, so a managed service provider can expect proactive supervision even without an incident.

Does my supervisor change if we grow? No. Your supervisor follows your sector. What can change is your classification: growth can move you from important to essential, and so from reactive to proactive supervision. Changes to registered details must be reported within two weeks.

Sources

• NCSC: supervision under the Cbw
• RDI: sectors under supervision · RDI supervision
• ILT: digital resilience
• NCSC: information brochure (PDF)
• Cyberbeveiligingswet, consolidated text

Further reading

• NIS2 in the Netherlands: the English guide
• The Next 90 Days: NIS2 & CRA for security officers
• Cybersecurity Laws and Their Control Baselines

Note, August 2026. The first of those dates has passed: the Cyberbeveiligingswet has been in force since 15 August 2026. The plan below still holds, but read Phase 1 as work that is now overdue rather than work you are preparing for. The CRA's reporting obligations still lie ahead, on 11 September 2026.

Count with me for a second.

On 15 August 2026, the Dutch Cybersecurity Act (Cyberbeveiligingswet) enters into force. Not "is announced," not "phases in." Enters into force. The Senate voted on 7 July; the government has locked the date. There is no general transition period. The obligations apply immediately. Only higher-education institutions get three years.

On 11 September 2026, a second clock starts. From that day, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents under the Cyber Resilience Act. First warning within 24 hours.

That's not a horizon measured in months. It's a matter of weeks. And the ninety days ahead of you aren't the run-up to those dates. They contain both deadlines and your first weeks living under them. That second part is the part nobody talks about, and it's the part that counts.

Because the deadline isn't an audit somewhere in 2027. The deadline is whether you can demonstrate you're in control on the day the clock starts running.

Most organizations I talk to now know that they're in scope. They have a plan to make a plan. They have a consultant, a gap analysis from March, and a steering group that reconvenes after the summer. That's exactly the position in which the clock catches you off guard: in scope, time running, and the plan is an agenda item.

This piece is not an explainer on NIS2. Those exist in abundance. This is a countdown: what must be done, tested, and demonstrable, and in what order, because the two dates leave you no choice about the order.

1. What changes on 15 August

The Cybersecurity Act (Cbw) implements NIS2 in the Netherlands and replaces the 2018 Wbni. More than 8,000 organizations fall directly within scope, across eighteen sectors. On top of that, roughly 500 organizations are formally designated as critical entities under the simultaneously introduced Critical Entities Resilience Act (Wwke), the Dutch CER implementation.

One thing up front, because it's consistently told wrong: the law is not one document. There are three layers. The Cbw is the framework. The Cybersecurity Decree (Cbb) works out the obligations: risk management, registration, the training requirement for directors. It enters into force at the same time. The third layer is ministerial regulations per sector, which specify, among other things, when an incident must be reported. If you wait until all three layers have settled before you start, you start too late.

Four things switch on at 00:00 on 15 August.

Registration duty. You must register your organization in the entity register, in the Netherlands via mijn.ncsc.nl. The NCSC itself estimates registration at ten minutes, provided you've gathered the data beforehand. That "provided" does the work: both network and organizational data are requested, which means your CISO, network administrator, and a director all have to be involved. And you need eHerkenning (the Dutch eID for businesses). This is the cheapest task on your list and simultaneously the easiest one to trip over on 14 August.

Duty of care. Appropriate and proportionate technical, operational, and organizational measures, based on an all-hazards approach. That explicitly includes physical: a fire in the server room is a risk that requires measures. And it extends to your supply chain. More on that shortly.

Reporting duty. Significant incidents, in phases, from the moment you become aware of them: within 24 hours an early warning to your CSIRT and sector regulator, within 72 hours an initial notification, and within one month at the latest the final report.

Note that last figure. The Cbw gives you a month for the final report. The CRA works on fourteen days for actively exploited vulnerabilities. Two laws, two clocks, different numbers. Anyone who builds one runbook on "it's 24/72 anyway" builds a runbook that violates one of the two laws.

And then the board. This is the part that goes quiet in the meeting. Directors of essential and important entities are ultimately responsible for compliance with the duty of care and can be held personally liable if the organization fails to meet it. They are also required to complete training and must be able to produce a certificate of attendance.

Read that last sentence again as a security officer. There is now a physical document that is either in a folder, or isn't. That's no longer a policy discussion. That's a piece of evidence.

Supervision is divided among sector regulators: RDI, DNB, AFM, IGJ, ILT, NVWA, and ANVS, depending on your (sub)sector. The NCSC is not a regulator. It's your CSIRT and the place where you register. That distinction is not semantics: it determines whom you report to, and who can enforce.

Essential entities get proactive supervision: being checked without anything having happened. Important entities get reactive supervision: after the fact, following an incident or a signal. Fines run up to €10 million or 2% of worldwide annual turnover for essential entities, and €7 million or 1.4% for important entities. Always: the higher of the two.

One power deserves separate attention, because it was added by amendment and therefore goes further than NIS2 itself prescribes: the relevant minister can require essential and important entities to stop using certain products or services from specific suppliers, with a deadline for replacement. National security as the grounds, your architecture as the subject. Anyone who doesn't know their supplier concentration doesn't know their own replaceability.

2. What starts on 11 September

The CRA, Regulation (EU) 2024/2847, has a longer run-up than most people think and a sharper sting than they hope.

From 11 September 2026, the reporting obligations of Article 14 apply. Actively exploited vulnerabilities and severe incidents affecting the security of your product:

• 24 hours: early warning
• 72 hours: full notification
• 14 days: final report after a corrective measure is available (for actively exploited vulnerabilities); one month for severe incidents

You report only once, through ENISA's Single Reporting Platform, addressed to the CSIRT of your main establishment, with ENISA informed simultaneously. The platform is operational as of 11 September; there is a testing period beforehand. If you're in scope of the CRA: go test. A reporting channel you use for the first time during an actively exploited vulnerability isn't a reporting channel, it's a second incident.

Fines run up to €15 million or 2.5% of worldwide annual turnover. That highest bracket applies to, among other things, breaches of the essential requirements in Annex I and of the obligations in Articles 13 and 14. So the reporting duty sits in the heaviest fine category.

Who is a "manufacturer"? Two surprises here.

The first: you're a manufacturer if you develop, or have developed, a product with digital elements and place it on the market under your own brand name. Paid or free. But you're also treated as a manufacturer, as an importer or distributor, when you place a product on the market under your own name or trademark, or carry out a substantial modification. Take an open-source library, build it into a product you supply under your own name. You're a manufacturer. Not a steward. Manufacturer.

For the average Dutch organization that thinks "the CRA is for hardware vendors": do you white-label software? Do you supply a portal under your own brand? Then this conversation is for you.

The second surprise is in the transitional provision, and it's sharper than it looks. Article 69(2) says products placed on the market before 11 December 2027 fall under the CRA requirements only if they undergo a substantial modification from that date. That sounds like breathing room. But paragraph 3 makes an explicit exception to it:

"By way of derogation from paragraph 2, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027."

Translated: the rest of the CRA waits for your next substantial modification. The reporting duty does not. It applies from 11 September 2026 to your entire installed base. To that product from 2019 still running at forty customers, whose builder is two employers down the road. You have no design obligation for that product. You do have a reporting obligation, and it starts running the moment you "become aware" of active exploitation. Do you know what's running? Do you know who reports it? Do you know within how many hours you'd hear?

And for completeness, in one paragraph: the financial sector already knows this pattern. DORA has applied since January 2025 and has already had the discussion there: not "is your data safe," but "can you keep operating when your technology fails." What happens to the rest of the Netherlands on 15 August, banks and insurers already have behind them. That's not comfort. It's a free preview of what regulators are going to ask.

3. The letter you don't get

Now the part that's most often told wrong, usually by people who want to sell you something.

You hear it a lot: "tens of thousands of companies fall indirectly under NIS2." That's not true, and it's important to be precise, because the truth is more uncomfortable.

The Cbw imposes no direct obligations on suppliers of Cbw organizations. In fact, the NCSC is explicit: a regulator will not supervise suppliers and therefore will not fine them either. No letter. No fine. No registration duty.

What does happen: Article 21(2)(d) requires Cbw organizations to take measures to secure their supply chain, including the relationships with their direct suppliers and service providers. And under Article 21(3), in determining what is "appropriate," they must take into account the specific vulnerabilities of each direct supplier and the overall quality of that supplier's products and security practices, including secure development procedures.

So: the regulator isn't coming for you. Your customer is.

According to the NCSC, you'll likely appear in the risk inventory if you supply services or products related to a Cbw organization's network and information systems, if you supply an ICT component, or if you have access to their systems. The coffee supplier, no. The party managing office IT, yes.

And here's the operational pain, which the NCSC names honestly: the criteria aren't in the law. "Appropriate measures" leads, per supplier, to a bespoke package of requirements. Supply to multiple Cbw organizations, and you'll get different lists of measures to respond to. Five customers, five questionnaires, five different definitions of the same thing.

A certificate helps that conversation, since you can quickly show which standards you follow. But the NCSC warns in the same breath: it offers no guarantee that the identified chain risk is actually covered. ISO 27001 or CYRA can be handy. The Cbw doesn't require them.

No law compelling you. But a market assessing you. That's not a softer variant of compliance. It's compliance with no clear requirements and no clear endpoint, and it starts on 15 August, when 8,000 organizations begin asking at once.

4. The trap: "audit-ready someday" versus "in control now"

I break into systems. That's my job. And the pattern is the same every time.

I come into organizations that have passed their audit. The certificate is on the wall. The policy is set, the risk assessment is done, the measures are "implemented." And then the service account from the 2023 migration turns out to still exist, with permissions no one can explain anymore, outside the reach of every offboarding process, because it isn't tied to a human.

That service account is in no audit report. Not because the auditor was bad. Because an audit is a point-in-time snapshot.

That's the whole issue. An audit proves you had it in order on one Tuesday. Attackers pick a different Tuesday. And from 15 August, regulators will too: for essential entities without cause, without an incident, without notice.

The space between those two Tuesdays is where my work happens. It's also exactly the space where "compliant" ends and "in control" begins.

The difference isn't rhetorical, it's testable. Ask yourself these four questions, and accept only answers with a timestamp:

• Can you demonstrate a measure works today, or only that it was described in March?
• If you get a call now about active exploitation: how many hours does it take you to determine whether it affects you? You have 24 until the first report, and that clock starts at "become aware," not "understood."
• Who pushed the button on the report last time, and are they still here?
• If the regulator asks for evidence tomorrow morning, does that cost you an export or three weeks?

A program that answers "three weeks" to the fourth question is not in control. It's documented. That's something else, and the difference costs you 24 hours you don't have.

Compliance describes what you would do. Control is what happens when it goes wrong, at quarter past three in the morning, in August, when half your team is on holiday.

That's not a rhetorical holiday, by the way. 15 August falls in the middle of the summer break.

5. The next 90 days: what must be done, tested, and demonstrable

No eighteen-month roadmap. Three phases, and they're ordered not by comfort but by the two dates. What's legally required before 15 August is in phase 1, full stop. What touches the CRA clock is in phase 2. And phase 3 is where "in control" gets proven, in the first weeks you're running under the law.

Phase 1 · Before 15 August: the non-negotiables

Everything here must be done on the day the law enters into force. Not "under way." Done.

• Define your scope. Essential or important entity? The distinction sets your fine ceiling and whether you get proactive supervision. Even "we're not in scope" is a decision you must be able to defend, with a date.
• Register. Sort out eHerkenning now, gather the network and organizational data beforehand (NCSC checklist), put your CISO, network administrator, and a director in one meeting, and register via mijn.ncsc.nl. Mandatory as of 15 August.
• Schedule board training and keep the certificate of attendance. The training duty itself runs to roughly 15 August 2028, so this is the one item here you may finish later. Book it now anyway: it is the piece of evidence the personal-liability story lands on.
• Have the board sign off on residual risks, with a date. Liability that isn't assigned sits with your directors without their knowing it.
• Demonstrable on 15 August: registration confirmation, a dated scope decision, a signed board resolution. Training certificates follow as the training is completed, up to roughly 15 August 2028.

Phase 2 · Before 11 September: the CRA clock

• Determine whether you're a manufacturer under the CRA. Do you place something on the market under your own brand, or make a substantial modification? Then probably yes, even if you don't think of yourself as one.
• Map your installed base. All products placed on the market before 11 December 2027 fall under the Article 14 reporting duty. Know what's running, at whom, in which version.
• Build one reporting runbook with two clocks. Cbw: 24h → 72h → 1 month. CRA Art. 14: 24h → 72h → 14 days (1 month for severe incidents). Put them side by side; they are not identical. Record who establishes "become aware" and how that moment is logged.
• Test ENISA's Single Reporting Platform during the testing period, before 11 September, not after.
• Demonstrable on 11 September: a tested runbook, a decision card with names and phone numbers, a product register, and a measured time-to-first-report.

Phase 3 · The first weeks under it: where "in control" is proven

This is why it's called "the next 90 days" and not "the last 30." Meeting the law is phases 1 and 2. Demonstrating you're in control happens after, and it's exactly what a proactive regulator comes to check.

• Adopt one control baseline and map it to both laws. ISO 27001 or NIST CSF 2.0, mapped to the duty of care and (if you're a manufacturer) to CRA Annex I. The mapping table (control → legal requirement → evidence → owner → last verified) is the most important document you'll make this summer.
• Capture evidence continuously, in the process, not in a quarterly sprint. A control without a fresh evidence date is an assumption.
• Run your reporting runbook again with a holiday roster. 15 August falls in the summer.
• Prepare for proactive supervision (essential entities): checks without an incident, without notice.
• Set up a quarterly cycle in which evidence ages and is re-confirmed.
• Demonstrable, ongoing: one mapping table with an owner per control and a date per piece of evidence.

6. One control, many frameworks

Reading phase 3, you'll have thought something along the lines of: this is doing the same work twice.

It doesn't have to be, and that's the best news in this whole piece.

Access control is access control. Logging is logging. Continuity is continuity. That same control appears in the Cbw duty of care, in CRA Annex I, in ISO 27001, in DORA, and in the GDPR: different words, different numbering, different regulator. Most organizations build it five times, evidence it five times, and defend it five times, because the compliance work is organized per law instead of per control.

Flip it around. Build the control once. Capture the evidence once. Map that one control to every law that demands it.

That's not a trick to do less. It's the only way to survive these ninety days without doubling the work, and it's exactly why the mapping table from phase 3 is the most important document you'll make this summer. Not because a regulator asks for it. Because it's the only artefact that tells you which evidence you're missing before someone else asks the question.

7. What "operated, not archived" means

I built Soveryne because I saw the same thing too often: organizations with a fine policy folder and a service account from 2023 still left open, evidence that was valid on the day it was collected and on no day after, in a compliance stack that itself ran outside the EU jurisdiction it was meant to provide evidence for. Evidence that runs with your systems instead of alongside them, inside the jurisdiction you have to account for it in: that's the difference between a program you operate and one you archive.

Beyond that, I'm not selling you anything here. If you take one thing from this piece, let it be the mapping table. You can start it in a spreadsheet on Monday.

8. A few weeks left

Back to the countdown.

On 15 August, someone asks you a question. Maybe a regulator, maybe your biggest customer, maybe your own director who has just understood what "personally liable" means. The question isn't "are we compliant?" That question has an answer you wrote down in March.

The question is: can you demonstrate it, today, with a date on it?

If the answer is "give me three weeks," you know what the next ninety days hold. If the answer is an export, you're in control.

There is no transition period. That's not meant as a threat. It's just the date.

FAQ

When does the Dutch Cybersecurity Act enter into force? 15 August 2026. There is no general transition period, so the obligations apply from that date. Only higher-education institutions get a three-year runway.

When do the CRA reporting obligations start? 11 September 2026. From that day, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents, with a first warning inside 24 hours.

Does NIS2 apply to my organization? It depends on sector and size rather than on whether you consider yourself critical. Work from the sector annexes and your headcount and turnover first, then check whether a customer's supply-chain obligations pull you in regardless.

What does "demonstrable" actually mean here? That you can produce, on the day you are asked, a current record of the control, who owns it, and evidence dated recently enough to still be meaningful. A policy document written in March is not evidence that the control ran in August.

Are directors personally liable? NIS2 puts management responsibility for cybersecurity risk-management measures on the board, including approving and overseeing them. Delegating the work does not delegate the accountability.

Is this legal advice? No. This is an operational reading of the deadlines to help you sequence work. Check your specific scope and obligations with your own counsel.

Working through the next ninety days? Soveryne Command is live, and the way in is a free intake. Tell us what you have to demonstrate, and by when. Register your interest

Ilke Tosunoğlu is an ethical hacker and penetration tester, and founder of Soveryne. Want to respond or talk through the countdown? LinkedIn.

This pillar page maps the stakes. Three ideas carry it, and each has a full article behind it.

What "digital sovereignty" actually means

First, the definition, because the word is abused. The EU's own Joint Research Centre defines digital sovereignty as "the EU's capacity to exercise independence in the digital realm while remaining open and connected to global networks" (JRC Policy Brief JRC144908, 2025). The clause after the "while" is the whole point: sovereignty is not self-sufficiency, and not a wall. It is the ability to decide, operate, switch, and secure critical infrastructure without unacceptable exposure to foreign legal compulsion, single-vendor lock-in, or coercion.

The dependence is real, and it is layered

Europe is weakest exactly where the future is being built, and strongest in a few deep chokepoints it cannot lose quickly. The public-cloud layer is the clearest illustration: three US hyperscalers hold roughly 70% of the EU cloud market (Synergy Research), while the largest European provider sits around 2%. In frontier AI, the gap is starker still. Yet Europe holds genuine leverage where it counts: one Dutch company, ASML, builds close to 100% of the world's EUV lithography machines.

The full layer-by-layer map, and where Europe still holds the whip hand, is in The Real Map of Europe's Digital Dependence.

Concentration turns ordinary tools into systemic risk

Dependence would matter less if it were spread thin. It is not. When millions of systems share the same software and the same provider, a local defect becomes a continent-scale failure, no attacker required. On 19 July 2024, a single content update from one security vendor crashed an estimated 8.5 million Windows devices worldwide, grounding airlines and diverting hospitals. Regulators have caught up: under DORA, the European Supervisory Authorities designated the first 19 critical ICT third-party providers for direct oversight in November 2025, on criteria explicitly about concentration and substitutability.

How convenience quietly becomes critical infrastructure, and what supervisors now expect, is the subject of When Ordinary Tools Quietly Become Critical Infrastructure.

Compliance is not sovereignty

Here is the trap that catches well-run organizations: you can pass every audit on the calendar and still be one foreign legal order, one license change, or one provider outage away from losing control of your own operations. A US-headquartered "EU region" can be fully GDPR- and NIS2-aligned on paper while remaining reachable under foreign law, a point a hyperscaler conceded under oath at the French Senate in 2025. The audit was never designed to catch that. Europe is regulating its dependencies faster than it builds substitutes for them, and a compliance stamp does not close that gap.

Why the audit and the dependency are different problems, and what to do about it, is in Compliant but Dependent.

Where this leads

Naming the stakes is step one. The method for acting on them, selective autonomy rather than autarky, is the subject of the second pillar, Sovereignty You Can Actually Operate. The sharpest new front, keeping AI inference and data on sovereign ground, is the third, Sovereign AI, Explained.

If you would rather see what sovereign-by-default looks like as a product, explore the Soveryne Cloud Foundation, or get in touch and we'll show you your real exposure across the frameworks that apply to you.

Not autarky: sovereignty is a dial

The realistic objective is not a European wall. Europe already proves the point: it is deeply dependent in cloud and AI, yet holds one of the most asymmetric chokepoints on earth in lithography. That is sovereignty as leverage, not isolation, and the lesson scales down to every organization. You do not need to own the whole stack; you need control where control is decisive. The full argument, and the workload-tiering tool that operationalizes it, is in Sovereignty Is Not Autarky.

Location is not control

The most common mistake is treating an "EU region" as sovereignty. Residency answers where the bytes sit; sovereignty answers whose laws govern them and who can be compelled to hand them over. Under the US CLOUD Act, a demand served on a US-headquartered provider reaches data it controls anywhere in the world, Frankfurt and Dublin included. The architectural answer, customer-held keys, encryption, no-egress isolation, and an EU operating entity, is what turns a promise into a property of the system. Read Sovereignty by Architecture, Not by Promise and its companion Who Can Actually Compel Your Data?.

Sovereign security needs sovereign ground

A related trap sits one layer down. Europe fields genuinely strong security vendors, but the high-value control planes, cloud-native security, hyperscale telemetry, identity, run overwhelmingly on US infrastructure, and European tools frequently run on the very systems they are meant to protect. Sovereign security has to include the ground it stands on. That is the argument of The Cyber Paradox.

The truest test: can you leave?

Sovereignty is a capacity, and the capacity that matters most is the ability to walk away. A provider you cannot leave has sovereignty over you, whatever colour the badge. Public-cloud adoption is near-universal; tested exit plans are not. From 12 January 2027 the EU Data Act prohibits all cloud switching and egress charges (Data Act, Art. 29), removing the financial moat, but the effort, the proprietary APIs and untested failover, is still yours to solve. Why the exit is the real test is in If You Can't Leave, You're Not Sovereign.

The 12-month plan

None of this requires ripping out what works. The pragmatic sequence: map dependencies and concentration, tier workloads by the sovereignty they actually need, fix the sensitive tiers first with customer-held keys, design a tested exit, prefer open standards where they're ready, and treat skills as critical infrastructure. The full playbook, with the EU's SEAL assurance ladder and what not to do, is in A Pragmatic Sovereignty Playbook.

Where this leads

The stakes are the first pillar, Europe's Digital Dependence, Explained. The sharpest new front, sovereign AI, is the third, Sovereign AI, Explained.

To put the sensitive tiers on sovereign ground, explore the Soveryne Cloud Foundation, or get in touch and we'll help you tier your workloads. If we're not the right fit for a given tier, we'll say so.

Every dependency starts as a convenience. The cloud did, until three companies held most of the market and leaving became unthinkable. AI is now running the same play, and the tell is the speed: cloud needed a decade to become load-bearing; AI is doing it in eighteen months. The difference is that this time the pattern is visible in advance, which means it is avoidable.

Three ideas make sovereign AI a concrete discipline rather than a slogan. Each has a full article behind it.

Don't let AI become the next lock-in

The shape of AI dependence rhymes with cloud, one layer up. The US builds the frontier models; Europe consumes them, and the market is already concentrated in a handful of providers. AI adds new, stickier lock-in mechanisms, too: API coupling, fine-tuning welded to one base model, and the data gravity of embeddings, where switching providers means re-embedding the entire corpus. The answer is portability by design, a model-abstraction layer, multi-model routing, and grounding over fine-tuning, so your architecture looks less like a stack and more like a portfolio. The full case is in Don't Let AI Become the Next Cloud Lock-In.

The prompt is the data

Here is the insight most sovereignty programs miss. Everyone accepts that customer data shouldn't sit in a foreign jurisdiction. Almost nobody applies the same rule to the prompts sent to an AI model, even though the prompt, and the context retrieved to answer it, often are the customer data.

An AI feature that ships the most sensitive record in the system to a model running elsewhere puts a hole in the residency perimeter exactly the shape of an API call. Why inference has to happen on sovereign ground, and why embeddings leak the source, is in The Prompt Is the Data.

Secure AI the way attackers break it

Sovereign AI is not only about where the data goes; it is about whether the system survives contact with an attacker. Prompt injection is OWASP's number-one LLM risk, and it cannot be fully "solved", because a language model reads its trusted instructions and untrusted input through the same channel. The realistic goal is to build so a successful injection can achieve very little: defense in depth, least privilege, output filtering, and keeping the "lethal trifecta" of sensitive data, untrusted content, and external communication from ever lining up. The offensive-security view is in Securing AI the Way Attackers Break It.

Where this leads

The stakes are the first pillar, Europe's Digital Dependence, Explained. The method, selective autonomy across the whole estate, is the second, Sovereignty You Can Actually Operate.

This is exactly why Counsel is built the way it is, grounded, cited, and running on EU-sovereign infrastructure so prompts and embeddings never cross the key boundary. To see it in practice, get in touch.

This is practical guidance for boards and compliance leaders, not legal advice. Current as of July 2026.

The liability moved into the boardroom

The most consequential shift in EU digital regulation isn't a new obligation: it's who answers for it.

• NIS2, Article 20: management bodies must approve and oversee cybersecurity risk-management measures, must take training, and can be held personally liable. Several Member States can impose sanctions including temporary bans on individuals holding management positions.
• DORA, Article 5: the management body bears ultimate, non-delegable responsibility for the ICT risk-management framework; it must approve the resilience strategy, continuity and recovery plans, and critical third-party arrangements, and keep its own knowledge current.
• GDPR, Article 5(2): the accountability principle already required the organization to demonstrate compliance.
• The AI Act adds governance and quality-management duties for AI.

Read together, these say something new: a director can no longer treat compliance as someone else's paperwork. The obligation to oversee, and the liability for failing to, sits with the board itself.

Why "we passed the audit" is not "we are assured"

Here's the trap that catches boards. A certificate or an annual audit is a point-in-time stamp. It attests that on the day of assessment, controls looked adequate. But the environment changes, the estate changes, and (as this series has shown repeatedly) the law changes. The AI Act's deadlines moved in mid-2026. NIS2 enforcement hardened weeks later. A certificate issued against last year's understanding is quietly out of date.

Continuous assurance is the alternative: an always-on, dated, inspectable stream of evidence, plus a live view of coverage, open gaps, and trend. The distinction matters because "compliant" and "assured" are not the same word. Compliant is a status you claimed on a date. Assured is a property you can demonstrate right now.

What the board actually needs to see

Directors don't need the control library; they need a decision-useful view of exposure. A board-ready compliance picture answers five questions on one page:

That's the artifact that turns a compliance program into governance a board can sign off (and, when a regulator or an incident comes, defend).

Where Soveryne fits

This is where the whole series lands. Command is built to produce exactly this view: framework coverage and control posture at a glance, open gaps by framework, and continuous validation so the evidence behind the picture is current rather than a year old. It turns "we passed the audit" into "here is our live, evidenced posture across every framework that applies to us": the difference between a stamp and assurance, and precisely what a board carrying personal liability needs to see. The dashboard the board reviews and the control library the team operates are the same system, so there's no gap between what's reported and what's real.

And because the board's questions are often about change ("what does the new rule mean for us?"), Counsel gives directors and their advisors grounded, cited answers on obligations and what's shifting, from the frameworks themselves. Coverage intelligence for the questions; proof of implementation for the answers.

If you've followed this series from the maze to here, the throughline is simple: compliance became a mapping-and-evidence problem, the evidence has to be continuous, and the board now owns the result. Soveryne is built to make that ownership defensible rather than nerve-wracking. Get in touch and we'll show you your posture across the frameworks that apply to you, and if we're not the right fit, we'll say so.

FAQ

Can board members be personally liable for compliance failures? Under NIS2, yes: management bodies must approve and oversee cyber measures and can be held liable, with some Member States allowing temporary management bans. DORA makes the management body's responsibility for ICT risk ultimate and non-delegable.

What is continuous compliance? An always-on approach where controls are evidenced continuously and coverage, gaps, and trend are visible in real time, as opposed to a point-in-time audit that attests to a single moment and decays as the environment and law change.

Isn't passing an audit enough? An audit or certificate is strong evidence for a point in time, but it doesn't stay true as your estate and the regulations change. Assurance means being able to demonstrate your posture now, not last year.

What does a board need to see about compliance? Coverage by framework, open gaps ranked by risk, remediation trend, upcoming regulatory dates, and evidence freshness: a decision-useful one-page view of exposure, not the full control library.

Compliance is now the board's to own. Make it defensible, not nerve-wracking. See your live, evidenced posture across every applicable framework in Command, and get cited answers on what's changing from Counsel. Get in touch.

Sources

• NIS2, Article 20 (management accountability): https://eur-lex.europa.eu/eli/dir/2022/2555/oj
• DORA, Article 5 (management body responsibility): https://eur-lex.europa.eu/eli/reg/2022/2554/oj
• GDPR, Article 5(2) (accountability): https://eur-lex.europa.eu/eli/reg/2016/679/oj
• European Commission, NIS2 enforcement (CJEU referral, 8 July 2026): https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1499

This is practical guidance for compliance teams, not legal advice. Current as of July 2026.

Gap analysis has a bad reputation because most organizations do it as an annual scramble: a consultant, a spreadsheet, a panic, a binder, and then eleven months of drift. It doesn't have to be that way. Done as a repeatable loop, gap analysis is the steady heartbeat of a compliance program. Here's the loop.

The seven-step gap-analysis loop

1. Scope: which laws and frameworks apply? Start here, always. You fall under GDPR if you process personal data; NIS2 by sector and size; DORA if you're a financial entity; the CRA if you place a digital product on the EU market; the AI Act if you provide or deploy AI. Getting scope wrong produces false assurance, the most dangerous outcome, because you feel covered and aren't.

2. Inventory: what do you actually have? Your controls, their owners, and the evidence behind them, plus the assets, systems, data, AI use-cases, and suppliers they protect. You can't find a gap in something you can't see.

3. Map: connect controls to requirements. Map each control to the framework requirements it satisfies. Use the seven shared control domains and existing crosswalks (ENISA's NIS2→ISO 27001 mapping, NIST informative references). Don't invent a taxonomy.

4. Find the gaps. Two kinds: requirements with no control (a genuine hole), and controls with no or expired evidence: "orphaned controls" and "evidence rot." The second is the one audits actually fail on.

5. Prioritize: by risk × exposure × deadline. (The regulatory clock, and what's actually landing when, is laid out in the timeline.) Not every gap is equal. Weight by the harm if exploited, the likelihood an auditor or incident surfaces it, and the regulatory clock (DORA already applies; CRA reporting starts September 2026; the AI Act's high-risk obligations now land in December 2027 per the Council's final adoption of the Digital Omnibus).

6. Remediate: with owners and evidence targets. Every gap gets an owner, a due date, and a definition of the evidence the fix must produce. A remediation that doesn't produce evidence hasn't closed the gap in any way an auditor will accept.

7. Evidence: continuously. Keep evidence dated, inspectable, and current. Then loop back to scope, because the laws move.

The antipatterns that sink gap analyses

Three failure modes appear again and again. Name them so your team can catch them:

• Evidence theater. Policies and questionnaires produced faster than the working controls behind them. The bottleneck is never documents; it's turning governance language into measurable, inspectable, system-linked evidence.
• Policy without practice. A signed policy with nothing operational behind it. It passes a document review and fails a technical one.
• False assurance from bad scoping. "We're aligned to ISO" is not "we meet NIS2." Alignment to a framework is not compliance with a law.

This is now a legal expectation, not a nice-to-have

Gap analysis used to be optional hygiene. Two laws made it an expectation. DORA requires documented, tested resilience: you must be able to show the gaps you found and closed. NIS2 requires evidence of implementation, not just policy, and its Article 20 makes management accountable for it. Regulators increasingly want to see the loop, not just the certificate.

Where Soveryne fits

The seven-step loop is a lot of connective work by hand, and it's exactly what Command automates. It runs gap analysis per framework: enroll the frameworks in scope, and Command shows you, requirement by requirement, where you have a mapped control with current evidence and where you have a hole: coverage, audit-readiness, and open gaps at a glance. Because controls are mapped across frameworks, closing one gap can close it in several places at once, and its continuous validation turns step 7 from an annual scramble into a live signal, so evidence rot surfaces the day it happens rather than the week before an audit. That's steps 2 through 7, operated.

And step 1 (scope) is a Counsel question: "does the CRA apply to our product?" or "are we an essential entity under NIS2?" answered from the regulations with citations. Coverage intelligence sets the scope; Command finds the gaps and proves they're closed.

FAQ

How do I do a compliance gap analysis? Scope the applicable laws, inventory your controls and evidence, map controls to requirements, identify gaps (missing controls and missing/expired evidence), prioritize by risk and deadline, remediate with owners, and keep evidence continuous, then repeat.

What's the most common reason gap analyses fail? Evidence theater (producing policies faster than the working, inspectable controls behind them) and bad scoping that creates false assurance.

How often should I run a gap analysis? Continuously, not annually. Regulations and environments change (the AI Act's deadlines moved in 2026), and evidence expires, so a point-in-time analysis is stale quickly.

Is gap analysis legally required? Not by name, but DORA requires documented, tested resilience and NIS2 requires evidence of implementation. Both effectively require you to find and close gaps and prove it.

Turn the annual scramble into a live signal. Run gap analysis per framework and keep evidence current with Command; settle what's in scope with cited answers from Counsel.

Sources

• ENISA, NIS2 Technical Implementation Guidance (mapping for step 3): https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance
• DORA (documented, tested resilience): https://eur-lex.europa.eu/eli/reg/2022/2554/oj
• NIS2 (evidence of implementation; Art. 20 accountability): https://eur-lex.europa.eu/eli/dir/2022/2555/oj

Across this series we've established the shape of the problem: dependence is real and measurable, ordinary tools quietly become critical, compliance isn't sovereignty, and the honest goal is selective autonomy, not isolation. The recurring risk underneath all of it is simple: Europe has been regulating its dependencies faster than it builds substitutes for them, and an organization that waits for that gap to close will wait a long time.

You don't have to. Here is the playbook: six steps, sequenced, each anchored to something concrete you can point at. None of it requires ripping out what works.

Step 1: Map your dependencies and concentration

You cannot manage a single point of failure you can't see. Start by building the inventory: which providers underpin which functions, which of them are "not easily substitutable," and where several critical services quietly trace back to the same parent. This isn't just good practice. Under DORA it's a baseline obligation, complete with a register of ICT third parties and a concentration-risk assessment (DORA Art. 28(3) and Art. 29). Most organizations discover their real exposure is more concentrated than the org chart suggests.

Step 2: Tier your workloads by how sovereign they need to be

Not everything needs the same treatment, and pretending it does is how sovereignty projects stall. Sort your estate by the honest question: if a foreign party could access, disrupt, or cut this off, what happens? The EU's own Cloud Sovereignty Framework gives you a ready-made ladder for this, Sovereignty Effectiveness Assurance Levels (SEAL) 0 to 4, and you can set a minimum level per data class rather than boiling the ocean. The rows below show the levels that matter for procurement decisions; SEAL-1 (contractual EU-law protections without enforceability) sits below the practical floor and is omitted here.

Source: European Commission Cloud Sovereignty Framework. The Commission itself did exactly this in its April 2026 sovereign-cloud tender: it set SEAL-2 as the floor, reserved higher levels for sensitive workloads, and split the award across four providers to avoid lock-in (EC). That's the template: tiering, not a wall.

Step 3: Fix the sensitive tiers first

Now spend your scarce sovereignty budget where it counts: move the Tier-1 and Tier-2 workloads (the crown jewels) onto genuinely sovereign infrastructure, and do it with customer-held keys, because data residency alone doesn't answer the compulsion question. Leave the general-purpose Tier-3 estate where it is for now, kept portable. This is the single highest-return move in the playbook, and it's finite and achievable in a year.

Step 4: Design for exit

Sovereignty you can't walk away from isn't sovereignty. Build the exit before you need it: open formats, machine-readable export, tested failover, and reversibility clauses in every contract. Two hard deadlines make this urgent and cheaper: DORA Art. 28(8) requires documented, tested exit strategies for critical functions, and from 12 January 2027 the EU Data Act bans all switching and egress charges (Data Act Art. 29). Prepare now and you walk through that door the day it opens.

Step 5: Prefer open standards and open source where the function is mature

For identity, collaboration, document formats, and middleware, the deep points of administrative lock-in, favor open standards and open-source options where they're genuinely ready. Public administrations across Europe are proving it works: Schleswig-Holstein has moved almost 80% of its state-administration workstations (excluding tax administration) to open-source office software (Land Schleswig-Holstein, December 2025), and the trend is toward "public money, public code." It reduces long-run lock-in and builds demand for European and open ecosystems. (We go deep on this in the companion technical post.)

Step 6: Treat skills as critical infrastructure

None of the above sticks without people to run it. Europe is short roughly 300,000 cybersecurity professionals (ISC2, 2024), and sovereignty specifically depends on having teams that can operate, audit, and switch the systems you've chosen. Budget for it, use conversion pathways from adjacent IT roles, and treat vendor knowledge-transfer as a hard requirement, not a nicety.

Procurement is your fastest lever

If you take one thing from this playbook, take this: procurement moves faster than anything else you control. You don't have to build a European cloud; you have to buy in a way that builds one. Sovereignty criteria in tenders, multi-sourcing to avoid lock-in, exit clauses tied to ownership changes, and open-source-first defaults are already reshaping the market, from the EU institutions' €180M tender to national frameworks in the Netherlands, Denmark, France, and Germany. Anchor demand is the lever that turns "we wish Europe had alternatives" into "Europe has alternatives."

What not to do

Three failure modes to avoid, because they waste the budget and the goodwill:

• Autarky. Building everything yourself is neither realistic nor desirable. Adopt the world's best where it's safe to; reserve sovereignty for what matters.
• Sovereignty theatre. A "sovereign" badge without customer-held keys, tested exit, and real EU operational control is what critics rightly call "sovereignty washing": a label that's proven "empty in substance" (Lawfare, 2025).
• Rip-and-replace. Big-bang migrations fail. Tier, sequence, and move the sensitive workloads first.

Where Soveryne fits

This playbook is, more or less, the company we built. Command does Steps 1 and 4 as a product, mapping dependencies and controls, keeping tested exit and continuity evidenced, across NIS2, DORA, and ISO 27001. The Soveryne Cloud Foundation is where you put the Step-3 sensitive workloads: EU-hosted, operated by an EU entity, keys in EU jurisdiction, EU-sovereign AI inference, open-source core, no US-jurisdiction subprocessor in the data path. And Counsel gives you grounded, cited answers on that same sovereign ground. Step 6, skills, is why knowledge transfer to your own team is part of the engagement rather than an upsell. It's selective autonomy, delivered: pragmatic, evidenced, and startable now.

If you want a place to begin, get in touch. We'll help you tier your workloads and, true to the brand, if we're not the right fit for a given tier, we'll say so.

FAQ

How do I start reducing dependence on US tech without disrupting the business? Map dependencies, tier workloads by sovereignty need, and move only the sensitive tiers first onto sovereign infrastructure with your own keys. Keep the rest portable. It's sequencing, not a rip-and-replace.

What is the SEAL framework? The EU Cloud Sovereignty Framework's Sovereignty Effectiveness Assurance Levels (0–4), a way to score how sovereign a cloud service actually is. It's the best off-the-shelf yardstick for setting a minimum standard per data class.

What's the fastest lever to build European alternatives? Procurement. Sovereignty criteria in tenders, multi-sourcing, exit clauses, and open-source-first defaults create the anchor demand that builds supply, faster than waiting for regulation or new entrants.

What should I avoid? Autarky, sovereignty theatre (a badge without keys or a tested exit), and big-bang migrations. All three waste effort and undermine trust.

You can start this on Monday. Map, tier, fix the crown jewels, design the exit, and buy in a way that builds the alternative. To put the sensitive tiers on sovereign ground, explore the Soveryne Cloud Foundation; to operate the whole program, see Command or get in touch.

Sources

• European Commission, Cloud Sovereignty Framework explained (2026): https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01_en
• European Commission, €180M sovereign-cloud tender (IP/26/833): https://ec.europa.eu/commission/presscorner/detail/en/ip_26_833
• DORA, Article 28 (exit strategies): https://www.digital-operational-resilience-act.com/Article_28.html ; Article 29 (concentration): https://www.digital-operational-resilience-act.com/Article_29.html
• EU Data Act, Article 29 (switching/egress): https://www.eu-data-act.com/Data_Act_Article_29.html
• ISC2, EU cybersecurity workforce study (2024): https://digital-skills-jobs.europa.eu/en/latest/news/2024-cybersecurity-landscape-insights-isc2-cybersecurity-workforce-study
• Synergy Research, EU cloud market share (2025): https://www.srgresearch.com/articles/european-cloud-providers-local-market-share-now-holds-steady-at-15
• Lawfare, "sovereignty washing" (2025): https://www.lawfaremedia.org/article/tech-s--sovereignty-washing--in-europe-will-ripple-in-the-global-south
• European Commission, Cloud and AI Development Act (proposed 3 June 2026): https://digital-strategy.ec.europa.eu/en/policies/cloud-and-ai-development-act

"Sovereign" has become the most over-claimed word in enterprise infrastructure, which is a shame, because it names something precise and buildable. This capstone lays out a vendor-neutral reference architecture for sovereign-by-default platforms: the seven pillars that, together, make sovereignty an enforced and testable property rather than a label. Each pillar comes with an authoritative anchor and a plain "what good looks like." Use it as a checklist against whatever you're evaluating, including us.

The organizing idea, drawn from recent research on "sovereign-by-design" systems, is that sovereignty should be an enforceable, verifiable system property, something the architecture guarantees and a test can confirm, not something an operator promises to uphold.

The seven pillars

Let's take them in turn.

1 & 2. Jurisdiction and residency by construction

Sovereignty starts with a legal fact and a physical one. The legal fact is ownership: as we've covered, an "EU region" of a US-parented provider remains reachable under foreign law, so genuine sovereignty needs an EU-governed operating entity, the bar that certifications like SecNumCloud set with explicit protection against extraterritorial demands. The physical fact is residency by construction: data confined to a region by a default-deny replication policy that excludes other regions outright, so it cannot leave rather than merely shouldn't. The EU Cloud Sovereignty Framework's SEAL 0–4 ladder is the yardstick, and notably, in its 2026 tender, no provider reached the top level (EC). Honesty about that ceiling is part of the discipline.

3. Key custody, with an honest caveat

Encryption decides the compulsion question only if the keys sit outside the provider's reach. Customer-held (HYOK) keys mean a legal order yields ciphertext: nothing to hand over. Confidential computing, which processes data inside hardware-isolated enclaves, is a valuable additional layer. But treat it as defense-in-depth, not a guarantee: in 2025, the TEE.Fail research demonstrated that a roughly $1,000 physical interposer could extract keys from mainstream trusted-execution environments and even forge the attestations meant to prove the isolation held (tee.fail). In the sovereignty threat model, where the adversary may have hardware access, that matters. Customer-held keys remain the load-bearing control.

4. Regional inference: the prompt is the data

The newest pillar, and the one most "sovereign" designs forget: AI. A prompt is a data transfer and an embedding is a recoverable fingerprint of its source text, so region-locking your database while sending prompts to a foreign GPU defeats the whole design. Inference and embeddings have to run in the data's jurisdiction. It costs more (you duplicate inference capacity per region) and that's the honest price of keeping the prompt at home.

5. Resilience without monoculture

Sovereignty and resilience share a root cause: concentration. The architectural answer is cell-based isolation (independent replicas of the stack, each serving a slice of tenants) so that, in AWS's own formulation, "a single-cell failure affects at most 1/N of traffic" (AWS). No single provider, no shared fate, no continent-wide blast radius from one bad change.

6 & 7. Audit and the test that proves it

The last two pillars are what separate a claim from a guarantee. Audit must be tamper-evident: hash-chained and integrity-keyed, per region, and fail-closed so that an action which can't be provably logged simply doesn't happen. ("Append-only" storage is not the same as tamper-evident; it can still be rewritten by whoever controls the store.) And enforcement must be backed by a standing test: enforce residency at the data, dispatch, and audit layers, then run an automated check that attempts a forbidden cross-region access and asserts it's blocked. That test is the receipt. Without it, every refactor is a chance to silently lose the property you claimed. If it isn't enforced and tested, it isn't sovereign.

The Soveryne Cloud Foundation as a worked example

We didn't derive these pillars in the abstract. They're the specification we built the Soveryne Cloud Foundation against, and every earlier post in this series is really one pillar examined up close: jurisdiction and keys, region-locked residency, regional inference, anti-monoculture resilience, and portability. The Foundation is EU-governed and EU-operated, with data confined by design, keys in your jurisdiction, AI inference that stays home, distributed cell-isolated compute, a tamper-evident audit trail, and enforcement you can test. Command and Counsel run on it because sovereignty that stops at the application layer isn't sovereignty.

If you're evaluating your own stack, or ours, hold it against these seven pillars. Where it can't answer "yes, and here's the test," that's where the word "sovereign" is doing more work than the architecture. To pressure-test your architecture with us, get in touch.

FAQ

What makes a cloud architecture genuinely "sovereign by default"? Sovereignty enforced by the architecture and provable by a test (across jurisdiction, residency, key custody, regional AI inference, cell-based resilience, tamper-evident audit, and standing enforcement checks) rather than promised by an operator or implied by an "EU region" label.

Is confidential computing enough for sovereign data? No. It's a useful defense-in-depth layer, but 2025 research (TEE.Fail) showed mainstream trusted-execution environments can be defeated with physical access and their attestations forged. Customer-held keys remain the primary control.

How do you prove a system is sovereign rather than just claim it? Enforce residency at multiple checkpoints and run a standing automated test that attempts a forbidden cross-region access and asserts it fails. That test is the evidence; without it, the property can silently regress.

What is the SEAL framework? The EU Cloud Sovereignty Framework's assurance levels (0–4) for scoring how sovereign a service actually is: a practical maturity model to hold any architecture, including your own, against.

That's the blueprint: seven pillars, enforced and tested. Hold your stack against it, and if you want to hold ours against it too, get in touch or explore the Soveryne Cloud Foundation.

Sources

• European Commission, Cloud Sovereignty Framework explained (2026): https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01_en
• TEE.Fail research (2025): https://tee.fail/
• AWS, Reducing the scope of impact with cell-based architecture: https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/
• Confidential Computing Consortium: https://confidentialcomputing.io/overview/
• ANSSI, SecNumCloud (trusted cloud qualification): https://cyber.gouv.fr/enjeux-technologiques/cloud/
• Esposito, Marchesi, Tonelli & Lenarduzzi, "Sovereign-by-Design: A Reference Architecture for AI and Blockchain Enabled Systems" (2026), https://arxiv.org/abs/2602.05486

This is practical guidance for compliance teams, not legal advice. Current as of July 2026.

The insight: laws differ in object, not in work

Across this series we've looked at GDPR, NIS2, DORA, the AI Act, and the CRA one at a time. Line them up and a pattern jumps out: they govern different things, but they demand the same work. The obligations converge on about seven shared control domains.

This is where the compliance-maze gets its punchline. Seven domains carry most of the obligations across the entire stack. That is not a coincidence: it's the structure of the maze, and it's the exit.

The dividend, made concrete

Take one control: access control (least privilege, MFA, reviewed permissions). Count where a single, well-evidenced implementation of it lands:

One control. Six frameworks satisfied. One set of evidence (the access logs, the MFA config, the quarterly review record) counted toward all six audits. The same is true of encryption, incident response, risk assessment, and supplier oversight. This is the difference between doing access control six times and doing it once.

This reuse is officially intended

You don't have to take a vendor's word that frameworks overlap. In June 2025, ENISA published guidance that maps each NIS2 Article 21 measure to ISO/IEC 27001:2022 and NIST CSF 2.0, an official statement that your ISO 27001 controls can serve as NIST- and NIS2-aligned evidence (ENISA). NIST's frameworks are built with "informative references" for exactly this cross-mapping. The regulators expect you to reuse, not rebuild.

The honest trade-off

To be fair to the alternative: a law-by-law program gives you crisp, single-thread traceability: this obligation, this project, this binder. The shared-control model costs more to design at the start; you have to build the mapping. But every law after the first is nearly free, because it reuses controls you already run. Given that EU digital law only accumulates, the shared-control model wins on total cost, and, more importantly, it stops the "conflicting versions of the truth" that sink audits when four separate repositories drift apart.

Where Soveryne fits

This post describes exactly what Command is built to do. It's the product embodiment of the overlap dividend. Enroll the frameworks that apply to you, and Command drafts controls mapped to every framework requirement each one satisfies, so a single evidenced control is automatically counted toward GDPR, NIS2, DORA, ISO 27001, and more. Its framework-comparison view shows you, for any two frameworks, precisely where they overlap, so you can see the dividend before you bank it. Evidence collected once counts toward every audit it's relevant to; that's the whole design.

Practically: run your ISO 27001 program in Command, and your NIS2 and DORA posture is largely already evidenced rather than a second and third project. Command makes this explicit: unlimited frameworks, so adding the next law is a mapping exercise, not a new program.

And when you're deciding whether two obligations really are the same control (does NIS2's cryptography measure map to ISO 27001 Annex A 8.24?), Counsel answers from the frameworks and the ENISA mapping, cited, so your crosswalk is grounded in the source.

FAQ

How much do compliance frameworks actually overlap? Substantially. Most obligations across GDPR, NIS2, DORA, ISO 27001, SOC 2 and NIST CSF fall into about seven shared control domains: governance, inventory, risk, secure development, third-party, incidents, and evidence.

Can one control satisfy multiple frameworks? Yes. A single well-evidenced control like access control or encryption maps to requirements in GDPR, NIS2, DORA, ISO 27001, SOC 2 and NIST CSF at once, so the evidence is reused across every audit.

Is cross-framework mapping officially recognized? Yes. ENISA's June 2025 NIS2 guidance maps Article 21 to ISO 27001 and NIST CSF 2.0, and NIST publishes informative references to support cross-mapping. Regulators expect reuse.

What's the downside of a shared-control model? It takes more effort to design the mapping up front than a single-law project. But it dramatically lowers the marginal cost of every subsequent framework and prevents evidence drift.

Do the work once, prove it everywhere. See where your frameworks overlap (and evidence controls once across all of them) with Command; ground your crosswalk with cited answers from Counsel.

Sources

• ENISA, NIS2 Technical Implementation Guidance (NIS2 → ISO 27001 / NIST CSF 2.0 mapping): https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance
• NIST Cybersecurity Framework 2.0 (informative references): https://www.nist.gov/cyberframework
• EUR-Lex, GDPR Art. 32, NIS2 Art. 21, DORA primary texts: https://eur-lex.europa.eu/

There's a comforting version of digital sovereignty that's really just shopping: pick a provider with the right flag on it, sign, and feel sovereign. But sovereignty isn't a logo. It's a capacity: specifically, the capacity to decide, which includes the capacity to walk away. A provider you cannot leave has sovereignty over you, whatever colour its badge is.

This is the companion to our technical piece on building portability into the architecture. Here, the strategic case: why the exit is the real test, why so few organizations can pass it, and what changes in 2027 that you should be preparing for now.

Almost nobody can actually leave

Start with how unprepared most organizations are. Vendor lock-in is now a top-tier worry (a February 2026 survey found 94% of IT leaders concerned about it, nearly half "very concerned" (Parallels)), and around 70% rank it among their top three cloud risks (Flexera 2025). Worry, though, is not readiness. Under DORA, financial entities must now hold a documented, tested exit strategy for every ICT service supporting a critical function, and most simply don't have the tested artifact yet. The mandate exists; the rehearsed exit largely doesn't.

That gap is the vulnerability. An exit plan you've never tested is not a control: it's a hope with a cover page.

The levers that keep you in

Lock-in isn't one thing; it's a set of levers, and knowing them is how you disarm them.

The egress lever is the most concrete. Hyperscaler egress runs around $0.09/GB in Europe, roughly $900 to move 10 TB, every month you're migrating (AWS EC2 pricing; Azure bandwidth pricing). That's not a cost; it's a disincentive, engineered. Tellingly, European providers have moved the other way: OVHcloud dropped all object-storage egress fees in December 2025, and Scaleway charges nothing, turning "free to leave" into a competitive feature (SoftwareSeni).

The consolidation lever is the sneakiest, because it happens after you've committed. When Broadcom acquired VMware, European cloud providers reported price increases of 800% to 1,500%, perpetual licenses were withdrawn, and multi-year subscriptions became mandatory, prompting the industry association CISPE to file an antitrust complaint and take the Commission to court (CISPE / ECCO, 2025). The customers who "chose" VMware a decade earlier had sovereignty over neither its price nor their exit. Lock-in deepens through M&A and licensing, not just market share.

What "leaving" actually costs: three real exits

The good news, visible in organizations that have actually done it: leaving is feasible, and often pays for itself. The numbers are worth having.

Note the detail in the 37signals case: to let them delete their account cleanly, the hyperscaler waived roughly $250,000 in egress fees. The exit tax is negotiable, but only leverage, or the law, makes it so.

What changes in 2027, and why to prepare now

Which brings us to the law. The EU Data Act has set a hard date that reshapes the economics of leaving: switching rules have applied since 12 September 2025 (providers may charge only the direct costs of switching), and from 12 January 2027 all switching and egress charges are prohibited outright (Data Act, Art. 29).

The Act also caps notice and transition periods and mandates that providers let you export data in a "structured, commonly used, machine-readable format." The financial moat around the exit is being drained by regulation. But the Data Act removes the fee, not the effort: the proprietary APIs, the un-portable embeddings, the untested failover are still yours to solve. The organizations that prepare portability now will simply walk through the door that opens in 2027; the rest will discover the door was never the hard part.

Sovereignty you can prove

The through-line of this whole series is that sovereignty has to be demonstrable, not asserted, and nowhere is that clearer than exit. The truest sovereignty metric is a question you can answer with a test, not a testimonial: can we leave, and have we proven it?

This is why we built the Soveryne Cloud Foundation with an open-source core you can inspect and portability as a default rather than a premium: no proprietary trap, keys in your jurisdiction, and operational knowledge transferred to your team so that "sovereign" never quietly becomes "dependent on us." And it's why Command treats exit and continuity as first-class, evidenced controls: the tested exit strategy DORA now expects, kept current rather than filed and forgotten. We'd rather earn your stay than trap it. That's what it means to build for the door.

FAQ

What's the best test of digital sovereignty? Whether you can actually leave your provider (on your own terms, on your own timeline) and prove it with a tested exit. If leaving is impossible or ruinous, you don't control the relationship; the provider does.

When do cloud egress fees end in the EU? From 12 January 2027, the EU Data Act prohibits all switching charges, including data egress fees. During the transition since September 2025, providers may only charge the direct costs of switching.

Why is vendor lock-in getting worse? Beyond ordinary data gravity, lock-in now deepens through proprietary managed services, non-portable AI embeddings, and, critically, post-acquisition licensing changes, as the Broadcom/VMware price increases of 800–1,500% showed.

How do you build a cloud exit strategy? Use open formats and standards, avoid proprietary service coupling, keep your keys and embeddings under your control, contract for data-return and reversibility, and, above all, test the migration, the way you'd test disaster recovery.

A provider you can't leave isn't a sovereign choice; it's a dependency with better branding. See a foundation built for the door, open-core, portable, keys in your jurisdiction: explore the Soveryne Cloud Foundation and Command.

Sources

• Parallels, cloud vendor lock-in survey (2026): https://www.parallels.com/newsroom/news/press-releases/20260217-cloud-survey/
• Flexera, 2025 State of the Cloud: https://www.flexera.com/blog/finops/the-latest-cloud-computing-trends-flexera-2025-state-of-the-cloud-report/
• EU Data Act, Article 29 (switching/egress charges): https://www.eu-data-act.com/Data_Act_Article_29.html
• DORA, Article 28 (exit strategies): https://www.digital-operational-resilience-act.com/Article_28.html
• CISPE / ECCO on Broadcom-VMware: https://www.theregister.com/2025/10/28/cispe_ecco_broadcom/
• France Health Data Hub migration: https://www.lemondeinformatique.fr/actualites/lire-scaleway-devient-l-hebergeur-du-health-data-hub-99998.html
• Schleswig-Holstein open-source migration: https://www.heise.de/en/news/Goodbye-Microsoft-Schleswig-Holstein-relies-on-Open-Source-and-saves-millions-11105459.html
• 37signals cloud repatriation: https://www.theregister.com/2025/05/09/37signals_cloud_repatriation_storage_savings/
• EU cloud provider egress comparison: https://www.softwareseni.com/eu-native-cloud-providers-compared-hetzner-ovhcloud-scaleway-and-t-systems/

Most anti-lock-in advice is a list of things to avoid. That's necessary but insufficient, because lock-in isn't a mistake you make once; it accumulates, quietly, every time you reach for a convenient proprietary service. The durable answer is architectural: build so that portability is a property of the system, not a project you'll get to later. Call it no lock-in by construction.

Three pillars hold it up (an open-source core, open standards and portable data, and a tested exit) plus one principle that ties them together: the customer should be able to leave even a sovereign provider, or the sovereignty is just a nicer cage.

Pillar 1: An open-source core you can actually inspect

A "sovereign but proprietary" black box has a problem: you're trusting a claim you can't verify. Open source changes the trust model from "believe us" to "check for yourself." That's not ideology; it's auditability. Europe's public sector has leaned into this hard: the European Commission's own Open Source Strategy commits that its software "will be open sourced," and the "Public Money? Public Code!" campaign, backed by hundreds of organizations, argues that publicly funded software should be public and inspectable for exactly this reason (FSFE).

And it works at serious scale. France's national Gendarmerie has run its own Linux desktop, GendBuntu, across more than 103,000 workstations (around 97% of the force) for well over a decade, cutting total cost of ownership by roughly 40% (OSOR / European Commission). That's not a pilot; it's over a decade of evidence that an inspectable core is operable, durable, and cheaper.

Pillar 2: Open standards and portable data

Lock-in lives in formats and interfaces as much as in contracts. If your data only makes sense inside one vendor's system, you don't own it; you rent access to it. The countermeasure is to build on open standards at every layer where they exist:

The regulatory floor is rising to meet good practice here: the Data Act mandates machine-readable export and "functional equivalence" on switching, and from 12 January 2027 removes egress fees entirely (Data Act Art. 29). If your export already targets open formats, you're ahead of the deadline instead of scrambling for it.

Pillar 3: A tested exit, treated like disaster recovery

Here's the discipline most teams skip: an exit plan that has never been executed is fiction. Supervisors have caught up to this: the ECB and EBA now expect exit strategies to be in place before go-live and tested periodically, with a maintained list of qualified alternatives, and DORA makes tested exit a hard requirement for critical functions (DORA Art. 28). Treat exit like DR: rehearse the migration, measure how long it takes and what it costs, and fix what breaks before the day you need it. As one practitioner put it plainly, "without an exit option, 'sovereignty' is just a slogan" (Korte, 2026).

The cautionary tale, and the principle

Why all this rigour? Because the alternative is on the record. When a widely-used virtualization platform was acquired, its new owner pushed through licensing changes that European providers said raised prices 800% to 1,500%, ended perpetual licenses, and forced multi-year commitments (CISPE/ECCO, 2025). Every one of those customers had "chosen" that software years earlier. Closed, acquirable software means your future terms are set by whoever owns the vendor next, not by you.

Which leads to the principle that governs everything above: you should be able to leave even your sovereign provider. Sovereignty that depends on trusting one European vendor forever is just dependency wearing a better flag. Real portability means the option to walk is always live, and that's a design constraint, not a marketing line.

How we build it into the Soveryne Cloud Foundation

We hold ourselves to that principle, which is uncomfortable for a vendor and exactly the point. The Soveryne Cloud Foundation is built on an open-source core you can inspect, with your data portable and your keys in your jurisdiction, so leaving never means stranding either. And for the strictest deployments, the Soveryne tier includes knowledge transfer to your own team and on-premises options: we deliberately hand over the operational capability to run it, so sovereignty with us never becomes dependence on us. Paired with Command, the tested exit stops being a document you file and becomes a control you keep current.

The goal is not to make leaving painless because we expect you to. It's to earn the relationship by never trapping it.

FAQ

How do you avoid vendor lock-in by design? Build on an open-source core, use open standards and formats (ODF, OCI, open APIs), keep data machine-readable and keys under your control, and rehearse a tested exit. Portability becomes a property of the system rather than a future project.

Why does open source matter for sovereignty? Because it turns "trust us" into "verify it." An inspectable core can be audited, modified, and operated by your own team: the difference between sovereignty and a nicer black box.

Isn't a European sovereign provider enough? Only if you can also leave it. Sovereignty that depends on trusting one vendor indefinitely is still dependency. The design goal is that you can walk away from any provider, sovereign ones included.

What does the EU Data Act change for portability? It mandates machine-readable export and functional equivalence on switching, caps transition periods, and from 12 January 2027 bans egress and switching fees, making portability the legal default, not a premium.

Build so leaving is a rehearsal, not a rescue. See the open-core, portable, EU-sovereign foundation, the one we'd want you to be able to leave: explore the Soveryne Cloud Foundation, or read the companion piece on why exit is the real test.

Sources

• FSFE, Public Money? Public Code!: https://publiccode.eu/en/openletter/
• European Commission, Open Source Software Strategy: https://commission.europa.eu/about/departments-and-executive-agencies/digital-services/open-source-software-strategy_en
• OSOR / European Commission, French Gendarmerie open source (GendBuntu): https://interoperable-europe.ec.europa.eu/collection/open-source-observatory-osor/news/french-gendarmerie-open-sou
• EU Data Act, Article 29 (switching/egress): https://www.eu-data-act.com/Data_Act_Article_29.html
• DORA, Article 28 (exit strategies): https://www.digital-operational-resilience-act.com/Article_28.html
• CISPE / ECCO on Broadcom-VMware licensing: https://www.theregister.com/2025/10/28/cispe_ecco_broadcom/
• Korte, "Exit strategy: a key to digital sovereignty" (2026): https://www.korte.co/2026/02/12/exit-strategy-a-key-to-digital-sovereignty/

This is practical guidance for compliance teams, not legal advice. Current as of July 2026.

Why the AI Act exists

The EU AI Act (Regulation (EU) 2024/1689) is the world's first comprehensive horizontal law for artificial intelligence. Its goal: safe, trustworthy AI that respects fundamental rights, with legal certainty and a single EU market for AI. In force 1 August 2024 (EUR-Lex).

It regulates by risk tier, not by technology:

General-purpose AI models carry their own duties (Articles 51–56): technical documentation, downstream information, an EU copyright-compliance policy, and a public summary of training content, with extra obligations for systemic-risk models.

Fines run to €35M or 7% of global turnover for prohibited practices, and €15M or 3% for most other breaches (Article 99).

The timeline that just moved: the live proof point

Here is why a static AI compliance explainer is dangerous. The AI Act's high-risk obligations were originally scheduled for August 2026 and 2027. In mid-2026, through the "Digital Omnibus," the EU formally delayed them, because the supporting harmonized standards and national authorities weren't ready. Council gave final adoption on 29 June 2026.

Source: Council of the EU, 29 June 2026. Confirm the Official Journal citation of the amending regulation before relying on these dates for a filing.

Anyone who wrote "high-risk obligations apply August 2026" against the 2024 text is now wrong by more than a year. That is the timing-drift problem, live.

The frameworks that operationalize responsible AI

The AI Act tells you what. Two management frameworks tell you how. Usefully, they're built to sit on the governance and security systems you already have.

One honest caveat: the AI Act's harmonized standards (which grant a presumption of conformity) are being developed by CEN-CENELEC and are delayed, and the Commission has asked for an AI-Act-specific quality-management standard rather than adopting ISO 42001 wholesale. So treat ISO 42001 as the best available way to operationalize and demonstrate AI governance today, not as automatic legal conformity.

AI governance is an overlay, not a greenfield

The most reassuring finding: the AI Act doesn't start from scratch. Its obligations overlap heavily with laws you already handle.

• GDPR: AI Act human-oversight (Art. 14) ↔ GDPR automated-decision rules (Art. 22); AI Act technical documentation and logging ↔ GDPR records and DPIAs; AI Act training-data governance (Art. 10) ↔ GDPR data-protection principles.
• NIS2 / security: AI Act robustness, vulnerability monitoring, and cybersecurity (Art. 15) and serious-incident reporting (Art. 73) mirror NIS2 risk management and reporting.

So responsible-AI governance is a management-system layer on top of your privacy and security controls: the same shared control domains, applied to a new object. For the security side of AI specifically (prompt injection, data exfiltration), see our technical post, Securing AI the Way Attackers Break It.

Where Soveryne fits

The AI Act is where the two Soveryne jobs are most obviously needed.

Because the rules move, coverage intelligence is not optional here. Counsel answers "is this system high-risk?" and "what's the current deadline?" from the AI Act text and official sources (with citations, and current) rather than from an explainer that predates the June 2026 delay. For a law that literally changed its own dates this year, a living, grounded answer is the only safe one. Counsel is itself a governed AI assistant (grounded, cited, EU-sovereign), which is to say, governance you can actually use.

Then Command turns the AI Act into mapped controls alongside GDPR and NIS2, so your AI inventory, risk assessments, documentation, and human-oversight measures are evidenced in the same control library, reusing the privacy and security work you've already done. AI governance stops being a separate program and becomes an overlay on the one you run.

FAQ

When do the AI Act's high-risk obligations apply? As of the June 2026 "Digital Omnibus," Annex III high-risk obligations apply from 2 December 2027 and Annex I (product-embedded) from 2 August 2028, pushed back from the original 2026/2027 dates. Transparency obligations still apply from 2 August 2026.

What framework should we adopt for the AI Act? ISO/IEC 42001 (the first certifiable AI management system) is the strongest tool to operationalize and demonstrate AI governance, complemented by the NIST AI RMF. Note the AI Act's own harmonized standards are still in development.

Does the AI Act replace our GDPR obligations for AI? No. They're cumulative and overlapping. An AI-Act-compliant system can still breach GDPR (e.g. on automated decisions or training data), so AI governance layers on top of your privacy controls.

Why did the AI Act deadlines change? The supporting harmonized standards and national authorities weren't ready, so the EU formally delayed the high-risk obligations, a reminder that AI compliance dates must be checked against current sources, not static summaries.

The AI Act moves, so your answers must too. Get current, cited answers on AI Act scope and deadlines from Counsel, and evidence AI governance alongside GDPR and NIS2 in Command.

Sources

• AI Act (EUR-Lex): https://eur-lex.europa.eu/eli/reg/2024/1689/oj
• Council of the EU, final adoption of the AI Act simplification (Digital Omnibus), 29 June 2026: https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/
• ISO/IEC 42001:2023: https://www.iso.org/standard/42001
• NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
• CEN-CENELEC JTC 21 (harmonized AI standards): https://jtc21.eu/

Every dependency starts as a convenience. The cloud did: elastic, cheap, easier than running your own data center, until three companies held roughly 70% of Europe's cloud market and leaving became unthinkable. AI is now running the same play, and the tell is how fast it's moving. Cloud needed a decade to become load-bearing; AI is doing it in eighteen months.

This is the companion to the technical piece on why sovereign AI means keeping inference at home. Here, the strategic question: how do you adopt AI aggressively without waking up in three years locked to a foreign model you can't leave?

The stakes: a familiar gap, one layer up

First, the shape of the dependence, because it rhymes with cloud. The US builds the frontier models; Europe consumes them.

Sources: Stanford HAI AI Index 2026; OECD, 2026.

And the market is already concentrated: three vendors (Anthropic, OpenAI, and Google) account for roughly 88% of enterprise LLM API usage (Menlo Ventures, 2025). That's the same handful-of-providers structure that made cloud so hard to leave.

Why AI lock-in is deeper than cloud lock-in

Cloud lock-in was mostly about data gravity and migration cost. AI adds several new, stickier mechanisms, and most organizations crossed the line into them in 2025 without noticing, the moment AI stopped being "a feature" and became "the workflow layer."

• API dependence. Your product now calls a specific provider's endpoint, tuned to its quirks.
• Prompts that don't transfer. System prompts and behaviors optimized against one model degrade or break when ported to another.
• Embedding data gravity: the sharpest one. A vector only has meaning inside the exact model that created it. Switching embedding providers means re-embedding your entire corpus; one worked example put moving 100M documents at "$3,000 just for the API calls, plus engineering time to rebuild indexes", and it only grows. So teams "pick one embedding model early and never change it." (Schift)
• Fine-tuning welded to a base model. Fine-tune on a provider's base and your investment evaporates when they deprecate it.
• Deprecation power. The vendor controls the clock, and uses it.

The access shocks are already happening

If lock-in still sounds abstract, look at the past eighteen months. These are real, and they hit production systems: a mid-2025 model API deprecated, the US "AI Diffusion Rule" issued and then rescinded, an export ban on advanced AI chips reversed months later, and, in early 2026, six models retired with roughly three months' notice.

Model deprecations force hard migrations on the vendor's schedule, not yours: OpenAI announced the retirement of six models in early 2026 with roughly three months' notice, against the six-to-twelve months enterprises say they need to re-validate production software (OpenAI deprecations; Remio). At the infrastructure layer, the US AI "Diffusion Rule" was issued and then rescinded within months, and export controls on advanced AI chips whipsawed on and off through 2025 (BIS; Bloomberg). Even the frontier vendors treat single-source AI as a risk: OpenAI itself signed a ~$38B deal to diversify its own compute away from a single provider. If they hedge, so should you.

The portability answer

Here's the encouraging part: because the models are converging in quality (the top US and Chinese models are now within a few percent on benchmarks), the differentiator is no longer raw capability. It's whether you can move. And enterprises are already acting: 37% now run five or more models in production (Typedef). The design patterns that keep you free:

1. A model-abstraction layer. Put a gateway between your applications and any provider, so your code talks to one interface and you can swap or fail over underneath.
2. Multi-model routing. Route by task and cost; never let one provider become a single point of failure.
3. Open-weight models as the escape hatch. Open-weight frontier and small models (Europe's Mistral among them) let you keep the model itself under your control.
4. Own your embeddings and data. Treat embedding-model choice as a migration decision, keep the corpus and vector store yours, and prefer grounding over fine-tuning: retrieval against data you control is far more portable than behavior welded into a vendor's base model.

Your future AI architecture should look less like a stack and more like a portfolio.

Europe's response, and the honest gap

Europe is building compute: AI Factories, and an InvestAI plan aiming to mobilise ~€200B for AI overall, including a ~€20B fund for AI Gigafactories (European Commission). It matters. But we should be honest that it's ambition, not yet capacity: Europe still holds ~5% of global compute and one frontier-scale lab, and think-tanks like Bruegel argue the smarter play may be to "prosper below the tech frontier" in applied AI rather than chase parity (Bruegel). Either way, the organization-level lesson is the same: don't wait for the gap to close. Design for portability now.

How Soveryne keeps you unlocked

We built Counsel on exactly these principles. It answers from your frameworks and documents, grounded and cited, so the value lives in your knowledge, not in a vendor's proprietary model behavior. It runs on the Soveryne Cloud Foundation, where AI and LLM inference are EU-sovereign and the embeddings stay in your jurisdiction, under your control, not tied to a foreign provider's endpoint. The design goal is deliberate: adopt AI fully, keep your data and your optionality, and never trade one dependence for a deeper one. That's the difference between using AI and being captured by it.

FAQ

Why is AI lock-in worse than cloud lock-in? It forms faster and adds new binding mechanisms (API dependence, non-transferable prompt tuning, embedding data gravity, fine-tuning welded to a base model, and vendor-controlled deprecation) on top of ordinary data gravity.

What is embedding data gravity? A vector embedding only has meaning inside the model that created it, so switching embedding providers means re-embedding your entire corpus, often expensive enough that teams never switch. It's one of the strongest AI lock-in forces.

How do you avoid AI vendor lock-in? Use a model-abstraction layer, route across multiple models, favor open-weight models, keep your embeddings and data under your control, and prefer grounding (RAG) over fine-tuning into a provider's base model.

Is sovereign AI realistic for Europe? For frontier-model parity, not soon. But sovereignty at the level that matters to most organizations (keeping your data, inference, and optionality under EU control) is achievable today, and is where the practical value is.

Adopt AI aggressively; stay portable by design. See a grounded, cited, EU-sovereign AI assistant that keeps your data and your optionality: explore Counsel and the Soveryne Cloud Foundation.

Sources

• Stanford HAI, AI Index 2026: https://hai.stanford.edu/ai-index/2026-ai-index-report
• OECD, AI venture capital 2025 (2026): https://www.oecd.org/en/about/news/announcements/2026/02/ai-firms-capture-61-percent-of-global-venture-capital-in-2025.html
• Menlo Ventures, State of Generative AI in the Enterprise (2025): https://menlovc.com/perspective/2025-the-state-of-generative-ai-in-the-enterprise/
• Schift, Why Vector Migration Matters: https://schift.io/blog/why-vector-migration-matters/
• OpenAI, API deprecations: https://developers.openai.com/api/docs/deprecations
• US BIS, rescission of AI Diffusion Rule: https://www.bis.gov/press-release/department-commerce-announces-rescission-biden-era-artificial-intelligence-diffusion-rule-strengthens
• Typedef, State of LLM adoption: https://www.typedef.ai/resources/llm-adoption-statistics
• European Commission, AI Gigafactories: https://commission.europa.eu/topics/competitiveness/competitiveness-coordination-tool-projects/ai-gigafactories_en
• Bruegel, Catch up with the US or prosper below the tech frontier: https://www.bruegel.org/policy-brief/catch-us-or-prosper-below-tech-frontier-eu-artificial-intelligence-strategy

We spend enormous effort deciding where data lives: residency, encryption, key custody. Then we wire in an AI feature that takes the most sensitive record in the system, wraps it in a prompt, and sends it to a model running somewhere else entirely. The residency perimeter you built has a hole in it exactly the shape of an API call.

This post makes the technical case that AI inference is a data-processing event that has to happen on sovereign ground, and that this is not a nice-to-have but a consequence of how models actually work. It's the companion to our strategic piece on AI lock-in.

A prompt is a data transfer

Start with the obvious thing that's easy to forget. When you call an external model, you send it the prompt and whatever context you retrieved to ground the answer: the support ticket, the patient note, the contract clause. If that content contains personal or confidential data, then the API call is a transfer of that data to wherever the model runs, governed by that provider's jurisdiction.

And once it's there, its fate is out of your hands. Commercial providers typically retain API inputs for a window (often ~30 days for abuse monitoring) even under "we don't train on your data" terms, and retention means it can be compelled. In late 2025, a US court ordered a major AI provider to preserve and produce 20 million user conversation logs in a lawsuit; the provider objected that "more than 99.99%" of them had nothing to do with the case, and produced them anyway (OpenAI; Bloomberg Law). The lesson isn't about one company; it's structural. Prompts are retainable, discoverable data, governed by the legal system of the place the model runs.

Europe's regulators see it the same way. The European Data Protection Board's Opinion 28/2024 holds that an AI model can only be considered anonymous if the chance of extracting personal data "either directly or through queries" is negligible (EDPB). In other words, the query surface itself is a regulated processing surface. Inference is not a safe zone.

The embedding is a fingerprint of your text

Here's the part most people get wrong, and it's the crux of the whole argument. There's a comforting belief that embeddings (the vectors you compute to power retrieval and RAG) are "just numbers," anonymised, safe to compute anywhere. They are not.

An embedding is a lossy but recoverable fingerprint of the source text. Peer-reviewed research (Morris et al., EMNLP 2023) built a method, vec2text, that recovers 92% of short text inputs exactly from their embeddings alone, and, in their words, "can recover important personal information (full names) from a dataset of clinical notes" (ACL Anthology). The reason is a basic information-theory fact the authors invoke directly: a function "cannot add information to an input, [it] can only sustain or decrease" it (The Gradient). The embedding is a compression of your text. And compressions can be decompressed.

Two honest caveats, because overclaiming would undercut the point. The 92% figure is for short texts, roughly sentence- or chunk-length. Recovering a whole long document from one fixed-size vector is harder and, past some length, impossible. But note what that exception is: RAG systems store your corpus as exactly these short chunks. The unit that inverts cleanly is the unit vector databases are full of. And the attacks are getting cheaper: 2025 research demonstrated zero-shot embedding inversion that needs no model-specific training at all (ZSInvert, 2025). So "we only send embeddings to the foreign GPU, not the raw text" is not the safeguard it sounds like. Computing embeddings abroad exfiltrates the source by reduction.

Therefore: inference and embeddings must be regional

Put the two halves together. The prompt is a data transfer. The embedding is a recoverable copy. So if you're serious about keeping data in a jurisdiction, the model that processes it (for both inference and embedding) has to run in that jurisdiction too. There is no clever workaround, because the thing crossing the border is the data, in prompt form or vector form.

This is the sentence that trips up most "sovereign AI" stories: they region-lock the database and then send the prompt to a central GPU farm somewhere else. That defeats the entire design. Regional inference isn't a premium feature to bolt on; it's the load-bearing requirement. It does have a real cost (you duplicate inference capacity per region instead of pooling it globally), and we'd rather name that honestly than pretend it away. The prompt is the data; there's no free lunch.

How the Soveryne Cloud Foundation keeps the prompt at home

We built the Soveryne Cloud Foundation around this exact constraint, which is why the platform states it plainly: AI and LLM inference run on EU-sovereign infrastructure, so you get the intelligence without sending your data to a foreign cloud. Both inference and embedding happen in-region, on a platform we operate ourselves, so the prompt, the retrieved context, and the vectors never leave the jurisdiction you chose. Combined with region-locked tenancy and EU-held keys, the AI feature sits inside your residency perimeter instead of punching a hole in it.

It's also why Counsel is designed the way it is: it answers from your own documents, grounded and cited, on sovereign infrastructure, and, as we cover elsewhere, keeps you off any single foreign model. For the strictest needs, the Soveryne tier provides dedicated GPUs for AI inference in your own environment. Same principle, all the way down: if the data has to stay home, so does the model that reads it.

FAQ

Is sending a prompt to an AI model a data transfer? Yes. If the prompt or the context retrieved to answer it contains personal or confidential data, calling an external model transfers that data to wherever the model runs, governed by that provider's jurisdiction, and subject to its retention and legal process.

Are embeddings personal data? They can be. Research shows text embeddings can be inverted to recover the source: around 92% of short texts exactly, including personal details like names. An embedding is a recoverable fingerprint of the text, not an anonymised token.

Why does AI inference need to run in-region? Because the prompt and the embedding are the data. Region-locking your database but running inference elsewhere still sends the sensitive content across the border. Sovereign AI requires regional inference and embedding.

Doesn't regional inference cost more? Yes, you duplicate inference capacity per region rather than pooling it globally. That's the honest trade-off. But it's the only way to keep the data in jurisdiction, because the prompt is the data.

If the data has to stay home, so does the model that reads it. See EU-sovereign inference that keeps your prompts and embeddings in jurisdiction: explore the Soveryne Cloud Foundation and Counsel.

Sources

• Morris et al., Text Embeddings Reveal (Almost) As Much As Text, EMNLP 2023: https://aclanthology.org/2023.emnlp-main.765/
• Jack Morris, "Do text embeddings perfectly encode text?", The Gradient (2024): https://thegradient.pub/text-embedding-inversion/
• Zhang, Morris, Shmatikov, Universal Zero-shot Embedding Inversion (2025): https://arxiv.org/abs/2504.00147
• EDPB, Opinion 28/2024 on AI models and personal data: https://www.edpb.europa.eu/system/files/2024-12/edpb_opinion_202428_ai-models_en.pdf
• OpenAI, "Fighting the New York Times' invasion of user privacy" (2025): https://openai.com/index/fighting-nyt-user-privacy-invasion/
• Bloomberg Law, OpenAI ordered to turn over 20M ChatGPT logs (2025): https://news.bloomberglaw.com/ip-law/openai-must-turn-over-20-million-chatgpt-logs-judge-affirms
• OpenAI, Enterprise privacy (retention terms): https://openai.com/enterprise-privacy/

This is practical guidance for compliance and risk teams, not legal advice. Current as of July 2026.

Why finance got its own law

Banks, insurers, and market infrastructure now depend on technology, and on a small number of tech vendors, to deliver services across borders. When that ICT fails or is attacked, the disruption is systemic. Before DORA, the rules for managing this were fragmented across directives and national regimes. The Digital Operational Resilience Act (Regulation (EU) 2022/2554) replaced that patchwork with one harmonized regime. In force 16 January 2023; applicable from 17 January 2025 (EIOPA).

It applies to 20 types of financial entities, banks, payment and e-money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, (re)insurers, credit-rating agencies, crowdfunding providers and more (Art. 2(1)–(2), EUR-Lex), plus the critical ICT third-party providers they rely on.

The five pillars

(A quick myth-buster on Pillar 3: DORA requires entities using internal testers to bring in external testers "every three tests," not "every three years." Baseline TLPT runs at least every three years for significant entities.)

The two genuinely new obligations

Most of DORA restates good ICT practice. Two parts are new work for almost everyone.

The Register of Information. Every in-scope entity must maintain a register of all its ICT third-party contractual arrangements. It's not busywork: these registers feed the regulators' assessment of which providers are systemically critical. The first submission to the European Supervisory Authorities was due 30 April 2025; the 2024 voluntary dry run drew 1,039 entities from all 27 Member States; of the registers the ESAs were able to analyze, 93.5% failed at least one data-quality check (ESAs Dry Run report, 17 December 2024).

Oversight of Critical ICT Third-Party Providers. On 18 November 2025, the ESAs designated the first 19 critical ICT third-party providers. And the list is broader than the hyperscalers everyone expects. It spans cloud (AWS EMEA, Microsoft Ireland, Google Cloud EMEA, Oracle Netherlands), IT services (IBM, Accenture, Capgemini, Kyndryl, NTT DATA, TCS), market data (Bloomberg, LSEG, FIS), telecoms (Deutsche Telekom, Orange, Colt) and colocation (Equinix, InterXion), with SAP rounding it out. Each now has a Lead Overseer (ESAs).

And the board owns it. DORA Article 5 makes the management body bear ultimate, non-delegable responsibility for the ICT risk-management framework: approving the resilience strategy, continuity and recovery plans, and critical third-party arrangements, and keeping its own knowledge current through training.

Which frameworks map to DORA

DORA is also the sharpest case for the overlap dividend: most of it maps to security and continuity work you already run. DORA is deliberately framework-agnostic: it mandates no ISO or NIST standard. But its pillars map cleanly onto frameworks a mature financial entity likely already runs, which is how you make it manageable.

• ISO/IEC 27001 + ISO/IEC 27005 anchor Pillar 1 (security controls + risk methodology).
• ISO 22301 covers the continuity, response, and recovery requirements (Articles 11–12).
• NIST CSF 2.0 cross-cuts Pillars 1–3, and its Govern function aligns with the Article 5 board duties.
• ISO/IEC 20000-1 supports Pillar 4 third-party and service management; the ECB's TIBER-EU framework directly supports Pillar 3 testing.

(These are industry alignments that help you demonstrate DORA compliance, not legal requirements.)

Where Soveryne fits

DORA is the sharpest illustration of the series thesis: most of it is evidence you may already have, in the wrong shape. Command enrolls DORA and maps its five pillars to the ISO 27001, 22301, and 27005 controls behind them, so your existing security and continuity evidence is counted toward DORA rather than rebuilt. And its continuous validation keeps that evidence current for the resilience-testing and reporting obligations. The Register of Information is exactly the kind of living, auditable artifact Command is built to maintain rather than assemble in a panic before a supervisory request. DORA sits in Command alongside every other framework, with continuous validation included.

And for the interpretation questions that DORA generates in volume (is this incident "major"? what must this third-party contract include? does this vendor's designation change our obligations?), Counsel answers from the DORA text and the ESAs' technical standards with citations, so your first line of coverage is the regulation itself.

FAQ

When did DORA start applying? DORA entered into force on 16 January 2023 and became applicable on 17 January 2025.

What are DORA's five pillars? ICT risk management, incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing.

What is the DORA Register of Information? A register every in-scope entity must maintain of all its ICT third-party contractual arrangements. It feeds the regulators' assessment of which providers are critical; the first ESA submission was due 30 April 2025.

Which frameworks help with DORA compliance? ISO/IEC 27001 and 27005 (risk), ISO 22301 (continuity), NIST CSF 2.0 (cross-cutting), ISO/IEC 20000 (third-party/service), and TIBER-EU (testing). DORA mandates none of them, but they map to its pillars.

Most of DORA is evidence you already have, in the wrong shape. Map the five pillars to controls and keep the Register live with Command; resolve incident-classification and third-party questions with cited answers from Counsel.

Sources

• DORA (EUR-Lex): https://eur-lex.europa.eu/eli/reg/2022/2554/oj · EIOPA overview: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en
• ESAs, first designation of critical ICT third-party providers (18 Nov 2025): https://www.eba.europa.eu/publications-and-media/press-releases/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital
• RTS on threat-led penetration testing (2025/1190): https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng
• ECB, TIBER-EU aligned with DORA: https://www.ecb.europa.eu/press/intro/news/html/ecb.mipnews250211.en.html

Of all the layers in Europe's technology stack, cybersecurity is the one where the continent looks strongest. It has credible, scaled vendors: endpoint and anti-malware champions, some of the world's larger managed-detection providers, real depth in operational-technology security, privileged-access management, and cryptography. If you only read the vendor logos, you'd conclude Europe is doing fine here.

Then you look underneath, and the paradox appears. The high-value control planes of modern security (cloud-native security, hyperscale threat telemetry, identity, and the data layers behind detection and response) are overwhelmingly US-controlled. Worse, Europe's own security tools frequently run on the very US clouds, operating systems, and identity systems they are meant to protect. A cyber crisis in those layers wouldn't just be a security incident. It would be a sovereignty incident, expressed through the security stack itself.

Where Europe is genuinely strong

Let's give credit first, because the strength is real. Europe fields security vendors with global reach and growing revenue.

This is a real industry. But notice the shape of it: Europe's strength is concentrated in services and labour (managed detection, SOCs, consulting, operational security) and in specific product niches. As the European Parliament's dependency study puts it plainly, "US and Israeli vendors dominate tools such as firewalls, identity management, and SIEM systems, while EU firms specialise mainly in services" (EP, 2025).

The dependent substrate

Here is the layer the logos don't show. The most valuable, most defensible parts of the security market, the control planes, are US-held, and they're the ground everything else runs on.

• Detection data layers. North America accounts for 41.8% of global XDR revenue, and the top five XDR vendors, Palo Alto Networks, CrowdStrike, Microsoft, SentinelOne, and Trend Micro, hold 50–60% of the market (MarketsandMarkets). The leading SIEM platforms, Splunk (Cisco), Microsoft Sentinel, and IBM QRadar, are all US-owned.
• Identity. The dominant enterprise identity backplane is Microsoft Entra ID, and the economics are a moat: enterprise-license bundling makes identity effectively free with the productivity suite, so displacing it means replacing the whole stack that authenticates through it. When Entra has a bad day, everything authenticated through it has a bad day.
• Endpoint and OS. The most-deployed endpoint-security platforms are Microsoft Defender for Endpoint and CrowdStrike Falcon, both running on Windows, an operating system with 1bn+ active devices (Microsoft). That OS is the substrate European tools defend, and often run on.

The most authoritative statement of the paradox comes from the German Institute for International and Security Affairs (SWP), whose 2025 analysis is titled, simply, Europe's Cybersecurity Depends on the United States. Its sharpest finding: even if Europe built a full "EuroStack," "large parts of the cybersecurity information ecosystem and markets for cybersecurity products would remain dominated by the United States" (SWP, 2025). Sovereign cloud alone does not fix the security layer.

The proof is already on the record

This isn't theoretical. In July 2024, a single US security vendor's faulty update crashed roughly 8.5 million Windows devices worldwide, the largest IT outage in history, grounding airlines and disrupting hospitals and banks (CISA; Microsoft). The tool that took the endpoints down was the security tool, running kernel-level on a US OS. In October 2025, a configuration fault in a US identity/edge service rippled through collaboration platforms, airline check-in, and public-sector systems (The Register).

And in April 2025, US funding for the CVE vulnerability database (a piece of shared global infrastructure the entire industry depends on) nearly lapsed. It was restored, but "only for eleven months and on a limited basis," prompting the EU to stand up its own vulnerability database (SWP). The dependency runs all the way down to the reference data.

Why Europe's defenders struggle to reach the substrate

The gap isn't talent; it's scale and capital. Europe generates about 17% of new global enterprise value but captures only 10% of exit value, and European venture funding sits near $44bn a year against roughly $375bn of underfunding over the last decade (Atomico, State of European Tech 2025). The control-plane layers are winner-take-all: telemetry improves with scale, identity compounds with installed base, and network effects make catch-up "an impossible hill to climb" for latecomers, as the EP study puts it. Add an EU cybersecurity workforce gap of roughly 299,000 (ISC2, 2024), and you have an industry that produces excellent defenders who still, too often, plug into someone else's backplane.

The way out: sovereignty has to reach the substrate

The resolution to the paradox is not "buy European security tools." It's to make sure the ground those tools run on is sovereign too: EU-hosted infrastructure, EU-controlled identity, EU-held keys and telemetry. A European EDR that reports into a US-controlled data layer, or runs on a US identity system, has moved the logo without moving the dependency.

This is exactly why we built the way we did. Command (Soveryne's security-program workspace, with controls mapped and evidenced across People, Organization, and Technology, and threat intelligence triaged against your own controls) runs entirely on the Soveryne Cloud Foundation: EU-hosted, operated by an EU entity, EU-held keys, EU-sovereign AI inference, no US-jurisdiction subprocessor in the data path. The telemetry, the identity, the evidence, and the keys stay in jurisdiction. And because we're built by offensive specialists, the defenses are designed the way attackers actually break them, the subject of our companion technical post.

Sovereign security that runs on dependent ground isn't sovereign. It's just better-branded dependency.

FAQ

Isn't European cybersecurity already strong? In services and specific product niches, yes: Europe has real, scaled vendors. But the high-value control planes (cloud-native security, XDR/SIEM telemetry, identity, endpoint OS) remain US-dominated, and European tools often run on them.

What is the "cyber paradox"? That Europe's defensive security industry, its relative strength, frequently depends on the very US clouds, operating systems, and identity systems it is meant to protect, so a failure or coercion in those layers becomes a security and sovereignty crisis.

Does building a European sovereign cloud fix cybersecurity dependence? Not on its own. As SWP Berlin notes, much of the cybersecurity product and threat-intelligence ecosystem would remain US-dominated even with a European cloud. Sovereign security must also cover identity, telemetry, keys, and the tools themselves.

What does "sovereign security" actually require? EU-hosted infrastructure, EU-controlled identity, EU-held encryption keys, EU-controlled detection telemetry, not just EU-branded tools running on foreign backplanes.

A shield is only as sovereign as the ground it stands on. See security operations that run on EU-sovereign infrastructure end to end: explore Command and the Soveryne Cloud Foundation.

Sources

• SWP Berlin, Europe's Cybersecurity Depends on the United States (2025): https://www.swp-berlin.org/en/publication/europes-cybersecurity-depends-on-the-united-states
• European Parliament, European Software and Cyber Dependencies (2025): https://www.europarl.europa.eu/RegData/etudes/STUD/2025/778576/ECTI_STU(2025)778576_EN.pdf
• ENISA, Cloud Cybersecurity Market Analysis: https://www.enisa.europa.eu/publications/cloud-cybersecurity-market-analysis
• CISA, CrowdStrike outage alert (2024): https://www.cisa.gov/news-events/alerts/2024/07/19/widespread-it-outage-due-crowdstrike-update
• Microsoft / CNBC, 8.5M devices affected (2024): https://www.cnbc.com/2024/07/20/microsoft-says-about-8point5-million-of-its-devices-affected-by-crowdstrike-related-outage.html
• The Register, EU resilience after Azure outage (2025): https://www.theregister.com/2025/10/30/europe_azure_outage_reaction/
• MarketsandMarkets, XDR market: https://www.marketsandmarkets.com/ResearchInsight/extended-detection-response-market.asp
• ISC2, EU Cybersecurity Workforce Study (2024): https://digital-skills-jobs.europa.eu/system/files/2024-12/ISC2_Workfoce-Study-Findings-EU.pdf

If you're deploying an AI assistant, the most important security fact to internalise is this one, from the UK's National Cyber Security Centre: "Under the hood of an LLM, there's no distinction made between 'data' or 'instructions'; there is only ever 'next token.'" (NCSC, 2025) A language model reads the trusted system prompt and the untrusted document you fed it through the same channel, with no built-in boundary between them. That is why an instruction hidden in a webpage, an email, or an uploaded file can hijack the model, and why the industry's own standards body says there may be no fool-proof fix.

This is the companion to our piece on the cyber paradox. There we argued sovereign security has to reach the substrate. Here we go a layer deeper, into the newest and least-understood attack surface, and how to build against it the way an attacker would test it.

Prompt injection is OWASP's #1 LLM risk

The OWASP Top 10 for LLM Applications (2025) ranks the risks, and Prompt Injection sits at number one (LLM01) (OWASP).

There are two flavours. Direct injection is when a user's own input subverts the model. Indirect injection, the dangerous one for any system that reads external content, is when malicious instructions are smuggled in via a retrieved document, a web page, or an email the model processes. OWASP is blunt about the ceiling: "Given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection."

Why it's structurally hard (and different from SQL injection)

It's tempting to assume this is like SQL injection: a solved problem, if you parameterise your queries. It isn't. As NCSC explains, SQL injection can be fully mitigated because you can separate code from data; prompt injection likely can't, because the model has no such separation. The best you can do is "reducing the likelihood or impact of attacks." NCSC's design conclusion is worth quoting to any team shipping an agent: "If the system's security cannot tolerate the remaining risk, it may not be a good use case for LLMs."

The most useful mental model for the impact side is Simon Willison's "lethal trifecta": an AI agent becomes dangerous when it simultaneously has (1) access to private data, (2) exposure to untrusted content, and (3) the ability to communicate externally (Willison, 2025). Any two are survivable. All three together let attacker-controlled text read your secrets and ship them out, with no exploit code required.

This isn't hypothetical. In 2025, researchers disclosed a zero-click prompt-injection exploit against a major AI assistant (CVE-2025-32711, CVSS 9.3): a booby-trapped email, retrieved later by the assistant, silently exfiltrated data with no user action (The Hacker News). A separate class of attacks hides instructions in code-repository comments to steal secrets. The recurring exfiltration channel across nearly all of them is the same: coaxing the model to render a remote image or link whose URL carries the stolen data.

Defense in depth: shrink the blast radius

Since you can't eliminate the vulnerability, you engineer so that a successful injection can't accomplish much. The techniques that actually work are layered and mostly deterministic, not "ask the model nicely."

Two honesty caveats, because this field is full of overclaims. Content-marking "raises the bar significantly… but does not hold up against determined adaptive adversaries" (Microsoft). And even strong architectural defenses that isolate a "quarantined" model from tools neutralise most, not all, attacks, and they cost you capability: one leading design still solves only ~67% of tasks on the AgentDojo benchmark (Google DeepMind/ETH). Anyone selling you a product that "stops prompt injection" doesn't understand the problem. The goal is defense in depth, not a silver bullet.

How we harden AI in the Soveryne Cloud Foundation

Because Soveryne is built by offensive specialists, we treat the model as a component an attacker will try to turn against you, and we build the layers accordingly, on the Soveryne Cloud Foundation.

Untrusted content is sanitised and fenced before it ever reaches the model: hidden control characters and disguised role markers are stripped, and any external data is wrapped so the model can't mistake it for an instruction. The assistant runs under least privilege, with high-risk actions handled in code rather than delegated to the model. Every answer passes a deterministic post-generation verifier that checks it is actually grounded in the trusted sources. Off-topic or unsupported output is caught, not rendered. The classic exfiltration channels are closed by a strict content-security policy and egress controls, so a coaxed remote-image beacon has nowhere to call home. And every interaction is logged to a tamper-evident trail for review.

This is also why our AI assistant, Counsel, answers only from your own frameworks and documents and cites every source: grounding isn't just a trust feature, it's a security control; it makes ungrounded, injected instructions visibly out of place. All of it runs on EU-sovereign infrastructure, so hardening the AI and keeping it in jurisdiction are the same piece of work.

FAQ

What is prompt injection? An attack where text (from a user, or hidden in a document, web page, or email the model reads) subverts an AI system's behavior, because the model can't reliably tell instructions from data. It's OWASP's #1 LLM risk.

Can prompt injection be fully prevented? Almost certainly not, according to OWASP and the UK's NCSC: unlike SQL injection, there's no clean separation of code and data in an LLM. The realistic goal is defense in depth that shrinks the impact of a successful injection.

What is the "lethal trifecta"? Simon Willison's model: an AI agent is dangerous when it combines access to private data, exposure to untrusted content, and the ability to send data externally. Removing any one of the three contains the risk.

How do you stop AI data exfiltration? Break the outbound channel: block auto-rendered remote images and links, allow-list egress, apply least privilege and human approval for risky actions, and verify that outputs are grounded before acting on them.

You can't "solve" prompt injection, but you can build so it barely matters. See how the Soveryne Cloud Foundation hardens AI end to end: explore the platform and Counsel, or read the companion piece on the cyber paradox.

Sources

• OWASP Top 10 for LLM Applications 2025: https://genai.owasp.org/llm-top-10/ ; LLM01 Prompt Injection: https://genai.owasp.org/llmrisk/llm01-prompt-injection/
• NCSC, "Prompt injection is not SQL injection (it may be worse)" (2025): https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
• NIST AI 100-2e2025, Adversarial ML taxonomy: https://csrc.nist.gov/pubs/ai/100/2/e2025/final
• Simon Willison, "The lethal trifecta" (2025): https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
• Microsoft, "Defending Against Indirect Prompt Injection With Spotlighting": https://arxiv.org/abs/2403.14720
• OpenAI, "The Instruction Hierarchy": https://openai.com/index/the-instruction-hierarchy/
• Google DeepMind / ETH Zürich, "Defeating Prompt Injections by Design" (CaMeL): https://arxiv.org/abs/2503.18813
• The Hacker News, zero-click AI vulnerability (CVE-2025-32711): https://thehackernews.com/2025/06/zero-click-ai-vulnerability-exposes.html

This is practical guidance for compliance teams, not legal advice. Current as of July 2026.

Two laws, two objects

NIS2 governs organizational cybersecurity. The Cyber Resilience Act governs product cybersecurity. Knowing which one is talking to you is the first step.

NIS2: Directive (EU) 2022/2555

Why it exists: NIS1 was narrow, fragmented, and weakly enforced. NIS2 widens scope to 18 sectors, harmonizes the criteria, tightens reporting, and adds two things that changed the game: supply-chain security and direct management accountability.

Who's in scope: essential entities (energy, transport, banking, health, water, digital infrastructure, public administration and more) and important entities (postal, waste, chemicals, food, manufacturing, digital providers, research), generally medium-sized and above (≥50 staff or ≥€10M turnover), with some entities in scope regardless of size.

What it requires:

• Article 21 (ten minimum risk-management measures): risk analysis and security policies, incident handling, business continuity and backups, supply-chain security, security in acquisition/development/maintenance, effectiveness assessment, cyber hygiene and training, cryptography, HR security and access control, and MFA/secure communications.
• Article 20 (accountability): management bodies must approve and oversee the measures, undergo training, and can be held personally liable, including, in some Member States, temporary management bans.
• Article 23 (reporting): early warning 24 hours, notification 72 hours, final report 1 month.

Fines: essential entities €10M or 2% of global turnover; important entities €7M or 1.4%. And enforcement is live: on 8 July 2026 the Commission referred Ireland, Spain, France, and the Netherlands to the EU Court of Justice for failing to transpose NIS2 (Commission).

The Cyber Resilience Act: Regulation (EU) 2024/2847

Why it exists: products with digital elements shipped with known vulnerabilities, no updates, and no transparency. The CRA imposes horizontal, lifecycle security requirements on hardware and software placed on the EU market: secure-by-design, no known exploitable vulnerabilities at release, vulnerability handling with coordinated disclosure, free security updates over a support period, and conformity assessment with CE marking.

Dates: in force 10 December 2024; reporting obligations from 11 September 2026 (actively exploited vulnerabilities and severe incidents, on a 24h/72h/14-day cadence); main obligations from 11 December 2027. Fines up to €15M or 2.5% of global turnover (EUR-Lex).

(A third instrument, the Cyber Solidarity Act (2025/38, in force February 2025), builds EU-wide detection and emergency response, context rather than a control obligation.)

The frameworks to adopt, and the official mapping

Here is the practical relief. In June 2025, ENISA published Technical Implementation Guidance that maps each NIS2 Article 21 measure directly to ISO/IEC 27001:2022 and NIST CSF 2.0, an official signal that you can reuse an existing security program as NIS2 evidence.

Sources: ENISA NIS2 guidance; NIST CSF 2.0.

The message, echoing the overlap dividend: you do not need a bespoke program per cyber law. Run a mainstream baseline (ISO 27001 / NIST CSF 2.0), add IEC 62443 where you have operational technology and CRA product controls where you ship software. And map, don't reinvent.

Where Soveryne fits

NIS2 and the CRA are the clearest case for "map once, prove many." Command does exactly what ENISA's guidance implies: it enrolls NIS2 alongside ISO 27001 and maps the shared controls once, so your ISO 27001 evidence counts as NIS2 evidence rather than being rebuilt. Its coverage spans People, Organization, and Technology, matching NIS2's mix of training (People), governance and supply-chain (Organization), and technical controls (Technology), with continuous validation so the 24/72-hour reporting posture and the Article 21 measures stay demonstrably in place. Command is built around exactly this: the frameworks that apply to you, operated, not papered.

And when the scoping and interpretation questions come (are we an essential or important entity? does Article 21 require MFA everywhere?), Counsel answers from NIS2, the CRA, and the ENISA guidance with citations, so the coverage question is settled from the source, not a forum thread.

FAQ

Who has to comply with NIS2? Essential and important entities across 18 sectors, generally medium-sized and above, plus some entities regardless of size (e.g. DNS and TLD registries). Exact scope depends on national transposition.

What frameworks satisfy NIS2? ISO/IEC 27001:2022 and NIST CSF 2.0 are the primary references. ENISA's June 2025 guidance officially maps NIS2's Article 21 measures to both. Add IEC 62443 for operational technology.

How is the CRA different from NIS2? NIS2 governs how an organization runs security; the CRA governs the security of products with digital elements across their lifecycle: secure-by-design, vulnerability handling, and updates.

Can management be held liable under NIS2? Yes. Article 20 makes management bodies responsible for approving and overseeing cyber measures, and Member States may impose personal liability, including temporary management bans.

Reuse your security program as NIS2 evidence rather than rebuilding it. Map controls once with Command, and settle scope and interpretation with cited answers from Counsel.

Sources

• NIS2 (EUR-Lex): https://eur-lex.europa.eu/eli/dir/2022/2555/oj
• Cyber Resilience Act (EUR-Lex): https://eur-lex.europa.eu/eli/reg/2024/2847/oj
• ENISA, NIS2 Technical Implementation Guidance (maps NIS2 → ISO 27001 / NIST CSF 2.0): https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance
• European Commission, NIS2 CJEU referral, 8 July 2026: https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1499
• NIST CSF 2.0: https://www.nist.gov/cyberframework · CIS Controls v8.1: https://www.cisecurity.org/controls/v8-1 · ISA/IEC 62443: https://www.isa.org/

Whenever "digital sovereignty" comes up, someone reaches for the strawman: so you want Europe to build its own version of everything and wall itself off? It's an easy position to dismiss, because it would be slow, expensive, and worse for everyone. But it is not what sovereignty means, and treating it as the goal is how organizations talk themselves into doing nothing.

The first three posts in this series mapped the dependence, showed how ordinary tools become critical, and explained why compliance isn't the finish line. This is the pivot. The realistic objective is not autarky. It is selective autonomy: sovereign capacity where it genuinely matters, openness everywhere else, and the ability to tell the difference.

What digital sovereignty actually means

Start with the definition that the EU's own research service uses. The Joint Research Centre defines digital sovereignty as "the EU's capacity to exercise independence in the digital realm while remaining open and connected to global networks" (JRC Policy Brief JRC144908, 2025). The clause after the "while" is not decoration; it makes the definition itself anti-autarky.

That phrase is the whole argument. Not closed. Not powerless. The goal is the capacity to decide: to operate, switch, secure, and scale critical infrastructure without unacceptable exposure to foreign compulsion, lock-in, or coercion. Self-sufficiency is one possible means to that end, and usually a bad one.

Europe already proves the point

The case for selective autonomy isn't theoretical. Europe lives it. The continent is deeply dependent in cloud and AI, yet it holds one of the most asymmetric chokepoints on the planet: a single Dutch company builds close to 100% of the world's most advanced lithography machines, the tools required to make every leading-edge chip (Yole Group). When Washington wanted to restrict China's access to advanced chipmaking, it needed Dutch cooperation to do it.

That is sovereignty as leverage, not isolation. Europe didn't get it by building everything; it got it by being indispensable at one critical point. The lesson scales down to any organization: you don't need to own the whole stack. You need control where control is decisive.

How to decide what needs to be sovereign

The practical tool is workload tiering: sorting what you run by how much sovereign control it actually requires, then spending your scarce sovereignty budget where it counts.

Most organizations discover that the share of workloads needing full sovereignty is smaller than they feared, but that those workloads are exactly the ones they'd been treating most casually. The point of tiering is not to move everything. It's to stop treating your crown jewels like your marketing site.

The honest part: what sovereignty costs

A credible sovereignty argument has to be honest about price, because pretending it's free is how trust gets lost. So, plainly: there are two cost stories, and which one applies depends on what you mean by "sovereign cloud."

• Sovereignty bolted onto a foreign hyperscaler, a "sovereign region" SKU, typically carries a 15–30% price premium over standard regions (BCG, 2025). You pay more, and you still inherit the parent company's jurisdiction.
• Sovereignty as "use a European provider" is frequently cheaper, not more expensive. European providers are often far less costly on compute, and dramatically cheaper on data egress, where hyperscaler fees can run dozens of times higher.

There are real costs to genuine sovereignty: duplicated AI inference capacity per region, smaller economies of scale in some places. We won't pretend otherwise. But the framing that "sovereignty always costs more" is simply false; often the dependency is what's quietly expensive.

Where US "sovereign cloud" offers help, and where they stop short

To be fair to the alternatives: the major US providers' sovereign offerings are real engineering, and they do reduce some exposure: EU data boundaries, EU-resident operations, customer-managed keys, EU-governed subsidiaries. For some workloads, that's enough.

What they don't change is the part that matters most for Tier 1: the controlling parent remains subject to foreign law, the software roadmap stays foreign-controlled, and as CarMax's Eric Swanson put it to InfoQ, "US ownership and headquarters mean US law can still apply to the provider, regardless of where the infrastructure runs. Sovereign cloud offerings do not override the Patriot Act." (InfoQ, 2026). Selective autonomy means using those offers where they fit, and reserving genuinely sovereign infrastructure for the workloads where "mostly sovereign" isn't good enough.

Why we built Soveryne for the middle path

This is the worldview the whole company is built on, so we'll state it plainly. We did not build Soveryne to help anyone wall themselves off from the world's best technology. We built it so that European organizations can keep the workloads that matter under genuine EU control: by default, pragmatically, without a multi-year rebuild.

That's why the Soveryne Cloud Foundation is EU-sovereign by default, not by upgrade: keys in EU jurisdiction, compute in the EU regions you choose, AI inference that stays home, and an open-source core you can inspect. It's why Command and Counsel run on that foundation rather than treating sovereignty as a checkbox. And it's why our pitch is pragmatic to the point of bluntness: get in touch, and if we're not the right fit for a given workload, we'll say so. That is what selective autonomy looks like as a product.

FAQ

What does digital sovereignty actually mean? The capacity to exercise independence over your digital infrastructure (to decide, operate, switch, and secure it without unacceptable foreign exposure) while remaining open and connected to global networks. It is not self-sufficiency.

Is digital sovereignty the same as building everything in Europe? No. That's autarky, and it's neither realistic nor desirable. Sovereignty is about control where it matters, achieved through leverage, portability, and selective autonomy.

Does sovereign cloud always cost more? No. Hyperscaler "sovereign region" SKUs carry roughly a 15–30% premium, but independent European providers are often cheaper than hyperscalers, especially on data egress. The cost depends entirely on the approach.

Are US "sovereign cloud" offerings good enough? For some workloads, yes. For Tier 1 (defense, justice, health, core administration, critical infrastructure), they leave the controlling parent under foreign law, which is exactly the exposure those workloads can't accept.

Sovereignty isn't a wall; it's a dial you set per workload. The companion technical post shows how that dial is enforced in code. To see sovereign-by-default in practice, explore the Soveryne Cloud Foundation or get in touch.

Sources

• JRC, Open but Not Powerless: Towards a Common Understanding of EU Digital Sovereignty (2025): https://publications.jrc.ec.europa.eu/repository/handle/JRC144908
• Yole Group, EU semiconductor equipment leadership: https://www.yolegroup.com/strategy-insights/underappreciated-eu-suppliers-lead-the-semiconductor-equipment-market/
• BCG, Cloud Cover: price, sovereignty demands, and waste (2025): https://www.bcg.com/publications/2025/cloud-cover-price-sovereignty-demands-waste
• InfoQ, analysis of US-parented sovereign cloud and CLOUD Act exposure (2026): https://www.infoq.com/news/2026/01/aws-european-sovereign-cloud/
• European Commission, Draghi report on European competitiveness: https://commission.europa.eu/topics/competitiveness/draghi-report_en

"Your data stays in the EU" is a sentence. Sovereignty is whether that sentence is enforced at every layer that touches the data, and whether you can run a test that fails if it isn't. A residency promise that lives only in a contract or a config screen is a promise, and the record is that promises break: asked under oath at the French Senate whether Microsoft could guarantee French data would never be passed to US authorities, Anton Carniaux answered "Non, je ne peux pas le garantir" (French Senate hearing, 10 June 2025). A residency guarantee the system has no code path to violate is architecture.

This post walks through how to make geography a first-class property of a platform: a single region choice that binds data, compute, and AI inference together; a lock that turns that choice into a commitment; enforcement at the points where bytes actually move; and a test that serves as the receipt.

Geography has to be a property, not a setting

The mistake most "regional" systems make is treating location as a deployment detail: something you configure per service and hope stays consistent. Sovereignty needs the opposite: one region label that every layer reads, so a tenant tagged for a given EU region writes to EU storage, runs on EU compute, and never even produces an internal request that a non-EU worker could pick up.

The goal is that a customer's data, and the compute that touches it, stay in a named region by construction, not by careful operations.

Seven layers, one region

Genuine regional isolation isn't a single feature; it's the same region decision enforced at every layer, so there is no seam where data can leak out.

The single most powerful primitive here is the explicit exclusion, and it is exactly what the Commission's own Cloud Sovereignty Framework implementation guidance requires at level SOV-3: "strict confinement of storage and processing to European jurisdictions, with no fallback to third countries." A replication policy that says, in effect, "replicate three copies inside this EU region, and zero copies anywhere else" means the data layer will not stream that tenant's data outside the region, not as a matter of policy, but because the system has no instruction that would let it. Sovereignty by absence of capability.

The region lock: a commitment device

Letting a tenant casually flip regions sounds like flexibility. It's actually a data-leak path: every easy migration is a moment when data crosses a boundary. So the region, once chosen, should lock.

A region lock is a commitment device: it makes the easy path the sovereign one, and forces the rare, legitimate case of moving a tenant to go through an explicit, consented, audited export rather than a quiet config change. Moving a tenant should cost the operator a deliberate act. That cost is the point.

Enforcement: sovereignty you can't accidentally undo

Layers and locks are only real if something refuses to break them. Three enforcement checkpoints close the loop, and they're deliberately redundant, defense in depth, so a mistake at one layer is caught at another:

1. At the data layer. Before any read or write executes, the system asserts the tenant's region equals the local region. A mismatch is refused and recorded. This is the one checkpoint that actually touches bytes; if it's correct, the rest is reinforcement.
2. At the dispatch layer. A request that arrives for a tenant belonging to another region is rejected outright (think: a clear "wrong region" refusal) rather than processed.
3. At the audit layer. Every cross-region attempt is written to the tamper-evident log as a sovereignty event, so drift is visible and reviewable, not silent.

The receipt: a test that fails if sovereignty is broken

Here is the part that separates a sovereignty claim from a sovereignty guarantee, and it's the simplest idea in this whole post: write a test that tries to break the boundary, and assert that it fails.

Spin up a tenant in one EU region. From another region, attempt a read of that tenant's data. Assert that the attempt is refused. That single automated test is the receipt: proof that residency is wired through end to end, and a tripwire that catches the day a refactor quietly breaks the contract. Without it, every code change is a chance to silently lose sovereignty. The Commission's own framework relies "on self-assessment and self-declaration", a real gap, and one we propose closing with an automated cross-region test. If it isn't tested, it isn't sovereign, our proposal, not established practice.

And the inference, too: because the prompt is the data

One boundary is easy to forget: AI. An embedding or a prompt sent to a model in another region is a data transfer like any other. In fact, an embedding vector is a lossy fingerprint of the source text, so computing it elsewhere exfiltrates the source by reduction. Region-locking the data and then shipping the prompt to a central GPU farm abroad would defeat the entire design. So inference and embedding have to be per-region too, running on the same sovereign ground as the data. (We make this case in full in a later post, but it's a first-class constraint here, not an afterthought.)

How the Soveryne Cloud Foundation implements the dial

This is not a thought experiment for us; it's how the Soveryne Cloud Foundation is built. You choose the EU regions your data and compute live in, and that choice is bound across storage, processing, and routing: geographically controlled in transit and at rest, by design. Compute clusters are distributed across the EU and pinned to the regions you select. AI and LLM inference run on EU-sovereign infrastructure in-region, because the prompt is the data. And because the foundation is operated end to end by an EU entity, with no US-jurisdiction subprocessor in the data path, the region you choose is a commitment the architecture keeps, not a setting we promise to honor.

For organizations that need the strongest isolation, the Soveryne tier provides a dedicated environment with its own inference GPUs and on-premises options. The dial goes all the way to the top, and you can see exactly where it's set.

FAQ

What does "data residency by design" mean? That residency is enforced by the architecture at every layer (storage, compute, routing, and inference) rather than configured per service and trusted to stay consistent. The system cannot move the data out of region because it has no instruction that would let it.

How do you prove data never leaves a region? With enforcement at the data, dispatch, and audit layers, and an automated cross-region rejection test: attempt to access a region-locked tenant from another region and assert the attempt fails. That test is the proof.

What is a region lock? A commitment that, once a tenant's region is set, it can't be casually changed. Moving the tenant requires an explicit, consented, audited export and re-provision, so the easy path is always the sovereign one.

Why does AI inference need to be regional? Because a prompt or embedding sent to a model elsewhere is a data transfer: an embedding is a compressed fingerprint of the source. Region-locking data but not inference would leak the very data you protected.

A residency promise you can't test is just a promise. See the region-locked, EU-sovereign foundation that makes it provable: explore the Soveryne Cloud Foundation, or read the companion piece on why sovereignty is selective, not total.

Sources

• JRC, Open but Not Powerless: Towards a Common Understanding of EU Digital Sovereignty (2025): https://publications.jrc.ec.europa.eu/repository/handle/JRC144908
• European Commission, Cloud Sovereignty Framework explained (2026): https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01_en
• French Senate hearing transcript (Microsoft France under oath, 10 June 2025): https://www.senat.fr/compte-rendu-commissions/20250609/ce_commande_publique.html

This is practical guidance for compliance teams, not legal advice. Current as of July 2026.

Why GDPR exists

Before 2018, Europe had 28 national interpretations of a 1995 directive and a digital economy running on personal data. GDPR (Regulation (EU) 2016/679) replaced that patchwork with one directly-applicable law: harmonized rules, enforceable individual rights, and, its defining move, the accountability principle (Article 5(2)). You must be able to demonstrate compliance, not merely assert it. In force 24 May 2016, applicable from 25 May 2018 (EUR-Lex).

The obligations that generate real, recurring work (and the same pattern shows up in the overlap dividend):

Maximum fine: €20M or 4% of global annual turnover (Art. 83). Cumulative GDPR fines now exceed €6 billion, the largest being €1.2 billion against Meta (2023) for unlawful EU–US transfers (Enforcement Tracker).

Two things people get wrong about the privacy landscape

• ePrivacy is not a coming regulation. The 2002 ePrivacy Directive (the "cookie law") is still in force and applied through national law. The proposed ePrivacy Regulation was withdrawn in 2025. Don't plan around it.
• Health data has its own overlay, on a long fuse. The European Health Data Space (Regulation (EU) 2025/327) entered into force 26 March 2025, but its major obligations apply from 2029 (and 2031 for further data categories). For health organizations it's a roadmap, not an immediate scramble.

The frameworks that prove privacy compliance

GDPR tells you what. These frameworks are how you demonstrate it, and one of them changed materially in 2025.

Sources: ISO/IEC 27701:2025; NIST Privacy Framework.

The worked example that ties the series together: GDPR's accountability obligation (Art. 5(2)) → an ISO 27701 control for documented processing and roles → the evidence artifact (your RoPA, DPIA, and access logs). One obligation, one control, one piece of evidence, reusable the next time an auditor asks.

Where Soveryne fits

Privacy is the domain where "demonstrate" bites hardest, and where the two Soveryne jobs are clearest.

When a data-subject request lands, or a transfer question comes up, or you're not sure whether a processing activity needs a DPIA, that's coverage intelligence: Counsel answers from GDPR and its guidance, and from your own uploaded policies and records, with every claim cited, so a DPO gets a grounded answer in seconds instead of re-reading the regulation. Its knowledge base already includes GDPR alongside NIS2, DORA, ISO/IEC and NIST.

When the auditor asks you to prove accountability, that's proof of implementation: Command maps your GDPR obligations to ISO/IEC 27701 and 27001 controls, tracks the evidence for each, and, because privacy controls overlap heavily with security controls, lets that same evidence count toward your NIS2 and ISO 27001 posture at the same time. Demonstrating GDPR compliance stops being a separate project and becomes part of one evidenced control library. And it all runs on EU-sovereign infrastructure, which, for a privacy program, is the point.

FAQ

Which framework best demonstrates GDPR compliance? ISO/IEC 27701 (now a standalone privacy information management system standard that maps its controls to GDPR articles) is the strongest single tool, layered on ISO/IEC 27001 for the security side.

Is ISO 27701 the same as GDPR? No. GDPR is the law; ISO 27701 is a certifiable management system that helps you demonstrate you meet it. Certification is strong evidence but not a legal safe harbor.

Do I still need to worry about ePrivacy / cookies? Yes: the 2002 ePrivacy Directive is still in force via national law. But the proposed ePrivacy Regulation was withdrawn in 2025, so don't plan around it.

When does the European Health Data Space start applying? It entered into force in March 2025, but its major obligations apply from 2029 (and 2031 for further data categories), a long runway for health-sector organizations.

Privacy compliance is provable, not just promised. Get cited answers on GDPR with Counsel, and map obligations to evidenced ISO 27701 controls with Command.

Sources

• GDPR (EUR-Lex): https://eur-lex.europa.eu/eli/reg/2016/679/oj
• European Health Data Space (Regulation 2025/327): https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space-regulation-ehds_en
• ISO/IEC 27701:2025: https://www.iso.org/standard/27701
• NIST Privacy Framework: https://www.nist.gov/privacy-framework
• GDPR Enforcement Tracker: https://www.enforcementtracker.com/statistics

Europe has built, in under a decade, the most comprehensive digital rulebook on Earth. NIS2, DORA, the Cyber Resilience Act, the Cyber Solidarity Act, the Data Act, the AI Act, and, in 2026, a tech-sovereignty package on top. If regulation alone produced sovereignty, Europe would already be sovereign.

It isn't. And the reason is a gap most boards never see: Europe is writing rules about its dependencies faster than it is building the substitutes for them. An organization can be fully compliant and still be one foreign legal order, one licensing change, or one provider outage away from losing control of its own operations.

This post is about that gap: what the rulebook does and doesn't buy you, and why "we passed the audit" is the beginning of the sovereignty conversation, not the end.

The rulebook is real, and growing fast

First, credit where due. The European rulebook is not theatre; it has teeth, and it is converging on dependence as a named risk.

Notice what DORA in particular represents. When the European Supervisory Authorities formally designated 19 critical ICT third-party providers (names like AWS, Microsoft, and Google among them), they were, in effect, publishing a list of the dependencies the system cannot yet replace. Regulation has become honest about the problem. It has not yet solved it.

What an audit proves, and what it doesn't

Here is the distinction that matters. A compliance certificate is evidence that you have managed a risk to a defined standard. It is not evidence that you have removed the dependency.

You can satisfy every line on the left and still be structurally dependent. A US-headquartered "EU region" can be fully GDPR- and NIS2-aligned on paper while remaining reachable under foreign law, a point a hyperscaler conceded under oath in 2025, when Microsoft France told the French Senate it could not guarantee French data would never be passed to US authorities (The Register). The audit was never designed to catch that. (We dig into exactly who can be compelled, and why, in the companion piece, Who Can Actually Compel Your Data?)

Why the gap keeps widening

The deeper problem is one of pace. Rules can be written in months; infrastructure takes years and tens of billions. And the spending gap between Europe's substitutes and the incumbents it depends on is stark.

On the build side, the EU's flagship sovereign-cloud procurement (a tender awarded to four European providers in April 2026) was worth €180 million (European Commission). In the same period, a single hyperscaler committed €15.7 billion to data centers in Spain alone (Amazon), with Microsoft and Google each committing billions more across the continent. Europe's own auditors concluded the Chips Act will likely reach only 11.7% of the global chip value chain by 2030, against a 20% target (European Court of Auditors).

The rulebook is a powerful lever. But you cannot regulate a substitute into existence as fast as a competitor can build the thing you depend on. That is the gap.

What to do while the gap exists

The pragmatic move is not to wait for Europe to "win," and not to treat compliance as the finish line. It is to turn the same effort you already spend on compliance into a genuine reduction in dependence.

1. Tier your workloads. Decide which functions truly need sovereign treatment and which don't. Not everything has to move; the crown jewels do. (We make the full case for this in Sovereignty Is Not Autarky.)
2. Make "can we leave?" an audit question. A tested exit plan is worth more than a binder of policies. DORA already requires it for critical functions. Apply it everywhere that matters.
3. Control the keys. The single highest-leverage step: hold your own encryption keys, so compliance with "encryption at rest" also reduces who can be compelled.
4. Do the compliance once, across frameworks. Evidence collected for NIS2 should count toward DORA and ISO 27001, and should map to controls that genuinely lower dependence, not just satisfy an auditor.

This last point is where compliance and sovereignty stop being in tension. Command turns the frameworks that apply to you into controls that are drafted, mapped, and continuously evidenced across NIS2, DORA, and ISO 27001, so the work you do to pass an audit is the same work that maps and reduces your real dependencies. And because it runs on the Soveryne Cloud Foundation (EU-hosted, operated by an EU entity with no US-jurisdiction subprocessor in the data path and no US-held keys), passing the audit and reducing the dependency become the same motion rather than two competing ones. If DORA is your driver, Command covers unlimited frameworks with continuous validation (see how pricing works).

FAQ

Can you be NIS2 or DORA compliant and still be dependent on US tech? Yes. Compliance proves you have managed a risk to a standard; it does not prove you have removed the underlying dependency or that your provider is beyond foreign legal compulsion.

What's the difference between compliance and sovereignty? Compliance is meeting a defined regulatory standard. Sovereignty is the operational capacity to control, operate, and switch your infrastructure without unacceptable foreign exposure. You can have the first without the second.

Does DORA solve cloud concentration risk? DORA brings critical ICT providers under direct EU oversight and requires exit strategies (important steps), but oversight is not substitution. The dependence remains until alternatives exist and are adopted.

How can compliance work also reduce dependence? By mapping each control to the framework and to the dependency it addresses, and by holding your own keys and testing your exits. So audit evidence doubles as a sovereignty measure.

Passing the audit is necessary. It is not sufficient. The next post shows exactly who can be compelled to hand over your data, and the architecture that takes the question off the table. To make compliance and sovereignty the same motion, explore Command or see how pricing works.

Sources

• European Commission, NIS2 Directive: https://digital-strategy.ec.europa.eu/en/policies/nis2-directive
• ESAs, first 19 critical ICT third-party providers under DORA (2025): https://www.eiopa.europa.eu/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital-2025-11-18_en
• EU Data Act, Article 29 (switching/egress charges): https://www.eu-data-act.com/Data_Act_Article_29.html
• European Commission, Cloud and AI Development Act: https://digital-strategy.ec.europa.eu/en/policies/cloud-and-ai-development-act
• European Commission, €180M sovereign-cloud procurement (2026): https://commission.europa.eu/news-and-media/news/commission-advances-cloud-sovereignty-through-strategic-procurement-2026-04-17_en
• Amazon, AWS €15.7bn investment in Spain: https://www.aboutamazon.eu/news/job-creation-and-investment/aws-plans-to-invest-15-7-billion-in-spain-supporting-the-creation-of-17-500-jobs-annually-in-local-businesses
• European Court of Auditors, The EU's strategy for microchips (SR 12/2025): https://www.eca.europa.eu/ECAPublications/SR-2025-12/SR-2025-12_EN.pdf
• The Register, Microsoft "cannot guarantee" data sovereignty (2025): https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/

In the companion post we argued that a passed audit can hide a live dependency. Here is the sharpest example of that gap. Two systems can both be "encrypted at rest" and have completely different sovereignty: in one, a lawful order to the provider produces your data in plaintext; in the other, the same order produces ciphertext that no one present can read. The difference is not the encryption. It is key custody.

This post is about where the keys live, who can be compelled to use them, and how to build so that the honest answer to a foreign legal order is "there is nothing readable to hand over."

Encryption is necessary. It is not the whole answer.

Encryption defends data against the wrong people getting the bytes. It does nothing, on its own, against the right people being lawfully ordered to decrypt. If your provider holds the decryption keys, even inside an "EU region", then a compulsion order served on that provider's parent company can reach your data, because the provider has the practical ability to produce it.

So the useful question is not "is it encrypted?" but "who can be made to turn it into plaintext?", exactly the fork shown above.

This is why "bring your own key" schemes that still store the key inside the provider's own key manager don't fully close the gap: the provider can still be compelled to use it. What closes the gap is keys held outside the provider's reach: by you, or by an EU-governed entity that is not subject to the foreign order.

The layers that actually matter

Real data protection is not one control but a stack of them, each answering a different threat. Here is the model, described by what each layer does rather than by any product.

The first two are table stakes. The differentiators are lower down: purpose-derived keys mean a breach of one subsystem doesn't hand an attacker the whole estate; versioned ciphertext means you can rotate keys routinely instead of treating rotation as a risky event; and custody is the one that decides the compulsion question.

What about "encryption in use"?

The newest frontier is processing data while it stays encrypted, inside hardware-isolated environments that even the operator supposedly can't read, with cryptographic attestation that the isolation held. It is genuinely useful and worth adopting. But treat the marketing with care. In late 2025, researchers demonstrated attacks that defeated several mainstream hardware-isolation technologies with a low-cost physical interposer and even forged attestation (BleepingComputer, 2025). For the sovereignty threat model specifically, where the adversary you're worried about is the party with physical access to the hardware, confidential computing narrows the window but does not, by itself, replace customer-held keys. The honest stack uses both.

Evidence you can't quietly edit

There is a second custody question that gets less attention: who can rewrite the record of what happened? An audit trail that the operator can silently alter is not evidence; it is a story.

The architectural answer is a tamper-evident, hash-chained audit log: each entry cryptographically chained to the last, protected by an integrity key, and verifiable after the fact. The design choice that makes it real is counterintuitive: the log should fail closed. If its integrity key is missing, the system should refuse the operation rather than write a record it cannot later prove. Better to reject an action than to log something unverifiable.

How the Soveryne Cloud Foundation handles keys and evidence

We built the Soveryne Cloud Foundation around the principle this whole post argues for: sovereignty is decided at the key boundary, so the boundary is where we put the engineering.

Data is encrypted in transit and at rest, isolated per tenant, with keys held inside EU jurisdiction, not in a foreign provider's key manager, so an order served on a foreign provider yields ciphertext only. Sensitive fields are individually encrypted with keys derived per purpose, so a single compromise can't cascade, and ciphertext is versioned for seamless key rotation rather than treated as a once-a-decade emergency. Every privileged action is written to a tamper-evident, hash-chained audit log that fails closed without its integrity key. So your record of who did what is something you can prove, not just assert. And because AI and LLM inference run on EU-sovereign infrastructure, the data you send to a model never crosses the key boundary you just established.

For the strictest postures, the Soveryne tier adds a dedicated environment with its own inference GPUs and on-premises options, plus knowledge transfer to your team, so the keys, and the control of them, stay with you.

FAQ

Does the CLOUD Act apply if my data is encrypted? It depends on who holds the keys. If the provider can be compelled to decrypt, encryption doesn't defeat the order. If the keys are held by you or an independent EU entity outside the provider's reach, the order yields only ciphertext.

What's the difference between BYOK and HYOK? "Bring your own key" usually still stores the key inside the provider's key manager, so the provider can be compelled to use it. "Hold your own key" keeps the key outside the provider entirely, which is what actually removes the provider's ability to produce plaintext.

Is "encrypted at rest" enough for data sovereignty? No. It protects against theft of stored data, but not against lawful compulsion of whoever holds the keys. Custody, not encryption alone, decides the sovereignty question.

Does confidential computing solve foreign-access risk? It helps by protecting data during processing, but recent research shows hardware isolation can be attacked with physical access: the exact scenario sovereignty cares about. Use it alongside customer-held keys, not instead of them.

The bytes don't matter if someone else holds the key that turns them back into words. See how the Soveryne Cloud Foundation keeps custody (and the audit trail) in EU jurisdiction: explore the platform, or read the companion piece on why compliance isn't sovereignty.

Sources

• The Register, Microsoft "cannot guarantee" data sovereignty (2025): https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/
• BleepingComputer, hardware-isolation (TEE) attack research (2025): https://www.bleepingcomputer.com/news/security/teefail-attack-breaks-confidential-computing-on-intel-amd-nvidia-cpus/
• Public Sector Network, encryption doesn't guarantee sovereignty: https://publicsectornetwork.com/insight/cloud-act-and-data-protection-encryption-doesnt-guarantee-sovereignty
• Utimaco, achieving data sovereignty through key control: https://utimaco.com/news/blog-posts/achieve-data-sovereignty-gaining-control-over-encryption-keys-three-approaches
• CSIS, the CLOUD Act and transatlantic trust: https://www.csis.org/analysis/cloud-act-and-transatlantic-trust

This is practical guidance for compliance teams, not legal advice. Current as of July 2026.

If you feel like the rules keep multiplying, you're right, and there's a shape to it. EU digital regulation arrived in three waves, each triggered by a different anxiety, and each one added to rather than replaced the last.

Wave 1: Data protection (2016–2018)

The modern era starts with GDPR (Regulation (EU) 2016/679): adopted in 2016, applicable from 25 May 2018, replacing the fragmented 1995 Data Protection Directive. The driver was simple: national privacy rules had diverged, and the digital economy had made personal data the core asset of business. GDPR harmonized the rules, gave individuals enforceable rights, and introduced the accountability principle: you must be able to demonstrate compliance, not just claim it. That single word, demonstrate, set the tone for everything that followed (EUR-Lex).

Wave 2: Cyber and platforms (2022–2024)

The second wave answered breaches, supply-chain attacks, platform power, and the financial sector's growing dependence on a handful of tech vendors. In a compressed span:

• NIS2 (2022/2555) widened EU cybersecurity obligations across 18 sectors and added management accountability.
• DORA (2022/2554) did the same for finance, with a tighter, five-pillar resilience regime.
• The DSA and DMA targeted platform power.
• The AI Act, the Cyber Resilience Act, and eIDAS2 followed in 2024, extending rule-making into AI, product security, and digital identity.

Wave 3: AI and sovereignty (2024–2026)

The third wave is still breaking: the AI Act phasing in, the CRA's obligations arriving in 2026–2027, the Data Act applying from 2025, the Cyber Solidarity Act, the European Health Data Space, and (in June 2026) a tech-sovereignty package (with the Cloud and AI Development Act proposed). The drivers now are AI and geopolitics.

The verified timeline

Here is the stack, dated and current as of July 2026, with one entry that proves the whole point.

Source: EUR-Lex primary texts; European Commission.

The pattern that should change how you operate

Two things jump out of that table.

First, regulation compounds; it rarely repeals. GDPR didn't go away when NIS2 arrived. NIS2 didn't go away when DORA arrived. Obligations accumulate, and they overlap. A compliance posture built in 2018 and left alone is not "done"; it has silently decayed.

Second, and this is the live proof, the dates themselves move. The AI Act's high-risk obligations were originally set for August 2026 and 2027. In mid-2026, through the "Digital Omnibus," the EU formally pushed them back to December 2027 and August 2028 (Council of the EU, final adoption 29 June 2026). Any explainer written against the 2024 text is already wrong. Meanwhile, on 8 July 2026 the Commission referred four Member States to the Court of Justice for failing to transpose NIS2: the same law, moving in the opposite direction, toward harder enforcement.

This timeline is the acceleration argument that motivates the compliance-mapping approach. Static knowledge decays in both directions: obligations tighten and timelines shift. That is the operational problem this series keeps returning to.

Where Soveryne fits

A printed timeline is out of date the day it's published, as the AI Act just demonstrated. That's exactly the job of Counsel: a living answer instead of a static one. Ask "what's the current deadline for AI Act high-risk systems?" or "did NIS2 transposition complete in the Netherlands?" and Counsel answers from the frameworks and official sources in its knowledge base (with citations) rather than from a blog post that's six months stale. For a domain where the ground shifts under you, a grounded, current, cited answer is the difference between confidence and exposure.

And when a date does move, as it will again, Command is where that change lands operationally: reprioritize the controls tied to that deadline, and keep the evidence current instead of scrambling before an audit. The timeline moves; your program shouldn't have to lurch.

FAQ

Why has EU digital regulation accelerated so much? Three waves of drivers: harmonizing data protection (2016–18), responding to cyber and platform risk (2022–24), and governing AI and sovereignty (2024–26). Each wave added laws rather than replacing earlier ones.

Do newer laws replace older ones like GDPR? Almost never. NIS2 replaced NIS1, but GDPR, DORA, the AI Act and others coexist and overlap. Obligations compound over time.

Why do compliance deadlines keep changing? Implementation depends on supporting standards, tools, and national transposition. When those lag, the EU adjusts timelines (as it did for the AI Act's high-risk obligations in 2026), so any static reference can quickly become inaccurate.

How do I keep up with changing regulation without a full-time legal team? Use a grounded, cited assistant that answers from current frameworks (rather than stale summaries), and a control platform where a changed deadline simply reprioritizes existing work.

The rules keep moving; your answers should too. Get current, cited answers with Counsel, and keep controls aligned to shifting deadlines with Command.

Sources

• EUR-Lex, GDPR, NIS2, DORA, AI Act, CRA, Data Act primary texts: https://eur-lex.europa.eu/
• European Commission, NIS2 CJEU referral, 8 July 2026: https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1499
• Council of the EU, final adoption of AI Act simplification (Digital Omnibus), 29 June 2026: https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/

On 19 July 2024, a single content update from one security vendor crashed an estimated 8.5 million Windows devices worldwide. No attacker was involved. Airlines grounded fleets, hospitals diverted patients, banks and payment systems stalled, broadcasters went dark. One study put the direct losses to US Fortune 500 companies alone at $5.4 billion (Parametrix, 2024; Microsoft).

The uncomfortable lesson was not "that vendor was careless." It was that a tool most organizations adopted for convenience had quietly become critical infrastructure: a single point of failure with a continent-sized blast radius. And it was far from the only one.

How convenience becomes a single point of failure

There is a repeatable mechanism here, and naming it is the first step to managing it.

It runs in four steps. A tool is adopted for efficiency. It gets embedded into business-critical workflows: security agents in the kernel, identity in the login path, email and collaboration everywhere. The market concentrates: three hyperscalers now hold roughly 70% of the EU cloud market (Synergy Research), and supervisors note "low levels of substitutability." Finally, criticality emerges, without anyone ever deciding it should.

The Bank of England's then-governor saw this coming back in 2019: "Two providers account for nearly half of revenues in cloud computing, bringing scale and efficiency, but also concerns about dependence and a single point of failure in the case of a cyber-attack." (Mark Carney, Mansion House, 20 June 2019)

When one update takes down a continent

CrowdStrike was not a one-off. In the space of a single month in late 2025, three more attacker-free outages cascaded across the internet, all from concentrated platforms, each from a single internal change.

Sources: CISA; ThousandEyes; Cloudflare.

Notice the pattern: the most recent and most disruptive of these involved no attacker at all. A bad update, a DNS race, a permissions change, a config push. When millions of systems share the same software and the same provider, a local defect becomes a correlated, continent-scale failure. (The engineering choices that contain this, and the ones that don't, are the subject of our companion piece, Designing Against the Monoculture.)

Why regulators now treat concentration as systemic risk

This is the shift that matters most for European organizations: concentration has moved from a procurement preference to a supervised, systemic risk.

• DORA. On 18 November 2025, the European Supervisory Authorities designated the first 19 critical ICT third-party providers for direct EU oversight, including AWS, Microsoft, Google Cloud, Oracle, SAP, and others. The designation criteria are explicitly about concentration of reliance and substitutability. (ESAs, 2025)
• ECB. Its 2025 cloud-outsourcing guide warns of "an increased reliance… a concentration of a small number… particularly cloud service providers, and low levels of substitutability." (ECB, 2025)
• National audit. The Netherlands Court of Audit found that every Dutch ministry uses public cloud, more than half of the most important services come from Amazon, Microsoft, or Google, and 67% had no strategic risk assessment. (Court of Audit, 2025)

The regulator is, in effect, naming the dependencies it cannot yet replace.

The risk hiding in plain sight: you can't leave

Public-cloud adoption is near-universal; tested exit plans are not. The ECB's 2025 supervisory guidance on cloud outsourcing exists precisely because supervisors kept finding deficiencies in banks' exit strategies, from missing documentation to untested transitions (ECB, 2025).

That gap is exactly why the EU has had to legislate it. Under DORA's Article 28(8), financial entities must now maintain documented, tested exit strategies for critical services. And from 12 January 2027, the EU Data Act prohibits all cloud switching and egress charges, removing the financial penalty that has long made leaving a hyperscaler prohibitively expensive (EU Data Act, Art. 29).

When France's Health Data Hub decided to move its national health platform off a US hyperscaler to a European provider on sovereignty grounds, the migration was budgeted at roughly 18 months (Euronews, 2026). Exit is feasible, but only if you designed for it.

How to reduce cloud concentration risk

Concentration risk is manageable without ripping everything out overnight. A pragmatic sequence:

1. Map your dependencies, including fourth- and nth-party ones. You can't manage a single point of failure you can't see.
2. Tier your workloads. Decide which functions are critical or important, and treat those to a higher standard than the rest.
3. Demand portability by design: open standards, machine-readable export, and contract clauses for reversibility.
4. Test the exit. An untested exit plan is a hope, not a control. Run switch drills for critical entities.
5. Evidence it continuously, the way DORA and NIS2 now expect, not as an annual paperwork exercise.

This is where the work meets the tooling. Command operates your whole security program from one place: controls drafted and mapped to the frameworks that apply to you (NIS2, DORA, ISO 27001), evidence collected once and counted across audits, and threat intelligence triaged against your actual controls. If your concern is DORA specifically, Command covers unlimited frameworks with continuous validation (see how pricing works).

And concentration is itself a design choice. The Soveryne Cloud Foundation runs on geographically distributed compute across the EU, on a platform we operate ourselves rather than resold from a single hyperscaler, so there is no single site, and no single provider, to take you down with it.

FAQ

What is cloud concentration risk? The risk that an organization, sector, or economy depends so heavily on a small number of cloud or IT providers that the failure of one causes systemic, cascading disruption. Regulators now treat it as an operational and financial-stability risk.

What is a critical ICT third-party provider under DORA? A provider whose large-scale failure could threaten financial stability, designated for direct EU oversight. The first 19 were named in November 2025.

Are cloud providers "too big to fail"? Supervisors increasingly treat the largest providers as systemically important, which is precisely why DORA, the ECB, and national audit offices now require concentration mapping, exit strategies, and resilience testing.

How do you reduce cloud concentration risk? Map dependencies, tier workloads, require portability and open standards, test your exit, and evidence resilience continuously.

Concentration is the quiet root cause behind legal, operational, and security risk all at once. The companion technical post shows the architecture that contains a single faulty update. To see controls mapped and evidenced in one place, explore Command, or see how pricing works.

Sources

• Microsoft, CrowdStrike outage (8.5M devices): https://blogs.microsoft.com/blog/2024/07/20/helping-our-customers-through-the-crowdstrike-outage/
• Parametrix, $5.4B Fortune 500 loss estimate: https://www.parametrixinsurance.com/in-the-news/crowdstrike-to-cost-fortune-500-5-4-billion-insured-loss-range-of-540-million-to-1-08-billion
• ESAs, first 19 critical ICT third-party providers under DORA (2025): https://www.eiopa.europa.eu/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital-2025-11-18_en
• ECB, guide on outsourcing cloud services (2025): https://www.bankingsupervision.europa.eu/press/pr/date/2025/html/ssm.pr250716~c0401b1b6b.en.html
• Netherlands Court of Audit, central government in the cloud (2025): https://english.rekenkamer.nl/publications/reports/2025/01/15/dutch-central-government-in-the-cloud
• Bank of England, Mark Carney, Mansion House speech (2019): https://www.bankofengland.co.uk/-/media/boe/files/speech/2019/enable-empower-ensure-a-new-finance-for-the-new-economy-speech-by-mark-carney
• EU Data Act, Article 29 (switching charges): https://www.eu-data-act.com/Data_Act_Article_29.html
• Euronews, France Health Data Hub migration (2026): https://www.euronews.com/health/2026/04/24/france-moves-public-health-data-from-microsoft-to-french-cloud-provider

In the companion post we argued that ordinary tools quietly become critical infrastructure. This is the engineer's follow-up: given that concentration exists, how do you build a platform that a single faulty change cannot take down continent-wide?

The answer is older than the cloud. In 2003, security researchers Dan Geer and Bruce Schneier described software monoculture: when millions of systems share one codebase, "what one machine has, so has every other." A single defect becomes a population-level event (Schneier, 2003). Twenty-one years later, that thesis was proven at scale.

Anatomy of a continent-wide outage

On 19 July 2024, a security vendor pushed a content update that crashed roughly 8.5 million machines into boot loops. The published root-cause analysis is a precise anatomy of how a small bug becomes a global one (CrowdStrike RCA, 2024):

• A configuration template defined 21 input fields, but the sensor code supplied only 20.
• A content update referenced that non-existent 21st field, triggering an out-of-bounds read in kernel-mode code, an unrecoverable crash.
• The validator that should have caught the bad file had a logic error and passed it.
• And the decisive part: while the vendor's code shipped through staged rollout, the content update was pushed to the entire fleet at once, with no canary and no customer-controlled timing.

Three ingredients had to coincide: homogeneity (everyone runs the same thing), a privileged execution position (kernel code can crash the host), and a rapid, unstaged update channel. Remove any one and the blast radius collapses.

The transferable rule writes itself: if a change can brick the host, it ships in rings, whether you call it code, content, configuration, or data.

What is blast radius, and how to reduce it

Blast radius is the maximum impact a single failure can cause. Resilient systems are designed so that number is a fraction of the whole, never "everything and everyone." A handful of well-understood patterns do this:

Patterns drawn from established industry practice (e.g. AWS Builders' Library).

The principle behind all of them is the same: install boundaries so a failure is contained. As AWS's Colm MacCárthaigh puts it, without isolation "the scope of impact for this kind of failure is 'everything and everyone'" (Amazon Builders' Library).

Event-driven resilience: failure as a local, absorbable event

Patterns are necessary; a runtime that absorbs failure is what makes them work day to day. An event-driven design (components communicating through a message bus rather than calling each other directly) turns a fault into something local and recoverable instead of a synchronized crash.

The load-bearing properties:

• Decoupling. A slow or failed consumer never blocks the producer; the bus holds the message.
• Stateless workers. State lives in the bus and the system of record, so any worker can pick up any job and a dead worker is replaced without data loss.
• Idempotency + retries with backoff and jitter. Duplicate processing is harmless and retries don't stampede.
• Dead-letter queues. One bad message is quarantined for inspection instead of poisoning the pipeline.
• Self-healing reconciliation. The system continuously converges toward its desired state. Recovery is steady-state behavior, not a heroic manual event.

Deployment safety: a deploy is an event, not a redeploy

The CrowdStrike lesson was ultimately about delivery, not C++. Treat every change, including configuration and content, as a discrete, observable, reversible event:

1. Progressive / ring rollout. Expose a change to a small population first; expand only if health metrics hold.
2. Automated rollback. Detect anomalies and revert to known-good without waiting for a human; at fleet scale, people are too slow.
3. Configuration-as-data, validated. Config gets a schema, a validator that is itself tested, and the same staged rollout as code.
4. Customer-controlled update rings. Let operators pause or stage updates, a principle the EU Cyber Resilience Act now echoes with its right to opt out of automatic updates.

Regulators have caught up to this, too. DORA, NIS2, and the Cyber Resilience Act now treat single-vendor concentration and uncontrolled auto-update channels as systemic risks to be managed, not stylistic preferences (Kroll, 2024). CISA Director Jen Easterly called it "a useful exercise, like a dress rehearsal for what China may want to do to us" (Cybersecurity Dive, 8 August 2024).

How the Soveryne Cloud Foundation is built for the bad day

We built the Soveryne Cloud Foundation on these principles because resilience, like sovereignty, has to be a property of the architecture rather than a line in an SLA.

The foundation is event-driven by design: components communicate through a message-addressed bus, compute is stateless and rebuildable, and work that fails is retried, quarantined, or reconciled rather than allowed to cascade. It runs on geographically distributed compute clusters across the EU (no single site and no single provider to fail with) and treats every change as a staged, reversible event rather than a fleet-wide flip. Configuration reload is a first-class, observable operation, not a redeploy.

That same foundation is why, when something does go wrong, the blast radius is a contained event instead of a continent-wide outage. And because operational resilience is now something you must evidence, not just claim, Command lets you map and continuously validate those controls the way DORA and NIS2 expect.

FAQ

What is software monoculture? When a large population of systems runs the same software, so they share the same vulnerabilities and failure modes. A single defect or bad update can then affect the entire population at once: the digital equivalent of a crop monoculture wiped out by one pathogen.

How did monoculture make the 2024 outage worse? Millions of machines ran an identical agent in a privileged position and received the same update simultaneously, so one defective file produced a perfectly correlated, global failure.

What is blast radius, and how do you reduce it? Blast radius is the maximum impact of a single failure. You reduce it with isolation boundaries (cells, bulkheads, shuffle sharding, zonal isolation) and with staged rollouts, so a failure is contained to a fraction of the system.

What is a cell-based architecture? A design that runs multiple independent replicas ("cells") of the full stack, each serving a subset of users, with no shared fate between them, so a failure or a bad deploy affects only one cell.

A bad change is inevitable; a continent-wide outage is a design choice. See the event-driven, EU-sovereign foundation we built to contain it, explore the Soveryne Cloud Foundation, or read the companion post on why concentration is now a systemic risk.

Sources

• Geer, Schneier et al., CyberInsecurity: The Cost of Monopoly (2003): https://www.schneier.com/essays/archives/2003/09/cyberinsecurity_the.html
• CrowdStrike, External Technical Root Cause Analysis, Channel File 291 (2024): https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf
• CISA, Widespread IT outage due to CrowdStrike update (2024): https://www.cisa.gov/news-events/alerts/2024/07/19/widespread-it-outage-due-crowdstrike-update
• AWS Builders' Library, Workload isolation using shuffle-sharding: https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/
• The Reactive Manifesto: https://www.reactivemanifesto.org/
• Kroll, CrowdStrike incident and systemic cyber risk under EU regulations (2024): https://www.kroll.com/en/publications/cyber/crowdstrike-incident-systemic-cyber-risk-eu-regulations

This is practical guidance for compliance teams, not legal advice. Current as of July 2026.

"Are we ISO compliant?" is one of the most common questions in a compliance program, and it contains a category error. You don't comply with ISO. ISO is a way to demonstrate that you comply with something else: the law. Getting this distinction right is the difference between a program that scales and one that spins.

The four-layer stack

Here is the mental model to keep. It has exactly four layers, and each answers a different question.

A law tells you what. A framework shows you how. A control is the doing. Evidence is the proof. Miss any layer and you have a gap: an obligation with no framework is guesswork; a framework with no controls is a binder; controls with no evidence are a claim.

Frameworks are not laws, and that's the point

Frameworks make laws implementable and auditable. Crucially, they differ in how they're assured, and buyers conflate these constantly:

• ISO standards are certifiable. An accredited third party audits you and issues a certificate (ISO/IEC 27001 for security, ISO/IEC 27701 for privacy, ISO/IEC 42001 for AI).
• NIST frameworks are voluntary and self-assessed. NIST CSF 2.0, the Privacy Framework, and the AI RMF are designed to be flexible and, importantly, mapping-friendly: NIST explicitly publishes "informative references" so one framework's controls map to another's.
• SOC 2 is an attestation. A licensed accountant issues a report on your controls against the Trust Services Criteria.

None of these is legal compliance. Each is a recognized way to demonstrate it. A regulator doesn't accept "we hold ISO 27001" as a defense to a GDPR breach, but a well-run ISO 27001 program is exactly the evidence that shows you met GDPR's "security of processing" obligation (Article 32).

Which frameworks map to which laws

You don't pick a framework in a vacuum; you pick the one that best demonstrates the laws that apply to you.

(Framework mappings are how you operationalize a law; they are not, by themselves, legal compliance. Sources: NIST, ISO.)

Start with the question everyone skips: does this even apply to me?

This is the mental model behind the whole compliance series. Before any of this, one step decides whether you're solving the right problem: scoping. In our reading of these five laws, the biggest compliance risk isn't ignorance of a law; it's misjudging how a law binds you. You fall under GDPR because you process EU personal data; under NIS2 because of your sector and size; under DORA because you're a regulated financial entity; under the CRA because you place a digital product on the EU market; under the AI Act because you provide or deploy AI. Different triggers, different scopes. "We cover cybersecurity" is not a compliance claim.

Where Soveryne fits

The four-layer stack maps cleanly onto two jobs.

The first is coverage intelligence: what applies to me, and what exactly does it require? That's Counsel: ask a plain-language question ("does GDPR Article 32 require encryption?") and get an answer drawn from the frameworks themselves (GDPR, NIS2, DORA, ISO/IEC, NIST) with every claim cited so you can verify it, not trust it.

The second is proof of implementation: show me the controls and the evidence. That's Command: enroll the frameworks that apply to you and it drafts the controls, maps each one to the framework requirements it satisfies, and tracks the evidence, so the four-layer stack (law → framework → control → evidence) is connected and inspectable rather than scattered across spreadsheets. Command even lets you compare two frameworks side by side to see exactly where they overlap.

Get the vocabulary right, and the tooling follows: Counsel answers what; Command proves how.

FAQ

What's the difference between a law and a framework? A law is a binding obligation (GDPR, NIS2). A framework or standard (ISO 27001, NIST CSF) is a structured, often certifiable method for meeting and demonstrating that obligation. Frameworks aren't laws; they help you comply with them.

Is ISO 27001 the same as being GDPR compliant? No. ISO 27001 certifies your information-security management system. It's strong evidence toward GDPR's security-of-processing requirement, but GDPR has obligations (rights, lawful basis, transfers) that ISO 27001 alone doesn't cover. ISO/IEC 27701 addresses the privacy side.

ISO vs NIST vs SOC 2: which should I use? ISO is certifiable and international; NIST is voluntary, flexible, and mapping-friendly; SOC 2 is a US-style attestation for customer assurance. Many organizations use several, mapped to a single control set to avoid duplicate work.

How do I know which laws apply to my organization? By scoping against each law's trigger: personal data (GDPR), sector + size (NIS2), financial-entity status (DORA), placing digital products on the EU market (CRA), providing/deploying AI (AI Act).

Know the layers, then connect them. Get cited answers on what a rule requires with Counsel, and map obligations to evidenced controls with Command.

Sources

• NIST Cybersecurity Framework 2.0 (informative references / mappings): https://www.nist.gov/cyberframework
• ISO, standards catalogue (27001, 27701, 42001): https://www.iso.org/
• NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
• GDPR, Article 32 (security of processing): https://eur-lex.europa.eu/eli/reg/2016/679/oj

When people argue about "digital sovereignty," the conversation usually floats somewhere above the evidence. So let's put it back on the ground. The question this piece answers is narrow and testable: how dependent is Europe on US technology, layer by layer, and where does Europe actually hold leverage?

The short version: dependence is real, it is measurable, and it is measured in euros. Around 80% of European corporate spending on software and cloud (roughly €264 billion a year) flows to US vendors. That is about 1.5% of EU GDP, or one and a half times the entire EU budget, leaving the continent every year. (European Parliament, 2025)

But "dependence" is not uniform. Europe is weakest exactly where the future is being built, and strongest in a few deep chokepoints it cannot lose quickly. This is the map.

What "digital sovereignty" actually means

First, a definition, because the word is abused. The EU's own Joint Research Centre defines digital sovereignty as the EU's capacity to exercise independence in the digital realm while remaining open and connected to global networks (JRC Policy Brief JRC144908, 2025). It is not self-sufficiency or building everything yourself.

That distinction matters for everything below. The goal is not a European wall. It is the ability to decide, operate, switch, and secure critical infrastructure without unacceptable exposure to foreign legal compulsion, single-vendor lock-in, or coercion.

The rest of this article is about the gap between the first two. And we go deep on it in the companion piece, Sovereignty by Architecture, Not by Promise.

How dependent is Europe, layer by layer

Here is the dependence stack, with a sourced headline metric for each layer.

The cloud layer is the clearest illustration. Three American firms hold roughly seven-tenths of the market: AWS (~30%), Microsoft Azure (~25%), and Google Cloud (~15%), while the leading European providers, SAP and Deutsche Telekom, each hold about 2% (Synergy Research; European Parliament 2025).

And the trend is the uncomfortable part: Europe's cloud adoption is rising fast. 52.7% of EU enterprises used paid cloud services in 2025, up 7.4 points in two years (Eurostat, 2026). But the most common uses are email, office software, and file storage, precisely the categories where US suites dominate. Europe's adoption curve has also been a dependence curve.

AI is the starkest gap of all, and the one that compounds.

Sources: Stanford HAI AI Index 2025/26; OECD, 2026.

Where Europe actually holds leverage

Dependence is only half the map. Europe is not a passenger everywhere. In a few places, the world depends on it.

• Lithography. One Dutch company, ASML, builds close to 100% of the world's EUV lithography machines, the tools required to make every advanced chip on Earth. When the US wanted to restrict China's access to advanced chipmaking, it needed Dutch cooperation. That is not dependence; that is leverage. (Yole Group)
• Semiconductor equipment. EMEA vendors held 29% of the global wafer-fabrication equipment market in 2023 (Yole Group; ASML, ASM and ZEISS alongside Israeli suppliers), a genuine value-chain stronghold even though Europe makes few leading-edge chips itself.
• Telecom. Ericsson and Nokia together account for around 43% of the global 5G radio-access market. Two of the top three vendors on Earth are European. (Dell'Oro / Fierce Network)
• Rules. GDPR, the AI Act, and the DMA show the "Brussels effect": Europe sets standards the rest of the world has to follow, even where it doesn't build the technology.

The shape of the asymmetry is the real insight:

Europe is strong in chokepoints and standards, and weak in full-stack platforms and scale. That is why "just build a European Google" misunderstands the problem, and why the realistic goal is selective autonomy, not autarky.

Does an "EU region" fix it?

Here is the trap most organizations fall into. They move to a US hyperscaler's "EU region," check the data-residency box, and assume the sovereignty problem is solved. It is not.

Jurisdiction follows the provider's nationality, not the data's location. Under the US CLOUD Act, a US-headquartered company can be compelled to produce data regardless of where it physically sits. Asked under oath at the French Senate in June 2025 whether he could guarantee French citizens' data would never be handed to US authorities, Microsoft France's director of public and legal affairs answered plainly: "No, I cannot guarantee it." (The Register, 2025)

An EU postcode is residency. It is not sovereignty. We unpack exactly why (and what does close the gap) in Sovereignty by Architecture, Not by Promise.

Why we built Soveryne the way we did

We did not start Soveryne to wave a flag. We started it because the map above describes a practical risk for any European organization that takes security and continuity seriously, and because the pragmatic middle path between "use a US hyperscaler and hope" and "build everything yourself" barely existed.

So we built the Soveryne Cloud Foundation: the EU-sovereign cloud our own security products run on. Data and encryption keys stay inside EU jurisdiction by architecture, not by a foreign provider's promise. Compute and storage stay in the EU regions you choose. AI and LLM inference run on EU-sovereign infrastructure, so you get the intelligence without sending your data to a foreign cloud. No US-jurisdiction subprocessor in the data path and no US-held keys, with an open-source core you can inspect.

On top of it run Counsel, a sovereign AI assistant that answers from your own frameworks and documents and cites every source, and Command, which operates your whole security program. The point of the foundation is simple: your data, your questions, and your controls all stay in jurisdiction by default.

That is what selective autonomy looks like in practice: not isolation, but control where it actually matters.

FAQ

What percentage of the EU cloud market do US companies control? Roughly 70%, split across AWS (~30%), Microsoft Azure (~25%), and Google Cloud (~15%). Europe's leading providers, SAP and Deutsche Telekom, each hold about 2%. (Synergy Research)

Why is Europe so dependent on US technology? Because the highest-value digital layers (cloud, foundation models, operating systems, productivity) are winner-take-all markets with strong network effects, where the US built scale first. Europe's strengths sit in slower-moving hardware and standards.

Does storing data in an EU data center protect it from US law? Not by itself. Under the CLOUD Act, a US-headquartered provider can be compelled to produce data regardless of where it is stored. Location is residency; jurisdiction is sovereignty. See our companion piece.

What's the difference between digital sovereignty and data sovereignty? Digital sovereignty is the broad capacity to control your digital infrastructure; data sovereignty specifically concerns whose laws govern your data and who can compel access to it.

Europe's dependence is real and measurable, but so is the path out of it. The next post in this series shows how everyday tools quietly become critical infrastructure. If you'd rather see what sovereign-by-default looks like in practice, explore the Soveryne Cloud Foundation or see our pricing.

Sources

• European Parliament, European Software and Cyber Dependencies (2025): https://www.europarl.europa.eu/RegData/etudes/STUD/2025/778576/ECTI_STU(2025)778576_EN.pdf
• Synergy Research, European cloud provider share (2025): https://www.srgresearch.com/articles/european-cloud-providers-local-market-share-now-holds-steady-at-15
• European Court of Auditors, The EU's strategy for microchips (SR 12/2025): https://www.eca.europa.eu/ECAPublications/SR-2025-12/SR-2025-12_EN.pdf
• Eurostat, cloud computing use by enterprises (2026): https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20260203-1
• Stanford HAI, AI Index 2025: https://hai.stanford.edu/ai-index/2025-ai-index-report
• OECD, AI venture capital (2026): https://www.oecd.org/en/about/news/announcements/2026/02/ai-firms-capture-61-percent-of-global-venture-capital-in-2025.html
• The Register, Microsoft "cannot guarantee" data sovereignty (2025): https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/458553
• Yole Group, EU semiconductor equipment suppliers: https://www.yolegroup.com/strategy-insights/underappreciated-eu-suppliers-lead-the-semiconductor-equipment-market/

If you've ever evaluated a cloud provider's "sovereign" offering, you've seen the reassurance: your data stays in our EU region. It sounds decisive. It is also, on its own, beside the point.

We argued the why of European dependence in the companion piece. This post is about the how: why location does not equal control, and what it actually takes to make data residency a guarantee you can prove rather than a promise you have to trust.

Data residency vs data sovereignty

Start with the distinction that the whole field turns on.

Residency answers "where are the bytes?" Sovereignty answers "who can be compelled to hand them over, or to decrypt them?" You can have perfect residency and zero sovereignty at the same time.

Why location ≠ control

Here is the mechanism that makes an "EU region" insufficient. Jurisdiction follows the provider's corporate nationality, not the data's coordinates.

Under the US CLOUD Act, a demand served on a US-headquartered company reaches data it controls anywhere in the world: Frankfurt, Dublin, Amsterdam included. Storage location is legally irrelevant; what matters is that the provider is subject to that jurisdiction. The clearest confirmation came from a hyperscaler itself: asked under oath whether French data could be shielded from US authorities, Microsoft France's representative said, "No, I cannot guarantee it." (The Register, 2025)

This is also why the legal "fix" for transatlantic transfers is fragile. The EU–US Data Privacy Framework was upheld by the EU General Court in 2025, but it remains an adequacy decision that can be annulled, and the underlying access powers it sits alongside are untouched. In late 2025, US legal and political changes affecting agency independence and surveillance authorities reopened exactly these questions (WilmerHale, 2025). A promise can be withdrawn. Architecture cannot.

Is an EU region enough for GDPR?

Short answer: no, not on its own. Choosing an EU region changes where data sits, not which government can compel access to it. For GDPR you also need a valid transfer position and, crucially, technical and organizational measures that hold even if the provider is lawfully ordered to act against your interests. An EU region is a necessary ingredient, not the finished dish.

The "sovereign cloud" labels, and what they leave out

The market has responded with tiers, certifications, and "sovereign" SKUs. They are not all equal. The EU's own Cloud Sovereignty Framework scores offerings on a ladder (SEAL-1 to SEAL-4), and the gap between the rungs is the whole story.

Source: European Commission, Cloud Sovereignty Framework, 2026. In the April 2026 EU sovereign-cloud tender, the European awardees reached SEAL-2 and SEAL-3.

The residual gaps in US-parented "sovereign" offerings are consistent: control of the software roadmap stays with the foreign parent; encryption keys may still be technically reachable by the provider; operational and support access paths remain; and the ultimate corporate jurisdiction is unchanged. Independent analysts have been blunt that wholly-owned "sovereign" clouds keep CLOUD Act exposure that "never fully goes away" (InfoQ, 2026).

Residency by construction: the enforcement primitives

So what makes residency an architectural guarantee? The shift is from "we promise not to move it" to "we are technically incapable of disclosing it." Four primitives do the work.

1. Customer-held / external keys. If the operator never holds your decryption keys, a legal order produces ciphertext. There is nothing readable to hand over. This is the single highest-leverage control, and the reason "encrypted at rest" alone is not enough: what matters is who can be compelled to produce the key.

2. Encryption in transit, at rest, and in use. The first two are table stakes. Processing data inside hardware-isolated environments, with verifiable attestation, narrows the window where plaintext is exposed to the operator.

3. No-egress regional isolation. Compute and storage that cannot replicate out of a chosen jurisdiction by default: localization designed into the system, not promised in a policy.

4. Independent EU operation. The decisive, non-technical primitive: an operating entity governed by EU law and not controlled by a foreign parent. This is the part that actually severs the chain of compulsion, and it's why genuinely sovereign offerings tend to be operated by European entities, not foreign-owned subsidiaries.

Put together, these four primitives are what turn a promise ("we won't move your data"), one that depends on trust and a stable legal regime and can be revoked, into a property of the system that holds even under a lawful order.

How we built the Soveryne Cloud Foundation

The platform page for the Soveryne Cloud Foundation carries one line that summarizes our entire design philosophy, and the title of this post: sovereign by architecture, not by promise. That wasn't marketing-first. It was an engineering constraint we set ourselves.

So the foundation is built on those primitives. Files and data are encrypted in transit and at rest, isolated per tenant, with keys held inside EU jurisdiction, so what is yours stays yours, and there is nothing for a foreign order to compel. You control which EU regions your compute and storage live in, by design. AI and LLM inference run on EU-sovereign infrastructure, because, as we argue in detail elsewhere, the prompt is the data, and sending it to a foreign GPU is a transfer like any other. And it is operated end to end by an EU entity, on a platform we run ourselves, with no US-jurisdiction subprocessor in the data path and no US-held keys and an open-source core you can inspect.

For organizations that need the strictest posture, the Soveryne tier provides a dedicated environment with its own inference GPUs, on-premises deployment options, and knowledge transferred to your own team, so sovereignty never quietly becomes dependence on us either. Where you need grounded, cited answers that stay in-jurisdiction, that's exactly what Counsel is built to do.

FAQ

What is the difference between data residency and data sovereignty? Residency is where data physically sits; sovereignty is whose laws govern it and who can compel access. Residency is geography; sovereignty is jurisdiction.

Can the US access EU data under the CLOUD Act? Yes, if the provider is subject to US jurisdiction. A US-headquartered company can be compelled to produce data it controls, regardless of where that data is stored.

Does the CLOUD Act apply if the data is encrypted? It depends on who holds the keys. If the provider can be compelled to decrypt, encryption doesn't defeat the order. If the keys are held externally by the customer or an independent EU entity, the order produces only ciphertext.

Is choosing an EU region enough for GDPR compliance? No. It addresses residency, not the question of foreign legal compulsion. You also need a valid transfer position and technical/organizational measures: ideally external key custody and EU-controlled operation.

Sovereignty is a property you can engineer and prove, not a checkbox you trust. See the architecture in practice, explore the Soveryne Cloud Foundation, or read the companion piece on Europe's real dependence map.

Sources

• The Register, Microsoft "cannot guarantee" data sovereignty (2025): https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/
• European Commission, Cloud Sovereignty Framework explained (2026): https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01_en
• InfoQ, analysis of US-parented sovereign cloud and CLOUD Act exposure (2026): https://www.infoq.com/news/2026/01/aws-european-sovereign-cloud/
• WilmerHale, CJEU to review the EU–US Data Privacy Framework (2025): https://www.wilmerhale.com/en/insights/blogs/wilmerhale-privacy-and-cybersecurity-law/20251201-european-court-of-justice-to-review-challenge-to-eu-us-data-privacy-framework
• CSIS, the CLOUD Act and transatlantic trust: https://www.csis.org/analysis/cloud-act-and-transatlantic-trust
• BSI, C3A, Criteria enabling Cloud Computing Autonomy (2026): https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/C3A/C3A.html

This is practical guidance for compliance teams, not legal advice; your obligations depend on your jurisdiction, sector and facts. Current as of July 2026.

Consider a mid-sized European SaaS company. It processes personal data, so it falls under GDPR. It operates in a covered sector above the size threshold, so it falls under NIS2. It sells software into the EU market, so the Cyber Resilience Act applies to its product. It ships an AI feature, so the AI Act applies. If it serves banks, its customers pull it into DORA. Five laws, five different triggers, five sets of obligations, deadlines, and penalties, landing on the same organization at the same time.

None of them replaced the others. They stacked. And that stacking is why "are we compliant?" stopped being a checkbox and became the subject of this whole series.

The maze is real, but it is not random

Here's the good news buried in the complexity. When you lay these laws side by side, they target different legal objects (personal data, cyber risk, financial resilience, AI systems, products), but they demand strikingly similar organizational work. Every one of them asks you to:

• define scope and inventory your systems, data, and suppliers;
• assign accountable owners (increasingly at board level);
• assess risk and treat it;
• document controls and operate them;
• oversee third parties;
• detect, handle, and report incidents;
• and, the thread through all of it, retain evidence that you actually did these things.

The report underpinning this series calls these the shared control domains, and there are only about seven of them. That is the single most useful fact in compliance today: the laws differ in what they govern, not in the work they force you to do.

Why it feels impossible anyway

If the underlying work overlaps, why does compliance feel like it's multiplying? Because most organizations run it the way the laws are written: one program per law.

Each new law becomes another project, another questionnaire, another spreadsheet, another audit binder; and, quietly, another copy of the same "truth" that will drift out of sync with the others. This produces two failure modes worth naming:

• Duplication. You implement, document, and evidence access control four times because four frameworks ask for it, instead of once.
• Evidence theater. Policies and questionnaires get produced faster than the working, inspectable controls behind them. You have a binder that says you're compliant and no traceable proof that you are.

Add an EU cybersecurity workforce gap of roughly 299,000 (ISC2, 2024), and the spreadsheet model doesn't just underperform: it burns out the team and still fails audits.

The stakes, in plain numbers

This isn't abstract. The penalty ceilings across the stack are real and, increasingly, enforced.

Sources: EUR-Lex primary texts; European Commission.

The way through: run compliance as one system

The organizations that cope are not the ones that work hardest per law. They're the ones that stopped treating each law as a separate program and built one mapped control library: obligations mapped to shared controls, each control owned and evidenced once, and that evidence reused across every framework it satisfies. Collect proof of access control once, and count it toward GDPR, NIS2, DORA, ISO 27001, and SOC 2 simultaneously.

To be fair to the alternative: the law-by-law model has one virtue: clean traceability of a single obligation back to its source. But it doesn't scale, and it drifts. The shared-control model costs more to design up front and wins on every marginal law after that. Given that the laws only accumulate, that's the bet worth making.

Where Soveryne fits

This is precisely the problem Command exists to solve. Instead of a program per law, Command gives you one workspace where controls are drafted, mapped to every framework that applies to you (GDPR, NIS2, DORA, ISO 27001 and more), and evidenced continuously across People, Organization, and Technology, so the work you do to satisfy one obligation is counted toward all the others it covers. That's the "map once, prove many" model, delivered.

And when the question is the other half of the maze (which obligations actually apply, and what a given rule requires), Counsel answers from the frameworks themselves and cites every source, so you get a grounded answer instead of a guess. Together they cover the two questions the maze keeps asking: what applies to me (Counsel) and can I prove I've done it (Command). Both run on EU-sovereign infrastructure: fitting, for a compliance stack built around European law.

The rest of this series walks the maze one wall at a time: the frameworks, the timeline, the privacy laws, the cyber laws, DORA, AI, the overlap, the gaps, and the boardroom. If you'd rather see the whole program in one place now, start with a conversation.

FAQ

Why is compliance harder now than five years ago? Because multiple EU laws (GDPR, NIS2, DORA, AI Act, CRA) now apply to the same organization simultaneously, each with its own trigger, deadlines, and penalties; and they stacked rather than replaced one another.

Is compliance the same as security? No. Compliance is meeting a legal or framework obligation and being able to prove it; security is actually reducing risk. You can have one without the other, which is why evidence and traceability matter.

Do I need a separate program for each regulation? It's the intuitive approach, but it duplicates work and creates drift. Mapping obligations to a single shared control library, evidenced once and reused across frameworks, scales far better.

What's the fastest way to reduce compliance overhead? De-duplication: identify the controls that satisfy multiple frameworks at once, evidence them once, and reuse that evidence (the subject of the "overlap dividend" later in this series).

The maze is real, but it has a map. See your whole program, controls mapped and evidenced across every framework, in Command, or get cited answers on what applies to you with Counsel.

Sources

• EUR-Lex, primary legislative texts (GDPR, NIS2, DORA, AI Act, CRA): https://eur-lex.europa.eu/
• European Commission, NIS2 CJEU referral, 8 July 2026 (IP/26/1499): https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1499
• ESAs, first designation of critical ICT third-party providers (Nov 2025): https://www.eba.europa.eu/publications-and-media/press-releases/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital
• GDPR Enforcement Tracker (cumulative fines): https://www.enforcementtracker.com/statistics