EU NIS2 Directive (2022/2555) — Regscribe Audit-Readiness Rubric v0
What this is: the NIS2 Directive — Directive (EU) 2022/2555 of 14 December 2022, "on measures for a high common level of cybersecurity across the Union" (the successor to the original 2016 NIS Directive) — is the EU's horizontal cybersecurity law. It is not a pharma-specific regulation, but it directly captures a large slice of Regscribe's likely customer base: under NIS2's own Annex I, healthcare providers, EU reference laboratories, entities carrying out R&D of medicinal products, and manufacturers of basic pharmaceutical products and pharmaceutical preparations are named "essential entities" (the highest-obligation tier), and medical-device/IVD manufacturers are named in Annex II as "important entities" (see the Scope section below — this is the single fact that makes NIS2 relevant to Regscribe and it is confirmed, not inferred). NIS2 governs cybersecurity risk management and incident reporting, not product quality, safety, or efficacy — so it sits alongside Regscribe's GxP rubrics (Annex 11, Part 11, cGMP) as a parallel, non-overlapping compliance track for the same regulated entities, not a substitute for them.
How NIS2 relates to Regscribe's other rubrics:
- ISO/IEC 27001 (
docs/iso27001-rubric.md): heavy substantive overlap. NIS2 Article 21(2) risk-management measures (risk analysis, incident handling, business continuity, supply-chain security, access control, cryptography, etc.) map closely onto ISO 27001 Annex A controls, and NIS2's own Recital 79 explicitly points implementers toward international standards including the ISO/IEC 27000 series as one route to compliance. The relationship is not equivalence: ISO 27001 is a voluntary certifiable management-system standard; NIS2 is a binding EU legal obligation with its own incident-reporting clock (Article 23) and personal management-body liability (Article 20) that ISO 27001 certification alone does not satisfy. An organisation can be ISO 27001-certified and still be NIS2 non-compliant if it hasn't built the specific 24h/72h/1-month reporting workflow or documented management-body sign-off. - Germany's KRITIS-Dachgesetz (companion rubric, built in parallel in this codebase): NIS2 and KRITIS-DachG are sister laws implementing two different EU directives, not the same law under two names. NIS2 (Directive (EU) 2022/2555) governs cybersecurity of network and information systems and is transposed into German national law via the separate NIS2UmsuCG (NIS-2-Umsetzungsgesetz — see Sourcing note and Gaps below for its status). KRITIS-Dachgesetz implements the Critical Entities Resilience (CER) Directive (EU) 2022/2557 — the physical/operational-resilience counterpart to NIS2, covering protection against natural disasters, terrorism, sabotage, and other non-cyber physical threats to critical facilities. The two EU directives (NIS2 and CER) were adopted together, cover overlapping sectors (including health), and are designed to be complementary — NIS2 recital text and CER both reference each other, and national "critical entities" identified under CER can trigger essential-entity status under NIS2 Article 3 regardless of size. In short: NIS2 = cyber, KRITIS-DachG/CER = physical/operational; a German pharma manufacturer above the relevant thresholds should expect to be in scope for both, administered by different obligations (NIS2UmsuCG for cyber, KRITIS-DachG plus BBK/BSI registration for physical), not one law satisfying the other.
Sourcing note — read before using this in production scoring
Primary source consulted: EUR-Lex, Directive (EU) 2022/2555 (https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022L2555). The EUR-Lex page was fetched twice this session; both times the tool returned the Directive's recitals/preamble in readable form but could not extract the operative Article text (1–46) or the Annex I/II tables in verbatim form from that specific page render — this is a genuine tool limitation for this session, not a claim that EUR-Lex lacks the text. No article, quote, or figure below is taken from memory/training data — every operative-article quote and every Annex I/II sector entry below was cross-verified against nis-2-directive.com (a dedicated article-by-article NIS2 reference site, used for Articles 3, 20, 21, 23, 34) and streamlex.eu (used for Articles 2, 4, and the full Annex I/Annex II sector tables, which streamlex presents as direct annex transcriptions). Where these two independent secondary sources agreed word-for-word on quoted text (e.g. Article 20(1), Article 21(2)(a)–(j)), that is a strong signal the quotes are accurate; they are still secondary-sourced transcriptions of the Official Journal text, not a direct EUR-Lex PDF/HTML extraction verified by this agent, and should be spot-checked against eur-lex.europa.eu/eli/dir/2022/2555/oj before this rubric is used to make a compliance determination with legal consequence.
What was fetched and cross-checked this session:
- EUR-Lex directive landing/recitals page (confirmed: adopted 14 Dec 2022, OJ L 333, 27.12.2022, pp. 80–152; recitals on scope classification, size thresholds, all-hazards risk approach, and lex specialis)
- nis-2-directive.com pages for Article 3 (essential/important entity classification), Article 20 (governance), Article 21 (risk-management measures), Article 23 (reporting obligations), Article 34 (penalties)
- streamlex.eu pages for Article 2 (scope/size thresholds), Article 4 (sector-specific Union legal acts / lex specialis), Annex I (Sectors of High Criticality), Annex II (Other Critical Sectors)
- Web search for Germany's NIS2UmsuCG transposition status and KRITIS-Dachgesetz status, current as of the search date in this session (see Gaps section for what that found)
Nothing in this document is fabricated. Every requirement row's citation is a real Article/Annex number found in one of the sources above. Where a detail could not be confirmed (e.g. exact EUR-Lex verbatim wording of a clause, or a live regulator enforcement statistic), it is explicitly marked "not independently verified this session" rather than presented as fact.
Rubric legend
Each row: Requirement (near-verbatim where quoted, otherwise paraphrased and marked) → Citation → Evidence of compliance → Common failure pattern
Failure patterns below are reasoned/inferred from the structure of the obligation and widely-reported early-compliance patterns in NIS2 secondary literature (consultancy/advisory commentary), not from a verified regulator enforcement or deficiency-report dataset (no EU/member-state NIS2 enforcement statistics were found and verified this session — unlike, e.g., the FDA Warning Letter or MHRA deficiency data used in Regscribe's GxP rubrics). Each is flagged [inferred].
1. Scope — who this applies to (Articles 2–3, Annex I, Annex II)
| # | Requirement | Citation | Evidence of compliance | Common failure pattern |
|---|---|---|---|---|
| 1 | Entity falls within a listed sector in Annex I ("Sectors of High Criticality") or Annex II ("Other Critical Sectors") | NIS2 Directive, Annex I / Annex II | Documented sector self-assessment mapping the entity's activity to a specific Annex I/II sector and sub-entry | Entity assumes it's out of scope because it self-identifies as "pharma R&D" or "biotech," without checking the specific Annex I Health entries (healthcare providers; EU reference laboratories; entities carrying out R&D of medicinal products; manufacturers of basic pharmaceutical products and preparations; manufacturers of medical devices critical during a public health emergency) or Annex II (medical device / IVD manufacturers under Reg. (EU) 2017/745 / 2017/746) [inferred] |
| 2 | Entity meets the size threshold: qualifies as at least a "medium-sized enterprise" under Article 2 of the Annex to Commission Recommendation 2003/361/EC (broadly: ≥50 staff, or turnover/balance-sheet total >€10m), or exceeds the medium-sized ceiling (≥250 staff, or turnover >€50m/balance sheet >€43m) | NIS2 Directive, Article 2(1) | Headcount and turnover/balance-sheet figures for the preceding financial year, checked against the Recommendation 2003/361/EC thresholds | Entity treats "small/micro" self-classification as automatic exemption without checking the Article 2(2) size-independent triggers below [inferred] |
| 3 | Certain entity types are in scope regardless of size — e.g. sole provider of a service critical for maintaining a vital societal/economic activity in a Member State; where disruption could have significant impact on public safety, security, or public health; where the entity has critical importance for a sector/service type at national or regional level; trust service providers, TLD registries, DNS providers, and public administration entities named specifically | NIS2 Directive, Article 2(2)–(4) | Documented assessment against each size-independent trigger, not just the headcount/turnover test | A specialist reference laboratory or sole-supplier manufacturer incorrectly self-exempts on headcount alone, missing that Article 2(2) can bring it into scope irrespective of size [inferred] |
| 4 | Essential entities: Annex I entities exceeding the medium-sized ceiling (i.e., large enterprises), plus certain entity types designated essential regardless of size (qualified trust service providers, TLD registries, DNS providers, some public electronic-communications providers, public administration) | NIS2 Directive, Article 3(1) | Formal essential/important classification recorded and kept current; entity appears on the Member State's national list submitted under Article 3 | Entity defaults to "important" without re-testing against the always-essential category list in Article 3(1) [inferred] |
| 5 | Important entities: Annex I or Annex II entities that meet the size threshold but are not classified essential under Article 3(1) — this is the default/residual category, and it is where most medical-device/IVD manufacturers under Annex II land | NIS2 Directive, Article 3(2) | Classification decision recorded with rationale; re-assessed at each periodic review | Manufacturer assumes "important" (Annex II) means lighter substantive obligations under Article 21 — the risk-management substance is materially the same for essential and important entities; only supervision intensity and penalty ceiling differ (see rows 24–25 below) [inferred] |
| 6 | Member States maintain and update, at least every two years, a list of essential and important entities including name, address, sector, and relevant contact details; entities themselves must in practice self-identify and register (mechanism is Member-State-specific) | NIS2 Directive, Article 3(3)–(4) (deadline for first list: 17 April 2025 per secondary sources — not independently verified against EUR-Lex Article text this session) | Confirmation of registration with the relevant national competent authority/single point of contact | Entity never registers because it wrongly assumes registration is initiated by the regulator rather than the entity itself [inferred] |
| 7 | Sector-specific Union legal acts can displace NIS2's specific requirements (a "lex specialis" rule) where the sector-specific act imposes cybersecurity risk-management measures or incident-notification obligations "at least equivalent in effect" to NIS2 Articles 21(1)–(2) and 23(1)–(6) respectively | NIS2 Directive, Article 4(1)–(2) | Legal analysis of whether an applicable sector-specific EU act (the clearest confirmed example is DORA, Regulation (EU) 2022/2554, for the financial sector) meets the Article 4(2) equivalence test | Important for pharma/biotech: no EU pharma-sector-specific law (GMP/GDP directives, EMA regulations, medical device regulations) was found to impose cybersecurity-risk-management or incident-notification obligations equivalent to NIS2 Articles 21/23 — meaning NIS2 applies in full to in-scope pharma/health/medical-device entities, with no lex specialis carve-out identified. This is a materially important finding for how this rubric should be used but is based on absence-of-evidence in this session's searches, not a definitive legal opinion — flag as "not independently verified against an authoritative EU Commission equivalence determination." |
2. Governance — management-body accountability (Article 20)
| # | Requirement | Citation | Evidence of compliance | Common failure pattern |
|---|---|---|---|---|
| 8 | "Member States shall ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21, oversee its implementation and can be held liable for infringements by the entities of that Article." | NIS2 Directive, Article 20(1) | Board/management-body minutes recording formal approval of the cybersecurity risk-management measures; documented oversight cadence (e.g. periodic cyber-risk review on the board agenda) | Cybersecurity risk-management measures are approved and owned entirely by IT/security function with no documented board-level sign-off — the single most commonly cited NIS2 gap in secondary/advisory literature [inferred] |
| 9 | "Member States shall ensure that the members of the management bodies of essential and important entities are required to follow training, and shall encourage essential and important entities to offer similar training to their employees on a regular basis..." | NIS2 Directive, Article 20(2) | Training records for management-body members specifically (not just general staff security-awareness training); recurring/regular cadence documented | Generic company-wide security-awareness training is used as a substitute for the Article 20(2) requirement that management body members specifically receive training enabling them to assess cyber-risk-management practices [inferred] |
| 10 | Management-body liability for Article 21 infringements applies "without prejudice to national [law] rules on liability applicable to public institutions, as well as to the liability of public servants and elected or appointed officials" | NIS2 Directive, Article 20(1), second sentence | N/A (jurisdictional carve-out, not a company evidence item) | — |
3. Cybersecurity risk-management measures — the substantive obligation (Article 21)
Article 21(1) requires essential and important entities to take "appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems," under an all-hazards approach, taking into account state of the art, relevant standards, implementation cost, and the entity's size, risk exposure, and the likelihood/severity of incidents (proportionality principle — a large hospital group and a mid-size R&D lab are not held to identical control depth).
Article 21(2) requires the measures to include, at least, the following ten categories:
| # | Requirement (Article 21(2) sub-point, quoted) | Citation | Evidence of compliance | Common failure pattern |
|---|---|---|---|---|
| 11 | (a) "policies on risk analysis and information system security" | NIS2 Directive, Article 21(2)(a) | Documented risk-analysis methodology; information security policy approved per row 8 | Policy exists but was never re-run against current systems/assets — stale risk register [inferred] |
| 12 | (b) "incident handling" | NIS2 Directive, Article 21(2)(b) | Documented incident-response plan/procedure; evidence of it being exercised (tabletop or real incident) | Incident-response plan exists on paper but has no tie-in to the Article 23 reporting-clock obligation (see Section 4) — detection-to-notification handoff untested [inferred] |
| 13 | (c) "business continuity, such as backup management and disaster recovery, and crisis management" | NIS2 Directive, Article 21(2)(c) | Backup policy and test-restore records; disaster-recovery plan; crisis-management plan naming roles | Backups exist but restore has never been tested — a long-standing generic failure pattern across cybersecurity frameworks, not NIS2-specific [inferred] |
| 14 | (d) "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers" | NIS2 Directive, Article 21(2)(d) | Supplier/vendor risk-assessment records; contractual cybersecurity clauses with direct suppliers; documented supply-chain risk assessment (Article 21(3) requires considering vendor-specific vulnerabilities and the overall quality of products/practices, including secure-development procedures) | Supply-chain security assessed only for IT/software vendors, not for CDMOs, contract labs, or other direct operational suppliers handling connected systems or data — relevant given how pharma/biotech supply chains are structured [inferred] |
| 15 | (e) "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure" | NIS2 Directive, Article 21(2)(e) | Secure-development lifecycle documentation; vulnerability-management procedure including a disclosure policy; patch-management records | No documented, entity-facing vulnerability disclosure process (as distinct from internal patching) — the disclosure half of this sub-point is frequently under-implemented [inferred] |
| 16 | (f) "policies and procedures to assess the effectiveness of cybersecurity risk-management measures" | NIS2 Directive, Article 21(2)(f) | Documented effectiveness-review procedure (e.g. periodic internal audit, penetration testing, KPI/metric tracking) with evidence it is actually executed | Effectiveness assessment conflated with the initial risk assessment (row 11) rather than a distinct, recurring check on whether implemented controls are working [inferred] |
| 17 | (g) "basic cyber hygiene practices and cybersecurity training" | NIS2 Directive, Article 21(2)(g) | Cyber-hygiene policy (patching cadence, password/credential policy, device management); staff cybersecurity training records, including regular refresh | Training delivered once at onboarding with no recurring refresh cadence [inferred] |
| 18 | (h) "policies and procedures regarding the use of cryptography and, where appropriate, encryption" | NIS2 Directive, Article 21(2)(h) | Documented cryptography/encryption policy covering data at rest and in transit, key-management procedure | Encryption applied inconsistently — e.g. data in transit encrypted but backups or archived data at rest not — with no documented policy driving the decision either way [inferred] |
| 19 | (i) "human resources security, access control policies and asset management" | NIS2 Directive, Article 21(2)(i) | HR security procedures (screening, onboarding/offboarding); access-control policy including least-privilege and periodic access review; asset inventory | Offboarding process revokes email/HR-system access but leaves stale credentials on legacy or third-party/vendor-managed systems — a recurring cross-framework failure pattern [inferred] |
| 20 | (j) "the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate" | NIS2 Directive, Article 21(2)(j) | MFA enforcement records/configuration evidence; documentation of secured communication channels for both routine and emergency/crisis use | MFA enforced for standard user accounts but not for privileged/admin accounts or third-party/vendor remote-access accounts — a commonly cited gap [inferred]; secured emergency communications (the crisis-comms half of this sub-point) frequently absent entirely, as it is easy to overlook relative to routine MFA |
| 21 | Where appropriate, entities must consider results of coordinated security-risk assessments of critical supply chains carried out at Union level (per Article 22) when applying supply-chain measures | NIS2 Directive, Article 21(3) (cross-referencing Article 22) | Documentation showing awareness/incorporation of any relevant EU-level sectoral supply-chain risk assessment | Not independently verified this session whether an EU-level Article 22 assessment has been carried out for the health/pharma supply chain specifically — flagged as a gap below |
4. Incident reporting obligations (Article 23)
This is NIS2's most distinctive and heavily cited operational feature — a strict, multi-stage reporting clock triggered by a "significant incident" (an incident is significant if it has caused or is capable of causing severe operational disruption/financial loss, or has affected/is capable of affecting other persons through considerable material or non-material damage).
| # | Requirement | Citation | Evidence of compliance | Common failure pattern |
|---|---|---|---|---|
| 22 | Early warning — within 24 hours. "Without undue delay and in any event within 24 hours of becoming aware of the significant incident," submit an early warning to the CSIRT or competent authority indicating whether the incident is suspected to be caused by unlawful/malicious acts or could have a cross-border impact | NIS2 Directive, Article 23(4)(a) | Documented, tested internal escalation procedure that can produce and submit an early warning within 24h of awareness (not of occurrence — the clock starts at detection/awareness) | Organisation measures the 24h clock from incident occurrence rather than awareness, understating true elapsed time when detection is delayed; internal escalation path from IT/SOC to whoever files the regulatory notification is undocumented or untested [inferred] |
| 23 | Incident notification — within 72 hours. Updates the early warning with an "initial assessment of the significant incident, including its severity and impact, as well as, where available, the indicators of compromise" | NIS2 Directive, Article 23(4)(b) | Documented procedure/template for the 72h notification; evidence indicators-of-compromise capture is part of standard incident-response workflow | Initial assessment produced but not treated as a discrete, timed regulatory deliverable distinct from internal incident-response documentation — teams conflate "we know what happened internally" with "we filed the formal 72h update" [inferred] |
| 24 | Final report — within 1 month. No later than one month after submission of the incident notification (or, for an ongoing incident, one month after handling concludes), submit a final report including: a detailed description of the incident (severity, impact); the type of threat/root cause likely to have triggered it; applied and ongoing mitigation measures; where applicable, the cross-border impact | NIS2 Directive, Article 23(4)(c) | Final-report template covering all four required elements; evidence of on-time submission for any real incident | Final report treated as optional or as a formality once the 72h notification is done, with root-cause analysis left incomplete a month later [inferred] |
| 25 | Trust service providers exception: must report significant incidents affecting the provision of their trust services "without undue delay and in any event within 24 hours" — the shorter, single-stage timeline (rather than the standard 72h notification stage) | NIS2 Directive, Article 23(4), TSP-specific provision | N/A for most Regscribe customers (relevant only if the entity is itself a qualified trust service provider) | — |
| 26 | Competent authority/CSIRT provides a response to the early warning "without undue delay and, where possible, within 24 hours" including initial feedback and, upon request, guidance on mitigation | NIS2 Directive, Article 23(5) | N/A (regulator-side obligation, not an entity evidence item) | — |
| 27 | Where a significant incident affects recipients of the entity's services, the entity must, where appropriate, notify those recipients "without undue delay" of the incident and of any measures/remedies they can take | NIS2 Directive, Article 23(2) | Documented customer/service-recipient notification procedure and template, distinct from the regulator-facing reporting chain | Regulator-facing reporting workflow built and tested, but no parallel process for notifying affected service recipients/customers [inferred] |
5. Penalties (Article 34)
| # | Requirement | Citation | Evidence of compliance | Common failure pattern |
|---|---|---|---|---|
| 28 | Essential entities: administrative fines up to at least €10,000,000, or 2% of total worldwide annual turnover in the preceding financial year, whichever is higher | NIS2 Directive, Article 34(4) | N/A (this is a regulatory penalty ceiling, not a company compliance artifact) | Entities under-classify themselves as "important" rather than "essential" to reduce perceived exposure, without a documented rationale for that classification decision (see rows 4–5) [inferred] |
| 29 | Important entities: administrative fines up to at least €7,000,000, or 1.4% of total worldwide annual turnover in the preceding financial year, whichever is higher | NIS2 Directive, Article 34(5) | N/A | — |
| 30 | Fines must be "effective, proportionate and dissuasive," with minimum assessment criteria set out elsewhere in the Directive (Article 32(7), per secondary source — not independently verified against EUR-Lex text this session) considered when deciding whether/how much to fine | NIS2 Directive, Article 34(1)–(3) (cross-referencing Article 32(7)) | N/A | — |
| 31 | Where a Member State's legal system doesn't provide for administrative fines, it must ensure equivalent effect is achieved through the courts, while ensuring the penalty is still effective/proportionate/dissuasive | NIS2 Directive, Article 34(9) (per secondary source characterization) | N/A — jurisdictional implementation detail | — |
Documents/evidence typically needed
Cybersecurity risk-management policy suite covering all ten Article 21(2) categories; board/management-body meeting minutes showing approval and ongoing oversight of those measures; management-body-specific training records; incident-response plan with a documented, tested 24h/72h/1-month reporting workflow tied to actual escalation paths; supply-chain/vendor risk-assessment records; vulnerability-management and disclosure procedure; cryptography/encryption policy; access-control policy and asset inventory; MFA enforcement evidence including for privileged/vendor accounts; entity classification rationale (essential vs important, sector/Annex mapping, size-threshold test); national competent-authority registration confirmation.
Pharma/biotech relevance
NIS2 is generic-economy legislation, not pharma-specific — but its Annex I explicitly and by name pulls in healthcare providers, EU reference laboratories, medicinal-product R&D entities, and basic pharmaceutical manufacturers as essential entities (the highest tier), and Annex II pulls in medical device/IVD manufacturers as important entities. This is a confirmed, not inferred, scope fact (Section 1 above). No lex specialis carve-out for pharma-sector EU law was identified this session (row 7), meaning in-scope pharma/biotech/health entities should expect full NIS2 applicability alongside their GxP obligations, not instead of them. The two tracks (GxP product-quality/patient-safety compliance vs NIS2 cybersecurity compliance) are administered separately and this rubric should not be presented as covering GxP ground already covered by Regscribe's Annex 11/Part 11/cGMP rubrics.
Common failure patterns — cross-cutting summary
All patterns below are [inferred] from the structure of the obligations and general NIS2 secondary/advisory commentary reviewed this session — no verified EU or member-state NIS2 enforcement/deficiency dataset was found or used, unlike the FDA Warning Letter or MHRA deficiency-trend data underpinning some of Regscribe's GxP rubrics:
- Board-level approval/oversight of cybersecurity risk-management measures (Article 20) treated as a rubber-stamp or absent entirely, with the real ownership sitting only in IT/security.
- The Article 23 reporting clock measured from incident occurrence rather than awareness, and/or the 24h/72h/1-month stages treated as one deliverable rather than three distinct, separately-timed regulatory submissions.
- Supply-chain security (Article 21(2)(d)) scoped only to software/IT vendors, missing direct operational suppliers (e.g. CDMOs, contract labs) that are equally "direct suppliers or service providers" under the Directive's own wording.
- MFA and access control implemented for standard accounts but not extended to privileged, legacy, or third-party/vendor remote-access accounts.
- Essential-vs-important entity classification performed once at a point in time and never re-tested against headcount/turnover growth or new size-independent triggers (Article 2(2)).
- Vulnerability disclosure policy (the outward-facing half of Article 21(2)(e)) omitted even where internal patching process is mature.
Gaps / follow-ups before this goes into production scoring
- EUR-Lex verbatim extraction not completed this session. All operative-article quotes (Articles 2–4, 20–23, 34) and Annex I/II text were sourced from two independent secondary reference sites (nis-2-directive.com, streamlex.eu) that present themselves as direct transcriptions, not from a first-party EUR-Lex HTML/PDF extraction by this agent. Recommend a follow-up session using a direct PDF fetch of
https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32022L2555(orpdftotext -layouton the Official Journal PDF, the method used successfully for the GVP rubric) to confirm word-for-word accuracy before this rubric is relied on for a legally consequential determination. - National transposition variance is real and unresolved. NIS2 required Member State transposition by 17 October 2024; the European Commission opened infringement proceedings against Germany and several other Member States for missing that deadline. Per this session's search, Germany's own NIS2UmsuCG was adopted by the Bundestag on 13 November 2025, by the Bundesrat on 21 November 2025, published 5 December 2025, and entered into force 6 December 2025 — meaning as of today (17 August 2026) Germany's national NIS2 law has been in force for roughly eight months. This was found via web search summaries, not independently verified against the Bundesgesetzblatt or an official German government source this session — confirm before citing a specific German entry-into-force date in a customer-facing context. Other Member States' transposition status was not checked this session and should not be assumed uniform — the Directive's EU-level Article 21/23 obligations bind essential/important entities regardless of transposition delay (via direct effect principles and infringement risk to the state), but the specific national supervisory authority, registration process, and any national gold-plating will vary by Member State and were not surveyed here.
- KRITIS-Dachgesetz status confirmed only at headline level. Germany's KRITIS-Dachgesetz (implementing the CER Directive, the physical-resilience sister law) reportedly entered into force 17 March 2026 with a BBK/BSI registration deadline of 17 July 2026, per this session's search — again not independently verified against a primary German government source. The companion rubric being built for KRITIS-DachG should independently verify and be the authoritative source for these dates; this document only asserts the relationship between NIS2 and CER/KRITIS-DachG, not KRITIS-DachG's own substantive requirements.
- Article 22 EU-level supply-chain risk assessments (referenced in Article 21(3)) — whether an EU-level coordinated risk assessment has actually been carried out for the health/pharmaceutical sector's critical supply chain specifically was not checked this session (row 21 above).
- No verified enforcement/penalty track record. Unlike GVP (MHRA inspection metrics) or the Annex 11 rubric (MHRA deficiency data), no actual NIS2 fine or enforcement-action dataset was located or reviewed this session — Section 5's penalty figures are the statutory ceilings from Article 34, not evidence of how they're applied in practice. Do not present the "Common failure pattern" columns above as empirically derived; they are structurally reasoned and explicitly flagged
[inferred]. - Article 4 lex specialis conclusion (row 7) is a negative finding, not a legal opinion. The statement that no pharma-specific EU cybersecurity-equivalent law was found should be treated as "absence of evidence in this session's searches," not as a definitive determination — an EU Commission implementing-guideline document on Article 4 equivalence (due per Article 4(3), by 17 July 2023) was referenced by nis-2-directive.com but not independently fetched and read this session.