NIS2 for Industrial Operators: What EU Plants Must Do

What a compliant plant looks like from the control room

Run the directive end to end and you don't get a binder. You get a plant where every controller, historian, and engineering workstation is in a named inventory, where traffic between the process network and the business network passes through a defined boundary, and where an operator can raise a qualified incident report inside a day because the telemetry to support it is already flowing. The paperwork is the residue. The working system underneath it is asset visibility, network segmentation, and a detection-to-notification path that fires fast enough to satisfy a hard legal clock.

That's the target state Directive (EU) 2022/2555 — the second Network and Information Security directive, NIS2 — is steering processing operators toward. It entered into force on 16 January 2023 and replaces the original 2016 NIS directive, with national transposition due by 17 October 2024 and the rules applying from the day after (EUR-Lex, Directive (EU) 2022/2555). Below is how the statute becomes a set of controls on the floor, in the order you'd actually build them.

First, work out whether you're in and as what

Scope is the gate, so settle it before anything else. NIS2 catches medium-sized and larger entities operating in the sectors its annexes list. Medium-sized here borrows the EU's own definition: from fifty staff, or annual turnover and balance sheet above ten million euro. Below that you're generally out, unless a member state designates you for a specific reason.

Manufacturing sits in Annex II, the directive's set of "other critical sectors" alongside food production, chemicals, and waste management. That placement matters because it sets your default class. Annex I sectors — energy, drinking water, digital infrastructure and the rest — produce essential entities. Annex II sectors produce important ones. A mid-sized food, metals, or waste-to-energy operator is therefore an important entity unless it also runs an Annex I activity, in which case the stricter class can pull it up.

The split decides how the regulator watches you, not whether the rules apply. Essential entities face proactive supervision: audits and inspections can land without a triggering event. Important entities face the reactive kind, where a competent authority acts on evidence or suspicion of a breach. Both carry the same core obligations. So if you read "important" as "lighter," you've misread it — the duties are identical, only the inspection cadence differs.

One more scope task gets skipped and shouldn't: registering yourself. The directive expects member states to keep lists of the essential and important entities operating in their territory, and it puts the burden on entities to come forward with basic identifying details — who you are, which sector, contact points, the member states you operate in. Self-assessment is the practical reality. Nobody mails you a letter telling you you're in scope. A group with plants in several countries can end up registered, and supervised, under several national authorities at once, so the registration step is also where the multi-jurisdiction problem first shows itself. Settle it on paper before you start spending on controls, because the class you land in shapes every downstream decision about evidence and audit-readiness.

The clock that governs the build

Two clocks run, and confusing them is a common mistake. The first is the transposition calendar already described, which fixes when national law bites. The second is the incident clock in Article 23, and it's the one your instrumentation has to serve.

When a significant incident hits, the directive sets a three-stage cadence. An early warning goes to your national CSIRT or competent authority within twenty-four hours of becoming aware of it, flagging whether the event looks malicious or could spill across borders. A fuller notification follows within seventy-two hours, carrying an initial severity assessment and any indicators of compromise you've gathered. A final report is due within one month of that notification, with the root-cause detail (EUR-Lex, Article 23). The authority is obliged to respond to the early warning within a day, which means the channel runs both ways.

Read those windows as engineering requirements, not legal trivia. A twenty-four-hour early warning is only achievable if you can tell, quickly, that something abnormal is happening on the process network and roughly what it touched. That is a detection-and-logging problem long before it's a compliance one. Plants that treat the report as a back-office task discover, mid-incident, that the data to write it was never being captured.

From statute to control: reading Article 21 as an OT spec

Article 21 is the heart of the obligation. It requires entities to take "appropriate and proportionate" technical and organisational measures, built on an all-hazards approach that protects both the information systems and the physical environment around them. Then it enumerates ten measure areas every entity must cover (EUR-Lex, Article 21(2)):

• risk-analysis and information-system security policies;
• incident handling;
• business continuity, including backup, disaster recovery, and crisis management;
• supply-chain security, covering relationships with direct suppliers and service providers;
• security in acquiring, developing, and maintaining systems, including vulnerability handling and disclosure;
• policies to assess whether the risk-management measures actually work;
• basic cyber hygiene and cybersecurity training;
• cryptography and, where appropriate, encryption;
• human-resources security, access control, and asset management;
• multi-factor or continuous authentication and secured communications, where appropriate.

The directive tells you what to cover but not how, and that's deliberate. For the how, the OT world already has two reference texts the regulators expect you to lean on. The first is the IEC 62443 series, the international standard for security in industrial automation and control systems. The second, on the US side but widely used in Europe for engineering detail, is NIST's Special Publication 800-82.

A word on "appropriate and proportionate," because operators fixate on it. The phrase isn't a loophole. The directive ties proportionality to the state of the art, the entity's exposure, the cost of measures, and the severity of what an incident would do. A waste-to-energy plant whose outage darkens a district has a higher bar than a workshop, and the regulator reads proportionality against the consequence, not against your appetite to spend. Treat it as a sizing rule for controls, not as permission to skip them.

NIST published Revision 3 of that guide, retitled Guide to Operational Technology (OT) Security, on 28 September 2023. It adds an OT overlay that tailors the SP 800-53 control catalogue into baselines for low-, moderate-, and high-impact OT systems (NIST SP 800-82 Rev. 3). That overlay is the closest thing to a ready-made mapping from a generic control list to controllers, PLCs, and HMIs that won't tolerate a forced reboot during a batch.

Building the baseline: asset inventory and segmentation

Now the pipeline. Almost every Article 21 measure depends on one prerequisite the statute assumes but doesn't spell out: you have to know what you have. So the first physical step is an OT asset inventory — every controller, drive, sensor gateway, switch, historian, and engineering laptop, with firmware versions and network addresses. In our work commissioning instrumentation on processing lines, the inventory is almost never complete on day one; serial devices behind a protocol converter, contractor laptops, and a forgotten remote-access modem are the usual gaps.

Most processing plants already have a mental model for the next step, even if they've never read a security standard: the layered plant network the ISA-95 and Purdue reference models describe, with field devices and controllers at the bottom, supervisory systems above them, and business IT at the top. Segmentation is mostly the work of making those layers real in the network rather than notional. The boundary between the manufacturing zone and the enterprise zone is the single highest-value control you can put in, because it's the path most external attacks have to traverse to reach a controller.

With an inventory in hand, the next layer is segmentation, and here IEC 62443 gives you the vocabulary. The standard groups assets into zones by shared security needs and routes all traffic between them through controlled conduits. A zone might be one production cell; a conduit is the firewalled link that lets it talk to the historian and nothing else. IEC 62443-3-3 then assigns each zone a target security level from one to four — from protection against casual mistakes (SL 1) up to protection against a well-resourced, determined attacker (SL 4) — scored across seven foundational requirements such as identification and authentication, use control, and data flow restriction (IEC 62443 series).

That zone-and-conduit map is the spine the rest of the controls hang from. Access control (measure i) becomes "who and what may cross this conduit." Detection (the basis of incident handling, measure b) becomes "watch the conduits and the boundary." The all-hazards clause even pulls in the physical layer, so a zone boundary is also a locked panel and a logged door, not only a firewall rule.

The step most rollouts get wrong

Here's the failure I'd warn any operations team about. The detection layer gets bolted on at the end, as a monitoring product dropped onto the network after the architecture is frozen, and it can't see what matters. Why does this happen? Because monitoring is bought as a box, not designed as a data flow.

Effective OT detection reads the same telemetry the process already generates — controller state, setpoint changes, command sequences on the wire — and learns the plant's normal rhythm so a deviation stands out. That only works if the network was instrumented to expose that traffic in the first place: span ports configured, conduits routed through points where a sensor can watch them, and a baseline captured while the plant runs normally. Retrofit it afterward and you get alert noise with no context, which is worse than nothing during the seventy-two-hour window when you're trying to assess severity. Design the segmentation and the visibility together, as one sensor-to-model pipeline, and the detection layer has something to learn from. We build that capture-and-learn path as part of the edge telemetry and analytics layer rather than as an afterthought, precisely because the order is what determines whether it works.

Detection, reporting, and the 24/72 clock in practice

String the pieces together and the incident path looks like this. The detection layer flags an anomaly on a conduit. Because the asset inventory exists, you can name the affected zone and devices within minutes, not days. Because logs are centralised, you can judge whether the event is significant — whether it disrupts service or could have done. That judgment, made fast, is what lets the twenty-four-hour early warning be a real assessment rather than a panicked guess.

The seventy-two-hour notification then upgrades the early warning with severity and indicators of compromise. None of that is writable from memory under pressure. It comes from retained, time-synced telemetry — the same data the model watches for detection, now read forensically. And the one-month final report leans on the same store for root cause. One pipeline serves detection, the legal clock, and the post-incident review, which is the whole argument for designing it once and properly.

Supply-chain risk (measure d) deserves a line here too, because it's the vector regulators keep flagging. ENISA, the EU's cybersecurity agency, has reported that manufacturing and industrial operators are among the most-targeted sectors and that attacks reaching plants through suppliers and remote-access vendors are rising (ENISA's 2023 threat reporting). In OT terms that means the vendor VPN into a packaging line is in scope, and the conduit it lands on needs the same monitoring as any internal one. The practical control is dull but effective: every remote-access path terminates in a known zone, runs through a jump host you log, and stays closed until a named person opens it for a named task. A standing always-on vendor tunnel is the kind of finding an auditor writes up first, and the kind of door an attacker walks through quietest.

Worth saying plainly: the detection model is only as good as the baseline it learned. A plant that captured its normal rhythm during a maintenance week, or during a single product run, hands the model a distorted picture of normal and pays for it later in false alarms. Capture the baseline across enough operating states to be representative, and refresh it after any real change to the process or the network. That discipline is unglamorous, and it's the difference between a detection layer that earns its keep and one the operators learn to ignore.

Governance: the part that reaches the boardroom

NIS2 puts a name on the liability, which is the change most likely to get budget approved. Article 20 requires the management body to approve the risk-management measures, to oversee their implementation, and it makes those individuals liable for the entity's infringements. The same article requires board members to undergo cybersecurity training and encourages them to extend it to staff (EUR-Lex, Article 20). Security is no longer something the plant manager can quietly own.

The enforcement teeth sit in Article 34. For essential entities, administrative fines reach a maximum of ten million euro or two percent of total worldwide annual turnover, whichever is higher. For important entities — where most manufacturers land — the ceiling is seven million euro or one and four-tenths percent of worldwide turnover (EUR-Lex, Article 34). Authorities can also suspend certifications and, in serious cases, bar an individual from management duties. That combination of corporate fines and personal exposure is what moves OT security from a deferred capital line to a board agenda item.

A workable sequence

Put the pipeline in build order and a realistic programme falls out:

1. Confirm scope and class against the size thresholds and the annexes, and write down why.
2. Build the OT asset inventory. Treat it as living data, not a one-off spreadsheet.
3. Define zones and conduits and assign each a target security level under IEC 62443-3-3.
4. Instrument the conduits and boundary for visibility, then capture a normal-operations baseline.
5. Stand up detection that learns from that baseline, and wire it to a logging store that retains enough history to write the 24/72/one-month reports.
6. Map your controls back to the ten Article 21 areas using NIST SP 800-82 Rev. 3 for the OT detail, and close the gaps.
7. Get the management body trained and on record approving the programme, per Article 20.

Where does this approach run out? It won't make a brittle, flat process network compliant by itself; if there's no room to segment without breaking interlocks, the architecture needs investment the directive can require but can't fund. The thresholds also vary in the fine print across member states as they transpose, so a group operating in several countries should expect divergence and check each national law rather than assume one reading holds everywhere. And no inventory stays accurate without a process to keep it current — the day you stop maintaining it is the day it starts lying to you. None of that changes the core build, though. Asset truth, segmentation, visibility, then detection, in that order. Get the order right and the directive's clock becomes something your plant can actually beat.

The honest summary for an operations engineer: NIS2 is less a cybersecurity mandate than a forcing function for the OT instrumentation discipline good plants wanted anyway. The deadline just made it non-negotiable. If you'd like a second set of eyes on the sensor-to-model side of a programme, that's the work we do day to day — see our industrial AI deployment services.