A Practical Guide to Assessing Digital Sovereignty

How This Guide Helps

Digital sovereignty cannot reliably be assessed with a single question:

• Are the data held in Europe?
• Is the provider European?
• Is there an ISO certification?
• Can I export my data?

Each of these questions can be relevant. None is sufficient on its own.

What matters is whether an organisation can identify its technological dependencies, substantiate the key claims, assess the consequences for its specific use case, and make and implement an informed decision.

This guide helps with that process.

It is not a certification scheme, a provider ranking or legal advice. Nor does it replace a regulatory or risk-based assessment of an individual case. It offers a structured starting point for a question that is often addressed too abstractly in practice:

How dependent are we on a provider, and is that dependency acceptable for this specific use case?

1. Digital sovereignty is not a yes-or-no attribute

Digital sovereignty is often discussed in terms of origin, data centre location or data protection. These factors matter, but they form only part of the picture.

An organisation can store all its data in Germany and still depend heavily on:

• Proprietary APIs
• An identity platform that cannot be replaced
• Global administration or support structures
• A single technology or licence supplier
• Proprietary data formats
• A lack of expertise to switch
• A contract without robust provisions for provider switching
• An architecture that can be replicated outside the provider only with substantial effort

Conversely, a dependency is not automatically a problem.

A highly integrated platform service can deliver substantial functional and commercial value. For a less critical use case, deliberately accepting greater dependency may be a rational choice.

The better question is therefore not:

Is the provider sovereign?

But:

What dependencies exist, which are material to our use case, and what informed decision do we make about them?

2. Why Evidence Is Essential

Sovereignty and security assessments often start with provider claims:

• “Data stays in the EU.”
• “Sovereign cloud in the EU.”
• “Customer-controlled encryption.”
• “Switch providers at any time.”
• “ISO 27001 certified.”
• “Audited against C5.”

These statements may be accurate and relevant. Initially, however, they are provider claims.

A sound decision requires at least four distinct levels of consideration:

Provider claim

What does the provider claim?

Evidence

What evidence supports the claim?

Reliability

How was the evidence produced, how current is it, and what conclusions can reliably be drawn from it?

Suitability for the use case

Does the evidence cover the relevant requirements, the service under review and the required period?

For example, a certificate may be valid and current but cover only a particular legal entity, region or part of the service.

An audit report may provide high-quality evidence without automatically covering all of an organisation’s requirements.

A contract may guarantee a data location without ensuring technical portability.

Therefore:

Do not simply check whether evidence exists. What matters is its relevance, currency and scope for the service under review.

3. The Five Dimensions

The guide structures the assessment around five dimensions:

1. Legal framework & control
2. Data & operations
3. Technology & supply chain
4. Portability & provider switching
5. Evidence & reliability

These five dimensions are deliberately practical.

They do not replace regulatory frameworks. The European Commission’s Cloud Sovereignty Framework, for example, uses 48 criteria across eight sovereignty areas. The approach used here gives organisations an accessible starting point and prepares the ground for an informed technology decision.

4. How to Use This Guide

5. Dimension A – Legal Framework & Control

6. Dimension B – Data & Operations

7. Dimension C – Technology & Supply Chain

8. Dimension D – Portability & Provider Switching

9. Dimension E – Evidence & Reliability

10. From Findings to Decisions

Choose the action that fits the dependencies identified, their consequences and the available alternatives. Document the rationale, residual risks, responsibilities and a review date. Several options can be combined.

Accept

Deliberately accept a known dependency where the benefits and effort justify it and mandatory requirements remain satisfied. Document the rationale and review the decision regularly.

Reduce

Reduce the dependency deliberately, for example through open interfaces, exportable configurations or stronger in-house expertise.

Limit the consequences

The dependency remains. Backups, recovery procedures or additional controls limit potential harm.

Develop alternatives

Additional providers, available capacity or in-house expertise create options. Check whether the alternatives actually have different dependencies.

Renegotiate

Improve contractual rights and services, for example for data return, switching assistance or notification of changes.

Migrate

Move the application and data to another environment. First check whether the target environment meets the relevant requirements and what new dependencies arise.

Replace

Replace a product or provider. Consider functionality, transition, data migration and ongoing operation of the new solution.

Bring activities in-house

Operate or control a previously outsourced activity in-house. The necessary skills, staff, resources and responsibilities must be secured over the long term.

The decision template in the PDF appendix brings the assessment, rationale and actions together.

11. Example: One Platform, Two Use Cases

This fictional example shows how the same technical finding can lead to different decisions depending on use. It does not assess a specific provider.

Starting Point

An organisation uses a cloud collaboration application. The review identifies the following:

• The contracting party is a European company. Under the contract, customer data are held in an EU region.
• Operations and technical control depend partly on other providers outside the EU.
• Customer-managed keys are available. They do not exclude technical access by the provider at every processing stage.
• Primary data can be exported. Some logs, permissions information and configurations cannot be transferred in full.
• Switching assistance is covered by the contract. A complete switch has not yet been tested.
• Independent audit reports are available. Whether they cover the current service and present use remains to be clarified.

12. Regulatory Context

This guide does not provide a complete mapping of legal requirements to individual assessment questions. However, several current frameworks show why provider dependency, supply chains, evidence and switching are increasingly concrete management responsibilities.

EU Cloud Sovereignty Framework

In June 2026, the European Commission published additional implementation guidance for its Cloud Sovereignty Framework.

The approach uses 48 criteria across eight sovereignty areas, supplemented by sovereignty scores and assurance levels.

For provider assessment, this means that control, technology dependencies and operational capabilities matter alongside data location.

DORA

Regulation (EU) 2022/2554 has applied since 17 January 2025.

Financial entities within its scope need exit strategies, among other measures, for ICT services supporting critical or important functions. The corresponding exit plans must be documented, adequately tested and reviewed regularly. Alternative solutions and transition plans also form part of the approach.

DORA does not apply to every organisation. Its underlying principle is nevertheless useful in practice:

Critical provider dependency should be examined before notice of termination is given.

NIS2 and the German BSIG

NIS2 expressly includes supply chain security and relationships with direct suppliers and service providers as part of cybersecurity risk management.

Section 30 BSIG sets out corresponding requirements for essential and important entities in Germany.

This is neither a general legal obligation for every organisation nor a complete definition of sovereignty. It does show that supplier and provider dependencies are part of sound risk management.

EU Data Act

The Data Act sets out requirements for switching between data processing services and for portability.

For switching governed by the Data Act, switching charges, including related data egress charges, are abolished from 12 January 2027. This does not mean every data transfer during ongoing use becomes free of charge.

A statutory right to switch does not replace the technical ability to do so.

BSI C5

C5 provides a criteria catalogue for independent audits of cloud services.

The BSI expressly states that a C5 attestation is not a BSI certification. It also notes that a C5 attestation alone does not automatically satisfy all requirements of the minimum standard for the use of external cloud services.

When reviewing a C5 report, check in particular the service covered, audit period, attestation type, identified deviations and controls that the customer must implement.

ISO/IEC 27001

ISO/IEC 27001:2022 specifies requirements for information security management systems.

A relevant certification can support the information security assessment.

It does not automatically demonstrate digital sovereignty.

13. When should you reassess?

Reassessment should be triggered in particular by:

• Contract renewal
• Acquisition or change of ownership
• Material change in critical subcontractors
• Change in data or operating locations
• New technical platform/control plane
• Significant security incident
• New regulatory requirements
• Change in application criticality
• New realistic alternatives
• Results of a switching test

14. The Most Important Rule

The goal is not maximum independence at any cost.

The goal is:

Make dependencies visible, distinguish evidence from assumptions, and make an informed decision about which dependency an organisation accepts for a specific purpose.

A documented, well-founded dependency can be a good decision.

A sound decision also identifies uncertainties and outstanding evidence. It specifies who will resolve them and when the assessment will be reviewed.

Appendix A: 25-Question Checklist

The fields on this web page can be completed. Entries are not saved or transmitted. For a working copy that can be saved, use the fillable PDF.

Tick a statement only when it is demonstrably satisfied. Explain any items that are not applicable. Record open issues with an owner and deadline. The ticks do not produce a sovereignty score.

Appendix B: Evidence Checklist

Select the documents required. Tick receipt and review separately. “Checked” means that relevance, currency and scope have been assessed. It does not automatically mean that all requirements are met.

Appendix C: Decision Template