NIS2 Article 21, measure by measure: what it means on a plant, and what proves it

Article 21 is the operational heart of NIS2. It lists ten minimum risk-management measures, written to fit every sector in the Union at once. That makes them broad by necessity, and vague as a result.

Two principles govern how they are read. Proportionality: the measures must match the risk, the size, the sector and the impact of the entity. And demonstrability: the Directive does not ask you to say you did something. It asks you to be able to show it.

So for each measure the useful question is not “have we done it?”. It is: what does this become on a production site, and what would we put on the table if someone asked?

Here are the ten, in the order of Article 21(2).

(a) Risk analysis and information system security policies

What it asks. A security policy, and a risk-analysis method that is actually used.

On a plant. The policy has to name OT explicitly, or it will be applied to the office estate and stop at the workshop door. The risk analysis has to be able to express consequences that are not data breaches: production stopped, product quality affected, people hurt. A method built only around confidentiality will under-rate industrial risk every time.

Evidence. A dated policy approved by management, the risk method applied to at least one real production system, and the asset inventory the analysis rests on. Without the inventory, the analysis is an opinion.

(b) Incident handling

What it asks. Procedures to detect, classify, respond to and close incidents.

On a plant. The classification words have to be defined and shared. Whether something is an event, an issue, an incident or a confirmed attack decides who is told and when. Detection has to reach into OT, which usually means passive network monitoring rather than agents on the controllers.

Evidence. The procedure, the incident register, the post-mortems of the last significant incidents, and proof that the 24-hour notification path exists and has been rehearsed. An untested notification path is one of the findings we come across most often.

(c) Business continuity, backup management and disaster recovery, crisis management

What it asks. Continuity with defined recovery objectives, a tested backup strategy, and a crisis organisation.

On a plant. Backups mean controller programs, HMI projects, drive and instrument parameters, recipes and network device configurations, not just servers. Recovery objectives also have to meet reality: the RTO written in the plan against the hours the last real restore actually took.

Evidence. Dated restore test reports with measured durations, not backup job logs. A crisis exercise, with its report and the actions that came out of it.

A backup is a hypothesis; a restore is evidence. This is the measure where the gap between the two stays invisible longest, usually until the day it matters.

(d) Supply chain security

What it asks. An assessment of supplier risk, security requirements in contracts, and continued oversight of critical providers.

On a plant. Here the gap between paper and reality is widest, because the suppliers that matter are rarely the ones purchasing classified as critical. The integrator with a permanent VPN into your line is critical. So is the machine builder whose cellular modem sits inside the cabinet, and the maintenance company whose technician has local administrator rights on the engineering station.

Evidence. A list of critical suppliers built from real dependencies, not contract value. The security clauses actually signed: incident notification, right to audit, access conditions. And proof of oversight, such as access reviews and periodic supplier reviews.

(e) Security in acquisition, development and maintenance, including vulnerability handling

What it asks. Security built into how systems are bought, built and maintained, plus a process for handling vulnerabilities.

On a plant. Two things carry most of the weight.

First, purchasing is the cheapest security control there is. Security requirements written into the specification of a new line cost next to nothing; the same requirements retrofitted after commissioning cost a shutdown. If your equipment specifications have no security clauses yet, that is the best return on effort anywhere on this list.

Second, vulnerability handling in OT is not patching on a calendar. A patch may need a shutdown and, on a regulated site, revalidation. NIS2 can live with that. What it cannot live with is the absence of a decision. A documented, risk-based decision not to patch, with compensating controls, holds up. Silence does not.

Evidence. A security annex in equipment specifications. A vulnerability register showing, for each significant finding, the decision, who took it, and the compensating measure where patching was declined. Change records showing that security impact is assessed.

(f) Policies and procedures to assess the effectiveness of the measures

What it asks. That you check whether what you put in place actually works.

On a plant. This is the measure most often skipped, and the one that separates a programme from a pile of projects. Effectiveness is not the number of controls deployed. It is whether the firewall rules still match the flows, whether the restore still works, whether the alerts still reach a person.

The assessment methods have to suit OT. An active penetration test on a live production network is not automatically a good idea. Configuration reviews, architecture reviews, tabletop exercises and passive assessments often give more value for less risk.

Evidence. An audit and review plan, the reports it produced and, the part that counts, what changed as a result. A finding with no closure is worse than no finding.

(g) Basic cyber hygiene practices and cybersecurity training

What it asks. Hygiene rules that are applied, and training, including for people in higher-risk roles.

On a plant. Generic e-learning does not reach the people who matter here. Engineering and maintenance need their own content (removable media, remote access, commissioning new equipment), operators need to know what to report and to whom, and management has its own obligation under Article 20.

Evidence. Attendance records by population, the content delivered, and the dates. As far as an inspection is concerned, awareness that cannot be evidenced did not happen.

(h) Policies and procedures on the use of cryptography and, where appropriate, encryption

What it asks. A policy on which algorithms are used where, and how keys are managed.

On a plant. Read with proportionality, because much industrial equipment simply cannot do it. Older controllers speak unauthenticated, unencrypted protocols and always will. Encrypting the line is not the goal. Protecting backups, remote-access sessions, and sensitive data in transit and at rest is.

The part people forget is key management. An encrypted backup whose key lives on the system that was just encrypted by ransomware is not a backup.

Evidence. The policy, the list of what is encrypted and what knowingly is not, with the reason, and a documented arrangement for key custody.

(i) Human resources security, access control policies and asset management

What it asks. Least privilege, joiner-mover-leaver processes, control of privileged accounts, and an asset inventory.

On a plant. Two things dominate. Shared accounts are everywhere in OT. One HMI operator session for the whole shift is normal, and sometimes justified for safety: nobody wants an operator typing a password during an upset. Pretending it does not happen helps no one. Document it, limit what the shared account can do, and make sure individual accountability exists where actions have consequences, for example through the batch record or a supervisor’s signature.

Contractor access belongs here too. Accounts created for an intervention three years ago and never closed turn up in almost every OT access review we run.

Evidence. The access control policy, a recent access review and its results, the list of privileged accounts and how they are protected, and the asset inventory with named owners.

(j) Multi-factor authentication, secured communications, emergency communications

What it asks. Multi-factor or continuous authentication, secured voice, video and text communications, and secured emergency communication systems, where appropriate.

On a plant. Multi-factor authentication on remote access is non-negotiable, and it is where to start. Remote access protected by a password alone keeps coming up in published OT incident reports and in our own assessments. Multi-factor on a control room HMI, on the other hand, is often inappropriate and sometimes unsafe.

The emergency communication channel is the item nobody implements and everybody needs. If ransomware has encrypted your corporate messaging, mailboxes and directory, how does the crisis team talk? An out-of-band channel, independent of the main information system and tested at least once, costs very little. It is the difference between a coordinated response and four hours of calls on personal mobiles.

Evidence. Where multi-factor is deployed and where it knowingly is not, with the justification. Proof that the emergency channel exists and was used in an exercise.

On ISO 27001

A common and fair question: we are certified, so are we compliant?

A mature information security management system covers a good share of Article 21: governance, risk method, access control, continuity, supplier clauses, awareness. It is a real head start, and much of the evidence an ISMS produces can be reused.

Three gaps remain whatever the certification, and they are gaps of nature, not of maturity:

• The notification deadlines. 24 hours, 72 hours, one month, counted from awareness. No certification requires that capability, and it is operational, not documentary.
• Supply chain. NIS2 goes further than the usual supplier clauses and makes your suppliers’ security part of your obligation.
• Management accountability. Article 20 puts responsibility on the management body and makes its training compulsory. A certificate does not discharge that.

A fourth one is specific to industry and rarely said out loud: the certification scope. Most ISO 27001 certificates cover the corporate information systems. The production network, the controllers, the engineering stations and the historian are often outside the scope, so the certificate says nothing about the very systems NIS2 cares most about on a plant. Read the scope statement on your own certificate before assuming coverage. It takes two minutes and changes the whole conversation.

That is where IEC 62443 comes in. It brings the industrial structure, zones, conduits and security levels, that ISO 27001 does not, and the two complement each other rather than compete.

What to do with this list

Do not turn it into a compliance project. Take the ten measures and, for each one, write two lines: what exists today, and what you would put on the table if asked tomorrow. Where the second line is empty, you have found the work, and it is usually much smaller than the size of the Directive suggests.

Compliance is judged on coherence and on the quality of the evidence, not on the number of controls. Five measures you can prove are worth more than ten you have asserted.

References

• Directive (EU) 2022/2555, Article 21(2), points (a) to (j), and Articles 20 and 23.
• ISO/IEC 27001:2022, information security management systems.
• ISA/IEC 62443 series, security for industrial automation and control systems: zones, conduits and security levels.