NIS2 in hospitals raises a real tension that does not appear in the text of the directive: cybersecurity cannot pause patient care. A hospital cannot disconnect a patient monitoring system to apply a patch, nor can it allow an incident response to leave the emergency department without data. And yet, Directive (EU) 2022/2555 requires the healthcare sector to adopt proportionate, documented and auditable cybersecurity measures.
The question is not whether to comply, it is how to do so in a way that strengthens operations rather than burdening them. Hospitals and healthcare centres that successfully integrate NIS2 into their real operations are those that treat security as just another clinical function: continuous, prioritised by patient risk and with clear ownership. This guide explains how to get there.
Transposition Status in Spain: What You Need to Know Today
Important legal note (May 2026): A pending transposition does not exempt organisations from reputational, contractual or operational risks. INCIBE-CERT, already designated as the reference CSIRT for the private sector, and CCN-CERT for the public sector, agree that the technical measures the directive requires take months to implement and waiting for the official gazette is not a viable strategy.
Why the Healthcare Sector Is Essential under NIS2
Directive (EU) 2022/2555 classifies the healthcare sector in its Annex I as a highly critical sector, carrying the most demanding obligations: active supervision by the competent authority, strict incident notification deadlines and elevated penalties for serious non-compliance. The reasoning is direct: an interruption of hospital systems can have consequences for patient lives, not just data or reputation.
Who Is Covered, and in Which Category
The directive distinguishes between essential entities and important entities, with specific size thresholds as confirmed by INCIBE-CERT:
- Essential entities: large Annex I companies with more than 250 employees and more than €50 million in annual turnover. Subject to proactive supervision and maximum penalties.
- Important entities: medium Annex I companies with more than 50 employees and more than €10 million in annual turnover. Subject to reactive supervision and somewhat lower penalties.
A district hospital of 180 beds may be an important entity, not an essential one, a distinction that has real implications for the supervisory regime and implementation timelines. Do not assume your category without analysing it.
Additionally, the competent authority of each Member State may classify as essential or important any provider whose failure could cause significant consequences for public health and safety, regardless of size. A small centre that is the sole provider of a critical service in its territory cannot assume it automatically falls outside scope.
Entities covered include:
- Public and private hospitals with inpatient care
- Specialist care centres with digital life-support systems
- Diagnostic laboratories connected to electronic health record systems
- Healthcare centre networks with centralised IT infrastructure
- Telemedicine platforms and electronic health records with impact on care continuity
The Hospital’s Specific Risk: When Clinical Data and Patient Lives Share a Network
The technology environment of a modern hospital is nothing like a conventional company. Electronic health record systems, connected medical devices (monitors, infusion pumps, ventilators, diagnostic imaging systems), clinical communication networks, laboratory platforms and administrative systems coexist, often with different vendors, different lifecycle stages and heterogeneous security levels.
This complexity creates three particular risks:
Direct impact on patient care. A ransomware attack that encrypts the HIS (Hospital Information System) does not just block data: it can divert ambulances, cancel scheduled surgeries and force a reversion to manual processes that generate errors. We have seen this in real incidents across Europe in recent years.
Extensive and heterogeneous attack surface. Connected medical devices (IoMT) do not always have the capacity to receive security updates. Many run operating systems without active support because the manufacturer’s certification does not contemplate frequent updates. This creates a permanent exposure surface.
Health data as a high-value target. Medical records are worth more on the black market than financial data. Hospitals are a priority target for malicious actors who combine data exfiltration with service disruption to maximise extortion pressure.
GDPR already imposed obligations on the processing of health data as a special category. NIS2 adds the network and systems security layer. And since March 2025 there is a third relevant framework: the European Health Data Space Regulation (EU) 2025/327 (EHDS), which entered into force on 26 March 2025 with progressive application through 2031. All three frameworks must be managed in a coordinated way, not as separate silos.
What NIS2 Specifically Requires of Hospitals
Article 21 of Directive (EU) 2022/2555 sets out the minimum risk management measures every obligated entity must adopt. Translated to the hospital environment:
Information security policies and risk analysis. The hospital needs a documented framework covering periodic risk analysis specific to the healthcare environment: not just corporate IT infrastructure, but also clinical systems, IoMT devices and third-party access. Connected medical devices must appear in the asset inventory with their risk profile.
Incident management. Detection, classification, containment and recovery procedures adapted to clinical reality. Classifying an incident in the emergency department while critical patients are present is different from doing so in a services company: procedures must reflect this. The breach response plan must be coordinated with care continuity protocols.
Continuity and recovery. Backup and recovery plans for critical clinical systems, with manual operation procedures tested regularly. Having backups is not enough: staff must know how to operate without digital systems for a defined time window.
Supply chain security. Vendors of clinical software, medical equipment maintenance, cloud imaging services and remote device support are documented risk vectors under NIS2. The hospital must assess and manage the risks each one introduces.
Access control and multi-factor authentication (MFA). For privileged access, identity management for own and external staff, and access control to clinical systems with traceability. This includes access by medical equipment maintenance engineers: one of the most frequently exploited vectors.
Staff training. Article 20 of the directive requires the management body to approve measures and receive cybersecurity training. In hospitals, this extends to clinical staff: social engineering targeting nursing or medical staff is the most common entry vector in healthcare environments. Training subsidised through FUNDAE can reduce the cost of this component.
Incident notification. The three-phase regime applies to incidents with significant impact on service delivery. In the healthcare sector, the “significant” threshold is typically reached sooner than in other sectors.
Management Body Liability: Figures That Matter
Article 20 of Directive (EU) 2022/2555 establishes direct management body liability. The Spanish draft law provides for:
- Fines of up to €500,000 for personal liability of directors in cases of serious non-compliance.
- Temporary disqualification from holding office.
For a hospital management committee or board of directors, this means that delegating all cybersecurity to the IT manager without effective executive involvement is no longer sufficient from a regulatory standpoint. The governing body must be able to explain what decisions it made, with what information and when it reviewed them.
Incident Management and Notification: Deadlines That Cannot Be Improvised
| Phase | Deadline | Minimum content |
|---|---|---|
| Early warning | 24 hours | Whether malicious origin is suspected and cross-border impact is possible |
| Incident notification | 72 hours | Initial impact assessment, available indicators of compromise, measures adopted |
| Final report | 1 month | Detailed description, root cause analysis, actual impact and lessons learned |
Source: INCIBE-CERT. NIS2: What You Need to Know
Deadlines run from when the entity becomes aware of the incident, not from when it has been fully analysed. In the healthcare sector, if the incident also involves a health data breach, both NIS2 deadlines and GDPR notification obligations apply simultaneously. The response must be coordinated from the very first moment.
How to Build the NIS2 Programme Without Stopping Patient Care
The usual trap is treating NIS2 compliance as a parallel IT project running alongside clinical operations. That approach produces documentation nobody on the ward recognises and measures that do not survive the first night shift. The approach that works is different:
Integrate cybersecurity into existing clinical processes. Protocols for dealing with digital system failures already exist in most hospitals. The starting point is expanding those protocols to include the cybersecurity dimension, not creating a parallel universe of procedures.
Prioritise by patient risk, not by technological maturity. The first question is not “which system has the most technical vulnerabilities?” but “which system failure could put a patient’s life at risk in the next two hours?”. NIS2 risk analysis in hospitals must follow that logic: care continuity first.
Implementation phases compatible with operations. Technical changes to critical clinical systems must be planned with the same rigour as scheduled maintenance: windows outside peak activity periods, rollback plans and coordination with affected clinical services.
Owners with real authority. In hospitals, the CISO or IT security manager rarely has direct authority over clinical systems. The NIS2 governance structure needs an interdisciplinary committee with representation from medical management, nursing, IT and legal. Without that structure, security decisions get blocked at departmental boundaries.
Continuous and realistic training for clinical staff. Not generic password courses: specific training on attacks targeting the healthcare sector, with social engineering examples adapted to the clinical context.
Connected Medical Devices (IoMT): The Usual Blind Spot
Connected medical devices are the biggest technical challenge of NIS2 in hospitals. Rules that work in corporate IT environments, immediate patching, replacing unsupported equipment, continuous updates, do not apply equally to a ICU monitor or a diagnostic imaging system.
The problem: many medical devices run manufacturer-certified software that cannot be modified without losing certification or warranty. Some run operating systems without active support. The manufacturer may take months to publish a security update. And disconnecting equipment for maintenance requires clinical coordination that is not always possible.
The NIS2-compatible response: the directive does not require patching what cannot be patched, it requires documenting the decision and the compensating controls. For IoMT devices with known unresolvable vulnerabilities, the correct approach combines:
- Network segmentation that isolates the device from known attack paths.
- Anomalous traffic monitoring to and from the device.
- Accepted residual risk register with an owner, a review date and documented compensating controls.
- Planned replacement process when the device reaches end of useful life.
The IEC 62443 framework, developed by the International Electrotechnical Commission for cybersecurity in industrial automation and control systems, provides specific controls for clinical automation environments that ISO/IEC 27001 does not detail for this context.
Vendors and Supply Chain: The Risk That Comes from Outside
Hospitals concentrate many vendors with access to critical systems: HIS integrators, medical equipment maintenance companies, outsourced diagnostic laboratories, radiology and imaging companies, telemedicine providers and cloud health record services.
NIS2 requires the hospital to assess and manage the risk each vendor introduces. Minimum process:
- Classify vendors by criticality: does it have access to systems that affect care continuity? Can it access health data? Does it have permanent remote access?
- Review access conditions: remote maintenance access must be documented, time-limited, logged and protected with MFA.
- Include security clauses in contracts: audit rights, obligation to notify incidents affecting the hospital, minimum vendor security requirements.
- Review periodically: annual review of critical vendors must be documented.
GDPR, NIS2 and EHDS in the Hospital: Three Frameworks That Must Talk to Each Other
The healthcare sector faces a triple regulatory obligation that must be managed in a coordinated way:
GDPR: protection of health data as a special category (Article 9). Data Protection Impact Assessments (DPIAs) for high-risk processing. Breach notification to the supervisory authority within 72 hours.
NIS2: network and systems security. Proportionate and documented risk management. Notification of incidents with significant service impact within 24h/72h/1 month.
EHDS, Regulation (EU) 2025/327: framework for the secure exchange of electronic health data across the EU. In force since 26 March 2025 with progressive application: general obligations from March 2027, further specific obligations from 2029 and 2031. Imposes interoperability and security requirements on electronic health record (EHR) systems and healthcare technology providers.
The most relevant overlap points between NIS2 and GDPR:
- Risk analysis: both the DPIA (GDPR) and the NIS2 risk analysis require documented assessments. Integrating them avoids duplicating effort and produces stronger evidence.
- Breach notification: an incident affecting clinical systems may simultaneously trigger the NIS2 obligation (service impact) and the GDPR obligation (health data breach). The response must be coordinated from the first minute.
- Vendor management: data processors under GDPR and critical vendors under NIS2 frequently overlap. Contracts must cover both dimensions.
Useful Certifications for Hospitals under NIS2
ISO/IEC 27001 provides the baseline ISMS: risk analysis, documented controls, continuous improvement cycle and structured incident management. For a hospital that needs to demonstrate NIS2 compliance, it is the most recognised certification before European supervisors.
ISO/IEC 27701 extends the ISMS with the Privacy Information Management System (PIMS), especially relevant for hospitals given the volume of health data they process and the need to align NIS2 with GDPR and EHDS within a single programme.
ENS (National Security Framework) applies when the hospital has a contractual relationship with public administrations, which is the case for most SNS hospitals and many publicly funded private ones. The CCN has developed the PCE-NIS2 Compliance Profile (Guide CCN-STIC 892) that aligns ENS with NIS2 requirements for the healthcare sector.
IEC 62443 provides specific controls for industrial automation and control systems that ISO 27001 does not detail for clinical automation and IoMT environments. Combining both frameworks is the most robust structure for hospitals with mixed infrastructure.
What Can Go Wrong: Penalties and Real Risks
Financial penalties:
- Essential entities: up to €10 million or 2% of global annual turnover, whichever is higher.
- Important entities: up to €7 million or 1.4% of global annual turnover.
- Personal liability of directors: up to €500,000 and temporary disqualification from office (Spanish draft law).
Beyond the fine:
- Temporary suspension of authorisation to operate regulated services.
- Reputational exposure before patients, insurers and funders.
- Real operational risk: centres that have not actively managed their cybersecurity risks are more vulnerable to attacks whose impact can be directly harmful to patients.
What Privalex Offers in NIS2 Projects for Hospitals
Privalex supports hospitals and healthcare entities in designing and implementing NIS2 programmes that are operational from day one, not just documentarily correct. Our approach integrates ISO/IEC 27001, ISO/IEC 27701, ENS and the specific requirements of the clinical environment, including IoMT devices, vendor access and coordination with care processes.
We work with the legal team, the DPO, the IT security manager and medical management to create a programme the organisation can sustain internally, not one that requires permanent consultancy to remain operational.
If you want to start with a no-cost NIS2 gap assessment adapted to the healthcare environment, access the free risk evaluation. To align scope and priorities with management, book a strategic session.
Frequently Asked Questions
Not necessarily. Hospitals in Annex I of Directive NIS2 are essential entities if they exceed 250 employees and €50 million in annual turnover. Those exceeding 50 employees and €10 million but not reaching those thresholds are important entities, subject to a different supervisory regime and penalty scale. Additionally, the competent authority may classify as essential or important any centre whose disruption would cause significant consequences for public health, regardless of size. Refer to the INCIBE-CERT guide on NIS2 in healthcare.
Directive NIS2 does not require patching what cannot be patched for certification reasons: it requires documenting the decision and compensating controls. For IoMT devices with known unresolvable vulnerabilities, the correct approach combines: network segmentation that isolates the device from known attack paths, anomalous traffic monitoring, an accepted residual risk register with an owner and a review date, and a planned replacement process when the device reaches end of useful life. The IEC 62443 framework provides specific controls for these types of environments.
When the incident has a significant impact on the delivery of healthcare services. The early warning is sent within 24 hours to INCIBE-CERT (private sector) or CCN-CERT (public sector), the formal notification within 72 hours and the final report within one month. Deadlines run from when the entity becomes aware of the incident, not from when it has been fully analysed. In the healthcare sector, the “significant” threshold is typically reached sooner than in other sectors because the impact can directly affect patient care. If the incident also involves a health data breach, GDPR notification obligations apply simultaneously.
All three frameworks overlap in hospitals. The most efficient approach integrates risk assessments (DPIA under GDPR and NIS2 risk analysis) into a single process coordinated between the DPO and the IT security manager. Vendor contracts must simultaneously cover data processor obligations (GDPR), critical vendor requirements (NIS2) and the future interoperability obligations of the EHDS, Regulation (EU) 2025/327, whose general obligations will apply from March 2027. An incident affecting clinical systems may trigger all three notification obligations simultaneously: the response must be coordinated from the very first minute.
ISO/IEC 27001 covers approximately 65–70% of the way to NIS2: risk management, documented controls and incident management. Typical gaps are the 24h/72h notification, formal supply chain management and specific board-level training. In the healthcare environment it should be complemented with ISO/IEC 27701 for the privacy and EHDS dimension, with ENS where the hospital has a relationship with public administrations, and with IEC 62443 for IoMT devices and clinical automation environments.
Essential entities can face fines of up to €10 million or 2% of global annual turnover, whichever is higher. Important entities can face up to €7 million or 1.4%. The Spanish draft law also provides for personal liability of directors with fines of up to €500,000 and temporary disqualification from office. For hospitals, the most immediate risk is not the fine but the operational exposure: centres that have not actively managed their cybersecurity risks are more vulnerable to attacks whose impact can be directly harmful to patients.