Article 40: Review

Article 40 exists to keep NIS 2 current. The European Commission must review how the Directive is working by 17 October 2027 and every 36 months after that, then report to the European Parliament and Council, including reassessing whether the size thresholds and the Annex I/II sector coverage remain appropriate for cybersecurity and societal/economic resilience. (Directive (EU) 2022/2555, Article 40)

For a Compliance Officer, CCO, or GRC lead, the operational question is: “How do I prevent a future Commission review (and the follow-on changes in national law and supervisory expectations) from surprising my program?” The practical answer is governance. You need a lightweight but strict regulatory change management process that continuously (1) monitors authoritative NIS 2 developments, (2) updates an obligation register and applicability rationale, (3) drives control and procedure changes through owners, and (4) preserves evidence that you made timely, risk-based decisions.

This requirement page focuses on execution: who owns what, what artifacts to keep, how auditors typically probe “review-readiness,” and how to turn future changes into controlled updates rather than fire drills. It also highlights two areas that frequently become exam focal points even when policy is “done”: incident reporting workflows and third-party dependency governance.

Regulatory text

What the law says (operator-relevant excerpt): The Commission must review the functioning of NIS 2 by 17 October 2027 and every 36 months thereafter, reporting to the European Parliament and Council, and assessing the relevance of entity size and the sectors/subsectors/types of entities in Annexes I and II for cybersecurity and the functioning of the economy and society. (Directive (EU) 2022/2555, Article 40)

What this means for you (practical interpretation):

• Article 40 signals that scope and expectations can change. Even if your current NIS 2 implementation is solid, the Commission’s review and report can drive amendments, reinterpretation, or new priorities through EU and Member State channels. (Directive (EU) 2022/2555, Article 40)
• Your operational obligation is indirect but real: maintain a change management mechanism so you can absorb and implement updates fast, prove you tracked them, and show that management understood the impact.

Plain-English interpretation of the requirement

Article 40 is a “forced refresh” clause. The EU is committing to re-check whether NIS 2 is working and whether the current scoping rules (especially entity size and sector coverage) still fit reality. (Directive (EU) 2022/2555, Article 40)

For your program, that translates into three concrete expectations:

1. No set-and-forget compliance. You need ongoing monitoring for updates that affect NIS 2 applicability, obligations, or supervisory practice.
2. Defensible scope decisions. If you are “in scope,” you must show why; if you think you are “out of scope,” you must show why, and revisit that decision when assumptions change.
3. Operational readiness beats policy completion. Supervisors test whether incident and third-party controls work in practice, and whether evidence exists at the moment they ask.

Who it applies to (entity and operational context)

Article 40 is a duty on the European Commission, but it affects:

• Essential and important entities implementing NIS 2 controls across one or more EU jurisdictions, because future reviews can alter scoping and expectations that flow into national law and supervisory activity. (Directive (EU) 2022/2555, Article 40)
• Multinational organizations with mixed footprints (EU subsidiaries, EU-facing services, EU critical operations) where applicability depends on entity size, sector classification, and local transposition.
• GRC and compliance functions that must coordinate legal interpretation, control ownership, and evidence readiness across security, IT operations, procurement/TPRM, and incident response.

Operationally, the requirement matters most when you have any of the following:

• Growth, M&A, or restructuring that could change “size” status or sector classification.
• Heavy reliance on critical third parties (cloud, MSPs, OT suppliers, telecom, software supply chain).
• Distributed incident detection/response across regions, which complicates consistent reporting triggers and recordkeeping.

What you actually need to do (step-by-step)

The goal is “review-proofing” your NIS 2 program: you can quickly incorporate changes prompted by Article 40 review outputs and related national updates.

Step 1: Assign ownership and cadence for NIS 2 regulatory change intake

• Owner: Compliance/GRC (primary), with Legal and CISO as required reviewers.
• Define intake sources: EUR-Lex NIS 2 text and updates, Commission publications related to NIS 2 functioning, and Member State transposition updates as they are published. (Directive (EU) 2022/2555; Directive (EU) 2022/2555, Article 40)
• Define what triggers action: changes to scope criteria, sector classification, reporting expectations, or supervisory guidance.

Deliverable: a short “NIS 2 Regulatory Change SOP” that says who monitors, who triages, and how decisions get documented.

Step 2: Maintain a NIS 2 obligation register with applicability notes

This is your central artifact for operationalizing Article 40’s change pressure.

Minimum fields:

• Jurisdiction / legal entity / business line
• In-scope determination and written rationale
• Applicable NIS 2 obligations (by article/topic)
• Control owner and implementation status
• Known dependencies (critical systems, critical third parties)
• Review history (what changed, when, why, who approved)

This aligns with the practical control expectation to “Maintain a NIS 2 obligation register with jurisdictional applicability notes, control owners, and implementation milestones.”

Step 3: Map obligations to controls and “what changes when scope changes”

Build a mapping that lets you answer: “If we become in scope in Country X, what must be switched on?”

Include:

• Control library mapping: ISO 27001/27002, NIST CSF, or internal control framework crosswalk.
• Delta controls: what is additional for NIS 2 (for example, incident notification workflow rigor, third-party dependency governance evidence).
• Control operation evidence: where proof comes from (ticketing system, SIEM logs, IR tooling, procurement systems).

Step 4: Operationalize two high-friction areas: incidents and third parties

Article 40 itself is not about incident response, but it increases scrutiny over whether NIS 2 is functioning. These domains frequently expose “paper compliance.”

1. Incident triage, escalation, and reporting workflow

• Define triage criteria, decision rights, and escalation path.
• Write timing triggers and evidence retention rules into the workflow documentation.
• Run tabletop tests and keep outputs.

This aligns with the practical control expectation to “Codify incident triage, escalation, and reporting workflows with timing triggers and evidence retention requirements.”

2. Critical third-party dependency governance

• Maintain an inventory of critical third parties tied to essential services.
• Build a consistent risk assessment method and remediation tracking.
• Require assurance artifacts (contract terms, security attestations, performance reporting) and track exceptions.

This aligns with the practical control expectation to “Integrate critical third-party dependencies into risk assessments, remediation tracking, and assurance activities.”

Step 5: Prove you can absorb change fast

Create a “change pack” template:

• What changed (source, date)
• Applicability impact assessment
• Obligations/control deltas
• Implementation plan and owners
• Management sign-off
• Evidence plan (what will be produced, where it will be stored)

If you use Daydream, make it the system of record for the obligation register, ownership, milestones, and evidence pointers, so you can answer “what changed and what did you do about it?” without rebuilding history.

Required evidence and artifacts to retain

Keep these artifacts in a controlled repository with retention aligned to your broader compliance record policy:

Governance and scope

• NIS 2 applicability memos per jurisdiction/entity, including size/sector rationale and approval record.
• Obligation register with control owners and change history.
• Regulatory change intake log (source, triage notes, decision, actions).

Controls and operations

• Incident response runbooks: triage decision tree, escalation matrix, communications templates, and evidence capture checklist.
• Incident tabletop/exercise records and remediation tickets.
• Third-party inventory identifying critical dependencies.
• Third-party risk assessments, exception approvals, and remediation tracking.
• Contracts/SOWs with security requirements and notification clauses (where applicable to your program).

Assurance

• Internal audit or second-line testing plans and results for incident workflow execution and third-party risk governance.
• Management reporting packs showing open risks and remediation status.

Common exam/audit questions and hangups

Expect questions that test whether “review readiness” is real:

1. “Show your current NIS 2 scope and why.” Auditors look for a documented rationale, not oral explanations.
2. “How do you learn about regulatory changes and decide what to do?” Weakness: no defined intake, no decisions recorded.
3. “Demonstrate incident reporting readiness.” They often ask for evidence of a recent drill or a real incident record with timestamps and approvals.
4. “Which third parties are critical, and how do you know their risk is managed?” Hangup: inventory exists, but it is not linked to essential services and remediation.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating Article 40 as “nothing to do”	The review drives scope/exam changes; you get caught flat-footed	Build regulatory change intake + obligation register change control
No written applicability rationale	Scope decisions look arbitrary	Write a one-page memo per jurisdiction/entity and re-approve on change
Incident workflow exists but isn’t testable	No evidence of execution	Run exercises, store outputs, track remediation tickets
Third-party risk is decoupled from “critical services”	You can’t show operational dependency governance	Tie critical third parties to services, systems, and impact assessments
Evidence scattered across tools	Slow exam response, inconsistent truth	Central evidence index with pointers and owners (Daydream can host this)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for Article 40. Practically, the risk is indirect: if you miss a scope change or fail to incorporate new expectations after the Commission’s review and follow-on actions, you create gaps that surface during national supervisory exams or after a major incident.

The business impact usually shows up as:

• delayed remediation under supervisory pressure,
• inconsistent obligations across EU entities,
• inability to evidence timely decision-making.

A practical 30/60/90-day execution plan

Because this page cannot introduce uncited timing obligations, treat these as implementation phases you can run in parallel with existing NIS 2 work.

First phase (Immediate): Stand up governance and a single source of truth

• Appoint owners for NIS 2 regulatory intake, scope decisions, and evidence management.
• Create or clean up the NIS 2 obligation register (entity, jurisdiction, owner, status, evidence pointers).
• Draft scope/applicability memos for each EU entity and get approvals.

Second phase (Near-term): Make incident and third-party areas exam-ready

• Publish incident triage/escalation workflow with clear decision rights and evidence checklist.
• Inventory critical third parties and map them to essential services/systems.
• Define remediation tracking for third-party findings, including exception governance.

Third phase (Ongoing): Prove operational performance and change absorption

• Run an incident reporting tabletop exercise and close findings.
• Test a sample of critical third-party files for completeness (risk assessment, contract terms, assurance, remediation).
• Run a “regulatory change simulation”: take a hypothetical scope change and execute your change pack end-to-end.

Frequently Asked Questions

Does Article 40 create a direct obligation on my company?

Article 40 assigns the review obligation to the European Commission. Your operational responsibility is to be ready for the changes that review can trigger, and to manage NIS 2 applicability and obligations as they evolve. (Directive (EU) 2022/2555, Article 40)

What should I track to be “Article 40-ready”?

Track authoritative NIS 2 updates and outputs tied to how the Directive is functioning, then document your applicability decisions and resulting control changes. Keep the obligation register current and preserve decision records. (Directive (EU) 2022/2555, Article 40)

How do I document “size/sector applicability” without over-lawyering it?

Use a short memo template: entity facts, sector mapping to Annex I/II logic, assumptions, and an approval signature. Store it next to your obligation register entry so auditors can follow the trail.

What evidence will auditors expect even though Article 40 is an EU-level review?

They will still expect your NIS 2 program to have change management, clear scope rationale, and working operational controls. Incident handling records and critical third-party governance artifacts are the fastest way to prove maturity.

We operate in multiple EU countries. Do we need separate obligation registers?

You need one consistent register with jurisdiction-specific applicability notes and control ownership. Separate registers often drift and create conflicting answers during exams.

Where does Daydream fit without turning this into a tool project?

Use Daydream as the system of record for your NIS 2 obligation register, control ownership, milestones, and an evidence index. That gives you fast answers during exams and a clean change history when scope or expectations shift.