The 3 HIPAA–NIS2 Gaps That Put US Healthcare Groups at EUR 10M Risk — and the Controls That Close Them

Most US healthcare compliance teams assume their HIPAA programme covers their EU operations. Both frameworks target data security in a regulated sector, both carry significant penalties for non-compliance, and the investment in HIPAA controls is substantial enough that professionals expect it to carry weight elsewhere. It does not carry enough weight to satisfy NIS2.

Directive (EU) 2022/2555 — known as NIS2 — has been enforceable against EU-established entities since October 2024, with healthcare classified as a highly critical sector under Annex I. EU subsidiaries of US hospital groups, pharmaceutical manufacturers, medical device distributors, and digital health platforms are all within scope if they meet the relevant size thresholds. An organisation that is HIPAA-certified to the letter will still fail an NIS2 audit on three specific, measurable points.

This article identifies those three gaps with precision: the technical control mismatch between HIPAA’s §164.312 safeguards and the NIS2 technical benchmark, the operational conflict between HIPAA’s 60-day breach notification window and NIS2’s 24-hour early warning obligation under Article 23, and the contractual shortfall between a standard HIPAA Business Associate Agreement and NIS2 Article 21(2)(d) supply chain security requirements. For each gap, the controls that close it are mapped in detail.

The analysis draws from EUR-Lex primary text, the US Code of Federal Regulations, and HHS guidance. It is general information only — see the legal disclaimer at the foot of this article before acting on any of it.

Does NIS2 Apply to Your US Healthcare Group?

NIS2’s territorial scope is narrower than many US compliance teams expect: it applies to entities established in EU member states, not to every organisation that processes EU patient data or markets services into the EU. A US hospital with no EU legal entity is not directly subject to NIS2, regardless of GDPR exposure. The trigger is EU establishment, not data origination.

Three footprints typically bring a US healthcare group into NIS2 scope:

• EU-incorporated subsidiaries. A German GmbH clinical research unit, an Irish Ltd. digital health platform, or a Dutch BV distribution entity is an EU-established entity subject to NIS2 if it meets the size thresholds below.
• EU-based contract research organisations. CROs incorporated in EU member states that conduct clinical trials, laboratory analysis, or regulatory data management on behalf of the US parent.
• EU-established medical device or pharmaceutical operations. Manufacturing, distribution, or post-market surveillance entities incorporated in an EU member state.

Scope thresholds follow EU enterprise size definitions. Large enterprises — 250 or more employees or more than EUR 50 million annual turnover in the EU entity — qualify as essential entities under Annex I (which lists healthcare providers, pharmaceutical manufacturers, medical device manufacturers, IVD device makers, EU reference laboratories, and medicinal R&D entities). These face the most stringent requirements, including ex ante supervision and on-site inspections. Medium enterprises (50–249 employees or EUR 10–50 million turnover) in the same sectors qualify as important entities. Several member states additionally designate specific hospitals and critical healthcare infrastructure as essential entities irrespective of size.

An important nuance: the NIS2 obligations fall on the EU entity, not automatically on its US parent. However, enforcement actions and injunctions targeting a non-compliant EU subsidiary create reputational harm, potential group-level financial exposure through the global turnover element of Article 34 penalties, and — critically — contractual obligations that flow through any BAA or supply agreement the US parent signs with EU-based partners. The supply chain gap in Section 4 addresses that last point directly.

For a sector-by-sector breakdown of which healthcare organisations are classified as essential versus important under each member state’s transposition, the NIS2 healthcare guide covers Annex I classification in detail.

Gap 1 — Technical Controls: §164.312 vs the NIS2 Technical Benchmark

HIPAA’s technical safeguards are set out in 45 CFR §164.312 under five standards: access control (a), audit controls (b), integrity (c), person or entity authentication (d), and transmission security (e). Each standard carries implementation specifications labelled “Required” (implement without exception) or “Addressable” (implement unless a documented alternative achieves equivalent protection). Importantly, “Addressable” does not mean optional — it means implement, or document why a different measure is equally effective and deploy that alternative instead.

NIS2 Article 21 sets ten minimum measures for all covered entities and explicitly mandates multi-factor authentication under Article 21(2)(j) and encryption policies under Article 21(2)(h). Commission Implementing Regulation (EU) 2024/2690 (CIR 2024/2690), available on EUR-Lex, provides the binding technical detail across 13 thematic sections. One accuracy note: CIR 2024/2690 formally binds specific digital service provider types — DNS registries, cloud computing providers, CDN providers, managed service providers, and trust service providers — rather than healthcare providers directly. National competent authorities and ENISA’s June 2025 Technical Implementation Guidance treat the CIR Annex as the de facto technical standard for all NIS2 entities, and the Article 21(2)(h), (i), and (j) obligations bind every covered entity regardless of CIR scope. The table below uses the CIR Annex as the technical reference accordingly.

Control domain	HIPAA §164.312 standard	Spec. type	NIS2 Art. 21 / CIR 2024/2690 Annex	Gap for HIPAA-compliant organisations
Multi-factor authentication	Person or entity authentication (d)	Standard only — no method specified	Art. 21(2)(j): MFA or continuous authentication required; CIR §10: MFA for remote access and privileged accounts	HIPAA allows single-factor under a documented risk assessment; NIS2 mandates MFA explicitly for remote and privileged access
Encryption at rest	Encryption and decryption (a)(iv)	Addressable	Art. 21(2)(h): formal encryption policy required; CIR §12: classification-based protection controls	HIPAA permits a documented compensating measure; NIS2 requires a written encryption policy covering ePHI at rest
Encryption in transit	Transmission security — encryption (e)(2)(ii)	Addressable	Art. 21(2)(h); CIR §7: encrypted VPN connections for remote network access required	HIPAA “whenever deemed appropriate”; NIS2 requires encrypted remote access without a discretionary carve-out
Audit logging and detection	Audit controls (b)	Standard only — activity recording	CIR §3: incident detection capability, anomaly monitoring, log correlation, post-incident review	HIPAA requires recording activity; NIS2 requires detecting and correlating it — a SIEM or equivalent detection capability, not just a log archive
Access control and reviews	Unique user identification (a)(i); access rights management	Required	Art. 21(2)(i); CIR §10: access control policy, least privilege, mandatory periodic access reviews	Largely aligned; NIS2 adds a mandatory periodic access review cycle not specified in HIPAA
Network perimeter security	Transmission security — integrity controls (e)(2)(i)	Addressable	CIR §7: firewalls, VPN controls, traffic filtering, service connection limits required	HIPAA is addressable on network integrity; NIS2 mandates specific network perimeter controls
Supply chain security	Business associate safeguards (§164.308(b))	Required (BAA)	Art. 21(2)(d): supplier cybersecurity assessment, contractual requirements, audit rights, subcontractor oversight; CIR §5	HIPAA BAA controls PHI handling; NIS2 requires a full cybersecurity risk assessment of every direct supplier

Three gaps require priority action before any NIS2 audit.

MFA gap. NIS2 Article 21(2)(j) mandates MFA for all covered entities; CIR Section 10 specifies that MFA applies specifically to remote access and privileged account access. This is not discretionary. A HIPAA-compliant organisation using documented risk-based single-factor authentication for remote access must implement MFA for those sessions to satisfy NIS2 — regardless of what compensating controls are currently documented. Our NIS2 MFA requirements guide covers implementation options and audit evidence requirements.

Monitoring gap. HIPAA §164.312(b) requires hardware, software, or procedural mechanisms to record and examine activity in systems containing ePHI. NIS2’s CIR Section 3 goes further: it requires the ability to detect anomalous activity, correlate events across systems, and support post-incident forensic analysis. A passive log archive satisfies HIPAA. A functioning detection and response capability — whether a SIEM, a managed detection service, or a documented equivalent — is the NIS2 standard.

Encryption gap. HIPAA marks both at-rest and in-transit encryption as addressable, accepting documented compensating measures. NIS2 Article 21(2)(h) requires an explicit encryption policy; CIR Section 7 makes encrypted connections mandatory for remote network access. The flexibility HIPAA extends under the “addressable” label does not exist in NIS2 for remote access scenarios.

Gap 2 — The Notification Clash: 60 Days vs 24 Hours

HIPAA’s Breach Notification Rule (45 CFR §164.400–414) requires covered entities to notify affected individuals, HHS, and — for breaches affecting more than 500 residents of a state — prominent media outlets, all within 60 days of the discovery of a breach. Discovery is the first day a covered entity knows, or by exercising reasonable diligence would have known, of the breach. Critically, the 60-day clock starts only after the organisation determines that a breach occurred — typically after completing a four-factor risk assessment examining the nature and extent of PHI involved, who accessed or could have accessed it, whether PHI was actually acquired or viewed, and the extent to which risk has been mitigated.

NIS2 Article 23 operates on a different timeline and a different trigger. The three-stage framework is:

• 24 hours: early warning to the national CSIRT or competent authority, sent “without undue delay and in any event within 24 hours of becoming aware of the significant incident.” This notification requires only awareness of a potential significant incident — it does not require breach confirmation or a completed risk assessment.
• 72 hours: incident notification with an updated severity assessment and indicators of compromise, providing initial impact evaluation.
• 1 month: final report covering incident description, threat type, mitigation measures taken, and cross-border impact.

The fundamental tension. HIPAA notification begins after a risk assessment confirms a breach. NIS2’s early warning fires at awareness — before any risk assessment is complete. An organisation that detects unusual access to its EU systems at 09:00 on Monday must file a NIS2 early warning by 09:00 Tuesday, with whatever information is available at that point. The HIPAA four-factor assessment may not conclude until day 10, 20, or 40. These are parallel processes, not sequential ones.

A “significant incident” under NIS2 Article 23 is one that causes or has the potential to cause significant operational disruption of services or financial loss, or affects other natural or legal persons by causing considerable material or non-material damage. This threshold is lower than a confirmed HIPAA breach: a ransomware infection that has not yet been confirmed to have accessed ePHI qualifies as a significant NIS2 incident but may not yet have triggered HIPAA breach notification obligations.

The dual-track incident response workflow below separates the two processes from Day 0:

Day	NIS2 track (Article 23)	HIPAA track (§164.400–414)
0	Detect incident; assess whether “significant” under NIS2 (disruption or damage potential)	Begin four-factor risk assessment; preserve forensic evidence
1 (24h)	File early warning to CSIRT: incident type, preliminary scope, suspected cause, potential cross-border impact	Four-factor risk assessment in progress
3 (72h)	File incident notification: updated severity assessment, affected systems, initial mitigation steps taken	Risk assessment may or may not be complete; if breach confirmed, 60-day clock started at Day 0
1–60	Continue working with competent authority; implement mitigation	If breach confirmed: notify individuals, HHS (500+ individuals), media (500+ in state) within 60 days of Day 0
30	Final report due to competent authority	HIPAA notifications may or may not be complete depending on breach scope

Practical implication: pre-draft the early warning. The 24-hour window is tight enough that improvising a notification under active incident pressure leads to errors or missed deadlines. Best practice is maintaining a pre-drafted early warning template — an EU-entity letterhead document with fill-in fields for incident date, preliminary description, suspected cause category (technical failure, human error, third-party compromise, malicious act), and cross-border impact assessment — that the designated CSIRT contact can complete and submit within two hours of identifying a potential significant incident. The early warning does not require certainty; it signals awareness and initiates the regulatory clock.

For the full Article 23 framework, what constitutes a “significant incident” in practice, and the reporting portals for each EU member state, see the dedicated Article 23 incident notification guide. For practical step-by-step procedures and notification templates, the NIS2 incident reporting guide covers the full playbook.

Gap 3 — The Supply Chain Gap: HIPAA BAAs vs NIS2 Article 21(2)(d)

Standard HIPAA Business Associate Agreements (BAAs), required under 45 CFR §164.308(b), are built around one purpose: controlling how a business associate creates, receives, maintains, or transmits protected health information. A BAA must specify permitted uses and disclosures, require the BA to implement appropriate safeguards, obligate breach reporting to the covered entity, and mandate return or destruction of PHI at contract termination. Where the BA uses subcontractors who handle PHI, it must obtain its own BAA with each.

NIS2 Article 21(2)(d) requires covered entities to address “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers.” CIR 2024/2690 Section 5 specifies what this means contractually: supplier security criteria, cybersecurity requirements embedded in supplier contracts, audit rights over supplier security controls, oversight of subcontractors, and incident notification obligations flowing from supplier to the NIS2-covered entity in time for the entity to meet its own Article 23 obligations.

Five gaps exist between a standard HIPAA BAA and NIS2 supply chain security requirements:

1. No cybersecurity maturity criteria. BAAs require BAs to implement “appropriate safeguards” without specifying a maturity level or assessment framework. NIS2 supply chain security requires the covered entity to document the basis for trusting each supplier’s cybersecurity posture — a maturity assessment against ISO 27001, the NIS2 CIR Annex sections, or an equivalent framework.

2. No 24-hour incident notification flow-down. Most BAAs and the HHS model BAA require BAs to report breaches to the covered entity without unreasonable delay, in practice aligned with HIPAA’s own 60-day window. For an EU entity to file its own 24-hour early warning to the CSIRT, it needs to learn about a supplier-caused incident within hours, not days. Practitioners recommend a contractual 24-hour or same-day notification requirement from suppliers to the EU entity’s designated NIS2 contact as the flow-down standard.

3. Audit rights limited to PHI handling. HIPAA BAAs typically grant covered entities the right to audit or review how the BA handles PHI. NIS2 supply chain security requires audit rights over the supplier’s entire cybersecurity posture — network controls, patching cadence, access management, incident response capability — not solely PHI access records.

4. Subcontractor cascade is PHI-only. BAAs require subcontractor BAAs. NIS2 goes further: the covered entity must ensure that every link in its supply chain meets appropriate cybersecurity standards, not merely that a PHI-focused subcontract exists. CIR Section 5 anticipates oversight of N-tier supplier risks where applicable.

5. No vulnerability disclosure obligations. Standard BAAs do not address vulnerability disclosure. NIS2 supply chain security implies that suppliers should notify covered entities of known vulnerabilities in systems they operate on the entity’s behalf, enabling timely risk assessment and patching decisions.

Closing the gap with a NIS2 Security Addendum. Rather than renegotiating every BAA from scratch, EU-entity legal teams can supplement existing BAAs with a NIS2 Security Addendum. The addendum does not alter HIPAA PHI controls — it adds cybersecurity obligations on top. Key addendum clauses: a cybersecurity maturity self-assessment requirement (ISO 27001 or CIR Annex equivalent), a same-day or 24-hour incident notification obligation to the EU entity’s designated NIS2 contact, explicit audit rights over security controls beyond PHI access, subcontractor cybersecurity oversight obligations, and a vulnerability disclosure duty for systems operated on the entity’s behalf. New supplier contracts for EU entities should incorporate NIS2 supply chain clauses as standard from the outset, rather than as a post-signature addendum.

For a full framework of NIS2 supply chain requirements and template contract language, see the NIS2 supply chain security guide.

Your Dual-Regime Compliance Roadmap

Rationalising a HIPAA-compliant programme for NIS2 coverage does not require building two separate compliance systems. The controls overlap significantly — the gaps are specific and closeable. Five steps address the priority obligations in sequence:

Step 1: Map EU entities to NIS2 scope (2 weeks). Identify every EU-incorporated legal entity in the group. Determine essential or important status using Annex I healthcare classification and the applicable member state’s size thresholds. Note that Germany, France, and several other member states have designated specific categories of healthcare facility as essential irrespective of headcount. Register each in-scope entity with the relevant national competent authority — registration obligations vary by member state, but most required initial registration by April 2025. Confirm which national regulatory body has supervisory authority over each EU entity.

Step 2: Technical control gap assessment against Article 21 (4–6 weeks). Use the mapping table in Gap 1 as a starting framework. Prioritise the three confirmed gaps: MFA implementation for remote and privileged access, anomaly detection or SIEM capability, and a formal encryption policy. Document current-state controls, identify what is already satisfied by HIPAA investments, and scope the remaining work. The full NIS2 control checklist is available in the NIS2 requirements guide.

Step 3: Incident response procedure overhaul (2–4 weeks). Add a pre-drafted NIS2 early warning template to each EU entity’s IR playbook. Designate a named CSIRT contact point for every in-scope EU entity. Build the dual-track IR workflow illustrated in Gap 2. Train incident response staff that NIS2’s trigger is awareness of a potential significant incident — not confirmation of a breach. This is the most common operational mistake teams from HIPAA-only environments make when NIS2 exposure is added.

Step 4: BAA audit and NIS2 Security Addendum programme (4–8 weeks). Inventory all BAAs in force for EU entities. Assess each business associate’s cybersecurity maturity using a defined framework. Supplement relevant BAAs with a NIS2 Security Addendum covering 24-hour incident notification, cybersecurity audit rights, and maturity assessment requirements. Include NIS2 supply chain clauses as standard in all new supplier contracts for EU entities.

Step 5: Governance and board accountability (ongoing). NIS2 Article 20 makes management bodies personally responsible for approving and overseeing cybersecurity risk management measures — a step further than HIPAA’s institutional accountability model. Board members who approve an inadequate security posture may face personal liability. Brief the board on Article 34 penalty exposure (EUR 10 million or 2% of global annual turnover for essential entities, whichever is higher) and authorise the resource commitment required. Establish quarterly NIS2 compliance reviews and document all measures taken to build an audit trail for supervisory inspections.

The table below maps each step to the function that owns it and the typical timeline:

Role	Priority action	Step	Typical timeline
Legal Counsel	Scope determination; NCA registration; BAA audit and addendum programme	1, 4	Months 1–3
CISO / IT Security	Technical gap assessment; MFA deployment for remote and privileged access; SIEM or detection capability	2	Months 1–2
Compliance Officer	IR procedure overhaul; CSIRT contact designation; dual-track workflow documentation	3	Month 1
Board / C-Suite	Authorise resources; receive EUR 10M penalty exposure briefing; approve security governance policy under Art. 20	5	Month 1 (recurring quarterly)

Frequently Asked Questions

Is a US hospital that treats EU patients subject to NIS2? Not directly, if it has no EU legal establishment. Processing EU patient data triggers GDPR obligations; NIS2 applies to entities established in EU member states. A US-only hospital is outside NIS2’s direct scope. However, if that hospital contracts with EU-established business associates — cloud providers, imaging services, laboratory networks — those EU entities may be NIS2-covered and will flow cybersecurity requirements back to the US hospital through their own supply chain security obligations.

Does HIPAA compliance count toward NIS2? Partially. HIPAA’s §164.312 technical safeguards cover access control, audit controls, integrity, authentication, and transmission security — which overlap substantially with NIS2 Article 21(2)(i) and (j). The key difference is that HIPAA’s “addressable” flexibility allows documented alternatives to MFA and encryption. NIS2 closes those alternatives for remote access and encrypted connections. A HIPAA-compliant organisation starts with a strong foundation but is not NIS2-compliant without additional work in the three areas identified above.

What is the first step for a US healthcare group new to NIS2? Determine which EU entities, if any, are in scope and whether they qualify as essential or important entities. This scoping exercise takes one to two weeks and determines everything downstream — the national regulatory body to register with, the compliance timeline, the proportionate controls required, and the penalty exposure on the table. The NIS2 requirements guide provides a scoping checklist as a starting point.

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), Article 21 — Cybersecurity risk-management measures. Available at nis-2-directive.com/NIS_2_Directive_Article_21.html
2. Directive (EU) 2022/2555 (NIS2), Article 23 — Reporting obligations
3. Directive (EU) 2022/2555 (NIS2), Article 34 — Administrative fines
4. Commission Implementing Regulation (EU) 2024/2690, Annex — Technical and methodological requirements. Available at eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng
5. 45 CFR §164.312 — Technical safeguards. Available at law.cornell.edu/cfr/text/45/164.312 (cited inline above)
6. HIPAA Breach Notification Rule — HHS Office for Civil Rights
7. Business Associates — HHS Office for Civil Rights. Available at hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/
8. NIS2: What are the implications for the healthcare sector? — RSM UK
9. NIS2 Healthcare Impact — MyData Trust