NIS2 · Incident reporting for manufacturing & industrial operators
NIS2 Incident Reporting: The 24-Hour, 72-Hour and 1-Month Timeline
NIS2's Article 23 requires organisations in scope to report a significant incident in three stages: an early warning within 24 hours of becoming aware of it, a fuller incident notification within 72 hours, and a final report within one month. For a manufacturing or industrial operator, meeting the 24-hour stage is not something that can be improvised after an incident starts — it depends on an escalation process, a named contact point and pre-drafted templates that already exist before anything goes wrong.
Three deadlines, one clock — and it starts the moment you become aware, not the moment you understand
The 24-hour early warning, the 72-hour notification and the 1-month final report are staged obligations under the same incident, not three separate incidents. The clock for all three starts at the point of awareness of a significant incident — which is often well before the organisation has a complete picture of what happened.
What counts as a "significant incident" under NIS2
Not every security event triggers Article 23. NIS2 reserves the reporting obligation for incidents that meet a significance threshold, broadly framed around impact rather than a fixed technical category. An incident is treated as significant where it has caused, or is capable of causing, severe operational disruption to the services provided or financial loss to the entity concerned, or where it has affected — or is capable of affecting — other natural or legal persons by causing considerable material or non-material damage.
For a manufacturing operator, this means the trigger is not "was our IT system hit" but "could this stop the line, corrupt safety-relevant data, disrupt a supply commitment, or spread damage to a customer or supplier." A ransomware event that halts production for a shift, a compromise of an OT system controlling physical processes, or a breach that exposes partner data can all meet this bar, even where the underlying technical cause looks routine. Because the exact thresholds, sector-specific criteria and implementing detail are set out in national transposing legislation and in guidance from the competent authority or CSIRT in each member state, and because this area remains subject to ongoing regulatory clarification, organisations should treat the general description above as a starting point and confirm the applicable threshold with their national authority or a qualified compliance adviser — not rely on a general summary to make the call in a live incident.
Stage 1 — Early warning within 24 hours
The first obligation is an early warning, submitted without undue delay and in any event within 24 hours of becoming aware of a significant incident. At this stage the organisation is not expected to have completed an investigation — the purpose of the early warning is to alert the competent authority or CSIRT that something significant is underway, including, where relevant, whether the incident is suspected of being caused by unlawful or malicious action, or could have a cross-border impact.
- The clock starts at awareness, not at confirmation. A security team noticing anomalous behaviour on the shop-floor network on a Friday evening starts the 24-hour countdown then, whether or not the full scope is understood.
- The bar for content is low but the bar for speed is not. A short, factual alert is expected — not a root-cause analysis.
- This is where most organisations without preparation fail. Deciding, inside the first hours of a live incident, who has authority to notify, what to say, and to whom, is the wrong moment to design that process for the first time.
Stage 2 — Incident notification within 72 hours
Within 72 hours of becoming aware, the organisation must submit a more detailed incident notification. This builds on the early warning and is expected to include an initial assessment of the incident, including its severity and impact, and, where available, the indicators of compromise associated with it. This is the stage where the organisation is expected to have moved from "something happened" to a working, if still preliminary, understanding of what.
- Initial severity and impact assessment. A first read on how serious the incident is and what systems, processes or third parties are affected.
- Indicators of compromise, where available. Technical signals — the kind of detail an incident response or SOC function would normally already be capturing during containment.
- An updated picture, not a final one. The 72-hour notification is still an interim step; it is expected to be refined as the investigation progresses, feeding into the final report.
Practical tip
The 72-hour notification is much easier to produce well when the organisation already knows, before an incident occurs, roughly what "initial assessment," "severity" and "indicators of compromise" need to look like in its own environment. Building a pre-agreed template with your incident response lead and, where used, your managed detection provider, means the team is filling in fields under pressure rather than deciding the structure from nothing.
Stage 3 — Final report within one month
The final report is due within one month of the incident notification (or, where the incident is still ongoing at that point, of its resolution). It is expected to provide a detailed description of the incident, including its severity and impact, the type of threat or root cause likely to have triggered it, the mitigation measures applied and ongoing, and, where relevant, the cross-border impact of the incident.
- Detailed description and root cause. The organisation is now expected to state, with confidence, what happened and why — not simply what was observed.
- Mitigation measures. What has been done to contain and remediate the incident, and what remains in progress.
- Cross-border impact, where relevant. Manufacturing operators with production, suppliers or customers in more than one member state may need to address how the incident affected — or could affect — parties beyond their own jurisdiction.
// Demo IgeraIndustria — NIS2 incident response documentation query
Compliance Manager: Who is our named point of contact for the CSIRT, and where is that documented?
IgeraIndustria: Incident Response Plan, section 3.2: Head of IT Security designated as primary contact for CSIRT/competent authority notifications, with the Compliance Officer as backup. Escalation path and contact details maintained in Annex B. Source: Incident Response Plan, section 3.2 and Annex B.
Compliance Manager: Do we have a pre-drafted template for the 24-hour early warning?
IgeraIndustria: Yes — Incident Response Plan, Annex C: Early Warning Template, covering incident category, suspected cause, and cross-border relevance fields, last reviewed 2026-08-12. Source: Incident Response Plan, Annex C.
Why 24 hours is an operational challenge, not just a legal one
For a manufacturing company, the practical difficulty of Article 23 rarely sits in stage three — a month is enough time to build a thorough report if the investigation has been running properly. The real pressure point is stage one. Producing a qualified early warning inside 24 hours of awareness, on a live incident that may have started overnight, over a weekend, or during a plant shutdown, requires the organisation to already have in place, before anything happens:
- A defined escalation path. Who is told first when an anomaly is detected on the OT network or the ERP system, how it reaches someone with the authority to declare an incident, and how fast that decision gets made.
- A named point of contact with the national CSIRT or competent authority. Decided in advance, not worked out during the incident — including who acts if that person is unavailable.
- Pre-drafted templates. A skeleton early warning and 72-hour notification structure that the team populates with facts, rather than composing from scratch under time pressure.
- A clear internal trigger for "we are now inside Article 23." A documented, rehearsed threshold for when an operational disruption or security event is treated as a potential significant incident, so the 24-hour clock is recognised as running rather than discovered days later.
None of this is unique to NIS2 in spirit — it is standard incident response discipline. What NIS2 changes is the consequence of not having it: a missed or incomplete 24-hour early warning is now a compliance gap with its own exposure, on top of whatever operational damage the incident itself caused.
Common mistakes manufacturing operators make with the reporting timeline
- Waiting for certainty before notifying. Teams sometimes delay the 24-hour early warning until they are confident about what happened. The obligation is to warn early with limited information, not to wait until the picture is complete.
- No single owner for the decision to notify. Without a clearly named contact and a defined escalation path, the first hours of an incident can be lost to internal debate about who decides and who drafts the notification.
- Treating OT and IT incidents differently by default. Manufacturing environments often have separate IT and operational technology teams with different reporting instincts; if only one side has an NIS2-aware process, an OT-originated incident can be under-reported or reported late.
- Building the process only after an incident. Retrofitting an escalation path and templates while also managing a live incident compounds pressure at exactly the point where speed matters most.
- Treating the three stages as independent tasks. The early warning, notification and final report are a continuum on the same incident; failing to track how each stage feeds the next can create inconsistencies between what was reported at 24 hours and what is confirmed at one month.
- Assuming the significance threshold is self-evident. Given that "severe operational disruption" and "financial loss" are impact-based rather than precisely quantified in the directive itself, and that the applied thresholds are set out in national transposition, organisations sometimes under- or over-report by applying their own informal judgement rather than confirming the criteria that actually apply to them.
Frequently asked questions about NIS2 incident reporting
When does the 24-hour clock actually start?
It starts when the organisation becomes aware that a significant incident has occurred — not when the investigation is complete, and not when the cause is confirmed. Awareness of the fact that something significant has happened is generally what triggers the obligation, so a delay caused by wanting more certainty is not treated as a valid reason to notify late.
What is the difference between the early warning and the incident notification?
The 24-hour early warning is a brief, initial alert that a significant incident may be underway, including whether it may be caused by unlawful or malicious action or could have cross-border effects. The 72-hour incident notification goes further, providing an initial assessment of severity and impact and, where available, indicators of compromise — a more developed but still preliminary picture.
Do we have to report every security incident under NIS2?
No. Article 23 applies specifically to incidents that meet the significance threshold — broadly, those that have caused or are capable of causing severe operational disruption or financial loss, or that affect others with considerable damage. Lower-impact security events are handled through the organisation's normal incident management process without triggering the Article 23 clock.
What happens if our investigation is still ongoing after one month?
Where an incident is still ongoing at the one-month point, the framework anticipates a final report following resolution rather than an incomplete report being forced through prematurely, though organisations should confirm the exact procedural expectation with their national competent authority, since implementation detail can vary by member state transposition.
Does an OT/ICS incident on the factory floor count the same as an IT breach?
It can. The significance test is based on impact — operational disruption, financial loss, or harm to others — rather than on whether the affected system is classified as IT or OT. A compromise of a production control system that halts a line is capable of meeting the threshold in the same way a corporate network breach can, which is why both environments need to feed into the same escalation process.
NIS2 does not prescribe a specific job title; what matters operationally is that one person (with a documented backup) is clearly designated in advance, knows the notification channel and format expected by the relevant national authority, and has the authority to act within the 24-hour window without needing to escalate that decision itself.
Is NIS2's incident reporting regime still being finalised or could the detail change?
The core three-stage structure of Article 23 is established at directive level, but a substantial amount of operational detail — exact thresholds, notification formats, sector-specific guidance and reporting portals — is set through national transposing law and guidance from individual member states' competent authorities and CSIRTs, and this area continues to be clarified and refined. Organisations should treat published national guidance, not general summaries, as the authoritative source for exact procedural requirements.
Disclaimer: This article is for general informational purposes and does not constitute legal or certification advice. Exact significance thresholds, reporting formats and procedural deadlines under NIS2 depend on the national law transposing the directive in each member state and on guidance from the applicable competent authority or CSIRT. Before building or relying on an incident reporting process, consult a qualified compliance consultant or lawyer.
Could your team produce a qualified 24-hour early warning right now, on a Friday at 6pm?
IgeraIndustria answers directly from your own incident response plan, escalation matrix and notification templates, citing the exact source — so the process is ready before it's needed, not assembled while the clock is already running.
Explore IgeraIndustria
Expert IgeraIndustria · Updated 2026-09-27
