NIS2 Energy Incident Response: Art. 21(2)(b) Obligations and the 24h–72h–30d Reporting Chain

On 28 April 2025, the Iberian Peninsula lost power. Around 15 GW of generation disconnected within seconds, leaving Spain, Portugal, and parts of France without electricity for up to 10 hours. ENTSO-E’s final root cause report, published in March 2026, identified systemic failures across grid operations, generation dispatch, and regulatory coordination. Twenty-two recommendations followed—most of them pointing at the same underlying gap: the absence of pre-defined, practised incident response procedures capable of operating under real-time pressure.

That gap is now a legal obligation. Under Directive (EU) 2022/2555 (“NIS2”), every essential entity in the energy sector must implement “incident handling” as one of ten mandatory cybersecurity risk-management measures under Article 21(2)(b). For electricity grid operators and gas transmission system operators (TSOs), a second regulatory layer—the EU Network Code on Cybersecurity (NCCS, Commission Regulation EU 2024/1366)—adds sector-specific obligations on top. For renewables operators, a less-discussed threshold question determines when distributed generation assets aggregate into a “significant” incident.

This guide maps each obligation by entity type, explains what the 24h–72h–30d reporting chain actually requires at each stage, and addresses the operational constraints that make energy-sector incident response fundamentally different from a standard IT playbook—particularly for OT environments running SCADA systems, RTUs, and IEC 60870-5-104 field devices that cannot host endpoint agents.

Who Must Comply: Energy Entities Under NIS2 Annex I

NIS2 Annex I lists energy as a Sector of High Criticality, placing most operators in the “essential entity” category—the more heavily regulated tier. The scope is broader than many operators initially assume.

Entity Type	NIS2 Classification	Qualifying Threshold
Electricity TSOs	Essential	All—regardless of size
Electricity DSOs	Essential	≥50 employees or >EUR 10M turnover
Electricity generation operators	Essential	≥50 employees or >EUR 10M turnover
Gas TSOs	Essential	All—regardless of size
Gas DSOs / LNG operators / storage	Essential	≥50 employees or >EUR 10M turnover
Hydrogen production, storage, transmission	Essential	≥50 employees or >EUR 10M turnover
Oil transmission pipelines and storage	Essential	≥50 employees or >EUR 10M turnover
Renewables operators (wind, solar, hydro)	Essential	≥50 employees or >EUR 10M turnover
District heating and cooling	Essential	≥50 employees or >EUR 10M turnover

TSOs at both electricity and gas level sit outside the size thresholds entirely—they are essential entities by designation, not by headcount. For every other operator, the relevant question is whether the entity clears either the 50-employee or EUR 10 million annual turnover bar. Member states may impose lower thresholds through national transposition, so check your national competent authority’s implementing guidance alongside the Directive itself.

The practical decision tree for a renewables operator: (1) Does my organisation have more than 50 employees or exceed EUR 10M turnover? If yes—NIS2 applies. (2) Do I operate electricity generation capacity that could affect grid stability across member states? If yes—the NCCS designation process may additionally apply once national authorities complete the Electricity Cybersecurity Impact Index (ECII) assessment by September 2027.

What Article 21(2)(b) Actually Requires

The Directive text for Article 21(2)(b) is deliberately brief: “incident handling.” The operational content is in Article 21(2)’s broader requirement for an “all-hazards approach” that encompasses “policies on risk analysis and information system security” applied proportionately to “the degree of the entity’s exposure to risks.” For incident handling specifically, regulatory guidance and the Commission’s implementing acts identify six mandatory operational components that any compliant incident handling policy must address.

Component	What It Means in Practice	Audit Evidence Required
Prevention	Controls that reduce incident probability: patching schedules, access controls, network segmentation	Vulnerability management log; patch cadence documentation
Detection	Monitoring capable of identifying anomalous behaviour in both IT and OT environments	SOC coverage map; OT monitoring tool inventory
Analysis	Triage and significance assessment—determining whether an event meets the Art. 23(3) threshold	Pre-defined significance criteria; triage runbook
Containment	Isolation procedures that limit blast radius without triggering grid instability or gas flow interruption	Isolation playbooks; IT–OT boundary controls documentation
Response	Coordination across IT, OT, legal, communications, and regulatory reporting functions	RACI matrix; incident communication templates; notification workflows
Recovery	Restoration procedures with documented RTOs that account for OT vendor dependency and firmware reload times	BCP integration; tested recovery runbooks; RTO documentation

The critical operational difference from a standard IT policy: energy sector incident response cannot sequence these steps the way an IT team would. Containment in a substation—isolating a compromised bay controller—may require coordinating with the grid control centre before any network action is taken, because disconnecting the wrong device can cascade into a physical supply disruption. The Art. 21(2)(b) policy must document that coordination sequence explicitly.

For gas TSOs, the equivalent constraint operates on SCADA systems controlling compressor stations and metering points. A response action that triggers an unexpected pressure drop in a high-pressure transmission line creates a physical safety event, not just a cybersecurity incident. Incident handling policies in the gas sector must include a “safety override check” gate before any containment action—and that gate must be documented for audit purposes.

The 24h–72h–30d Reporting Chain: What Each Stage Requires

Article 23 of NIS2 establishes a three-stage notification cascade for significant incidents. The word “significant” does specific legal work here: under Article 23(3), an incident qualifies when it has caused—or is capable of causing—either (a) severe operational disruption or substantial financial loss to the entity, or (b) considerable material or non-material damage to other persons.

For energy operators, the “capable of causing” framing matters enormously. A ransomware infection that has not yet disrupted gas flow but has compromised the SCADA historian server is already reportable if it is “capable of” causing supply disruption. You do not need to wait for the disruption to occur.

Stage 1: 24-Hour Early Warning

The 24-hour clock starts at the moment your organisation becomes aware of a significant incident—not at the moment you confirm root cause, not when you determine attribution, and not when your investigation is complete. “Awareness” means the point at which a responsible person in the organisation had sufficient information to recognise that the event might be significant.

The early warning must include: (1) whether the incident is suspected to involve unlawful or malicious acts; (2) whether it has or may have cross-border impact. No root cause analysis is expected at this stage. The notification is explicitly provisional—its purpose is to alert the national CSIRT or competent authority so they can prepare to assist and coordinate.

The operational constraint in energy environments: detection infrastructure must be capable of generating a significance signal within hours. An SOC that monitors only IT systems will not see an OT event. A logging and monitoring architecture that covers SCADA, DCS, and field device telemetry is a prerequisite for meeting the 24-hour window—not an optional enhancement.

Stage 2: 72-Hour Incident Notification

Within 72 hours of the initial notification (not 72 hours from awareness), entities must provide a substantive update covering: severity assessment; indicators of compromise; the systems, services, and geographic regions affected; an estimated number of users impacted; and initial containment measures taken. For electricity operators, “geographic regions affected” should be interpreted to include cross-border electricity flows—this field becomes the trigger for NCCS parallel coordination (see the NCCS section below).

The 72-hour notification is where most energy operators encounter their first documentation crisis. The report must describe “the affected systems” in enough detail that the competent authority can assess criticality—but many energy OT environments lack the asset inventory that would allow this description to be generated quickly. A real-time OT asset inventory is not a nice-to-have; it is part of the pre-incident preparation that makes Art. 23 compliance operationally possible.

Stage 3: 30-Day Final Report

One month after the initial notification, or one month after resolution if the incident is ongoing, entities must submit a final report containing: the confirmed root cause; a description of the cyber threat or technical circumstances that caused the incident; the mitigation measures taken; and the actual or estimated cross-border impact. The final report is the document that will form the basis of any supervisory review under Article 32 or 33.

For energy operators, the final report should document not just what happened in IT systems, but the OT impact chain: which SCADA process was affected, what the physical consequence risk was, how the IT–OT boundary controls performed, and whether the incident revealed gaps in the Art. 21(2)(b) policy that have since been remediated. Our NIS2 incident response playbook guide maps this six-phase reporting sequence in detail.

The NCCS Overlay: When Electricity Operators Report Twice

Electricity entities designated as high-impact or critical-impact under Commission Regulation (EU) 2024/1366—the Network Code on Cybersecurity (NCCS)—face a second reporting layer that gas, oil, and renewables operators currently do not. The NCCS, developed under the coordination of ENTSO-E and the EU DSO Entity, establishes binding sector-specific cybersecurity rules for the EU electricity sector, building on NIS2 as its foundation.

The good news: Article 38 of the NCCS provides that if a significant incident is reported under NIS2 Article 23 and the notification includes the relevant cross-border impact information, that single filing satisfies the NCCS reporting obligation as well. The two regimes are not fully separate processes—they converge at the cross-border impact field of the NIS2 notification.

The practical implication: electricity TSOs and high-impact DSOs must ensure their Art. 23 notifications explicitly assess potential impact on cross-border electricity flows. A notification that describes the incident in IT terms alone—without reference to generation capacity affected, interconnector exposure, or balancing market participation—does not trigger the NCCS convergence and may leave the entity with an unfulfilled NCCS obligation.

ECII Designation and What Triggers NCCS Coverage

The Electricity Cybersecurity Impact Index (ECII) determines which electricity entities are designated as high-impact or critical-impact under the NCCS. The index measures potential disruption severity to cross-border electricity flows. National authorities are completing designation processes; provisional thresholds give a sense of the scale involved.

Member State	High-Impact Threshold	Critical-Impact Threshold
Germany	≥1,500 MW	≥3,000 MW
France	≥1,500 MW	≥3,000 MW
Austria	≥500 MW	≥3,000 MW

The Cyber-Attack Classification Scale Methodology (CACS), developed under NCCS Article 37(8), provides the decision framework for assessing whether a specific cyber-attack affecting an electricity operator is reportable under the NCCS. The methodology evaluates two dimensions: potential impact on cross-border electricity flows (determined by asset type and affected capacity) and attacker position in the attack chain. Entities should apply the CACS pre-assessment before an incident occurs—not in the middle of a 24-hour notification window.

Final entity designations under NCCS are due by September 2027. Compliance with the NCCS’s technical measures is required 24 months after those controls are formally adopted. However, incident reporting obligations and the CACS pre-assessment requirement apply from the point of designation—meaning the classification exercise and reporting preparation must happen well before the full compliance deadline.

OT Forensics Constraints: Why the 24-Hour Window Changes Everything

Thirty-two percent of energy sector operators have no critical OT process monitored by a security operations centre. For those organisations, a cyber-attack on a SCADA system may go undetected entirely until it manifests as a physical operational anomaly—a pressure drop, a frequency deviation, a breaker trip that does not match any scheduled maintenance event. By the time that anomaly is recognised as a cybersecurity event, the 24-hour early warning clock may already be running short.

The forensics challenge in OT environments compounds this problem. Standard IT incident response assumes that evidence collection—memory dumps, log exports, network packet captures—can happen on the affected system while it remains online. In an OT environment, that assumption breaks down across several dimensions.

You cannot install agents on most field devices. PLCs, RTUs, and distributed control system components cannot run endpoint detection and response (EDR) tools. The investigation of what occurred on those devices depends on passive network monitoring—capture of traffic between field devices and the control layer, preserved via a network tap or a monitoring tool that records IEC 60870-5-104 or IEC 61850 message exchanges. If passive monitoring was not in place before the incident, the forensic record may not exist.

Containment actions have physical consequences. In IT incident response, network isolation is the standard first containment step. In an OT environment, isolating a control network segment may remove operator visibility into a live physical process. For a substation, that means loss of real-time breaker status. For a gas compressor station, it means losing SCADA oversight of pressure control. The network security architecture for energy OT must define isolation boundaries in advance—documented in the Art. 21(2)(b) incident handling policy—so that containment decisions can be made without creating new safety risks.

Recovery timelines are longer. Restoring a compromised PLC involves more than re-imaging a virtual machine. It may require vendor-specific firmware reload procedures, factory acceptance testing, and coordination with the grid control centre before the device can return to service. OT recovery time objectives (RTOs) in the Art. 21(2)(c) business continuity documentation must reflect these vendor-dependency realities, not the RTO figures borrowed from IT systems.

The SANS Five ICS Critical Controls provide a practical framework for addressing these constraints: ICS-specific incident response, defensible control system network architecture, network visibility and monitoring, secure remote access governance, and risk-based vulnerability management. The first control—ICS-specific IR—is the operative requirement under Art. 21(2)(b). The remaining four determine whether the IR plan can be executed. See also our six-phase NIS2 IR playbook for the specific OT runbook structure that satisfies the Art. 23 documentation requirement.

Entity-Type Differences: Grid Operators, Gas TSOs, and Renewables

NIS2 applies a single incident response framework across all energy entities, but the operational context—and therefore the implementation detail—differs significantly by entity type.

Electricity TSOs and high-impact DSOs face the most complex compliance picture. They carry both NIS2 Art. 21(2)(b) obligations and the NCCS overlay, must apply the CACS pre-assessment methodology, and must maintain a reporting workflow capable of generating the cross-border impact field of an Art. 23 notification in real time. Given the grid topology, a TSO-level cybersecurity event at a major balancing node has potential cross-border consequences by definition—the NCCS notification trigger is a near-automatic result.

Gas TSOs and DSOs sit firmly within NIS2’s essential entity scope but outside the NCCS (which is an electricity-sector instrument). The equivalent coordination mechanism for gas is less formalised: ENTSO-G (the European Network of Transmission System Operators for Gas) and the Gas Coordination Group at EU level handle emergency coordination, but the regulatory instrument for gas-sector-specific cybersecurity incident reporting remains NIS2 Article 23 alone. Gas operators should not assume that a single NIS2 notification to the national CSIRT is sufficient if the incident affects cross-border gas flows—the competent authority will likely activate bilateral coordination mechanisms under existing gas security of supply regulations in parallel.

Renewables operators face a threshold question that is underappreciated in most compliance guidance. A single 10 MW wind farm is unlikely to meet the “severe operational disruption” threshold on its own if compromised. But a cyber-attack targeting the inverter control software used across a generation fleet—the kind of supply-chain attack targeting remote inverter management at scale—can aggregate individual assets into a significance event that involves hundreds of MW of generation. The significance determination for renewables must consider not just the capacity of the affected entity but the potential cascade if the same vulnerability exists across a class of assets. The Art. 21(2)(d) supply chain security requirement is directly relevant here: inverter firmware supply chain integrity is an incident handling precondition, not a separate concern.

Management Body Accountability Under Article 20

Article 20 of NIS2 makes incident response a board-level governance obligation, not an IT department discretionary function. Management bodies of essential entities—boards of directors, executive management committees, supervisory boards—must approve the cybersecurity risk-management measures adopted under Article 21, oversee their implementation, and—critically—can be held personally liable for infringements resulting from inadequate oversight.

For energy operators, this creates two practical obligations. First, the Art. 21(2)(b) incident handling policy must be formally approved by the management body—a board resolution or equivalent documented approval, not simply sign-off by the CISO. Second, when a significant incident occurs, the management body must be kept informed in near-real time: the reporting chain during an active incident must include a board-level notification pathway, not just technical teams and regulators.

The personal liability dimension is not hypothetical. National competent authorities are empowered under Article 32 to impose temporary bans on management body members if essential entities repeatedly fail to remediate compliance deficiencies. An incident handled without proper documentation—missing the 24-hour early warning, submitting an incomplete 72-hour notification, or failing to produce a 30-day final report—creates an enforcement record that can be used to establish a pattern of non-compliance and activate these personal liability provisions.

The maximum penalty for essential entities is EUR 10 million or 2% of global annual turnover, whichever is higher. For large electricity TSOs, 2% of global turnover substantially exceeds EUR 10 million. The penalty calculation is per infringement—a missed 24-hour notification and a deficient 72-hour notification are two separate events.

Incident Response Compliance Checklist for Energy Operators

Run this against your current incident response posture before you receive a supervisory inquiry—not after.

Requirement	Legal Basis	Status Check
Incident handling policy documented, covering all six components	Art. 21(2)(b)	Policy approved by management body? Board resolution on file?
Significance criteria pre-defined in writing	Art. 23(3)	Does the criteria document cover both IT and OT events? Is it accessible during an incident?
OT monitoring coverage verified	Art. 21(2)(b) detection component	Do SIEM/monitoring tools ingest OT network telemetry? ICS-specific tools deployed?
24-hour notification workflow operational	Art. 23(1)	Who sends the notification? What template do they use? Has it been tested?
72-hour report template ready	Art. 23(1)	Does it include cross-border impact field? Asset inventory available to populate “affected systems”?
OT-specific containment playbook documented	Art. 21(2)(b) containment component	Are isolation boundaries defined? Safety override check gate included?
NCCS CACS pre-assessment completed (electricity operators only)	NCCS Art. 37(8), EU 2024/1366	Has entity applied the classification scale to its critical processes? Is cross-border impact trigger documented?
OT RTO documentation reflects vendor recovery timelines	Art. 21(2)(c)	Does BCP cover field device firmware reload? Vendor coordination procedures on file?
Management body briefed on incident response governance	Art. 20	Board-level notification pathway in the IR plan? Training completed for management body members?

Key Takeaways

• Art. 21(2)(b) requires six documented components: prevention, detection, analysis, containment, response, and recovery—all adapted for OT environments where containment has physical safety consequences.
• The 24-hour early warning clock starts at awareness, not confirmation. Pre-defined significance criteria are a prerequisite, not a post-incident document.
• Electricity TSOs and high-impact DSOs carry a dual-filing obligation: NIS2 Art. 23 plus NCCS. A single notification satisfies both if the cross-border impact field is completed (NCCS Art. 38).
• Gas operators are outside the NCCS but not outside NIS2. Cross-border gas flow incidents will trigger bilateral authority coordination in parallel with Art. 23 notification.
• Renewables operators must assess significance at fleet level, not asset level—supply-chain attacks on inverter software can aggregate distributed capacity into a reportable event.
• Management bodies are personally accountable for approving the Art. 21(2)(b) policy and maintaining an active reporting pathway during incidents.

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

• Directive (EU) 2022/2555, Article 21 — Cybersecurity risk-management measures
• Directive (EU) 2022/2555, Article 23 — Reporting obligations
• EU Network Code on Cybersecurity (Commission Regulation EU 2024/1366) — OpenKRITIS
• Network Code on Cybersecurity — ENTSO-E official page
• NIS2 Compliance for OT: Strategic Implementation of ICS Controls — SANS Institute
• What NIS2 Means for Substation and SCADA Security — Wirtek