Most NIS2 preparation inside manufacturing companies has focused on governance: risk management policies, supply chain clauses, management body training. That work matters, and it is also the part that can be finished quietly over several quarters by people who are good at documents.
The reporting obligations are different in kind. Article 23 of Directive (EU) 2022/2555 does not ask whether you have a policy. It starts a clock the moment you become aware of a significant incident, and it asks you to produce specific factual claims about your own network under time pressure, in writing, to a national authority. You either have the evidence or you do not. No amount of policy work substitutes for it.
For a manufacturer whose production floor is full of controllers nobody has logged into since commissioning, that is the uncomfortable part.
The Three Deadlines, Precisely
NIS2 defines a staged reporting sequence to the national CSIRT or competent authority. The stages are cumulative, not alternatives.
Early warning, within 24 hours of becoming aware. This is deliberately minimal. You state that a significant incident has occurred, whether you suspect it was caused by unlawful or malicious acts, and whether it could have cross border impact. You are not expected to know root cause. You are expected to have noticed.
Incident notification, within 72 hours of becoming aware. This updates the early warning and adds an initial assessment of the incident, including its severity and impact, plus indicators of compromise where they are available. This is the first report that requires you to describe what actually happened on your network rather than that something did.
Final report, within one month of the incident notification. This is the substantial one: a detailed description of the incident including severity and impact, the type of threat or root cause that likely triggered it, the mitigation measures applied and ongoing, and any cross border impact. If the incident is still being handled at the one month mark, you file a progress report instead, and the final report follows within one month of your handling of the incident concluding.
An intermediate report can also be requested by the authority at any point in between. And separately from the authority track, where a significant incident is likely to adversely affect the provision of your services, you may be required to notify the recipients of those services, which for a component manufacturer means customers.
The 24 hour clock starts at awareness, not at intrusion. That sounds like relief and is the opposite. Regulators assess whether a competent operator in your position should reasonably have become aware sooner. A six month dwell time discovered by a customer phone call is not a defense, it is a finding about your detection capability.
What Makes an Incident Significant
The threshold is not left entirely to interpretation. An incident is significant if it has caused or is capable of causing severe operational disruption of your services or financial loss to your entity, or if it has affected or is capable of affecting other natural or legal persons by causing considerable material or non material damage.
Two words in that definition do a lot of work for manufacturers. "Capable of" means the obligation can attach to an incident that caused no downtime at all. An attacker who reached the engineering workstation, enumerated your controllers, and was evicted before writing anything was capable of causing severe operational disruption. "Other legal persons" pulls your customers into scope, which matters when your output is a safety relevant component in someone else's product.
Whether you fall under NIS2 at all depends on sector and size. Annex II lists manufacturing subsectors as important entities, including computer, electronic and optical products, electrical equipment, machinery and equipment, motor vehicles and trailers, and other transport equipment. Chemicals and food production appear as well. The general size threshold captures medium sized enterprises and above. Essential entities under Annex I face ex ante supervision and administrative fines of up to EUR 10 million or 2 percent of total worldwide annual turnover, whichever is higher. Important entities face ex post supervision and up to EUR 7 million or 1.4 percent. Article 20 makes management bodies responsible for approving and overseeing the measures, which is why this became a board topic rather than an IT one.
Why 24 Hours Is a Detection Problem, Not a Paperwork Problem
The early warning is three sentences long. Producing it requires something most production networks do not have, which is a mechanism that notices.
Consider what awareness has historically depended on in industrial environments. At the Saudi petrochemical facility hit by Triton in 2017, the safety instrumented systems tripped the plant into a safe state. That is what made the operator investigate. The security program did not raise the alarm, the safety system did, and only because the attackers' code had a flaw. At the Oldsmar water treatment facility in 2021, an operator happened to be watching his screen when a sodium hydroxide setpoint moved by more than a factor of one hundred. Awareness came from a person looking at a monitor at the right moment.
Neither of those is a control you can rely on to start a 24 hour clock. Both would have been noticed far earlier by anything watching what the devices themselves were doing on the wire.
That is the useful reframing. Industrial devices are unusually predictable. A PLC runs the same scan cycle for years, speaks to a small and static set of peers, uses a narrow subset of protocol function codes, and polls at intervals whose jitter is measured in milliseconds. When a host that has never spoken to a safety controller issues a program download to one, that is not a subtle statistical signal. It is a structural break in behavior that has been stable since commissioning. Awareness within 24 hours is achievable when detection is grounded in what devices actually do, and effectively impossible when it depends on a signature for a threat nobody has published yet.
The 72 Hour and One Month Reports Are Evidence Problems
The second report asks for severity, impact, and indicators of compromise. The third asks for root cause. Both are answerable only from data you were already collecting before the incident, because you cannot go back and instrument a network retroactively.
In practice the questions you will be asked to answer look like this. Which devices did the compromised host communicate with, and when did that behavior begin? Did any controller receive a write, a configuration change, or a program download, and what were the values? Did traffic cross a zone boundary that your segmentation documentation says is closed? Is there evidence the attacker reached the process layer or stopped at the network layer?
Answering those from firewall logs and endpoint telemetry alone is guesswork, because the traffic that matters happens between devices that run no agent and produce no log. Answering them from a recorded history of decoded industrial protocol exchanges is a query. The difference between those two positions is decided months before the incident, by what you chose to collect.
There is a second reason to care about evidence quality. Root cause in the final report is a claim you will be held to. A report that says the intrusion was contained at the DMZ, contradicted later by a customer finding your firmware modified, is a far worse outcome than a report that honestly states uncertainty. Confidence in that document should come from data, not from hope.
A practical readiness test: pick a controller at random and ask your team to produce, within one hour, the complete list of hosts that have communicated with it in the last 90 days, the protocol function codes used, and any write operations. If that takes a week or is impossible, you cannot file a credible 72 hour notification.
What to Put in Place Before the First Incident
Four things, in rough order of how much they reduce risk per unit of effort.
Establish who declares an incident significant, and give that person the authority to start the clock without a committee. Ambiguity here is what turns a 24 hour deadline into a 40 hour one.
Write the early warning template now, with the fields already mapped to where the answers come from. Under pressure, a form beats a blank page.
Make sure you can see the traffic. Passive collection from SPAN or mirror ports with full packet inspection is what supplies decoded protocol detail and a retained history, with flow telemetry such as sFlow or NetFlow useful as a complementary signal for coverage and volume. Neither approach touches a controller or requires a maintenance window, which is why this is one of the few OT security controls that can be deployed without a production risk conversation.
Then verify coverage honestly. Serial links behind protocol converters, cells connected by unmanaged switches, and traffic that never crosses a monitored uplink are invisible, and a clean dashboard will not tell you so. Knowing where you are blind is itself reportable knowledge.
The Underlying Point
NIS2 reporting does not create a new security requirement so much as it audits an existing one, publicly and on a deadline. The directive assumes you can detect an incident in your own environment and describe it accurately. For a manufacturer, that assumption lands squarely on the production network, where the devices are old, the protocols are unauthenticated, and the traditional tooling was designed for a different kind of network.
The compliance work and the security work turn out to be the same work. Anything that lets you file an honest 72 hour notification is also the thing that would have let you stop the incident earlier. Building it for the regulator and building it for the plant are not competing projects.