Gaia-X data spaces and the International Data Spaces Association (IDSA) connector architecture together constitute the EU’s most technically mature answer to the question of how organisations can share sensitive data without surrendering control over it. Where GDPR provides a legal floor and NIS-2 defines security obligations, Gaia-X and IDSA translate those obligations into machine-enforceable technical requirements: signed self-descriptions, certified connectors, and policy expressions that deny unauthorised access at the protocol level rather than relying solely on contractual promises.
For compliance officers, CISOs and data protection officers in government, finance, healthcare and legal services, this matters because the framework is no longer purely voluntary. Procurement rules in several EU member states and the emerging European Technological Sovereignty Package are making Gaia-X label levels and IDSA connector certification conditions of market access for cloud providers serving regulated workloads.
Gaia-X Trust Framework Labels: What They Mean and What They Require
The Gaia-X Trust Framework, codified in version 22.10 released in October 2022, defines three label levels that classify the degree of independently verified compliance a cloud or hosting provider can claim.
- Label Level 1 is based on self-declaration. A provider signs a structured Gaia-X Self-Description, a machine-readable JSON-LD document published to the Gaia-X Federated Catalogue, asserting compliance with baseline criteria covering data residency, transparency of subprocessors, and applicable law. No external audit is required at this level.
- Label Level 2 requires conformity assessment by a Gaia-X-recognised third party. The provider must demonstrate that its technical and organisational controls match its self-declared attributes. This level is the minimum threshold emerging in national public-sector procurement frameworks across France, Germany and the Netherlands.
- Label Level 3 demands a full audit by an accredited Conformity Assessment Body (CAB) recognised by Gaia-X AISBL. It covers portability, interoperability and the absence of technical lock-in mechanisms, and it is the level targeted by sectoral data spaces such as the European Health Data Space (EHDS) and Catena-X for manufacturing.
Gaia-X AISBL counted more than 300 member organisations from over 20 countries as of its 2023 annual report (Gaia-X AISBL, 2023). This breadth means the label ecosystem is substantial, but it also means the quality of self-declarations varies significantly. The Federated Catalogue is not a curated whitelist; it is a public registry of signed claims, and the verification burden rests with the procuring organisation.
IDSA Dataspace Protocol and ODRL: Technical Requirements for Sovereign Providers
The IDSA Dataspace Protocol (DSP) defines the technical handshake between participant connectors in a data space: catalogue exchange, contract negotiation and data transfer are all governed by the protocol, which is independent of the underlying cloud infrastructure. A provider that claims Gaia-X participation but cannot demonstrate a certified DSP-compliant connector is offering sovereignty in name only.
As the IDSA Reference Architecture Model states: “The International Data Spaces architecture ensures that data sovereignty is not just a contractual promise but a technically enforced reality through connector-level policy execution.”
Policy enforcement within DSP relies on ODRL (Open Digital Rights Language), a W3C recommendation that provides a vocabulary for expressing permissions, prohibitions and obligations as machine-readable policies attached to data assets. In practice, an ODRL policy attached to a dataset might specify that the data may only be processed by parties established in the EU, may not be transferred to subprocessors outside the EEA, and must be deleted after a defined retention period. When a compliant IDSA connector receives a data request, it evaluates the ODRL expression before releasing the asset. A requesting party whose jurisdiction or attributes violate the policy is denied access at the protocol layer, not merely at the contract layer.
For a regulated organisation selecting a sovereign hosting provider, this translates into a concrete technical requirement: the provider must deploy a connector that has passed IDSA certification, must publish machine-readable ODRL policies for all offered services, and must be able to demonstrate connector logs as audit evidence. Providers who cannot supply these artefacts are not participants in the Gaia-X data space ecosystem, whatever their marketing materials claim.
EU Cloud Sovereignty Framework SEAL Levels and Their Relationship to Gaia-X
The EU Cloud Sovereignty Framework introduced a parallel classification, the SEAL levels, which map roughly onto the Gaia-X label levels but are anchored more explicitly in the EUCS (European Union Cloud Security Scheme) certification work of ENISA.
| Level | Gaia-X Label | EU SEAL Equivalent | Verification Mechanism | Applicable Sector Requirement |
|---|---|---|---|---|
| Basic | Level 1 (self-declared) | SEAL Basic | Self-declaration + signed Self-Description | General commercial workloads |
| Substantial | Level 2 (third-party assessed) | SEAL Substantial | Recognised CAB conformity assessment | Public sector, NIS-2 important entities |
| High | Level 3 (accredited audit) | SEAL High | ENISA-accredited CAB full audit | Critical infrastructure, EHDS, DORA in-scope entities |
The EHDS regulation, which progressed through trilogue in 2023 and 2024, explicitly references Gaia-X-compatible data space infrastructure as a preferred technical implementation for the primary and secondary use of health data across member states. Catena-X, the automotive and manufacturing data space, has similarly adopted the IDSA DSP as its connector standard and requires Level 3 certification for providers handling production supply-chain data.
Verifying Genuine Compliance Rather Than Marketing Claims
Gaia-X AISBL is explicit that its framework does not create a curated cloud marketplace. As the organisation’s official position states: “Gaia-X is not a cloud provider. It is a framework for rules and standards that enable a federated, secure and interoperable data infrastructure.” The practical consequence is that verification is the procuring organisation’s responsibility.
A rigorous verification process for a prospective sovereign cloud provider should include at minimum the following steps:
- Query the Gaia-X Federated Catalogue directly for the provider’s signed Self-Description and confirm the label level claimed is supported by a current, valid CAB certificate, not merely a historical self-declaration.
- Request the IDSA connector certification documentation, including the version of the DSP specification the connector implements and the date of the most recent conformity test.
- Ask for ODRL policy artefacts for the specific services being procured and verify that those policies are enforced at connector level rather than at the application layer, where they could be bypassed by the provider’s own administrators.
- Review the provider’s subprocessor registry for any entities established outside the EU or EEA. Under GDPR Article 28 and the expanded Gaia-X Trust Framework criteria, every subprocessor must itself meet the same label level as the primary provider for any processing of personal or sensitive data.
- Obtain the provider’s most recent audit report from the CAB, including findings on third-country access controls and the technical mechanisms that prevent foreign law enforcement requests from being fulfilled without the data controller’s knowledge.
Contractual and Technical Controls Beyond Baseline GDPR
Standard GDPR processor agreements under Article 28 require documented processing purposes, deletion obligations and subprocessor notification. The Gaia-X Trust Framework 22.10 and the IDSA DSP architecture require additional controls that go materially further.
Data residency must be technically enforced, not merely declared. This means geographic constraints must be implemented at the infrastructure layer, with cryptographic attestation that data at rest and in transit does not leave specified jurisdictions. The provider must supply continuous audit logs demonstrating this, not just a contractual warranty.
Third-country access controls are a specific Trust Framework requirement. The provider must document the legal mechanisms that would apply if a non-EU authority (including the US Department of Justice under the CLOUD Act, or the NSA under FISA Section 702) demanded access to data, and must demonstrate technical controls, such as customer-controlled encryption keys and split-key architectures, that make compliance with such demands technically impossible without the data controller’s active participation.
Auditability requires that the controller, or its appointed auditor, can independently verify compliance at any time. This is distinct from the provider reporting to the controller: the controller must have the technical means to inspect, not merely the contractual right to request inspection.
Over 50% of EU public-sector cloud contracts are expected to include explicit data-residency and sovereignty clauses by 2025, according to Gartner forecasts published in 2023. This trajectory reflects both regulatory pressure and a growing recognition that contractual sovereignty without technical sovereignty is legally insufficient under NIS-2 and DORA.
The Cloud and AI Development Act and the Sovereignty Package
The European Technological Sovereignty Package, expected to reach its legislative form around June 2026, includes the Cloud and AI Development Act (CADA). CADA is designed to codify for strategic sectors, including energy, finance, health and government, what the Gaia-X Trust Framework currently provides as a voluntary standard.
Under the anticipated structure of CADA, providers serving regulated entities in strategic sectors will be required to hold a Gaia-X label at Level 2 or higher as a condition of public procurement eligibility above defined thresholds. They will also be required to deploy IDSA-certified connectors for any cross-border data exchange involving personal data or data classified as sensitive under sectoral regulations. The IDSA documented more than 30 active pilot and production data space implementations referencing the Dataspace Protocol as of its 2023 reference architecture update, providing the implementation base on which CADA compliance will be measured.
CADA does not replace GDPR, NIS-2 or DORA. It operates as a sector-specific overlay, much as DORA does for financial services. For a regulated organisation, this means that sovereign cloud procurement decisions made today on the basis of Gaia-X Label Level 2 and certified IDSA connectors will align with anticipated CADA requirements, while decisions based on self-declarations or non-EU legal entities will likely require remediation before CADA comes into force.
FAQ
Is Gaia-X Trust Framework Label Level 1 sufficient for public-sector cloud procurement in the EU?
Label Level 1 confirms only self-declared compliance and provides no independent assurance. Most national procurement frameworks and sectoral data spaces such as EHDS require Label Level 2 at a minimum, and Level 3 for sensitive or critical workloads.
What is the difference between a Gaia-X Self-Description and an IDSA connector?
A Gaia-X Self-Description is a signed, machine-readable declaration about a service’s attributes published to the Federated Catalogue. An IDSA connector is the runtime software component that enforces data-sharing policies using the Dataspace Protocol and ODRL. The Self-Description establishes identity and claims; the connector enforces those claims technically during actual data exchange.
How does ODRL policy enforcement prevent a cloud provider from sharing data with a foreign jurisdiction?
ODRL allows data owners to attach machine-readable usage policies specifying permitted parties, prohibited jurisdictions and retention obligations. A compliant IDSA connector evaluates the ODRL policy before releasing any data asset. If the requesting party’s jurisdiction falls outside the permitted scope, the transfer is blocked at connector level, not merely prohibited by contract.
What does the Cloud and AI Development Act add to existing Gaia-X and GDPR obligations?
CADA is expected to make Gaia-X label certification and IDSA connector deployment mandatory for providers serving strategic sectors in public procurement above defined thresholds. It builds on GDPR, NIS-2 and DORA rather than replacing them, and it converts currently voluntary framework participation into a legal prerequisite for market access in regulated sectors.
Can a Swiss-hosted provider participate in Gaia-X data spaces and satisfy EU data residency requirements simultaneously?
Yes, provided the provider obtains the appropriate Gaia-X label through a recognised Conformity Assessment Body and deploys a certified IDSA connector. Switzerland’s revised Federal Act on Data Protection provides an adequacy-equivalent legal basis, and physical hosting in Switzerland keeps data outside US CLOUD Act jurisdiction. The provider must publish a compliant Self-Description to the Federated Catalogue and demonstrate that no subprocessor in a non-adequate jurisdiction handles the data.