Hospital cybersecurity under NIS-2 is no longer a question of best-practice ambition; it is a statutory obligation with personal liability for senior management, mandatory incident reporting timelines and administrative fines calibrated to global turnover. For European health entities, the compliance picture in 2025 is shaped by at least six intersecting regulatory instruments, and the architecture choices made today determine whether a hospital can demonstrate sovereign control of patient data to a national supervisory authority or whether it remains exposed to foreign-jurisdiction legal access requests it cannot refuse.
The 2025 EU Action Plan and its mapping to NIS-2 Article 21
The EU Action Plan on the Cybersecurity of Hospitals and Healthcare Providers, published in January 2025 as COM(2025) 10, translates the general risk-management framework of NIS-2 Article 21 into sector-specific operational duties. It does not create new law but it signals supervisory expectations and allocates ENISA a direct implementation role.
NIS-2 Article 21 requires essential entities, which includes hospitals and health infrastructure operators listed under Annex I of Directive (EU) 2022/2555, to adopt measures covering incident handling, business continuity, supply-chain security, access control, cryptography, vulnerability management and multi-factor authentication. The Action Plan layers onto these obligations by specifying that health entities must conduct self-assessments against a baseline cybersecurity maturity model before mid-2026, must report to national competent authorities on gaps, and must implement a minimum set of 46 security measures drawn from the ENISA health-sector guidelines.
The Commission’s own framing in COM(2025) 10 reflects the threat reality: healthcare was the most targeted critical sector in the EU in 2023 according to the ENISA Threat Landscape 2023 report, and ransomware accounted for approximately 54 percent of all cyber threats against the EU health sector in the same period (ENISA Health Threat Landscape, 2023). The average global cost of a healthcare data breach reached USD 10.93 million in 2023, the highest of any industry sector for the thirteenth consecutive year (IBM Cost of a Data Breach Report, 2023).
EHDS, GDPR and NIS-2: how they interact in sovereign environments
The European Health Data Space Regulation (EHDS, Regulation (EU) 2025/327) introduces a primary-use framework for cross-border patient data access and a secondary-use framework for research and public-interest processing. Both tracks carry direct implications for how clinical record systems are architected and where data is processed.
Under GDPR, processing clinical records in a US-controlled cloud introduces a Chapter V transfer problem if that provider is subject to FISA 702 or CLOUD Act compelled disclosure: a US government order to the provider overrides any data processing agreement, and the patient whose record is disclosed cannot be notified in time to seek judicial redress. Swiss hosting under the revised Federal Act on Data Protection (revFADP), by contrast, places data under Swiss jurisdiction, which does not have an equivalent of the CLOUD Act and whose mutual legal assistance treaties with the US require dual criminality and judicial oversight.
For EHDS secondary use, Member States must designate health data access bodies that grant access through certified secure processing environments (SPEs). A sovereign or on-premises architecture can host an SPE provided it meets the technical interoperability specifications ENISA and the European Health Data Space Authority are developing. Critically, the data does not need to leave the sovereign perimeter: the SPE model is explicitly designed to allow researchers to bring their analysis to the data rather than the data to the researcher. This makes sovereign infrastructure not a barrier to EHDS compliance but a compatible foundation for it, as long as access logging, pseudonymisation and audit trail requirements are implemented.
Cyber Solidarity Act: preparedness testing and isolated environments
The Cyber Solidarity Act (Regulation (EU) 2025/38) establishes a European Cybersecurity Reserve of trusted managed security service providers and creates a cross-border preparedness mechanism through ENISA-piloted sectoral readiness exercises. For health entities designated as significant under NIS-2, the Act introduces coordinated vulnerability disclosure and structured penetration testing obligations at national and EU level.
ENISA is tasked with running tabletop and technical exercises specifically for the health sector, building on its existing European Cyber Security Exercise (EU CyberNet) framework. Hospitals that want to participate meaningfully in these exercises, and those that want to demonstrate readiness to their national authority, need isolated test environments that mirror production systems without exposing live patient data. Sovereign on-premises or air-gapped environments are technically suited for this: a Nextcloud-based document environment or a locally hosted electronic health record can be cloned into a hardened sandbox without the contractual and data-protection barriers that typically prevent such exercises in shared public cloud tenancies.
eIDAS 2.0 and the EU Digital Identity Wallet for healthcare
Regulation (EU) 2024/1183 amending the original eIDAS framework requires that all online services obligated to accept electronic identification must support EU Digital Identity (EUDI) Wallet credentials by the end of 2027. Health information systems that process patient records and provide online access to clinical data fall within scope.
For hospitals running sovereign identity infrastructure, the practical implication is that their identity and access management stack must implement the OpenID for Verifiable Presentations (OpenID4VP) and OpenID for Verifiable Credential Issuance (OpenID4VCI) protocols through which EUDI Wallets present credentials. These are open standards, not proprietary to any single vendor, which means a hospital using an open-source identity provider such as Keycloak can add EUDI Wallet support without migrating to a commercial identity-as-a-service product operated under a foreign jurisdiction. This is a meaningful advantage: updating a self-hosted identity stack is an engineering project; rebuilding identity architecture around a new compliance requirement when the current stack is owned by a US hyperscaler introduces both data-transfer and contractual dependency risks.
Demonstrating foreign-jurisdiction exclusion to a national NIS-2 authority
NIS-2 Article 21(2)(j) requires supply-chain security measures that include policies on the security of suppliers and service providers. When a hospital uses a US-headquartered cloud provider, the supervisory question is not merely whether the provider is contractually prohibited from disclosing data, but whether it is legally capable of resisting a CLOUD Act or FISA 702 order directed at it.
| Architecture | CLOUD Act / FISA 702 exposure | Evidence available to NIS-2 authority |
|---|---|---|
| US hyperscaler (EU data centre) | Full exposure: provider is a US person subject to 18 U.S.C. § 2713 | Data Processing Agreement only; cannot override US law |
| EU-headquartered provider (no US parent or subsidiary) | Reduced but not eliminated if US cloud infrastructure is sub-contracted | Corporate structure analysis, sub-processor list, legal opinion |
| Swiss-hosted, Swiss-incorporated provider | No CLOUD Act nexus; Swiss MLAT requires judicial oversight and dual criminality | Hosting agreement, Swiss incorporation certificate, revFADP compliance statement |
| On-premises sovereign infrastructure | No third-party provider subject to any foreign jurisdiction | Asset inventory, network architecture diagram, access control audit log |
To satisfy a national NIS-2 authority that patient data is not accessible to foreign-jurisdiction requests, a hospital should assemble a dossier that includes: the legal entity structure of all cloud and software vendors in the supply chain, an analysis of each vendor’s jurisdictional exposure under applicable US or non-EU law, contractual flow-down provisions that prohibit sub-processors from using US-incorporated infrastructure without prior written consent, and an architecture diagram showing the data path from clinical workstation to storage without traversing a provider with a US legal nexus. A legal opinion from external counsel, rather than a vendor self-attestation, carries significantly more weight with supervisors.
MDR, IVDR and NIS-2: the connected medical device problem
Hospitals are not only operators of IT systems; they are also operators of networked medical devices regulated under the Medical Devices Regulation (EU) 2017/745 (MDR) and the In Vitro Diagnostic Regulation (EU) 2017/746 (IVDR). MDR Annex I, Chapter I, Section 17 requires manufacturers to design devices with cybersecurity in mind throughout their lifecycle, including secure update mechanisms and access controls. But once a device is deployed in a hospital network, NIS-2 Article 21 supply-chain obligations apply to the hospital as well.
The practical interaction is this: a hospital’s NIS-2 Article 21 vulnerability-handling procedures must explicitly cover connected medical devices, not only IT workstations and servers. This means maintaining a software bill of materials (SBOM) for each networked device, monitoring for manufacturer security advisories under the MDR post-market surveillance framework, and applying patches within the timeframes set by national NIS-2 implementation guidance. Devices that can no longer receive security updates from their manufacturer create a documented residual risk that must be mitigated through compensating controls such as micro-segmentation, and that residual risk must be reported in the hospital’s NIS-2 risk register.
Building a provable compliance architecture
The convergence of COM(2025) 10, EHDS, the Cyber Solidarity Act, eIDAS 2.0 and MDR/IVDR creates a compliance surface that cannot be managed with a single point solution. What it requires is an architecture in which sovereignty, auditability and interoperability are designed in from the start rather than retrofitted through contractual clauses.
Concretely, this means hosting clinical records and communication systems on infrastructure where the hospital, not a vendor, controls encryption keys and access logs; implementing identity management that already supports EUDI Wallet protocols before the 2027 deadline; maintaining isolated test environments that can participate in ENISA preparedness exercises without exposing production data; and documenting the supply-chain security analysis in a format that a national competent authority can review without specialist legal support.
Swiss-hosted environments operated by Swiss-incorporated providers with no US corporate nexus offer a legally cleaner position than EU-region deployments of US hyperscalers, particularly for the CLOUD Act and FISA 702 exclusion evidence requirement. On-premises sovereign infrastructure offers the strongest position for all foreign-jurisdiction exclusion claims, at the cost of greater internal operational responsibility. The right answer depends on a hospital’s size, internal capability and risk tolerance, but the compliance evidence requirements for all regulators converge on one principle: sovereignty must be demonstrable, not merely asserted.
FAQ
Does using a US hyperscaler for clinical data expose a hospital to CLOUD Act requests even if data is stored in an EU data centre?
Yes. The CLOUD Act (18 U.S.C. § 2713) requires US-controlled providers to produce data in response to lawful US government orders regardless of where the data is physically stored. EU data-centre location does not eliminate this exposure; only using a provider with no US legal nexus does.
What is the deadline for hospitals to comply with NIS-2, and what sanctions apply for non-compliance?
NIS-2 (Directive 2022/2555) required transposition by 17 October 2024. Essential entities, including hospitals under Annex I, face maximum administrative fines of at least EUR 10 million or 2 percent of global annual turnover, whichever is higher, plus personal liability for senior management in the event of negligence.
How does the EHDS Regulation affect secondary use of clinical data held in sovereign infrastructure?
The EHDS Regulation requires Member States to designate health data access bodies that grant researchers and public-interest users access to secondary-use data. Sovereign or on-premises environments must implement the EHDS secure processing environment specifications; data does not need to leave the sovereign perimeter, but access logging and interoperability must meet EHDS technical standards set by the European Health Data Space Authority.
What does the eIDAS 2.0 EU Digital Identity Wallet require from health information systems by end of 2027?
Regulation (EU) 2024/1183 requires that all online services mandated to accept electronic identification must accept EUDI Wallet credentials by the deadline. Hospitals must ensure their identity and access management infrastructure supports EUDI Wallet authentication. This is achievable in sovereign setups using open standards such as OpenID4VP and OpenID4VCI implemented in self-hosted identity providers, without migrating to a foreign-jurisdiction identity service.
How do MDR and NIS-2 obligations overlap for a hospital using networked diagnostic devices?
MDR (EU) 2017/745 Annex I, Section 17 requires manufacturers to build cybersecurity into connected devices throughout their lifecycle. Hospitals remain responsible under NIS-2 Article 21 for supply-chain security and must verify that connected devices meet MDR cybersecurity requirements, maintain patch management procedures, hold a current software bill of materials for each device, and segment device networks to limit blast radius in the event of compromise.