Sector data spaces are federated environments in which organisations within a defined industry share, access, and govern data under common technical and legal rules, without surrendering control to a central operator. The EU Data Union Strategy, published in 2025 as COM(2025) 835, commits the European Commission to operationalising at least ten such spaces by 2026, covering health, finance, mobility, energy, agriculture, and, for the first time, defence. For the infrastructure operators, compliance officers, and CISOs who must host these environments, this is not a future policy question; it is an immediate technical and legal obligation.
What the EU Data Union Strategy Actually Requires from Infrastructure Operators
COM(2025) 835 establishes that sector data spaces must guarantee data residency within a defined legal perimeter, enforce machine-readable access policies, and support interoperability with other data spaces through standardised connectors. These three requirements translate into concrete infrastructure obligations that go well beyond conventional cloud procurement.
On data residency, the strategy specifies that sensitive sector datasets, particularly in health and defence, must be stored and processed in jurisdictions where EU law applies without jurisdictional override by a foreign government. This directly implicates the US CLOUD Act and FISA Section 702, both of which allow US authorities to compel disclosure of data held by US-controlled entities regardless of physical server location. Infrastructure operators offering hosting for a sector data space must therefore demonstrate that no part of their ownership chain or software stack is subject to such compelled-disclosure authority. Swiss hosting under the revised Federal Act on Data Protection (FADP) satisfies this requirement because Switzerland operates under no equivalent extraterritorial access law, and the European Commission has recognised Switzerland as an adequate jurisdiction under GDPR Article 45.
On access control, the strategy requires that every data transaction within a sector space be governed by a usage policy that is technically enforced, not merely contractually assumed. This is where the architecture of the data space matters as much as the jurisdiction of the host.
The European Health Data Space: Secondary Use and Sovereignty Obligations
Regulation (EU) 2025/327, which entered into force on 26 March 2025, gives the European Health Data Space (EHDS) its legal foundation. The EHDS creates two distinct data flows: primary use (patient care, covered by existing GDPR health data provisions) and secondary use (research, policy, AI training, covered by the new EHDS secondary-use permit regime). Sovereign infrastructure operators hosting EHDS-connected environments face obligations in both flows.
For secondary use, the EHDS requires that data accessed through health data access bodies (HDABs) be processed exclusively in secure processing environments. These environments must be technically isolated, must prevent data egress, and must log every access event in a format that regulators can audit. Critically, the EHDS prohibits transfer of secondary-use health data to third countries unless the third country is deemed adequate under GDPR or a specific transfer mechanism is in place. This means that a health data lab running on infrastructure subject to US jurisdiction is structurally non-compliant, irrespective of the contractual protections claimed by the provider.
The average total cost of a healthcare data breach globally reached USD 10.93 million per incident in 2023, according to the IBM Cost of a Data Breach Report 2023, making the financial case for sovereign secure processing environments as compelling as the legal one.
Technical and Contractual Requirements for Sovereign Hosting of a Sector Data Space
A sovereign infrastructure provider must satisfy obligations across three stacked layers: legal, contractual, and technical.
Legal and Contractual Layer
GDPR Article 28 requires that any processor handling personal data on behalf of a controller operate under a written Data Processing Agreement (DPA) that specifies the subject matter, duration, nature, and purpose of processing; the categories of data subjects; and the obligations and rights of the controller. For a sector data space, the DPA must also name all sub-processors, confirm that sub-processors are bound by equivalent obligations, and grant the controller audit rights. A sovereign provider cannot outsource storage, backup, or key management to a sub-processor in a non-adequate country without triggering a GDPR violation.
NIS-2 (Directive (EU) 2022/2555) adds a parallel layer: the provider, if it qualifies as an essential or important entity, must implement risk management measures, report significant incidents to the national competent authority within 24 hours, and ensure supply chain security. NIS-2 now covers 18 sectors, compared to 7 under the original NIS-1, according to ENISA, meaning that most infrastructure operators serving regulated sector data spaces will fall within its scope.
Technical Layer: Interoperability Standards
The EU Data Act’s interoperability provisions (Articles 33 to 37) require that data spaces support open, standardised interfaces that prevent vendor lock-in. For hosting operators, this means deploying infrastructure that can expose data through standardised APIs and that can interface with connectors from other data space participants without requiring proprietary middleware.
Gaia-X Trust Framework and IDSA Connector Specifications
The Gaia-X Trust Framework defines the criteria that a cloud provider must meet to be listed as a trusted participant in a Gaia-X-aligned data space. It operates through a system of self-descriptions, in which providers declare their jurisdiction, sub-processors, certifications, and technical capabilities, verified by accredited Conformity Assessment Bodies. A Gaia-X label does not replace GDPR compliance, but it provides a machine-readable attestation that regulators and data space participants can verify without repeating a full audit for every partnership.
The International Data Spaces Association (IDSA) Reference Architecture Model complements this by specifying the connector, the core software component that enforces data usage policies at the point of exchange. An IDSA-compliant connector negotiates contracts between data providers and consumers, logs all transactions in a tamper-evident audit trail, and enforces restrictions such as “this dataset may only be accessed from within EU jurisdiction” or “this health record may not be combined with mobility data.” For sovereignty purposes, deploying an IDSA connector means that access governance is technically enforced, reducing reliance on contractual promises that may be unenforceable across borders.
| Requirement | Gaia-X Trust Framework | IDSA Connector | GDPR Art. 28 DPA | NIS-2 |
|---|---|---|---|---|
| Jurisdiction declaration | Mandatory (self-description) | Enforceable at runtime | Named in agreement | Implicitly required |
| Sub-processor transparency | Required in self-description | Not specified | Mandatory annex | Supply chain audit required |
| Audit rights | Via Conformity Assessment Body | Transaction log | Controller audit right | National authority inspection |
| Incident reporting | Not specified | Not specified | Processor notifies controller | 24-hour report to authority |
Data Labs, AI Training, and Preventing Jurisdictional Exposure
The EU Data Union Strategy introduces the concept of data labs: controlled environments in which AI models can be trained on sensitive sector datasets without exposing the underlying data to the model developer or to external cloud infrastructure. The EHDS operationalises this for health data specifically, requiring that AI training on secondary-use health data occur only in approved secure processing environments with no data egress.
The European Data Protection Supervisor has noted that “data spaces are not just a technical architecture; they are a governance instrument. Without clear rules on who controls data and under which law, interoperability becomes a liability rather than an asset.” This applies directly to data labs: an organisation that permits AI training on sovereign sector data using a commercial cloud AI API is, by definition, exporting that data to whatever jurisdiction governs the API provider.
The technically sound approach is to run open-source model architectures such as Mistral or Llama on on-premises or sovereign-hosted GPU infrastructure, where the model weights, training logs, and output artefacts remain within the sovereign perimeter. Organisations must also assess whether model outputs can indirectly re-identify individuals, a risk that is especially acute for health and legal sector datasets, and govern model sharing under the same access control regime as the training data.
Documenting Compliance: A Framework for Audit-Ready Evidence
Compliance officers responsible for a sector data space deployment must produce documentation that satisfies simultaneously the EU Data Union Strategy’s interoperability requirements and the organisation’s sovereign data protection obligations under GDPR or FADP. The following four-layer documentation structure covers both dimensions.
First, a data residency map: a diagram and accompanying register showing that all primary storage, backup, disaster recovery, and key management infrastructure is within the declared jurisdiction, with no sub-processors in non-adequate countries. Second, a signed GDPR Article 28 DPA with a complete sub-processor annex and documented audit rights exercise schedule. Third, a Gaia-X self-description from the provider, verified by an accredited Conformity Assessment Body, or equivalent trust attestation. Fourth, an access governance log covering every data lab access request, the legal basis on which it was granted (such as an EHDS secondary-use permit), and the technical enforcement mechanism (such as the IDSA connector transaction record) that confirms the policy was applied.
The Gaia-X Association AISBL has stated that “the sovereignty of data infrastructure is inseparable from the sovereignty of the institutions that rely on it. Jurisdictional exposure at the infrastructure layer propagates directly into operational risk.” This framing is directly relevant to audit documentation: a regulator examining a sector data space incident will trace the exposure back through the infrastructure chain, and each layer without documented sovereignty controls becomes a finding.
For organisations subject to the Swiss FADP, the documentation logic is analogous but references FADP adequacy status and the specific provisions of the revised act that govern cross-border data transfers and processor obligations. The FADP’s alignment with GDPR principles means that a documentation package prepared for GDPR purposes is largely portable, provided the Swiss-specific provisions on the register of processing activities and the role of the data protection officer are addressed separately.
FAQ
Does a Swiss hosting provider automatically satisfy EU GDPR requirements for sector data space deployments?
Not automatically. Switzerland holds European Commission adequacy recognition under GDPR Article 45, which permits cross-border transfers without additional mechanisms. However, the provider must still execute a GDPR Article 28 Data Processing Agreement, implement appropriate technical and organisational measures, and demonstrate NIS-2-equivalent security controls where the data space serves EU-regulated entities.
What is the difference between a Gaia-X label and NIS-2 compliance for an infrastructure provider?
A Gaia-X label certifies that a provider’s self-description is accurate and that its service meets defined trust criteria around transparency, portability, and jurisdiction. NIS-2 compliance is a legal obligation under Directive (EU) 2022/2555 requiring risk management, incident reporting to national authorities within 24 hours, and supply chain security. Sector data space operators should require both: Gaia-X labelling for interoperability trust and NIS-2 alignment for security assurance.
What does an IDSA-compliant connector actually do in a sector data space deployment?
An IDSA connector is a software component that enforces data usage policies at the point of exchange. It negotiates contracts between data providers and consumers, logs transactions in a tamper-evident audit trail, and prevents data from being used outside agreed terms, for example by blocking access requests originating from outside the declared jurisdiction. For sovereign infrastructure operators, this transforms access governance from a contractual promise into a technical control.
How should a compliance officer document sovereignty controls for a sector data space audit?
Documentation must cover four layers: a data residency map confirming no sub-processors in non-adequate countries; a signed GDPR Article 28 DPA naming sub-processors and specifying audit rights; a Gaia-X self-description or equivalent trust attestation from the provider; and an access governance log cross-referencing data lab access decisions with their legal bases and IDSA connector transaction records.
Can AI models be trained on sector data space datasets without creating jurisdictional exposure?
Yes, provided the training environment is itself sovereign. The EU Data Union Strategy’s data lab concept is designed precisely to permit AI training on sensitive datasets under controlled conditions. The training must occur within the sovereign perimeter with no data egress to external cloud APIs, model weights must be governed under the same access policy as the training data, and outputs must be assessed for re-identification risk before any sharing. Open-source architectures such as Mistral or Llama, running on sovereign-hosted GPU infrastructure, satisfy this requirement where proprietary cloud AI services do not.