"We need a sovereign solution" is an understandable goal – but not yet a verifiable requirement. For some, sovereignty means a data center in Germany. Others mean European ownership, customer-owned keys, independent operation or the ability to change providers without loss of control.
As long as these ideas are not separated, invitations to tender full of big terms and small proofs are created. Providers can answer the same question differently, purchasing and security compare different levels, and in the end it remains unclear whether the selected service actually creates more control in everyday life.
The European Commission now takes a multidimensional view of cloud sovereignty. In addition to data location and legal space, operations, supply chain, technology and portability, among other things, play a role. For security platforms, this can be used to derive a practical evaluation model with eight fields.
1. Data: Where do they originate, flow and remain?
Don't start with the provider, start with the types of data. A security platform can inspect content, store metadata, assess devices, process identities and generate alarms. This information has different risks and retention requirements.
Record per data class:
- Source and professional owner,
- processing and storage location,
- transmission paths,
- Retention period and deletion process,
- Backup and support copies,
- permitted recipients and subcontractors.
Only this map shows whether "Data in Europe" applies to the entire process or only to a part.
2. Jurisdiction: Which law affects which party?
A server location does not automatically answer the laws of the vendor, parent, support organization, and subcontractors. The assessment must cover the entire service chain.
The sensible working question is not "Is the provider European?", but: Which party can access which data or systems under which legal basis – and which technical controls limit this access?
Security, data protection and purchasing should document this answer together. This is the only way to avoid confusing legal and technical assumptions.
3. Cryptography: Who has effective key control?
"Encrypted" is not a binary stamp of quality. Check whether keys are with the provider, with the customer, or in a separate trust area. Clarify rotation, backup, locking, and emergency access.
In the case of security services, there is also the fact that some functions have to check data in plain text in order to detect threats or policy violations. Sovereignty here does not mean preventing every processing. It means controlling the purpose of processing, the duration, the access paths and the subsequent treatment in a comprehensible manner.
4. Operation: Who can act technically?
A service can be hosted confidently and still operate non-sovereign. Privileged accounts, support access, automations, and policy changes are critical.
A resilient operating model answers:
- Who can read, modify, share, and restore?
- Are roles limited to the necessary minimum?
- Are administrative meetings logged?
- Are there time-limited accesses?
- What changes need a four-eyes principle?
- Can the customer revoke partner access immediately?
These rules must fit together technically and organizationally.
5. Supply chain: Which dependencies remain hidden?
Cloud and security services consist of more than one contractual partner. Hardware, virtualization, platform services, software components, updates, telemetry, and support can come from different supply chains.
Complete independence is rarely realistic. Transparent dependence, on the other hand, is achievable. Document critical suppliers, alternative procurement channels, update responsibilities, and components that cannot continue to operate without a specific manufacturer.
6. Technology: How open are interfaces and operational knowledge?
APIs, documented data models, and exportable configurations determine whether a company can continue to use its security data. Proprietary is not automatically bad. It becomes problematic when central operating information is only available within an interface and cannot be stored or transferred in a traceable way.
Therefore, check API coverage, export formats, automation options, access to documentation and the availability of your own or European operational expertise.
7. Portability: What does the exit really look like?
The EU is strengthening the switch between cloud providers. Technically, however, the exit remains a project. Security platforms include rules, exceptions, roles, certificates, integrations, data histories, and runbooks.
A robust exit test asks:
- What data and configurations can be exported?
- In what format and with what relationships?
- Which functions need to run twice during parallel operation?
- How will identities, keys and interfaces be converted?
- How is the deletion confirmed by the previous provider?
The exit is not a vote of no confidence. It is part of good architecture.
8. Governance: How is sovereignty maintained after the purchase?
A one-time exam ages quickly. Regions, subcontractors, products, integrations, and support models are changing. That's why sovereignty needs an owner, an inspection rhythm and measurable deviations.
Suitable control points are, for example:
- Proportion of documented data flows,
- Number of privileged roles and unclear support paths,
- Age of the last exit and restart test,
- open supply chain records,
- unmapped keys or certificates,
- Changes to data locations or subcontractors.
In this way, sovereignty becomes an ongoing operational discipline instead of a procurement argument.
The result is a decision matrix, not a seal
Not every workload needs the highest level in all eight fields. A public marketing portal has different requirements than a platform that processes identity, device, and security data.
The eight test bays help to determine the necessary control according to risk. A company can consciously decide which global manufacturer performance it uses, which data must remain regional, which components are operated in Europe and which exit capability is indispensable.
It is precisely this transparency that makes digital sovereignty credible: not the assertion of maximum independence, but the proven ability to control data, operations and decisions itself.