What the Commission’s January 2026 NIS2 Proposal Changes for Your Compliance Programme — and What It Doesn’t - NIS2-Templates.com — NIS2 Compliance Templates for EU Organisations

On 20 January 2026, the European Commission published COM(2026) 13 — a proposal to amend the NIS2 Directive in ways that will simplify compliance for some organisations, expand scope for others, and begin a multi-year path toward technical harmonisation across member states. It arrived at an uncomfortable moment: 22 of 27 member states had already transposed NIS2 [6], first enforcement actions were expected within months, and compliance officers running live programmes suddenly needed to know whether their existing work was still valid.

The short answer is yes — with important context. COM(2026) 13 is a proposal, not law. The timeline to binding national implementation is at minimum two to three years. But the changes in scope, the technical harmonisation framework, and new requirements around ransomware reporting will eventually reach every in-scope organisation. Understanding what changes, what stays the same, and when is what determines how you plan.

This guide maps every material change in COM(2026) 13 against your current Article 21 obligations, so you can separate the immediate enforcement picture from the medium-term reform horizon.

What the Commission Proposed — and Why Now

The January 2026 package is not the first set of NIS2 adjustments. The Digital Omnibus Package, published in November 2025, introduced an initial wave of technical changes. COM(2026) 13 builds on those, targeting three stated objectives: simplifying jurisdictional rules, harmonising technical security measures across member states, and aligning NIS2 with the proposed Cybersecurity Act 2 — which introduces an organisation-level certification scheme [1][2].

Free Download

Get the NIS2 Article 21 Compliance Checklist

90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.

Two pressures created the opening for reform. First, member states were interpreting Article 21’s risk-management obligations differently, generating fragmented compliance requirements for multinationals. Second, the Cybersecurity Act 2 proposal created a natural hook: if EU-wide certification schemes exist, it makes sense to embed compliance-by-certification into NIS2 simultaneously.

What the proposal is not: a fundamental rewrite. The Commission’s own framing describes “targeted amendments” and “simplification measures.” The core risk-management framework, the two-tier entity system, and the incident reporting architecture all remain in their current form. For organisations already running NIS2 programmes, this framing matters most.

Scope Changes: Who Enters, Who Exits, and Who Gets Reclassified

The proposal makes three categories of scope change: additions to the essential entity list, removals from existing sectors, and a threshold shift that reclassifies thousands of currently in-scope entities. The details vary significantly by sector, so check each category against your own entity type [1].

Scope additions — two new essential entity types:

COM(2026) 13 adds operators of submarine data transmission infrastructure as essential entities, classified as such regardless of size. The definition covers landing stations and the terrestrial fronthaul between beach manholes and landing stations, capturing non-public network operators, technology companies owning cable routes for internal capacity, and consortium members operating fibre pairs on shared cable systems [7]. The Commission cited growing geopolitical and cyber-related risks to undersea communications infrastructure as the rationale.

Providers of European Digital Identity Wallets and European Business Wallets are also designated essential entities regardless of organisational size [1]. This follows directly from the EU’s expanding digital identity framework and the eIDAS 2 rollout.

Scope removals — three sectors narrowed:

Chemical sector: Scope is narrowed from “manufacture, production and distribution” to manufacture and production only. Distribution activities are removed. Manufacturers subject to REACH obligations remain fully in scope [4].
DNS providers: Micro and small-sized DNS providers exit mandatory scope. Only DNS providers meeting standard NIS2 size thresholds — 50+ employees or €10M+ annual turnover — remain covered [5].
Power generation: A new 1 MW floor excludes very small generators, including most residential solar PV installations and small commercial systems [1].

Reclassification: the small mid-cap threshold shift

The most consequential change for existing compliance programmes is the new “small mid-cap” category. Currently, entities with 50+ employees or €10M+ annual turnover qualify for essential or important status depending on sector. COM(2026) 13 introduces a new upper threshold: only entities with 750+ employees or €150M+ annual turnover (or €129M+ balance sheet) can be classified as essential entities. Entities below this threshold can be classified as important entities at most — meaning ex-post, reactive supervision rather than proactive ex-ante audits [4].

Size	Current Status	Proposed Status (if adopted)
< 50 employees / < €10M turnover	Likely out of scope	No change
50–749 employees / €10M–€149M turnover	Essential or Important (sector-dependent)	Important entity only (maximum)
750+ employees / €150M+ turnover	Essential	Essential (unchanged)

The Commission estimates approximately 22,500 entities would shift from proactive ex-ante to reactive ex-post supervision as a result [4]. That is a meaningful reduction in supervisory intensity — but not a reduction in Article 21 obligations. Both essential and important entities must implement the same 10 security-domain measures. The difference is how and when a competent authority comes calling.

Critical timing note: None of these reclassifications take effect until member states transpose the amended directive — at minimum 2027 or 2028. If your organisation is currently registered as an essential entity, your current national law governs your current obligations. You cannot reduce your compliance programme on the basis of this proposal.

Technical Harmonisation: What It Means for Your Article 21 Documentation

This is where COM(2026) 13 has the most direct long-term impact on compliance programmes already underway.

Article 21 of Directive (EU) 2022/2555 requires entities to implement “appropriate and proportionate” technical, operational, and organisational measures across 10 security domains [8]. The directive specifies the domains but leaves precise technical requirements to member states and sector-specific national guidance. The result: an organisation operating across four EU jurisdictions can face four different interpretations of what the same Article 21(2)(e) requirement means in practice.

The proposed amendment gives the Commission authority to adopt implementing acts setting specific technical and methodological requirements for Article 21 measures. Once such an act is adopted for a given requirement, member states cannot impose additional technical, methodological, or sector-specific obligations on top of it [3][5]. For multinationals, this creates what practitioners describe as a more portable, EU-recognised evidence pack, reducing the need to tailor documentation to each member state’s preferences.

There is also a new certification pathway. Entities that obtain a “cyber-posture certificate” under a European cybersecurity certification scheme — where that scheme covers specific Article 21 requirements — cannot be required to undergo additional security audits for those requirements [1][3]. Certification does not eliminate ongoing compliance responsibility, but it substantially limits the audit burden for requirements covered by a valid certificate.

What this means for documentation you have already built: implementing acts do not yet exist and will not emerge until after the directive is adopted and transposed — at earliest 2028. Until then, national guidance and existing interpretations remain the compliance standard. The core Article 21(2)(a)–(j) domains themselves are not changing. Your risk assessment methodology, incident procedures, business continuity plans, supply chain security documentation, and cryptography policies address stable obligations that persist identically under the amended directive [8]. When implementing acts eventually arrive, your existing documentation provides the foundation — not something to replace, but something to align with new EU-wide specifications.

New Requirements: Ransomware Reporting, Post-Quantum Cryptography, and ENISA

Beyond scope and harmonisation, COM(2026) 13 introduces three new or enhanced obligations worth adding to your programme roadmap.

Ransomware reporting — standardised disclosure on request: Significant incidents linked to ransomware now require additional standardised information. Upon initial reporting (within existing Art.23 timelines, which are unchanged): whether an attack was detected, the attack vector used, and mitigation measures implemented. On competent authority request: whether a ransom demand was received, whether it was paid, the amount, the payment method, the recipient, and any cryptocurrency involvement [1][5].

This is an addition to existing Article 23 incident reporting, not a replacement. The 24-hour early warning and 72-hour update timelines are unchanged. The proposal explicitly states that ransomware disclosure “should not trigger additional obligations or increased liability” toward the competent authority [4]. However, organisations should separately assess the intersection with GDPR, applicable sanctions regimes, and anti-money laundering requirements before any payment decision — those frameworks are unaffected by this proposal.

Post-quantum cryptography — member-state policy obligation: Member states must include post-quantum cryptography (PQC) migration policies in their national cybersecurity strategies, with target completion dates of 2030 for critical use cases and 2035 for medium and low-risk systems [1][3]. This is a state-level obligation, not a direct entity requirement under Article 21 today. Once national strategies formalise PQC migration timelines, they will feed into implementing acts governing Article 21(2)(h) (cryptography policies). Organisations whose cryptography policy does not yet address PQC transition planning should add a forward-looking section before national requirements crystallise.

ENISA’s expanded role: ENISA receives a reinforced cross-border coordination mandate, specifically to conduct cybersecurity risk analysis of multi-member-state entities within 15 months of directive transposition, recommend joint examination teams for high-risk entities, and assist mutual assistance and joint supervisory actions [1]. For organisations with operations across three or more member states, this creates the foundation for coherent cross-border supervision — though ENISA remains a coordinator, not a direct enforcement authority.

What the Proposal Does Not Change

Given the volume of commentary on the January amendments, it is worth being explicit about what COM(2026) 13 leaves intact. This is where most current compliance work stays directly applicable.

The Article 21 risk-management framework is unchanged. All 10 security domains — (a) risk analysis and security policies, (b) incident handling, (c) business continuity, (d) supply chain security, (e) secure acquisition and development, (f) effectiveness assessment, (g) cyber hygiene and training, (h) cryptography, (i) HR security and access control, and (j) multi-factor authentication — remain in force exactly as drafted [8]. No proposed amendment modifies the substance of these obligations.

Incident reporting stays at national level. Despite pressure for a GDPR-style one-stop-shop, the proposal does not introduce one. Significant incidents still trigger reporting to your national competent authority. Organisations operating across multiple member states maintain separate reporting relationships with each [3].

Article 20 management accountability is unchanged. The personal accountability of management body members for approving and overseeing cybersecurity risk-management measures remains in full force. Boards that have adopted and documented NIS2 governance arrangements face no new obligations from this proposal — only the existing ones.

Penalty exposure is unchanged. Article 34 maximum fines — €10M or 2% of global annual turnover for essential entities; €7M or 1.4% for important entities, whichever is higher — remain as specified in the current directive. The proposal does not modify penalty thresholds.

The essential/important two-tier system persists. The small mid-cap threshold changes who falls into which tier, not the structure of the tiers. Essential entities retain ex-ante proactive oversight; important entities retain ex-post reactive oversight.

Implementation Timeline and What to Do Now

Milestone	Expected Timing	Compliance Relevance
COM(2026) 13 proposal published	20 January 2026 ✅	Legislative process begins; proposal may be modified
European Parliament & Council negotiations	Throughout 2026	Text subject to change; monitor for scope amendments
Directive adopted (best case)	Late 2026 – 2027	Member state transposition clock starts
National laws in force	2027 – 2028	New scope and thresholds bind entities
Commission implementing acts (technical measures)	Post-transposition	Art.21 harmonisation standards become binding
ENISA cross-border risk assessment	15 months post-transposition	Multi-jurisdiction entities first assessed under new framework

The practical answer to “do I need to redo my NIS2 documentation?” is no. Your existing documentation addresses real, stable Article 21 obligations that the proposal does not touch. When implementing acts are eventually adopted for specific domains, some policies may need to align with EU-wide technical specifications — targeted updates, not a rebuild.

The more urgent question for 2026 is enforcement under the current directive. With 22 member states having transposed NIS2 and the first enforcement actions expected this year [6], a programme built around Directive (EU) 2022/2555 as it stands today is what protects your organisation now. Visit the NIS2 scope page to verify your current entity classification, and review the Article 21 requirements overview to ensure your programme covers all 10 security domains before competent authority engagement begins. If you have questions about how the proposal affects your sector, the ENISA technical guidance summary provides the most current implementation context alongside the official directive text.

Frequently Asked Questions

Does COM(2026) 13 affect my NIS2 registration deadline?
No. Registration obligations under your current transposed national law are unchanged. The proposal must complete the legislative procedure and be transposed before any registration requirements change.

If our organisation would fall under the new small mid-cap threshold, should we stop investing in compliance?
No. The proposal is not law, and your existing classification governs your current obligations. Even if the proposal passes as drafted, reclassification from essential to important reduces supervisory intensity — not Article 21 documentation obligations, which apply equally to both tiers.

Does ISO 27001 certification satisfy the proposed cyber-posture certificate requirement?
Not directly. ISO 27001 is not a European cybersecurity certification scheme under the Cybersecurity Act. A distinct EU certification scheme would need to be established and recognised as covering specific Article 21 requirements before it can substitute for supervisory audits. ISO 27001 documentation remains useful as the underlying evidence base for any future certification.

What should we do now about post-quantum cryptography?
Add a forward-looking section to your cryptography policy acknowledging the proposed PQC migration timeline (2030 for critical systems, 2035 for medium and low-risk) and commit to a cryptographic asset inventory review before implementing acts formalise these requirements. No specific technical migration is required today under current NIS2 obligations.

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.