NIS2 in healthcare: what IT teams must instrument
Operational NIS2 evidence for a healthcare IT team: Articles 21 and 23 of Directive (EU) 2022/2555, the 24 h / 72 h / one-month clocks, national CSIRT versus GDPR Art. 33, and why Annex I is not automatic essential-entity status.
Ala Ben Aicha
Direct answer
NIS2 is not a single certificate. Article 23 requires 24 h, 72 h, then one month for essential or important entities. Annex I healthcare is not automatic essential-entity status. CSIRT and authority follow national transposition.
A directive, not the EHDS / MDR / GDPR stack
The EU healthcare compliance page maps four regimes. This page isolates NIS2 for the team that must instrument detection, escalation and evidence. Pin the text: Directive (EU) 2022/2555 (NIS 2). Transposition deadline: 17 October 2024; national measures applicable from 18 October 2024.
Health is listed in Annex I. That does not make every vendor, hoster or clinic an essential entity. Entity type, size (thresholds from the Annex to Recommendation 2003/361/EC, applied via Art. 3), specific inclusions and the national transposition law all count. A CISO does not “declare” status in a README: it is an organisational decision, with legal counsel.
The French-language sibling covers ANSSI and CERT-FR. Do not copy those names onto every member state. The national CSIRT and competent authority are transposition-dependent. Start from the Commission’s NIS2 overview and the member-state page that names your single point of contact.
Incident clocks: NIS2 Art. 23 is not GDPR Art. 33
Article 23 (ELI) requires notification of a significant incident to the CSIRT or the competent authority. The letters below are those of Art. 23(4); the 24 h / 72 h / one-month clocks remain the default deadlines of (a), (b) and (d):
| Clock | Deadline (directive) | Recipient (directive) | Minimum content | What this is not |
|---|---|---|---|---|
| Early warning | 24 h after becoming aware — Art. 23(4)(a) | CSIRT / competent authority | Significant incident; suspected unlawful or malicious act?; cross-border impact? | An internal Jira ticket, a Slack post-mortem |
| Incident notification | 72 h after becoming aware — Art. 23(4)(b) | same | Update of (a) plus initial assessment (severity, impact, IoCs if available) | The GDPR notification |
| Intermediate report | Upon request of the CSIRT / authority — Art. 23(4)(c) | same | Relevant updates on the situation | A final report “sent early” |
| Final report | One month after (b) — Art. 23(4)(d) | same | Detailed description (severity, impact); type of threat or likely root cause; mitigation applied and ongoing; cross-border impact where applicable | An ISO 27001 certificate; Art. 23(4)(c) |
| If the incident is still ongoing at (d) | Progress report at that time, then a final report one month after the incident is handled — Art. 23(4)(e) | same | (e) does not merge with (c): (c) is an authority request; (e) is the “still open at (d)” case | Silence until “we will see on Monday” |
| GDPR Art. 33 | 72 h (separate track) | Data-protection authority | Personal-data breach at risk | A NIS2 substitute |
(c) is not the one-month report. (d) is the final report, one month after the notification (b), not one month after becoming aware. (e) is not “on request if it lasts”: if the incident is still open at the (d) deadline, you file a progress report instead of the final (d) at that deadline, then a final within one month of handling.
The two 72-hour clocks can coincide on the calendar and diverge on recipient and content. NIS2 goes to the CSIRT / designated authority; GDPR Art. 33 goes to the data-protection authority. One email “we had an incident” satisfies neither.
Trust-service providers: derogation from point (b) of Art. 23(4) — notification in 24 h (not 72 h) for a significant incident that affects the trust service. Do not copy that derogation onto a hospital DPI.
Art. 21: ten families of measures, one audit trail per family
Article 21(2) lists proportionate measures (not a miracle product):
| Letter | Art. 21(2) family | Engineering evidence (example) |
|---|---|---|
| (a) | Policies on risk analysis and information-system security | Versioned risk register, named owner |
| (b) | Incident handling | 24 h / 72 h / 1-month runbook + dated exercise |
| (c) | Continuity, backup, recovery, crisis | Restore exercise with measured RTO/RPO — not a PDF policy |
| (d) | Supply-chain security | Supplier inventory + clauses + failover test |
| (e) | Acquisition / development / maintenance, vulnerabilities | SDLC, CVE handling, documented patch window |
| (f) | Assessing effectiveness | Scheduled audit / penetration test, not a marketing badge |
| (g) | Cyber hygiene and training | Training evidence for the management body (Art. 20) |
| (h) | Cryptography | TLS / key / HSM inventory, not “we have HTTPS” |
| (i) | HR, access control, assets | Dated access review, minimal CMDB |
| (j) | MFA, secured communications | MFA on EHR admin and on the incident-escalation path |
Article 20 charges the management body. A CISO who “signs NIS2” in Confluence is not Art. 20.
Integration exercise (no real data)
In a test environment, cut one downstream system (HL7 feed, FHIR API, or Mirth destination). Time: detection, “significant?” classification, 24 h early-warning draft to an internal mailbox (not to a CSIRT), queue growth, recovery, reconciliation. The gap this exercise reveals — missing owner, no clock, no IoC — is the backlog item. Do not notify a fictitious incident to an authority.
What this is not
This is not an essential-entity qualification, not an ENISA or national-authority opinion, not a substitute for legal counsel, not an ISO audit, and not clinical advice. I do not notify on your behalf. ANSSI / CERT-FR belong on the French page, not on every member-state runbook. GDPR health-data architecture remains a separate workstream.
If you need to instrument logs, queues and failover around care interfaces, that is digital health interoperability. For a bounded spike, use contact with project intent.