OT incident notification under NIS2: obligations, timelines and what to have ready before it happens

The structure of the NIS2 notification obligation

NIS2 (transposed in Italy through Legislative Decree 138/2024) introduces, for essential and important entities, an obligation to notify significant incidents structured in three phases with precise deadlines:

Early warning: within 24 hours from the moment the organisation becomes aware of the incident. It does not need to be a complete notification: it must communicate the nature of the incident, whether it is suspected to be intentional (an attack), and whether it has potential cross-border impact. It is an early signal, not an analysis.

Detailed notification: within 72 hours. It includes a preliminary assessment of the incident, its severity and impact, the indicators of compromise available, and the mitigation measures adopted. If the analysis is not yet complete, you provide the status of the ongoing investigation.

Final report: within one month of the detailed notification (or of the resolution of the incident, if later). It includes the full root-cause analysis, the actual impact, and the measures taken to eliminate the exploited vulnerability and prevent recurrence.

The recipient of the notification is CSIRT-IT (the Italian Computer Security Incident Response Team), which operates under ACN (the National Cybersecurity Agency). The notification is submitted through ACN's dedicated portal, after the organisation has registered.

What counts as a "significant incident" in OT

The definition of a significant incident for notification purposes is not trivial, and in OT it has some specific characteristics compared with IT.

An incident is significant when it crosses at least one of the following thresholds (defined by the legislation and by ENISA guidance):

Impact on service or production continuity. Significant interruption or degradation of the organisation's services. In manufacturing, this includes unplanned production stoppages caused by cyber events: ransomware that encrypts SCADA systems, manipulation of PLC logic that causes unnecessary safety shutdowns, an attack that makes supervisory HMIs unavailable.

Material economic impact. The exact threshold depends on the classification of the entity and on national guidance, but in general significant economic losses (prolonged production stoppages, plant damage, substantial recovery costs) fall within the perimeter.

Impact on third parties. If the incident has effects on customers, suppliers, or on the infrastructure of other entities. In OT this can include situations where the compromise of a control system affects public safety (a water treatment plant, an energy distribution system).

Breach of the confidentiality of significant data. In OT too: exfiltration of process data, plant drawings, or control system configurations.

The "significant" threshold leaves room for interpretation, and this is one of the most complex aspects of NIS2 compliance. The practical recommendation is to have an internal incident classification procedure that defines in advance, with concrete examples, which scenarios trigger the notification obligation. Waiting for the incident to decide whether it is significant means handling that decision under pressure, with incomplete information, at a moment when resources are already committed to the response.

What you need to have ready before the incident

The 24 hours for the early warning seem few, but they are manageable if the organisation is prepared. They become impossible if the response starts from scratch at the moment of the incident.

An up-to-date OT asset inventory. The first thing CSIRT-IT will ask is: which systems were involved? Answering requires an inventory that not only exists but is current. An inventory made six months ago and never reviewed is not enough: in an OT network devices change (installations, replacements, configurations), and the inventory must reflect the real state at the time of the incident.

System logs retained and recoverable. The technical evidence of the incident lives in the logs: network traffic captured by OT monitoring, system access logs, device configuration logs. These logs must be retained for an adequate period (NIS2 does not define a specific minimum, but good practice suggests at least six months for network logs and a year for significant security events) and they must be recoverable quickly. A log that exists but takes hours to extract and make readable is a problem during an investigation under pressure.

Baseline and anomaly indicators. To describe an incident in a way that is useful to the CSIRT, you need to be able to compare the behaviour observed during the incident with normal behaviour. Without a documented baseline of OT traffic and device behaviour, it is hard to say "this is anomalous" in a convincing and precise way. Continuous monitoring, beyond its operational value, is also the source of evidence that makes this comparison possible.

Pre-registered CSIRT-IT contacts and a portal access procedure. Registering on the ACN portal for NIS2 notifications should not be done during an incident. It should be done beforehand, with the organisation's correct details, with the contacts identified, and with the access credentials tested. At the moment of the 24-hour early warning, whoever has to notify must know where to go, with which credentials, and which template to fill in.

Clear responsibilities for who triggers the notification. Who decides that an incident is "significant"? Who has the authority to send the notification to CSIRT-IT? Who coordinates the collection of information for the detailed notification? These responsibilities must be documented in the incident response procedure and must include a backup for situations where the primary person is unavailable (out of office, involved in the technical response, or away on holiday).

The role of continuous monitoring as a source of evidence

There is one aspect of NIS2 notification that often does not get enough emphasis: the quality of the notification depends on the quality of the available evidence, and the evidence comes from monitoring.

An organisation that has passively monitored OT traffic in the months before the incident has available, at the moment of notification:

• The exact chronological sequence of anomalous events, with precise timestamps
• The list of devices involved in the suspicious communications
• The traffic patterns that deviate from the baseline
• The technical indicators (destination IPs, protocols used, function codes, payloads where applicable) that make it possible to describe the attack in technical terms

An organisation without monitoring has to reconstruct these elements after the fact, often incompletely, from fragmented logs or the memory of the technicians present. The resulting notification is less precise, less convincing, and harder to use as a basis for the final report.

Continuous monitoring is therefore not only an operational tool for detection: it is also the evidence infrastructure that makes a high-quality NIS2 notification possible. A CSIRT-IT that receives a notification with precise IoCs, a documented timeline and measured impact can provide more effective support than it can for a vague notification.

Rehearsing the notification before you need it: the tabletop exercise

The NIS2 notification procedure should not be read once and filed away. It should be rehearsed.

A tabletop exercise specific to NIS2 notification in OT does not require complex infrastructure: three or four hours, the right people in the room (or on a video call), and a realistic incident scenario are enough.

The scenario can be simple: "Monday morning, OT monitoring detects anomalous behaviour on three PLCs of the main production line. The initial analysis suggests unauthorised access. What do we do in the next 24 hours?"

The exercise surfaces the real gaps: who has the credentials for the ACN portal? Where is the notification template? How long does it take to extract the OT monitoring logs from the last 48 hours? Who approves the text of the notification before it is sent? Is the legal lead aware of the obligation and do they need to be involved?

Gaps that surface during a tabletop are corrected in weeks. The same gaps that surface during a real incident turn into breaches of the regulation, with penalties that compound the operational damage of the incident itself.

The recommended timing for the exercise is at least once a year, more often if the organisation is in the early stage of implementing NIS2 compliance or if there have been significant changes in the organisation (new contacts, new OT systems, acquisitions).

What to do today to be ready

A plan to prepare for NIS2 notification in OT that can be carried out in a logical sequence:

1. Check whether the organisation falls within the NIS2 perimeter as an essential or important entity, and in which sector. The classification determines the thresholds and the specific requirements.

2. Register the organisation on the ACN portal and identify the official NIS2 contacts (point of contact, head of information security).

3. Define the internal incident classification procedure: what counts as "significant", with concrete examples for the organisation's OT context.

4. Document the responsibilities in the notification chain: who decides, who notifies, who coordinates the collection of evidence, who communicates with CSIRT-IT.

5. Verify that OT monitoring (if present) generates and retains logs with precise timestamps and in a recoverable format. If monitoring is not in place, this is the most urgent gap to close.

6. Run a tabletop on an OT incident scenario, with a specific focus on the notification procedure in the first 24 to 72 hours.

NIS2 notification is not the hardest part of responding to an OT incident. The hard part is everything that precedes it: detecting the incident, containing it, collecting the evidence. But arriving unprepared even for the notification, which is the most procedural part, would be an avoidable mistake.

The MON5 angle

Meeting the 24-hour early warning without active monitoring is, as we have seen, almost impossible. The PROTECT phase of MON5 provides the evidence infrastructure described in this article: continuous passive monitoring of OT traffic, per-asset baselines, a timeline of anomalous events with precise timestamps, and technical indicators ready for notification to CSIRT-IT. The inventory continuously kept up to date by the ANALYZE phase answers the first question of every notification: which systems are involved.

Preparing before the incident also means knowing where to start. To check whether you would be able to produce this evidence today, you can begin with an OT assessment.

Analysis and commentary by MON5 based on public-domain research and data from the OT/ICS sector.