NIS2 Article 21: What Does the Risk Assessment Require – and What Does It Mean for OT?

Article 21 requires a risk assessment covering your entire organisation, including the OT environment. Learn what the requirements mean in practice, where the gaps typically are, and how to document everything correctly.

Many OT organisations treat NIS2 as though it is primarily an IT concern. That is a misunderstanding that can prove costly.

A central element of NIS2 is Article 21 – the risk assessment provision – which requires you to identify and manage risks across all assets your organisation relies on, including suppliers, sites, and the systems that control production lines, energy installations, and critical infrastructure.

If your OT environments have not been factored into that work, you may be carrying vulnerabilities you have no visibility into. Left unaddressed, those gaps can ultimately disrupt critical societal functions – and then cost you heavily when the supervisory authorities come knocking.

The challenge is that while Article 21 was written to be technology-neutral, it was effectively designed with IT logic in mind. OT environments operate by an entirely different set of rules.

This article explains what Article 21 actually requires, why risk assessment is particularly difficult in an OT context, and what you can concretely do about it.

Are you doing enough on NIS2? Read more here:
NIS2 and OT Security: How far along are you - and is it enough?

What Is NIS2 Article 21?

Article 21 is the directive's core cybersecurity provision. It requires both essential and important entities to take appropriate and proportionate technical, operational, and organisational measures to manage risks and to limit the impact if something goes wrong.

The critical word is proportionate. It means that the specific measures required to comply with Article 21 will not look the same for every organisation. What is sufficient depends on:

• The organisation's degree of risk exposure
• The size of the organisation
• The likelihood and severity of incidents, including their societal and economic consequences

The measures must also be based on an all-hazards approach. It is not enough to address only the obvious cyber threats. All relevant threats to the security of systems and their physical surroundings must be taken into account.

And then there is the governance requirement: management must approve the risk assessments and security measures and take ownership of them. NIS2 compliance is a board-level matter – it cannot be handed off to the IT department.

The 10 Minimum Requirements – Translated Into OT Reality

Article 21(2) sets out 10 minimum requirements. On paper, they sound reasonable enough. But for an OT organisation, there is often a significant gap between what the requirement says and what is actually achievable in practice.

What Are the Most Common Gaps in OT Environments?

When OT organisations conduct a gap analysis against Article 21, the same shortcomings come up time and again. Not because these organisations are irresponsible, but because OT environments are built for operations – not for documented risk management.

Most gaps are therefore not a question of willingness but of structural challenges that require an approach different from the one the IT world has shaped.

Read also: 5 Reasons NIS2 Is Harder for OT Organisations Than for Anyone Else

No complete asset inventory. You cannot assess the risk of assets you do not know exist. Many OT environments have grown organically over decades, and there is no consolidated picture of PLCs, HMIs, field devices, and communication flows. This is not just a technical problem – it is a foundational one. Everything else in the risk assessment rests on the asset inventory.

Risk assessment built on IT logic. Traditional information security risk management focuses on confidentiality, integrity, and availability. In OT, availability and functional safety are always the top priority. A risk assessment that recommends taking a system offline to apply a patch is technically correct but operationally unacceptable. The methodology must reflect OT's actual priorities.

Legacy systems cannot be scanned. Active vulnerability scanning can destabilise older PLCs and SCADA systems or directly trigger production shutdowns. Standard risk mapping tools are therefore either useless or dangerous. Passive monitoring methods and vendor documentation must be used instead.

Maintenance windows are too narrow. Planned shutdowns in production environments may be months away. NIS2 assumes a dynamic, continuous vulnerability management process – a fundamental contradiction with OT's design goal of predictability and stability.

IT and OT do not speak the same language. Risk assessment requires a shared risk picture across two worlds that have historically operated in silos. OT engineers know the systems but not the NIS2 requirements. IT security professionals know the requirements but not the systems. Management must own both – and that requires a common framework.

Knowledge lives in people's heads, not in systems. Many organisations have an intuitive sense of what is risky, but intuition is not enough. Article 21 requires documented policies and procedures. The informal knowledge held by the experienced OT engineer needs to be documented.

How to Document Your Risk Assessment

Article 21 does not simply require you to carry out a risk assessment. It must be documented so that management can approve it and supervisory authorities can audit it. Here is what you need, as a minimum.

1. Asset inventory as the foundation. Start with a complete list of all OT assets: PLCs, HMIs, SCADA servers, engineering workstations, field devices, and communication infrastructure. Use passive network monitoring to surface what you did not know was there. The inventory is not a one-off exercise – it must be maintained continuously.
2. Risk assessment using an OT methodology. Ground your assessment in OT-specific threats such as targeted attacks against industrial systems, ransomware, and sabotage, and in OT-specific consequences: production shutdowns, safety incidents, and environmental damage. Use a methodology that combines likelihood and consequence, and make it explicit that availability and safety carry the greatest weight.
3. Risk treatment plan with compensating controls. For assets that cannot be patched, document which compensating controls are in place – including network segmentation, anomaly detection, and access restrictions – and when a permanent solution is expected.
4. Documentation for all 10 minimum requirements. Each of the 10 requirements in Article 21(2) must be supported by a documented control, policy, or procedure. It does not need to be 10 separate documents, but it must be clear who is responsible, what is being done, and when it will be reviewed.
5. Management approval and ongoing review. The risk assessment must be approved by management and repeated regularly, or whenever there are significant changes to systems, the threat landscape, or the organisation. Article 21(2)(f) explicitly requires procedures for assessing whether the measures in place are actually working.
6. Supplier documentation. Document what security requirements you place on critical suppliers and how you follow up on them. Contractual minimum requirements are the starting point, but it is the follow-through that determines whether they hold in practice.

The list may look long, but most organisations are not starting from zero. They simply have not formalised what is already happening. It's about getting a clear picture of where you stand and what still needs to be done.

How Do You Get Your Risk Assessment Across the Line?

Article 21 is complicated enough on its own, and OT makes it even more complicated. But approach it systematically, one task at a time, and you will get there.

And you do not have to do it alone.

NorthGRC's OT Workbench is built to handle NIS2 through an OT lens. It brings compliance, risk management, supplier management, incident handling, and documentation together in a single overview – designed for industrial environments.

Your risk assessment, compensating controls, and documentation all live on the same platform, ready to be presented to management or regulators whenever needed.

If you need support along the way, our consultants have hands-on experience with NIS2 implementation in OT environments. We can assist with everything from the initial gap analysis to ongoing maintenance – or take on the full engagement if that makes the most sense.

And if you are unsure how far you have come with your NIS2 implementation overall, our article "NIS2 and OT Security: How Far Along Are You – and is it When Is It Enough?" provides a practical overview of maturity levels and what it takes to reach the finish line.