The ENISA technical guidance does not apply to your plant. Read it anyway.

In June 2025 ENISA published its Technical Implementation Guidance on Commission Implementing Regulation (EU) 2024/2690, the regulation that sets the technical and methodological requirements behind Article 21(2) of NIS2.

Two things about it are widely misunderstood, and both matter before you open it.

What it covers, and what it does not

The implementing regulation applies to a specific list of entity types, and industrial manufacturing is not on it. It covers: DNS service providers, top-level domain registries, cloud computing providers, data centre providers, content delivery networks, managed service and managed security service providers, providers of online marketplaces, search engines and social platforms, and trust service providers.

The reason is jurisdictional rather than technical: these sectors are inherently cross-border, so their requirements were set at Union level. For everyone else (energy, transport, health, water, pharmaceutical manufacturing, chemicals, food) requirements are set at national level by each Member State.

And the guidance itself is not binding. ENISA states it plainly: it is advisory, it does not replace national frameworks, and Member States retain the freedom to determine their own approach to supervision.

A third caveat prevents a common over-reaction. ENISA notes that the document cannot determine whether an entity needs all or only some of the evidence listed, and that requiring all of it would be, in its own words, a very strict approach to supervision. Pick from it; nobody expects every line to be ticked.

So why read it

It answers, more concretely than anything else published, a question every programme ends up asking.

Article 21 tells you to have incident handling. It does not tell you what an inspector will ask to see. This document does, for every single requirement, under a heading called “examples of evidence”. That structure (requirement, then guidance, then evidence, then tips) is what makes it useful far outside its legal scope.

National authorities read it too. Where a Member State has not published its own detailed expectations, this is the reference on the inspector’s side of the table. It is mapped to ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST CSF 2.0, ETSI EN 319 401 and CEN/TS 18026:2024, with the mapping table published separately as a spreadsheet, so a site already working to ISO 27001 can see quickly where it stands.

It also turns intentions into artefacts. “We manage risk” becomes a documented framework, documented assessment results, a treatment plan and a record of management approving the residual risks: a list you can build against. And it may be reused. The document is published under Creative Commons Attribution 4.0, including for commercial use, provided ENISA is credited and changes are indicated, which helps anyone writing internal procedures.

The ten documented policies

One item is worth extracting for anyone starting a programme. Beyond the overarching security policy, the regulation requires ten topic-specific documented policies:

1. Risk management
2. Incident handling
3. Supply chain security
4. Security testing
5. Assessing the effectiveness of the risk-management measures
6. Cryptography
7. Access control
8. Management of privileged and system administration accounts
9. Handling of information and assets
10. Removable media

Documenting them is mandatory; the format is not. ENISA is explicit that an entity may use separate documents, updates to existing ones, or a single comprehensive document. That flexibility is worth knowing before someone commits to producing ten new documents nobody will maintain.

The cadences: the most immediately usable output

Scattered through the guidance are recommended review frequencies. Collected in one place, they amount to a ready-made security calendar, and they are the fastest thing to lift from the document:

• At least annually: the security policy. Risk assessment and treatment plan. Compliance monitoring. Independent review. Incident-handling roles and procedures (tested, not just reviewed). Logging procedures and the list of logged assets. Business continuity and disaster recovery plans (tested). Crisis management (tested). Supply chain policy. Supplier registry. Secure acquisition processes. Network segmentation. Awareness programme. Training programme. Cryptography policy. Background verification procedure. Personnel role assignments. Access control policy. Access rights. Asset classification; asset handling policy.
• At least every two years: secure development rules. Change management procedures. Security testing policy. The policy for assessing effectiveness of measures.
• More often than annually: configurations, reviewed monthly. Identities, reviewed quarterly (annually for very small entities). Vulnerability monitoring channels, twice a year. Backup integrity checks weekly for high-criticality data and monthly otherwise, and immediately after a significant change.

If you do nothing else with this document, build that calendar and give each line an owner. On a plant, a compliance programme lasts when it looks like the maintenance plan, with dates that come round whether or not anyone remembers the audit.

What transfers well to a plant

Several titles are close to directly applicable, and in some cases the guidance is more industrially minded than people expect:

• Removable media (12.3). A required policy with concrete content: technical prohibition of connection unless there is an organisational reason, autorun disabled, scanning before use, protection in transit and storage, encryption where appropriate. This is the OT USB problem, written as a regulatory requirement.
• Network segmentation (6.8). Critical systems in secured zones, access between zones restricted to what operations or safety require, administration networks separated from the operational network, production separated from development and test. The vocabulary differs from IEC 62443 but the model is the same one.
• Supporting utilities (13.1) and physical security (13.2, 13.3). Power, cooling, HVAC, telecommunications, redundancy, emergency fuel contracts, monitoring of environmental thresholds. Much of this already sits with the plant’s maintenance team; what changes is that it now counts as part of the security case.
• Supply chain (5.1, 5.2). The contractual clauses are listed item by item: incident notification without undue delay, right to audit or to receive audit reports, vulnerability handling obligations, subcontracting requirements, obligations at contract termination. That list is usable directly in an equipment or integration contract.
• Change management (6.4) and configuration management (6.3). Emergency changes must be documented with the reason the normal procedure could not be followed, and the normal controls applied immediately afterwards. Anyone who has watched a commissioning under pressure knows exactly why that clause exists.

What transfers poorly

It was written for digital service providers, and it shows. The secure development life cycle chapter assumes you write software. Several passages assume cloud infrastructure, cross-zone replication, availability zones, cloud-native key management. Some access-control expectations assume an identity estate that a twenty-year-old control system does not have.

Two specific tensions deserve naming:

• Shared identities. The guidance permits them only where strictly necessary for business or operational reasons, with formal justification, explicit approval and documentation, and it lists compensating controls. An HMI session shared by a shift is exactly that case. Document it, compensate it, and stop pretending it does not exist.
• Patching. The regulation itself allows an entity not to apply a security patch where the disadvantages outweigh the cybersecurity benefits, provided the reasons are documented and substantiated. For an OT fleet that sentence matters more than any other in the framework: it turns the controller nobody dares to patch into a documented decision instead of a finding.

How to use it, concretely

It is not a standard, and it is not addressed to you. Use it for three things:

1. An evidence checklist. For each of your Article 21 measures, read the corresponding “examples of evidence” and ask what you could produce today. The gaps are your plan.
2. A review calendar. Lift the cadences above into the maintenance plan, with owners.
3. A contract annex. The supplier clauses in section 5.1.4 are a ready-made starting point for your next integration contract.

And check what your own Member State has published, because that is the text that actually binds you. In France, ANSSI’s ReCyF has been available as a working version since March 2026. Belgium has CyberFundamentals. Greece, Germany, Finland and Spain each have their own. ENISA lists them in its Annex I.

A framework that is not binding on you is still the clearest available description of what “demonstrable” means. Borrow the evidence list, keep your own legal basis straight.

References

• ENISA, Technical Implementation Guidance on Commission Implementing Regulation (EU) 2024/2690 (June 2025, v1.0; includes the mapping table). © European Union Agency for Cybersecurity (ENISA), 2025, reused under CC BY 4.0; this article summarises and comments on the source rather than reproducing it.
• Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024
• Directive (EU) 2022/2555, NIS2