Sovereign washing: when is a cloud really European?

“EU-hosted.” “Data centre in Frankfurt.” “GDPR-compliant.” These statements can describe important characteristics. Alone, they do not answer who controls data, which access is possible and which legal obligations apply to the providers involved.

The problem is sovereign washing: marketing a cloud service as sovereign or European without adequately explaining and substantiating the claimed characteristics. CISOs, data protection officers and compliance teams should therefore examine the specific service rather than the label alone.

This guide provides five assessment areas for procurement. They support vendor assessment; they are not a statutory quality mark or a score that automatically establishes GDPR compliance or digital sovereignty.

Substantively updated on 24 October 2026. Originally published on 11 May. This assessment distinguishes data protection law, government access and your own sovereignty requirements.

What is sovereign washing?

Sovereign washing describes unsubstantiated or misleadingly simplified sovereignty claims. Typical reasons to investigate include:

• An EU data centre without an explanation of control: storage location does not identify the operating company or who has administrative access.
• “GDPR-compliant” without reference to actual use: lawful use also depends on purpose, data, configuration and contracts. It is not a blanket property of every customer deployment.
• Standard contractual clauses without assessing the transfer: recipient, legal context and any necessary supplementary measures belong in the assessment.
• Encryption without a key and plaintext model: what matters is who can use keys and read data during operations.
• BYOK as a product name alone: check functionality, plan, operations and actual access possibilities.

Not every incomplete product description proves deception. Request missing information and document what remains unclear afterwards.

The legal background: Schrems II, CLOUD Act and the DSK assessment

1. Schrems II and today’s transfer framework. In 2020, the CJEU invalidated the EU-US Privacy Shield while confirming standard contractual clauses subject to conditions. That is not the entirety of today’s legal framework: the EU-US Data Privacy Framework (DPF) adequacy decision has existed since 2023. It can provide a basis for covered transfers to participating US organisations. Check the specific participation and service; the DPF does not replace all other GDPR obligations. CJEU judgment, European Commission on the DPF

2. CLOUD Act. The US Department of Justice explains that providers subject to US jurisdiction can be required to disclose data in their possession, custody or control regardless of storage location. This means neither automatic access to all EU data nor that a US shareholder alone brings every subsidiary within scope. Jurisdiction, a specific valid legal order and control over the requested data matter. Conversely, an EU headquarters alone does not establish comprehensive immunity from foreign law. DOJ CLOUD Act white paper

3. The DSK assessment of Microsoft 365. Germany’s data protection authorities’ 24 November 2022 position concerns the contractual terms and information assessed at that time. It is a historical reference for transparency and accountability, not a current blanket ban on all Microsoft 365 use. Procurement must examine today’s contracts, features and actual processing. DSK report from 2022

Lawful processing and digital sovereignty are different questions. A lawful transfer may still fail your additional procurement requirements. Conversely, European ownership does not prove complete GDPR compliance.

The five-part checklist for genuine sovereignty

First define your organisation’s requirements: particular data locations, restricted administrative access, customer key control or a tested provider exit. Then examine every relevant area. One critical unresolved issue is not offset by three other checkmarks.

1. Parent company and beneficial ownership

Who controls the contracting party and operations? Examine the specific company, group structure and material control. Ask which entities provide support, administration and key management.

European ownership can be a procurement criterion. It does not replace examination of other legal and technical dependencies. A stock exchange listing, a shareholding and government access are not automatically the same thing.

Ask the provider: “Which companies can access our data, and how do you substantiate your statement about applicable jurisdictions?”

2. Data residency and subprocessors

Where is each kind of data processed? Distinguish product data, backups, logs, metadata and support cases. Review subprocessors for infrastructure, email and other services, including their roles and access possibilities.

You need the subprocessor and data-flow information applicable to your contract. An Article 30 GDPR record of processing activities and a subprocessor list serve different purposes; one does not replace the other.

“Region may vary” needs clarification. A provider’s name alone, however, does not establish which data flows there in your deployment.

3. Encryption control and key management

Who can use keys and see plaintext? Encryption at rest and in transit protects against particular access paths. Whether it also prevents access through the provider depends on the architecture.

With BYOK (Bring Your Own Key), a customer may supply key material while the service can still use it for decryption. HYOK (Hold Your Own Key) also needs examination of the actual implementation. A product label does not guarantee data the provider cannot read.

Check key storage, usage rights, plaintext processing, revocation and recovery. The EDPB distinguishes effective encryption under specified conditions from situations where a cloud provider must process plaintext. EDPB Recommendations 01/2020

4. Government access and legal remedies

How does the provider handle data requests? Ask about verification of the legal basis, responsible teams, possible challenges and customer notification where permitted.

Transparency reports and contractual duties support assessment. A contract cannot simply exclude mandatory law. A promise to review or challenge a request differs from a guarantee never to disclose data.

For critical data, document which remaining access risks your organisation can accept and who decides.

5. Code and contract transparency

Which claims can you actually verify? Use contracts, subprocessor information, technical descriptions and suitable independent reports. For each attestation, check the service, scope and period.

Public source code can facilitate some examinations. Alone, it proves neither the version actually operated nor secure operations. Closed source is likewise not evidence of sovereign washing.

An NDA-protected report can protect sensitive details and still be useful. What matters is adequate access to claims and limitations relevant to your use. Assess a C5 attestation or code of conduct according to its actual scope, not as a blanket sovereignty certificate.

Three real examples

Microsoft 365 and privacy assessments. The DSK’s 2022 position illustrates why contracts and responsibilities need examination. Distinguish that historical state from current offerings and assessment of a specific school or public-sector deployment.

The 2021 OVHcloud fire. The provider documented the destruction of SBG2 and damage to SBG1 in Strasbourg. The case illustrates why data location and organisational control do not replace recoverability. Assess geographical separation, agreed backup services and actual restore tests separately. OVHcloud incident information

AWS European Sovereign Cloud. AWS announced general availability of its European offering in January 2026. Examine its specific companies, operational boundaries, contracts and technical controls rather than categorising it solely by group name. The vendor’s description is a source about the offering, not independent proof of all your organisation’s requirements. AWS announcement

Vendor assessment checklist for CISOs

When assessing a GRC platform, CRM, HR system or marketing cloud, ask:

• Which company is the contracting party, who controls it and who operates the service?
• Which subprocessors handle which data, and where?
• Where are product data, backups and logs? Which support access is possible?
• How do BYOK or HYOK actually work, and who can process plaintext?
• Which legal basis supports a relevant international transfer?
• How are government requests reviewed, documented and, where appropriate, challenged?
• Which contracts and audit reports cover our exact service and period?
• How can we export data, change provider and verify deletion?

Assess each answer with its source, scope, unresolved issue, owner and decision. One unresolved critical access path can matter more than several fulfilled secondary requirements.

Where Kopexa stands: an honest assessment

The same examination applies to Kopexa as to other providers. The following operator statements describe the working basis, not a guarantee of comprehensive legal immunity:

Kopexa is assessed here as a hosted SaaS platform. This does not promise on-premises or air-gapped deployment, ISO 27001 certification or a C5 attestation. Required service commitments and assurance belong in the specific contractual review before procurement.

Kopexa’s value lies in connecting suppliers, risks, requirements, measures and evidence traceably. A certificate or European address does not replace reviewing your actual use of our platform either.

What you can do now

1. Assess one important cloud service against the five areas. Start with indispensable requirements, not a blanket score.
2. Connect the assessment to your processing. Your record of processing activities should make clear which data and purposes belong to the service. Add the relevant vendor and transfer assessment without treating the two registers as identical.
3. Define procurement rules. Name minimum requirements, suitable evidence, responsibility and the handling of justified exceptions.

One unanswered question about an existing provider is enough for an initial working case. In Kopexa, use it to discuss how supplier, risk, measure and evidence stay connected. Our ISMS product page explains the platform.