NIS2 Healthcare Checklist: IoMT Inventory, MDR Overlap, and Patient Data Controls Under Article 21(2)

Does NIS2 Apply to Your Healthcare Organisation?

The answer depends on which side of the sector table you fall on. NIS2 Directive 2022/2555 distinguishes between essential entities — subject to proactive ex-ante supervision and the highest penalty tier — and important entities, subject to ex-post supervision triggered by incidents or complaints. Healthcare occupies both categories depending on the type of organisation.

Annex I of the directive lists healthcare providers — hospitals and clinics, both public and private — as essential entities. The same tier covers EU reference laboratories, manufacturers of basic pharmaceutical products, and medical device manufacturers designated as critical during a public health emergency. General manufacturers of medical devices and in vitro diagnostic (IVD) devices fall under Annex II as important entities, unless a Member State reclassifies them based on operational risk. The size threshold for either category is a medium or large enterprise: more than 50 employees, or annual turnover and balance sheet total exceeding €10 million.

Entity Type	NIS2 Annex	Tier	Maximum Penalty
Hospitals and healthcare providers	Annex I, Sector 5	Essential	€10M or 2% of global turnover
EU reference laboratories	Annex I, Sector 5	Essential	€10M or 2%
Basic pharmaceutical manufacturers	Annex I, Sector 5	Essential	€10M or 2%
Medical device manufacturers critical during public health emergency	Annex I, Sector 5	Essential	€10M or 2%
General medical device / IVD manufacturers	Annex II	Important	€7M or 1.4% of global turnover

If your organisation is both a healthcare provider and manufactures or configures devices in-house, you are an essential entity and must apply the more stringent requirements across all operations. NIS2 applies to the organisation, not to individual product lines. Member States were required to finalise their entity lists by 17 April 2025, after which a 12-month window opens for demonstrating full compliance. The essential vs important entity guide covers classification in more detail.

The IoMT Device Inventory Checklist

Article 21(2)(i) of NIS2 requires human resources security, access control, and asset management as one of the ten mandatory cybersecurity measures. For hospitals, asset management means more than cataloguing servers and laptops — it means classifying every device that processes patient data or connects to clinical networks, including equipment that predates modern security tooling.

The Commission Implementing Regulation (CIR) 2024/2690 provides the authoritative benchmark for what proportionate asset management looks like. Its Annex, Point 12, requires a classification policy, a complete inventory of network and information systems and supporting assets, handling rules per classification tier, and policies covering removable media and secure disposal. Applied to a hospital network, this means three device tiers:

Tier A — Clinical systems with direct patient data processing. Hospital Information Systems (HIS), Radiology Information Systems (RIS), Picture Archiving and Communication Systems (PACS), and electronic patient records. Highest risk classification. Strictest access controls and encryption requirements.

Tier B — Connected medical devices. Infusion pumps, patient monitors, imaging equipment, ventilators, and similar IoMT devices. Often run on proprietary or legacy operating systems that cannot accept standard security patches without manufacturer re-certification. Compensatory controls are required when patching is not feasible.

Tier C — Clinical support infrastructure. HVAC systems, building access control, pharmacy dispensing automation. Lower direct patient-data risk but network-connected, creating lateral movement paths to Tier A and B systems.

For each device in all three tiers, document the following eight fields:

1. Device identity: manufacturer, model number, serial number, and asset tag
2. Network connectivity: IP address, VLAN assignment, and wireless status
3. Software baseline: operating system, firmware version, and last patch date
4. Regulatory certification: MDR status and CE mark reference for devices placed on the market after May 2021
5. Support commitment: manufacturer end-of-support date (procurement contracts should specify support for the device’s operational lifetime plus five additional years)
6. Patch status: patchable / requires compensatory controls / end-of-life unpatched
7. Data classification: patient-identifiable, pseudonymised, or administrative only
8. Risk tier and controls: assigned tier (A, B, or C), active compensatory controls, and responsible owner

For Tier B devices that cannot receive security updates without manufacturer re-certification, the practical control is network isolation: a dedicated VLAN with no direct communication to Tier A systems, and network anomaly detection (NDR) monitoring the segment continuously. New procurement contracts should make cybersecurity support commitments a contractual requirement, not a vendor option. The NIS2 asset management guide covers the underlying documentation framework for the full inventory lifecycle.

MDR × NIS2 Dual Compliance: Six Overlapping Obligations

Medical device manufacturers face a compliance geometry that healthcare providers do not: the EU Medical Devices Regulation (MDR) 2017/745 governs product cybersecurity, while NIS2 governs organisational cybersecurity. The two regimes are cumulative, not alternative — NIS2 applies to the manufacturer as an entity regardless of what MDR requirements apply to the device. A single incident can trigger obligations under both simultaneously.

Six obligation domains overlap between the two frameworks. Understanding where they align — and where they diverge — prevents building two parallel compliance programmes when one unified control register will satisfy both.

Obligation Domain	NIS2 Reference	MDR Reference	Key Difference
Risk management	Article 21(2)(a) — risk analysis policies	Annex I, Section 3 — general safety and performance	NIS2 uses ISO 27001 risk framework; MDR uses ISO 14971 safety risk methodology. Maintain separate but cross-referenced risk registers.
Incident reporting	Article 23 — 24h early warning, 72h full report, 1-month final	Article 87 — serious incident reporting to national competent authority	Different triggers: NIS2 activates on cybersecurity incidents affecting availability/integrity/confidentiality; MDR activates on serious incidents involving patient harm or risk thereof. A ransomware attack affecting device availability may trigger both.
Supply chain security	Article 21(2)(d) — supplier and service provider security	Article 10(9) — obligations for authorised representatives and importers	NIS2 requires documented risk assessment of each direct supplier; MDR requires traceability of the economic operator chain.
Vulnerability management	Article 21(2)(e) — vulnerability handling and disclosure	Annex I, Section 17.2 — software cybersecurity lifecycle	MDR Section 17.2 requires that devices placed on the market after May 2021 include a software cybersecurity lifecycle plan. NIS2 Article 21(2)(e) requires the manufacturer organisation to maintain a vulnerability disclosure policy.
Business continuity	Article 21(2)(c) — backup management and disaster recovery	Article 10(8) — instructions for use and maintenance	NIS2 requires documented RTO and RPO. MDR requires the device to function as specified in its instructions for use — implying continuity of software updates and service.
Access control and asset management	Article 21(2)(i) — HR security, access control, asset management	Annex I, Section 17.2 — minimum security controls specified by design	MDR Section 17.2 requires minimum security controls built into the device; NIS2 requires organisational access policies governing who can connect to or configure devices.

The most efficient compliance strategy is a single integrated control register that documents both mapping references side by side for each control. When your quality management system (typically ISO 13485-aligned) already captures MDR evidence, add a NIS2 column to the same register rather than duplicating the documentation. For incident reporting, maintain a decision matrix that identifies which regulatory notification pathway activates based on the incident type — a documented procedure that both your legal and security teams can apply without escalation delay. For more on the Article 23 notification timeline, see the NIS2 incident notification guide.

Classifying Patient Data Under Article 21(2)(h)

Article 21(2)(h) requires policies and procedures for the use of cryptography and, where appropriate, encryption. For healthcare organisations, this is not a single policy — it is a classification decision. Different data categories carry different risk profiles and demand different cryptographic controls.

Patient data qualifies as a special category under GDPR Article 9, which requires specific legal grounds for processing. Under NIS2, a cybersecurity incident affecting that data triggers dual notification: a report to your national competent authority under Article 23 of NIS2, and a data breach notification to your data protection authority under GDPR Article 33. The classification tier of the affected data determines the urgency and scope of both reports.

A practical four-tier classification framework for healthcare data:

Tier	Data Type	Encryption Requirement	Key Management
Critical	Patient identifiers combined with clinical data (diagnoses, medications, imaging results) — data that directly identifies an individual and reveals health status	Encrypted in transit (TLS 1.3 minimum) and at rest (AES-256 minimum). No exceptions for internal transfers between clinical systems.	Separate key management infrastructure from encrypted data storage. Access logged and audited.
High	Aggregated clinical datasets where re-identification risk exists (ward-level infection data, demographic health statistics with small cohort sizes)	Encrypted at rest. In-transit encryption mandatory for external transmission; recommended for internal.	Access restricted to roles requiring data for clinical or research purposes. Quarterly access review.
Medium	Administrative and scheduling data (appointment records without clinical content, billing identifiers, staff contact details)	Encrypted at rest as a minimum. Access controlled by role.	Standard key management. Annual access review.
Low	Fully anonymised or pseudonymised research data where re-identification is not feasible without the mapping table	Standard access controls. Mapping table storing re-identification keys must itself be classified Critical.	Mapping table key management per Critical tier.

NIS2 does not specify a minimum encryption algorithm — the directive uses risk-based language, requiring controls appropriate to the risk profile. In practice, AES-256 for data at rest and TLS 1.3 for data in transit represent the current baseline for Critical and High tier healthcare data. Weak or deprecated algorithms (3DES, RC4, TLS 1.0/1.1) do not satisfy the proportionality requirement when stronger alternatives are readily available. The NIS2 cryptography and encryption guide covers algorithm selection and policy structure in full.

The Full Article 21(2) Healthcare Compliance Checklist

The ten mandatory cybersecurity measures in Article 21(2) apply to all essential and important entities. The checklist below adds healthcare-specific implementation notes to each measure — the areas where generic NIS2 guidance leaves clinical environments without a direct answer.

(a) Risk analysis and information security policy
Maintain a formal risk register covering three distinct environments: office IT (email, HR systems, finance), clinical IT (HIS, RIS, PACS, EHR), and IoMT (connected devices as per the Tier A/B/C inventory above). A single policy that treats all three environments identically will not satisfy the proportionality requirement. Assign a risk owner to each environment; typically the CISO or IT Security Manager for IT, and clinical informatics or biomedical engineering for the IoMT tier.

(b) Incident handling
The Article 23 notification timeline starts from the moment of becoming aware of the incident — not from the moment of confirmation or containment. Hospitals must distinguish between a cybersecurity incident and a patient safety incident, as these may trigger different escalation paths: the NIS2 competent authority for cybersecurity events; clinical governance and the national patient safety authority for events affecting patient care directly. Conduct tabletop exercises at least annually, including a scenario where a Tier B IoMT device is compromised.

(c) Business continuity, backup management, and disaster recovery
Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each clinical system tier. Life-critical systems — intensive care unit monitoring, operating theatre equipment, emergency department systems — require the shortest RTOs and dedicated failover infrastructure. Clinical backups should be stored in network-segregated security zones, not on the same VLAN as the source systems.

(d) Supply chain security
Article 21(3) requires evaluating vulnerabilities specific to each direct supplier. For hospitals, the direct supplier list includes medical device vendors, HIS/PACS/EHR software providers, cloud electronic health record services, managed security service providers, and biomedical equipment maintenance contractors. Develop a supplier risk scorecard that rates each vendor against security criteria and drives annual contract review. For medical device manufacturers, this obligation runs in both directions: you must assess your component suppliers, and your hospital customers are required to assess you. See the NIS2 supply chain security guide for the contractual clause requirements.

(e) Security in acquisition, development, and maintenance of systems
When procuring new IoMT devices, require that devices placed on the market after May 2021 carry evidence of MDR Annex I, Section 17.2 conformity — the software cybersecurity lifecycle requirement. For devices that are software-configurable, include vulnerability notification clauses in purchase contracts specifying how and within what timeframe the manufacturer will disclose identified vulnerabilities.

(f) Effectiveness assessment
Periodic testing of cybersecurity controls is mandatory. For healthcare, this must include penetration testing of HL7/FHIR API integration points — the interfaces between heterogeneous clinical systems that are frequently overlooked in standard IT penetration testing scopes. Test the network segmentation between IoMT VLANs and clinical IT networks at least annually.

(g) Cyber hygiene and training
Clinical staff training must differ from IT staff training. Clinicians need scenario-based training on phishing recognition and safe device handling; they do not need — and will not retain — technical security architecture content. Biomedical engineering staff require separate training on secure device configuration and maintenance reporting. Document completion rates and provide evidence to auditors on request.

(h) Cryptography and encryption
Apply the patient data classification framework from the section above. Maintain a documented cryptography policy that specifies approved algorithms, prohibited algorithms, key management procedures, and certificate lifecycle management. Review annually and update when ENISA or national cybersecurity authority guidance changes the approved algorithm list.

(i) Human resources security, access control, and asset management
Implement Privileged Access Management (PAM) for clinical systems — session-based authorisation with recording for administrator-level access to HIS, PACS, and IoMT management consoles. Apply role-based access control (RBAC) at the minimum privilege level for all clinical staff. Maintain the IoMT device inventory as a live document, not a static annual audit.

(j) Multi-factor authentication (MFA)
MFA is required for all remote access to clinical networks, all administrator access to critical systems, and all access to systems holding Critical or High tier patient data. For clinical workflows where MFA adds significant friction at the point of care, proximity-based authentication (smart card, badge tap) satisfies the NIS2 requirement while preserving clinical speed. See the NIS2 MFA requirements guide for implementation options.

Governance: Who Owns What in a Healthcare NIS2 Programme

Healthcare organisations have compliance roles that generic NIS2 frameworks do not anticipate. The role-responsibility matrix below reflects the actual structure of a hospital’s compliance programme:

Role	Primary NIS2 Responsibilities	Article 21(2) Measures Owned
CISO / IT Security Manager	Programme ownership, risk register, incident coordination, supplier assessments	(a) (b) (d) (e) (f) (i) (j)
Clinical Informaticist	EHR/HIS/PACS security requirements, clinical workflow integration for access controls and MFA	(a) (i) (j)
Biomedical Engineering	IoMT device inventory, Tier B device compensatory controls, MDR documentation, procurement security requirements	(a) (e) (i)
Data Protection Officer (DPO)	Patient data classification, GDPR Article 33 breach notification, Article 21(2)(h) cryptography policy	(h)
Legal / Compliance Officer	Entity registration, regulatory correspondence with competent authority, NIS2 transposition monitoring	(b) (d)
HR Manager	Staff NIS2 awareness training, background checks policy, offboarding access revocation	(g) (i)
Board / Management Body	Programme approval, personal accountability under Article 20, quarterly board reporting	All — oversight

Article 20 of NIS2 holds management bodies personally accountable for approving cybersecurity programmes and overseeing their implementation. In practice, this means the board or executive team must formally approve the risk register and cybersecurity policy, receive quarterly status reports, and undergo cybersecurity awareness training themselves. This is not a delegation that can be pushed entirely to the CISO.

Frequently Asked Questions

Are private clinics covered by NIS2?
Yes, if they qualify as a medium or large enterprise (more than 50 employees or annual turnover above €10 million). Small private clinics below these thresholds are generally out of scope unless a Member State specifically designates them based on their critical role in regional healthcare delivery.

Does a hospital that runs its own pharmacy need to comply with both the healthcare provider requirements and the pharmaceutical manufacturer requirements?
It depends on the scale of pharmaceutical production. A dispensing pharmacy within a hospital is not a manufacturer of basic pharmaceutical products in the NIS2 sense. Manufacturing of medicinal products at industrial scale is what triggers the Annex I pharmaceutical entry. Standard hospital pharmacies remain under the healthcare provider classification.

When does a cyber incident require both NIS2 and GDPR notification?
Any cybersecurity incident that results in unauthorised access, disclosure, loss, or destruction of personal data — including patient health records — simultaneously triggers NIS2 Article 23 notification to the competent authority and GDPR Article 33 notification to the data protection authority. Both run from the moment of becoming aware. The 72-hour window is the same for both obligations, but the recipients, required content, and follow-up obligations differ.

Our medical devices are old and cannot be patched. Are we non-compliant?
Not automatically. NIS2 requires appropriate and proportionate measures given the state of the art, the cost of implementation, and the risk profile. An unpatched legacy device that is network-isolated on a dedicated VLAN with anomaly detection monitoring, documented compensatory controls, and a replacement roadmap represents a proportionate approach for a device that cannot be patched. What NIS2 prohibits is an unpatched, network-connected device with no compensatory controls and no documented risk acceptance.

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.

Sources

[1] Directive (EU) 2022/2555 (NIS2 Directive) — EUR-Lex. Official text, Annex I, Article 21, and Article 34.

[2] Article 21: Cybersecurity Risk-Management Measures — NIS2 Resources. Verbatim text of Article 21(2)(a)-(j).

[3] NIS2 for Healthcare: What Hospitals and Clinics Must Implement — nFlo. IoMT implementation guidance.

[4] NIS2 for Healthcare: Annex I, MDR, Patient Data Protection — Cybervize. German market implementation perspective.

[5] EU CRA + NIS2: Impact on Medical Device Manufacturers — MedDeviceGuide. MDR and NIS2 dual compliance analysis.

[6] CIR 2024/2690 Technical and Methodological Requirements — NISD2.eu. Annex Point 12 asset management requirements.

[7] Health Sector Cybersecurity — ENISA. Threat landscape data and EU Action Plan for hospitals.

[8] NIS2 for Healthcare: What Providers Must Know — Copla. Governance and board accountability implementation guidance.