BLOG

NIS2 Incident Reporting for OT: Running the 24-Hour Clock on a Live Plant

The Article 23 timeline is not complicated to describe. An early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, a final report within one month of that notification, and an intermediate report if the incident is still running when the month is up. Reports go to the designated CSIRT or competent authority in each member state where you provide services.

Describing it is easy. Running it on a petrochemical site at 2am during a shift handover is not, and that is the part most compliance documentation skips. This article is about the operational mechanics rather than the timeline, because the timeline is not where industrial operators fail. Our NIS2 compliance playbook for OT and ICS covers the full obligation set.

What counts as significant, and why OT makes it harder

An incident is significant if it has caused or is capable of causing severe operational disruption of services or financial loss, or has affected or is capable of affecting other persons through material or non-material damage. The test is disjunctive, so meeting one limb is enough, and the phrase "capable of causing" does a great deal of work.

In OT that phrase is genuinely difficult. Malware found on an engineering workstation that has access to a safety instrumented system is capable of causing severe disruption even if nothing happened. A loss of view in a control room is capable of causing disruption even when the process stays within limits. Judged strictly, a number of events that an operations team would close out as near misses are reportable, and that judgment has to be made inside 24 hours by someone with the authority to make it.

Write the threshold down before you need it

The decision that an event is not significant is the one you will have to defend. Document your criteria in advance, with worked OT examples: malware on an engineering workstation, unexplained PLC logic change, loss of view beyond a stated duration, remote access session you cannot account for. A written threshold applied consistently is defensible. A judgment made at 2am under pressure, with no prior criteria, is not.

The three filings, and what each actually needs

Stage	Deadline	What it needs from you
Early warning	24 hours from awareness	Whether unlawful or malicious acts are suspected, and whether there is cross-border impact. Deliberately minimal. You are not expected to understand the incident yet.
Notification	72 hours from awareness	Updated information, an initial assessment of severity and impact, and indicators of compromise where you have them.
Final report	One month from the notification	Detailed description, threat type and root cause, mitigations applied and ongoing, confirmed cross-border impact.

The early warning is the one teams over-prepare. It asks very little. Two questions and an identification. Operators who delay it while they investigate have misread the obligation, because the whole point of a 24 hour early warning is that it comes before understanding.

Where industrial operators actually struggle

Awareness has no defined moment. A control room operator notices something odd at 11pm, mentions it at handover, and it reaches the security team at 10am. When did the clock start? Define awareness in your procedure or an authority will define it for you, and they will pick the earlier moment.
The people who can confirm it are the people fixing it. In IT, investigation and remediation can run in parallel with reporting. On a plant, the same two engineers are doing all three. Reporting has to be someone else's job or it does not happen.
Nobody on shift has filing authority. If the early warning needs a director who is asleep, you will miss the window. Delegate the decision to a named on-call role and record the delegation.
Multi-site means multi-filing. If you provide services in several member states, you may owe parallel reports to each affected CSIRT. Know which authorities those are in advance.
OT forensics is slow. You often cannot image a running controller. The 72 hour notification has to be written from monitoring data and operational observation, which is an argument for building an OT monitoring program before you need it.

What makes the 24 hour clock survivable

Four things, none of them a product. A written threshold with OT examples. A named on-call role with filing authority and a backup. Pre-written templates for all three stages, because a blank form at hour twenty is a problem. And a current asset inventory, because the first thing you will be asked is what the affected system is and what it connects to. Our OT asset inventory and device management guide covers that foundation.

Then test it. A timed tabletop against a plausible OT scenario finds the gaps that a document review never will, and it usually finds them in the handover and the authority chain rather than in the technology.

Why Choose Arista Cyber

We build reporting processes that work on running plants, with the constraints real: shift patterns, limited forensic access, engineers who are already the incident response team. Our consultants carry functional safety and OT security credentials and work to IEC 62443, so our procedures account for what an incident response action does to a safety case. Our case studies show the engagements.

Next Steps

Write the significance threshold with worked OT examples, name the on-call filing authority, build the templates, then run one timed exercise. In our experience that sequence takes weeks rather than months and removes most of the real risk in Article 23.

Common Questions

When does the 24 hour clock start?

When you become aware of a significant incident. Awareness is not defined in detail by the directive, which is why your own procedure should define it. Assume a supervisory authority will take the earliest point at which someone in your organization knew.

Do we report malware found on an engineering workstation if nothing happened?

Possibly yes. The test includes incidents capable of causing severe operational disruption, so access to safety or control systems can make a contained finding reportable. Apply a written threshold rather than deciding case by case.

Who do we report to if we operate in several member states?

The designated CSIRT or competent authority in each member state where you provide services. Parallel reports may be required, so identify those authorities before an incident.

Can we delegate the filing decision to a shift role?

Yes, and you should. Record the delegation and name a backup. An obligation that depends on reaching a director overnight will be missed.

How does this differ from CRA Article 14 reporting?

NIS2 is about significant incidents affecting your own services, filed to national authorities. The CRA is about exploited vulnerabilities or severe incidents in products you manufacture, filed through the EU Single Reporting Platform. A manufacturer that also operates in-scope services can owe both.

Could you file an early warning in 24 hours, at 2am, mid-handover?

Arista Cyber builds and tests NIS2 Article 23 reporting processes for industrial operators: significance thresholds with OT worked examples, on-call filing authority, templates for all three stages and a timed tabletop against your own plant.

Test your reporting process