Digital Sovereignty in IT Delivery: What CIOs Really Have to Decide in 2026

What does digital sovereignty mean in IT delivery?

In short: digital sovereignty is an organisation's ability to decide for itself about its data, its operations and its technology choices — and to reverse that decision if needed. It is therefore not a property of a data centre but a measurable property of your own architecture: how expensive, how fast and how risky would it be to switch providers if you had to?

That definition sounds unspectacular, but it moves the entire discussion. In most board rooms sovereignty is negotiated as a location question — "is the data in Frankfurt?" — and answered with a tick on a contract annex. That is the wrong question. A dataset in a Frankfurt data centre, operated by a subsidiary with a US parent company, through a proprietary managed-service API that exists nowhere else, is legally and operationally far less sovereign than a dataset in Ireland that could be migrated through an open interface within 48 hours.

For delivery leaders this is the key act of translation: sovereignty is a non-functional requirement like availability or scalability. It is decided in the architecture, not in procurement — and it decays silently when nobody verifies it.

That the topic is no longer a niche in 2026 is visible in the numbers from the German industry association Bitkom: in its trend survey, 51 percent of the founders surveyed name sovereign cloud and edge solutions as a defining trend of the year, 50 percent data sovereignty and 52 percent cybersecurity and privacy tech ([Bitkom, trend survey 2026](https://www.bitkom.org/Presse/Presseinformation/Bundesregierung-jedes-zweite-Digitalvorhaben-auf-Weg-gebracht)). Three of the most-named trends thus come from a single subject area.

Three layers: data, operations, technology

Anyone wanting to make sovereignty manageable has to break it apart. In practice three layers have proven useful, each assessable independently — and in real setups they routinely diverge.

**Data sovereignty** answers who can legally access the data. What matters here is not the storage location but the jurisdiction the operator's parent company is subject to. Encryption with customer-held keys (hold-your-own-key) shifts this question noticeably, but only resolves it if the provider genuinely needs no plaintext access to operate the service.

**Operational sovereignty** answers who gets the system running again when it breaks. If your operations team cannot perform a recovery without the provider's support, operations are not sovereign — regardless of where the hardware sits. This layer is the most frequently overlooked and tends to surface exactly when it is expensive.

**Technology sovereignty** answers whether a realistic replacement exists. A relational database with standard SQL is replaceable. A proprietary workflow service whose process logic lives in a vendor-specific notation effectively is not — here lock-in arises not from data but from logic.

Most organisations have a problem on at least one of these layers that they are unaware of, because nobody ever assessed the three separately. That is precisely what a structured baseline delivers — for example via our cloud migration assessment, which makes exit paths and dependencies visible per workload.

What certifications actually certify — and what they do not

The certification jungle is the most common source of bad decisions, because very different objects of assessment are sold under the same "sovereign" label. Three attestations appear regularly in the DACH region, and each examines something different.

The **C5 criteria catalogue** of the German Federal Office for Information Security is an audit standard for information security in cloud computing, issued as an attestation to auditor standards ([BSI, Cloud Computing Compliance Criteria Catalogue](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/kriterienkatalog-c5_node.html)). C5 says a great deal about security posture and transparency — but nothing about ownership structure or third-country access risk.

**SecNumCloud** is the French qualification issued by the ANSSI authority and goes considerably further: it also imposes requirements on operator structure and immunity from non-European law. Anyone looking for genuine legal immunity is more likely to find it here than in a pure security attestation.

**Gaia-X labels** in turn certify interoperability, data portability and transparency of contractual terms — they are explicitly not evidence of EU ownership and not protection against third-country access. The European Commission has since referenced the Gaia-X rules in its Cloud Sovereignty Framework, which strengthens their role as an interoperability anchor but does not widen what they assess.

The practical consequence: for every attestation a provider presents, ask which of the three layers it addresses. A provider with a C5 attestation and an EU data centre can still depend entirely on a group parent in another jurisdiction — and a provider without a prominent label can, through open standards, offer the higher exit capability in practice.

The Data Act turns sovereignty into a hard requirement

What was a strategic preference for years is now backed by regulation. Regulation (EU) 2023/2854 — the Data Act — contains binding rules in Chapter VI for switching between data processing services ([EUR-Lex, Regulation (EU) 2023/2854](https://eur-lex.europa.eu/eli/reg/2023/2854/oj)). It has applied since 12 September 2025.

Two points are immediately relevant for delivery organisations. First, the regulation obliges providers to actively enable switching: contractually defined transition periods, support for exporting data and — where applicable — digital assets. Second, switching charges are being phased out: from 12 January 2027 providers may in principle no longer charge for switching.

The effect is subtler than it sounds. The Data Act lowers the contractual and financial barriers to switching — but it does not remove the technical ones. If your business logic sits inside a proprietary service, a fee-free switch helps little, because the real effort lies in rebuilding, not in the provider's invoice. The regulation therefore clears exactly the hurdle you could most easily have cleared anyway, and leaves the hard one standing.

For delivery practice this means: from 2027 onwards, "switching would be too expensive" is an architecture argument, not a contractual one. And architecture arguments have to be measurable before they are believable. If you want to place this within the wider regulatory frame, see our regulatory map covering NIS2, DORA, CRA and the AI Act.

Sovereignty classes instead of all-or-nothing

The most expensive mistake in sovereignty programmes is the blanket decision. "We are going fully sovereign" produces costs nobody can justify and usually ends in an exemption list that hollows out the resolution. "We stay as we are" ignores that individual workloads genuinely represent concentration risk.

The robust route is classification. You assess each workload along two axes — damage potential from foreign access, and effort required to switch provider — and derive one of three sovereignty classes. The class then determines the permissible platforms, rather than the case-by-case taste of whichever architect is in the room.

1. 1Class A — sovereignty-critical: core personal and health data, competitively relevant source code, holdings under special regulatory protection. Requirement: legal immunity and customer-held key control, operation within the European legal area, documented exit path.
2. 2Class B — exit-capable: standard business applications without special protection needs. Requirement: open interfaces, data exportable in documented formats, tested exit path — hyperscalers permitted.
3. 3Class C — non-critical: public content, test environments, non-business-critical support services. Requirement: no particular sovereignty conditions, selection purely on cost and operational effort.

What this means for the delivery organisation

Sovereignty rarely fails on strategy and almost always on execution — because nobody owns it. The strategy function writes it down, procurement negotiates it, but nobody verifies it inside a sprint. Three mechanisms change that.

First: **exit capability as a non-functional requirement.** Every class A and B workload gets a documented target platform for the switching case and an estimated switching duration. That estimate is part of the architecture documentation and is updated on every material change. A number nobody maintains is not a number.

Second: **the exit test.** An estimate that has never been verified is a guess. For class A workloads the data export should actually be performed at least once a year, with restorability on an alternative platform evidenced on a sample basis — analogous to the backup restore test that nobody takes seriously until it fails once.

Third: **an architecture gate for new decisions.** When a team wants to adopt a vendor-specific managed service, the resulting binding is made explicit and assigned to a class. This is not a ban on proprietary services — they are often the economically correct choice. It is the requirement to make the decision consciously and traceably, instead of letting it disappear into a ticket.

These three mechanisms cost little and take effect immediately because they attach to existing routines. If you want to test how well your own governance actually carries such gates, our assessment templates are the entry point — and pricing covers full access.

Three anti-patterns that reliably get expensive

The same mistakes recur in sovereignty programmes — and all of them are well intentioned.

• **The location tick.** The region is set to "EU" and the topic is considered closed. Neither operational nor technology sovereignty was ever assessed, and the proprietary managed service at the core of the application remains untouched.
• **The big-bang resolution.** A board decision declares full migration to sovereign platforms. Because no classification exists, the requirement also hits non-critical systems, costs explode, and after two quarters the exemption list grows faster than the programme.
• **Sovereignty without an operating model.** A sovereign platform is procured, but your own team cannot run it because the managed-service depth of the previous provider is missing. Result: formal sovereignty with factually worse availability — and a rollback within a year.