NIS2 Healthcare Compliance: What Hospitals, Clinics, and Medical Device Manufacturers Must Implement Under Article 21 to Avoid a €10M Fine

In May 2021, the Conti ransomware group spent eight weeks inside Ireland's Health Service Executive before activating their payload. When they did, 80% of the HSE's IT systems were encrypted across 40+ hospitals. Radiology went dark. CT scans stopped. Outpatient appointments were cancelled nationwide. Recovery took four months and cost over €100 million [8].

Under NIS2, the same scenario today would carry additional consequences. The hospital's management board — not just its IT team — would face personal liability for failing to implement the cybersecurity risk-management measures required by Article 21 [4]. The incident reporting clock would start ticking within 24 hours of the board becoming aware of the attack [11]. And competent authorities would actively supervise whether the security programme approved by management matched what the directive required [2].

NIS2 Directive (EU) 2022/2555 entered force on 16 January 2023, with a Member State transposition deadline of 17 October 2024. The European Commission published its first-ever sector-specific cybersecurity initiative — the EU Action Plan for the Cybersecurity of Hospitals and Healthcare Providers — on 15 January 2025, signalling that health is a priority enforcement area [7].

This guide covers three distinct compliance tracks: hospitals and healthcare providers, pharmaceutical and research entities, and medical device manufacturers. It maps what Article 21 actually requires in a clinical environment, identifies where NIS2 intersects with GDPR and the EU Medical Device Regulation, and provides a 90-day action plan calibrated to healthcare operations.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Who Must Comply: Understanding NIS2 Scope in the Health Sector

The health sector sits in Annex I of the NIS2 Directive — the high-criticality tier — which means the full weight of the directive applies. But “health sector” covers very different organisations with meaningfully different compliance tracks, and the scope question is not the same for a regional hospital as it is for a medical device manufacturer.

The five entity types in Annex I, Sector 5:

Annex I, Sector 5 covers five categories of health-related entities [9]:

1. Healthcare providers — hospitals, clinics, and any entity providing healthcare as defined in Directive 2011/24/EU Article 3(g)
2. EU reference laboratories — bodies designated under Regulation (EU) 2022/2371
3. Pharmaceutical research and development entities — organisations carrying out R&D on medicinal products under Directive 2001/83/EC. See also: research sector compliance obligations
4. Pharmaceutical manufacturers — entities producing basic pharmaceutical products and preparations (NACE C21)
5. Medical device manufacturers critical during a public health emergency — entities whose devices appear on the Union list established under Commission Implementing Regulation (EU) 2022/1107, referenced in Regulation (EU) 2022/123 Article 22

Where regular medical device manufacturers sit:

Here is a distinction most compliance resources miss. The Annex I scope for medical devices is narrow — it covers only manufacturers whose devices are formally designated as critical during a declared public health emergency. That list is activated when an emergency is officially recognised and is currently limited in scope [10].

Regular medical device manufacturers — companies whose products are regulated under EU MDR 2017/745 or IVDR 2017/746 but are not on the critical emergency list — fall under Annex II (Manufacturing sector), classifying them as important entities, not essential [10]. The practical difference: essential entities face proactive, ex-ante supervisory inspection; important entities face ex-post supervision triggered by complaints or incidents. For a broader look at how manufacturing entities sit under NIS2, see manufacturing compliance requirements.

The size thresholds:

Entity type	Annex	Classification	Employees	Turnover
Hospital (Annex I)	I	Essential	250+	€50M+
Hospital (Annex I)	I	Important	50–249	€10M–50M
Regular MDM	II	Important	50+	€10M+
Small clinic / micro-enterprise	Either	Exempt	<50	<€10M

Note on small clinics: the exemption applies to standalone entities meeting micro-enterprise thresholds. A clinic that is part of a larger healthcare group may have its thresholds calculated at group level — parent company employees and turnover count [3]. For a detailed scope determination tool, the NIS2 scope checker covers all sectors and entity types.

Member States were required to publish their lists of essential and important entities by 17 April 2025. Entities that have not verified their classification should treat this as Day 1 of their compliance programme.

What Article 21 Requires from Healthcare Entities

Article 21(1) sets the standard: measures must be “appropriate and proportionate” to the risk posed — technically, operationally, and organisationally. The directive uses an all-hazards approach, meaning cybersecurity measures must address every plausible threat [1].

Article 21(2) specifies ten mandatory categories. For healthcare entities, each one maps to a distinct operational challenge:

(a) Risk analysis and information system security policies

In a hospital, the information security policy must cover clinical systems — Hospital Information Systems (HIS), Electronic Health Records (EHR), Picture Archiving and Communication Systems (PACS), and radiology information systems — not just administrative IT. Patient safety and operational continuity are both at stake: a risk register that omits PACS downtime scenarios misses the primary consequence of a cyberattack in a radiological setting.

(b) Incident handling

The incident response procedure must be documented, tested, and linked directly to the Article 23 notification timeline. Healthcare entities face a specific complication: clinical staff rarely recognise IT anomalies as cybersecurity incidents. The incident handling procedure must include a trigger checklist that nurses and clinicians can use — not just the IT team.

(c) Business continuity, backup, and crisis management

Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for clinical systems must reflect patient-safety timelines, not standard enterprise IT norms. A 72-hour RTO for an EHR is acceptable for a logistics company; in an emergency department, it is not. Backup policies must be tested: in the HSE attack, 80% of systems were encrypted [8] — an organisation with untested offline backups would have extended that four-month recovery significantly.

(d) Supply chain security

Healthcare entities typically operate a complex supplier ecosystem: EHR vendors, medical device manufacturers with network-connected equipment, cloud diagnostics platforms, and third-party laboratory information systems. Article 21(2)(d) requires documented security assessment of each direct supplier, taking into account their specific vulnerabilities. For healthcare, the highest-risk suppliers are those with direct access to clinical networks — including device vendors who connect remotely for maintenance. See also: cloud service supply chain security requirements.

(e) Security in acquisition, development, and maintenance of systems

This provision directly affects medical device procurement. Any networked device connected to hospital infrastructure is a “system” in NIS2 scope. Procurement specifications must include minimum security requirements: the duration of software update support, whether the device can receive patches without physical access, and whether the vendor has a documented vulnerability disclosure process.

(f) Effectiveness assessment policies and procedures

NIS2 requires entities to assess whether their security measures actually work. For healthcare, this means regular internal audits, penetration tests of clinical network segments, and documented results — not just a policy document approved and filed.

(g) Cyber hygiene practices and cybersecurity training

Medical and clinical staff are primary social engineering targets. According to ENISA's 2023 health sector threat analysis, only 27% of surveyed health organisations maintained dedicated ransomware defence programmes [5] — training is consistently the weakest link. Role-specific, recurring training for clinical staff is the minimum requirement.

(h) Cryptography and encryption policies

Patient data in transit — between HIS, PACS, and clinical workstations — and at rest must be encrypted under a documented policy. This is an area where GDPR Article 32 and NIS2 Article 21 directly overlap. See Section 4 for the full mapping.

(i) Human resources security, access control, and asset management

Role-based access control for clinical staff is required. Visitor access — including device vendor engineers connecting remotely — must be documented, time-scoped, and revoked immediately after the maintenance window closes. Contractor off-boarding is a common gap in healthcare environments where IT teams are small and vendor relationships are long-standing.

(j) Multi-factor authentication (MFA) or continuous authentication

MFA is mandatory under Article 21(2)(j). Healthcare faces a specific challenge: requiring MFA at a bedside terminal during a cardiac emergency creates a patient-safety risk. The solution is not to exempt clinical systems from MFA but to implement risk-based continuous authentication that reduces friction at the point of care while maintaining security — with documented emergency exception procedures approved at clinical director level [1].

The Medical Device Problem: When Your Equipment Cannot Be Patched

Healthcare entities face a compliance dimension that most other NIS2 sectors do not: a significant portion of their most critical “information systems” are clinical devices running software that was never designed for regular security updates.

Radiology imaging equipment, patient monitoring systems, and infusion pumps often run on end-of-life operating systems. A CT scanner purchased in 2016 may have been certified against Windows 7 — changing the operating system invalidates the device certification under EU MDR and IVDR. The manufacturer may provide security updates only on a fixed release cycle that lags behind discovered vulnerabilities by months.

This creates a direct tension with Article 21(2)(e), which requires security in the maintenance of network and information systems, and Article 21(2)(d), which requires supply chain security assessment of direct suppliers [1]. But NIS2's “appropriate and proportionate” standard accommodates the reality that legacy clinical devices cannot be patched on standard enterprise timelines. “We cannot patch it” is not an acceptable end-point — it is the start of a compensatory control analysis.

Network segmentation: Clinical devices should sit in isolated network segments with strict ingress and egress rules. A PACS server should not have unrestricted access to the wider hospital network. Older DICOM protocol implementations are particularly vulnerable — isolating PACS from general hospital IT is a minimum requirement, not a best practice.

Virtual patching: Next-generation firewalls can enforce application-layer controls that compensate for known vulnerabilities in segmented clinical networks. This does not replace patching but reduces exploitability while waiting for certified device updates.

Vendor access governance: Remote maintenance connections from medical device manufacturers — Tier-1 suppliers under Art. 21(2)(d) — must be time-scoped, monitored, and revoked. A persistent remote-access credential held by a device vendor is one of the highest-risk exposure points in a hospital network. The risk is not hypothetical: eight weeks elapsed between the attackers' initial access and the activation of ransomware in the HSE attack [8], and remote access credentials are a documented lateral movement vector in healthcare incidents.

Documentation for audit: The risk acceptance decision for an unpatched clinical device must be formally documented: the compensatory controls in place, the residual risk level, and the timeline for remediation. An undocumented compensatory control is invisible to auditors and provides no legal defence under Article 21(4)'s requirement to take corrective measures without undue delay [1].

For medical device manufacturers' own NIS2 obligations: If your organisation manufactures network-connected medical devices, NIS2 Article 21(2)(e) applies to your development and maintenance practices as well. Regular MDMs sit in Annex II as important entities [10]. Being MDR-compliant under EU MDR 2017/745 does not automatically satisfy NIS2 — the two regimes operate independently, as explained in the next section.

The Dual-Framework Burden: NIS2, GDPR, and the EU MDR

Healthcare entities already operate under GDPR, and many assume the overlap between GDPR Article 32 and NIS2 Article 21 gives them a significant head start. It does — but the overlap is smaller than it appears, and the additive obligations are where compliance gaps most often sit.

Where GDPR and NIS2 converge:

GDPR Article 32	NIS2 Article 21(2)	Overlap
Pseudonymisation and encryption	(h) Cryptography and encryption	Strong — same technical controls
Confidentiality, integrity, availability	(a) Risk analysis + (i) Access control	Partial — NIS2 scope includes operational systems, not just data
Ability to restore systems in a timely manner	(c) Business continuity	Partial — NIS2 requires documented BCP, not just restore capability

What NIS2 adds beyond GDPR:

The following Article 21(2) requirements have no direct GDPR equivalent and represent the true additive compliance burden:

• (b) Incident handling — GDPR has breach notification requirements but not a full incident handling procedure mandate
• (d) Supply chain security — GDPR processor agreements cover data; NIS2 requires assessment of the supplier's broader ICT security posture
• (e) Security in system acquisition and maintenance — GDPR does not address procurement security specifications
• (f) Effectiveness assessment — GDPR Data Protection Impact Assessments are not the same as ongoing security effectiveness reviews
• (j) MFA — GDPR does not mandate MFA; NIS2 Article 21(2)(j) does [1]

Reporting to different authorities:

A security incident that involves personal patient data triggers two parallel notification obligations: GDPR Article 33 to the Data Protection Authority (within 72 hours of becoming aware of the breach), and NIS2 Article 23 to the national competent authority or CSIRT (early warning within 24 hours, full notification within 72 hours). These are separate filings to separate authorities and cannot be combined [11].

For medical device manufacturers — the EU MDR dimension:

EU MDR 2017/745 includes cybersecurity requirements for software medical devices under Annex I, Section 17. These apply to the device itself; NIS2 applies to the manufacturer's organisational cybersecurity posture. Both frameworks apply independently. As the Johner Institute notes, organisations face a dual compliance obligation with no automatic credit transfer between the two regimes [10].

The Article 23 Clock: Healthcare Incident Reporting Under NIS2

Article 23 establishes a three-stage reporting cascade, and the clock starts at the moment of becoming aware — not at the moment of root cause confirmation [11]. The HSE Ireland timeline, mapped to what Article 23 would require today, illustrates why this matters [8]:

At 4am on 14 May 2021, the HSE received alerts that systems were compromised. That moment — not the subsequent investigation, not the financial damage calculation — is when the Article 23 clock starts:

• Within 24 hours of 4am: Early warning to national CSIRT or NCA. Required content: whether the incident is suspected to be malicious (yes), and whether it has potential cross-border impact (yes — HSE serves the entire Irish state) [11].
• Radiology systems down by morning: The “severe operational disruption” threshold under Article 23(3) is met within hours, not days. Waiting to report until financial impact is quantified is not permitted [11].
• Within 72 hours: Full incident notification. Requires initial severity and impact assessment plus indicators of compromise — even while the incident is still active [11].
• One month after the notification: Final report. Includes root cause analysis, threat actor profile, mitigation measures taken, and cross-border impact summary [11].

The eight-week dwell time before attack activation in the HSE incident would not itself trigger Article 23 reporting — the significant incident is the event that causes or is capable of causing severe operational disruption [11]. But it directly reinforces the Article 21(2)(b) obligation: a functioning security monitoring capability detecting the Cobalt Strike indicators during those eight weeks was the preventive control that failed.

The incoming ransomware payment reporting proposal:

The European Commission's January 2025 Action Plan proposes that entities reporting incidents under NIS2 — including healthcare providers — should also report any ransom payments made [7]. This is not yet a binding obligation, but healthcare organisations building their incident response procedures now should include a ransom payment documentation step in their workflow. ENISA's data shows ransomware accounts for 54% of health sector cyber threats [5] — this proposal is aimed directly at the healthcare context.

Who Owns What: A Healthcare Compliance Role Matrix

NIS2 Article 20 places compliance ownership explicitly at management body level — not with the IT department [4]. In a healthcare context, this creates governance questions that do not arise in other sectors, particularly around clinical emergency access and the role of clinical directors in security decisions.

Role	NIS2 obligation	Healthcare-specific dimension
Board / Management body	Approve the risk treatment plan and security measures; attend regular cybersecurity training [4]	Must formally approve clinical system security decisions, including documented risk acceptance for unpatched devices
CISO / IT Security Manager	Technical implementation of Art. 21(2) controls; incident detection; Art. 23 reporting chain	Responsible for clinical network segmentation, vendor access governance, IoMT asset register
Compliance / Legal Officer	NCA registration; Art. 23 notification filing; documentation for audit	Must maintain parallel GDPR–DPA and NIS2–NCA notification chains; these cannot be merged
CMO / Clinical Directors	Input into BCP clinical priority triage; access control exception governance	Clinical emergency MFA override must be defined at this level, approved by the management body, with mandatory audit logging for all override sessions
HR	Art. 21(2)(g) training programme; Art. 21(2)(i) onboarding/offboarding controls	Contractor off-boarding for device vendor engineers must be immediate — persistent credentials are a documented attack vector in healthcare incidents

The clinical emergency override question deserves specific attention. MFA requirements under Article 21(2)(j) are not waivable by IT alone. Clinical directors can document a pre-approved exception procedure for emergency scenarios, with mandatory audit logging for all sessions using the exception path. That decision must be made at CMO level and formally approved by the management body — not resolved informally between the CISO and ward staff.

Penalties and Enforcement: Why Management Bodies Are Personally Exposed

The headline penalty figures are well-established: essential entities face fines up to €10 million or 2% of global annual turnover under Article 34(4), whichever is higher. Important entities face fines up to €7 million or 1.4% of global annual turnover under Article 34(5) [2]. Both apply to violations of Articles 21 or 23.

What is less commonly understood is the Article 20 personal liability mechanism. NIS2 requires management bodies — not just the organisation — to approve cybersecurity risk-management measures and be accountable for their implementation [4]. Member States may hold management body members personally responsible for failures attributable to their decisions or omissions. This is distinct from the organisational fine and can run in parallel with it.

For healthcare management boards, this means the cybersecurity risk treatment plan is not a document the CISO produces and files. It is a document the board formally reviews, approves, and signs — because that approval record is the evidence that the board exercised its Article 20 governance obligation. The same applies to training: Article 20 requires management body members themselves to attend regular cybersecurity training. A board-level briefing delivered by the CISO once per year — documented, timestamped, and signed — satisfies this requirement. A verbal update in a board meeting does not.

State of enforcement (2025–2026):

Enforcement timelines vary by Member State. Countries that transposed NIS2 early are already supervising essential entities. National competent authorities for health sector entities are typically the relevant health ministry or a designated national cybersecurity authority — check your national NCA list to confirm the reporting authority for your jurisdiction. Essential entities are subject to proactive supervisory inspection; important entities are supervised reactively, following a complaint or incident.

Your First 90 Days: A Healthcare NIS2 Compliance Roadmap

Days 1–30: Scope determination and gap analysis

• Confirm entity classification using the thresholds in Section 1. If borderline, check whether your Member State NCA has published its entity list — registration may already be mandatory.
• Complete an asset inventory covering all network-connected clinical systems: HIS, EHR, PACS, RIS, networked diagnostic devices, and any Building Management Systems with IT connectivity.
• Map your existing supplier list to Article 21(2)(d): identify which suppliers have direct access to your clinical network, and flag those without a current security assessment on file.
• Run a gap analysis against the ten Article 21(2) measures. Prioritise measures (b) incident handling and (c) business continuity — these are the most operationally testable controls and the ones regulators ask about first.

Days 31–60: Priority controls implementation

• Formalise and test the incident response procedure, including the Article 23 notification chain. Assign a named individual responsible for the 24-hour early warning filing — this cannot be resolved by committee in the middle of an active incident.
• Deploy or expand MFA for clinical staff access to EHR and other critical systems. Document the clinical emergency exception procedure and obtain management body sign-off.
• Implement network segmentation for the highest-risk clinical systems — PACS and imaging equipment in particular.
• Document compensatory controls for all unpatched clinical devices, with formal risk acceptance signed by the management body.

Days 61–90: Governance readiness

• Arrange Article 20 management training. This is a board-level obligation — a CISO-only briefing does not satisfy it.
• Conduct an Article 23 tabletop exercise: simulate a ransomware scenario and walk through the 24-hour, 72-hour, and 1-month reporting cascade with the actual individuals responsible for each filing.
• Submit formal registration with your national NCA if required in your jurisdiction.
• Present the approved risk treatment plan to the management body for formal sign-off. Retain the signed record — this is the primary evidence of Article 20 compliance.

Frequently Asked Questions

Does NIS2 apply to private hospitals?

Yes. NIS2 does not distinguish between public and private healthcare providers. A private hospital that meets or exceeds the size thresholds — 50 employees or €10 million turnover for the important entity tier — is in scope. Ownership form is irrelevant; what matters is that the entity provides healthcare services as defined in Directive 2011/24/EU [9].

Are small clinics with fewer than 50 employees in scope?

Typically not, provided the clinic is a standalone entity below micro-enterprise thresholds. However, if the clinic is part of a larger healthcare group, the group's combined employee count and turnover may apply. Check with your national NCA and legal counsel if you operate within a network [3].

Do medical device manufacturers need to comply with both NIS2 and the EU MDR?

Yes — as independent obligations. EU MDR 2017/745 regulates the device's technical and cybersecurity specifications; NIS2 regulates the manufacturer's organisational cybersecurity posture. MDR compliance does not substitute for NIS2 compliance, and vice versa [10].

When does the Article 23 reporting clock start?

At the moment the entity “becomes aware” of a significant incident — not when root cause is confirmed, and not when financial impact is quantified. A monitoring alert indicating active ransomware or confirmed system encryption is an awareness event. The 24-hour early warning clock starts there [11].

What if we are subject to GDPR, NIS2, and the EU MDR simultaneously?

All three apply independently. A data breach affecting patient records triggers GDPR notification to the Data Protection Authority (72 hours from awareness of the personal data breach) and NIS2 notification to the NCA or CSIRT (24-hour early warning). These are separate filings to different authorities. The intersection reduces duplicated work on technical controls — encryption, access control, risk assessment — but does not reduce the number of distinct filing obligations.

Sources

1. NIS2 Directive (EU) 2022/2555, Article 21: Cybersecurity Risk-Management Measures
2. NIS2 Directive (EU) 2022/2555, Article 34: Administrative Fines
3. NIS2 Directive (EU) 2022/2555, Article 3: Essential and Important Entities
4. NIS2 Directive (EU) 2022/2555, Article 20: Governance
5. ENISA: Checking-up on Health — Ransomware Accounts for 54% of Cybersecurity Threats (July 2023)
6. ENISA: Health Sector Cybersecurity
7. European Commission: Action Plan on Cybersecurity for Hospitals and Healthcare Providers (January 2025)
8. Health Service Executive Ransomware Attack — Wikipedia (citing multiple verified sources)
9. SPAC Alliance: NIS2 Sectors and Entity Types
10. Johner Institute: NIS-2 and Medical Device Manufacturers
11. NIS2 Directive (EU) 2022/2555, Article 23: Reporting Obligations