I want to start with something that keeps coming up in conversations with OT operators: most of them know NIS2 exists, some have done a gap assessment, and almost none have actually changed anything in their control systems yet. The directive came into force in October 2024. The enforcement clock is running. And the gap between "we're aware of it" and "we're actually compliant" is wider than most organisations would be comfortable admitting to a regulator.
This guide is written for the people who need to close that gap — plant managers, operations directors, IT/OT leads, and anyone who's been handed "sort out NIS2" as an agenda item without much guidance on where to start.
The short version: NIS2 isn't a bigger version of the original NIS Directive. It's a different animal. The original regulation was narrow in scope and weak on enforcement. NIS2 covers a much wider range of sectors, sets stricter technical requirements, and — this is the part that gets people's attention — moves personal liability onto senior management. Not just corporate fines. Personal accountability. An operations director who can't show they took reasonable steps to secure their OT environment is exposed in a way they simply weren't before. That changes the conversation.
What NIS2 Is — and Who It Covers
NIS2 (Directive 2022/2555) replaced the original NIS Directive in 2024. It distinguishes between two categories of entities: Essential Entities and Important Entities. Essential entities face stronger supervisory measures and higher penalties.
| Category | Sectors Included | Penalties |
|---|---|---|
| Essential Entities | Energy (electricity, oil, gas, hydrogen), Transport, Banking, Financial market infrastructure, Health, Drinking water, Wastewater, Digital infrastructure, ICT service management, Public administration, Space | Up to €10 million or 2% of global annual turnover (whichever is higher) |
| Important Entities | Postal and courier services, Waste management, Chemical production, Food production and distribution, Manufacturing (medical devices, electronics, machinery, vehicles), Digital providers, Research | Up to €7 million or 1.4% of global annual turnover |
The size threshold is generally 50 employees or €10 million turnover. But some sectors — energy and water especially — have no size floor at all. A small municipal water operator with 12 staff can be in scope. And even if you're not directly covered, if you supply to someone who is, they will start asking questions about your security posture as part of their own supply chain obligations. The perimeter of NIS2 is larger than it looks on paper.
If you work in energy, water, transport, food, chemicals, or manufacturing and you have more than 50 employees — assume you're in scope and work backwards from there. Waiting for a regulator to confirm it is not a plan.
What NIS2 Requires for OT Environments
There's an article buried in the middle of the directive — Article 21 — where most of the operational work lives. It covers seven broad areas: risk management, incident handling, business continuity, supply chain, access control, asset management, and security awareness training. Reading through them as someone who works in OT environments, I'd say four of those seven catch operators off guard, not because they're new ideas but because the gap between "we have something for that" and "we can demonstrate this to a regulator" is much wider than people expect.
Risk Management
Article 21 says you need systematic risk analyses of your network and information systems, which sounds straightforward until you try to do it in an OT environment where half the assets aren't in any inventory and nobody's sure who owns the SCADA historian.
What it actually requires: a documented asset list, a record of threats and vulnerabilities against those assets, some estimate of likelihood and impact, and a named person responsible for each risk. Not a report that gets written once and filed. Something that gets updated when a new vendor gets remote access, or when you upgrade a control system, or when the network changes in any meaningful way.
I've seen organisations spend six months just on the asset inventory before they can do anything else. That's not unusual. Legacy OT environments carry 15 years of undocumented changes, and getting visibility is genuinely hard. Budget accordingly.
Incident Reporting
This one surprises people more than anything else in the directive — and I think it's because the timelines only feel manageable until you actually walk through what has to happen inside them.
Twenty-four hours after you detect a significant incident, you notify the competent authority — in Norway, that's NSM. Not a full investigation report. An early warning that says: something happened, here are the affected systems, here's roughly what we know. Then 72 hours for a fuller incident notification with an initial assessment of severity, impact, and indicators of compromise. And a final report within a month that covers root cause and what you did about it.
A "significant incident" covers any event that has caused, or could have caused, serious disruption to your operations. A ransomware attack on a production system is an obvious example. But a detected intrusion into an OT network — even one you caught and contained before any damage — probably counts too. The threshold is lower than most people assume.
In Norway, the competent authority is NSM — Nasjonal sikkerhetsmyndighet. They receive the 24-hour notification. Worth knowing who your contact is there before you need them at an inconvenient hour.
Supply Chain Security
This is the requirement that produces the most uncomfortable conversations. Article 21(d) says you must assess the cybersecurity practices of your vendors and service providers who have access to your OT systems, and embed minimum security requirements in your contracts with them.
In practice, OT vendor contracts almost never say anything meaningful about security. Your PLC vendor, your SCADA integrator, your remote maintenance provider — most of them are operating under agreements written years ago that don't mention MFA, don't specify what access controls are required, and don't give you any audit rights. Renegotiating all of those is slow and sometimes contentious, particularly when the vendor is the only authorised service provider for equipment you can't easily replace. But the legal obligation doesn't bend for commercial inconvenience.
The Liability Shift: Personal Accountability for Management
Most of the technical requirements in NIS2 are things OT operators have been told to do for years. What's genuinely different about this directive is Article 20.
Article 20 puts personal liability on management bodies — boards, managing directors, senior executives. Not the IT team. Not the person with "security" in their job title. The people who approve budgets, sign contracts, and make decisions about where the organisation spends money. Specifically:
Article 20 of NIS2: "Member States shall ensure that the members of the management bodies of essential and important entities can be held liable for infringements by those entities." Management bodies that fail to ensure NIS2 compliance can face temporary prohibitions from exercising managerial functions.
This is not theoretical. A competent authority can issue binding instructions that tell you exactly what to fix and by when — not a recommendation, an order. They can appoint a monitoring officer who then watches whether you're actually doing it. They can temporarily ban a named executive from exercising management functions, which is a consequence that lands quite differently from a corporate fine. They can publicly name the organisation in enforcement action — the naming and shaming mechanism tends to motivate boards faster than financial penalties alone. And they can fine up to €10 million or 2% of global annual turnover, whichever is higher.
For most OT-heavy organisations, this is genuinely unfamiliar ground. A plant manager or operations director who has spent their career focused on production uptime and process efficiency is now personally exposed if the organisation can't show it took reasonable security steps before a breach happened. The monitoring tool that was deferred for budget reasons. The vendor access policy that was on the to-do list. Those decisions look different when the regulator is asking about them after an incident.
Norsk Hydro is worth mentioning here. In March 2019, LockerGoga ransomware hit their systems and took down aluminium production across sites in Norway, Qatar, and the US. The recovery cost came to somewhere around NOK 800 million. NIS2 wasn't in force at the time — but if it had been, there would have been a parallel question about management accountability on top of the operational and financial damage. That's the environment industrial operators now work in.
NIS2 and OT: What "Good" Looks Like
NIS2 Article 21 describes what you need to achieve, not how to achieve it. It says risk management measures must be proportionate. It says you need to handle incidents, manage your supply chain, control access. But it doesn't specify exactly which tools or configurations satisfy those requirements. That's by design — a regulation that prescribes specific products would be outdated within a few years.
The practical answer for OT environments is IEC 62443, the international standard for industrial automation and control system security. It maps well onto NIS2's requirements, it's been around long enough that regulators know it, and alignment with it gives you a defensible basis for the decisions you've made. It's not officially written into NIS2, but across Europe, competent authorities are treating IEC 62443 documentation as credible evidence that you've taken your obligations seriously. That's worth knowing before you start designing your control framework.
A Roadmap to Compliance: Where to Start
People ask me where to start with NIS2 compliance, and my honest answer is: it depends on what state your OT environment is in. But there's a sequence that works for most industrial operators regardless of where they're starting from, and it doesn't begin with buying software.
Stage 1: Establish Governance
Before anything technical happens, you need to answer a basic organisational question: who owns OT security? Not which department — which person. By name. With the authority to make decisions and the budget to act on them.
Management also needs a proper briefing on personal liability before they start approving (or rejecting) security spending. I've seen companies where the plant manager genuinely didn't know they were personally exposed under NIS2. Once they understood that, the conversation about budget looked quite different. Get that briefing done early.
Stage 2: Gain Visibility
Asset discovery is unglamorous but unavoidable. You need a complete inventory of what's on your OT network — what it is, what it does, what it connects to, and how critical it is to operations. Without that, you can't do a risk assessment, and without a risk assessment, you can't claim to be managing risk.
Expect this to take longer than you think. Real OT environments have years of changes that weren't documented, equipment that runs without anyone being entirely sure who's responsible for it, and network topologies that diverged from the diagram on the wall sometime around 2018. Getting an accurate picture is the actual work. Everything after is more straightforward.
Stage 3: Implement Controls
Network Segmentation: Separate IT and OT networks with a demilitarised zone (DMZ). Within the OT network, segment by function and criticality — safety systems (SIS) should be isolated from SCADA, SCADA from engineering workstations, and engineering from corporate IT. IEC 62443 provides the zone and conduit model that NIS2 regulators recognise.
Access Control: Enforce multi-factor authentication for all remote access to OT systems. Apply role-based access so that engineers, operators, and vendors can only access the systems and data they need. Privileged access to critical systems should require explicit approval and should be time-limited.
Patch Management: Establish a risk-based patch process for OT systems. Not all patches can be applied in real-time — but all known vulnerabilities should be assessed, and compensating controls should be documented where patches cannot be applied immediately.
Incident Detection: Deploy passive OT network monitoring to detect anomalies. Without detection capability, the 24-hour reporting clock cannot start — you will discover incidents too late to meet the notification timeline.
| Control Area | Minimum NIS2-Aligned Measure | Preferred Measure |
|---|---|---|
| Asset Management | Documented inventory of critical OT assets | Continuous passive monitoring with automated updates |
| Network Segmentation | IT/OT separation with firewall | Zone-and-conduit model per IEC 62443, with OT DMZ |
| Access Control | Individual accounts, no shared passwords | MFA, PAM, just-in-time vendor access, session recording |
| Patch Management | Vulnerability register with risk ratings | Risk-based patch schedule, compensating controls documented |
| Incident Detection | Log collection from OT systems | Passive OT network monitor with anomaly detection, SIEM integration |
| Incident Response | Documented IR procedure with contact list | OT-specific IR playbooks, tested in tabletop exercises |
| Supply Chain | Vendor access documented and reviewed | Contractual security requirements, vendor security assessments |
Stage 4: Sustain and Report
This is where compliance programmes most often quietly fall apart. The assessment gets done, the remediation work happens, and then six months later nobody's sure who's supposed to be maintaining the risk register or running the next tabletop exercise. Build the ongoing work into your operating rhythm before you need it — the review cadence, the training schedule, the incident reporting procedures. When something goes wrong, you won't have time to figure out the process.
The Incident Reporting Challenge for OT
The 24-hour notification window is where most OT operators are least prepared, and I think it's worth spending some time on because it's not obvious how hard it is until you work through the scenario.
Say something anomalous happens on a Tuesday night. The night shift operator notices something odd around 2am but isn't sure if it's a real problem or a system quirk. They log it and carry on. The day shift comes in Wednesday morning, sees the log entry, and starts investigating. By noon, the security team is involved. By 3pm, they've confirmed it's a genuine intrusion. By now it's been 13 hours since the anomaly was first noticed — but you still need to figure out whether it crosses the "significant incident" threshold, draft the notification, get it approved internally, and get it to NSM. The 24-hour clock started when the incident started, not when you discovered it was serious. In many cases, organisations are already close to the limit before they've even begun the notification process.
What needs to be in place before any of that happens, not after: continuous OT network monitoring, because you genuinely cannot meet a 24-hour window if you find out about incidents by waiting for a shift operator to notice something odd. A clear escalation path that people actually know — who gets called, in what order, and who has the authority to formally declare a significant incident at 2am. And a pre-written notification template for NSM. The 24-hour submission doesn't require a full analysis, but it does require specific information in a specific structure, and writing that from scratch while simultaneously running an incident response is harder than it sounds. I've seen teams lose an hour just trying to figure out what the notification is supposed to say.
NIS2 as a Catalyst for IT-OT Convergence
I'll end with something that might sound counterintuitive: NIS2 is genuinely useful, beyond the compliance obligation.
The conversations it forces — between IT and OT teams, between operations and management, between procurement and security — are conversations that should have happened years ago in most industrial organisations. Who owns the network diagram? Who gets called first when something goes wrong? Who has authority to shut down a production line if a cyber incident requires it? These questions have uncomfortable answers in most companies. NIS2 gives you a legitimate reason, and a deadline, to work through them.
The operators I've seen handle this well weren't the ones who hired someone to write a gap report and file it. They were the ones who used the compliance programme to actually build something — proper asset visibility, working incident detection, vendor contracts that mean something. Those capabilities don't just satisfy a regulator. They reduce real risk. They also, increasingly, matter to insurers and to customers who ask about your security posture before signing contracts.
The compliance path and the "actually improve our security" path are the same path. That's one thing NIS2 got right.