NIS2 Manufacturing Checklist: 10 Article 21 Controls Mapped to IEC 62443-2-1 for Annex II Entities
National competent authorities across Germany, the Netherlands, Belgium, and several other EU member states have begun opening enforcement registers to Annex II entities — manufacturing plants included. The October 2024 NIS2 transposition deadline is past. The generic NIS2 checklists circulating online were built for IT departments: they describe policies, training records, and access reviews without mentioning the SCADA historian, the patch exception register, or the maintenance access log that OT-focused auditors will actually request.
This checklist maps each of the 10 NIS2 Article 21(2) security measure categories to the corresponding IEC 62443-2-1 Cybersecurity Management System (CSMS) clause — the OT-native industrial security framework that EU authorities recognise as state-of-the-art for industrial environments. For each control you get: what the directive requires, which IEC 62443-2-1 clause delivers it, and the specific OT evidence that belongs in your audit package.
Does This Apply to Your Manufacturing Business? NIS2 Annex II Scope
NIS2 Directive Annex II, Section 14 places six manufacturing sub-sectors in scope:
- Medical devices (Regulation (EU) 2017/745) and in vitro diagnostic medical devices (Regulation (EU) 2017/746)
- Computer, electronic and optical products (NACE C26)
- Electrical equipment (NACE C27)
- Machinery and equipment not elsewhere classified (NACE C28)
- Motor vehicles, trailers and semi-trailers (NACE C29)
- Other transport equipment (NACE C30)
Under Article 3(2) of the Directive, most manufacturing entities are classified as important entities unless a member state designates them as essential. The distinction matters: essential entities face proactive supervisory powers and a higher fine ceiling, while important entities are supervised reactively — but both face the full 10-measure Article 21(2) requirement without exception.
Get the NIS2 Article 21 Compliance Checklist
90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.
The size threshold applies at group level across all EU subsidiaries, not per individual legal entity. Meeting either size criterion is sufficient:
| Entity Type | Size Criterion | Fine Ceiling (Art.34) |
|---|---|---|
| Important entity | 50+ employees or €10M+ annual turnover | Up to €7,000,000 or 1.4% of worldwide annual turnover, whichever is higher |
| Essential entity (member-state designated) | Exceeds medium-enterprise ceiling, or nationally designated critical | Up to €10,000,000 or 2% of worldwide annual turnover, whichever is higher |
Quick decision check: Does your EU group manufacture products in NACE C26–C30 or produce medical or IVD devices? Does your group have 50 or more employees, or annual turnover above €10 million? If both answers are yes, NIS2 Article 21 applies to your organisation in full. For a broader overview of compliance obligations, see our NIS2 manufacturing compliance guide.
Why IEC 62443-2-1 Is the Right Starting Point for NIS2 Art.21 Compliance
NIS2 Article 21(1) requires measures reflecting “the state of the art” — a deliberate technology-neutral standard. For manufacturing OT environments, IEC 62443-2-1 (“Requirements for an IACS Security Management System”) is the recognised state-of-the-art management framework for industrial asset owners. ENISA references IEC 62443 alongside ISO 27001 in its NIS2 technical implementation guidance as a cybersecurity risk management framework.
Where ISO 27001 describes an information security management system built for IT environments, IEC 62443-2-1 defines a Cybersecurity Management System (CSMS) specifically for Industrial Automation and Control Systems (IACS). Its clauses govern risk identification at the zone-and-conduit level, maintenance access governance, OT personnel competency, and OT-specific incident response — the exact implementation challenges NIS2 Art.21 creates for manufacturers.
One scoping note worth stating clearly: Annex II manufacturing entities are not subject to Commission Implementing Regulation (EU) 2024/2690, which establishes specific technical requirements for a defined subset of Annex I digital infrastructure and digital service providers (DNS providers, cloud operators, managed service providers, and others). Manufacturing entities apply NIS2 Art.21 under the risk-based proportionality principle of Art.21(1). CIR 2024/2690’s technical measures serve as a useful state-of-the-art reference but are not legally binding for Annex II manufacturers.
A CSMS implemented to IEC 62443-2-1 does not automatically guarantee NIS2 compliance — the directive’s Article 23 incident reporting obligations and Article 20 management accountability requirements sit outside the standard’s scope — but it closes the majority of Art.21(2)(a)–(j) gaps for OT environments.
The 10-Item NIS2 Manufacturing Checklist: Art.21(2)(a)–(j) Mapped to IEC 62443-2-1
The table below maps each Art.21(2) measure category to the relevant IEC 62443-2-1 clause, the OT-specific implementation requirement, and the primary evidence an auditor will request. Items marked with IEC 62443-2-4 or IEC 62443-3-3 note where companion standards in the IEC 62443 family supplement the management-system requirements of 62443-2-1 with system-level or service-provider-level controls.
| # | NIS2 Art.21(2) Measure | IEC 62443 Primary Clause | OT Implementation | Key Evidence for Audit |
|---|---|---|---|---|
| (a) | Risk analysis and information security policies | 62443-2-1 §4.2.3; §4.3.2.3; §4.3.2.6 | OT risk register covering PLCs, SCADA servers, HMIs, and historians by zone and conduit; updated whenever production, supplier, or technology changes | Risk register (versioned, owner-named, board sign-off dates recorded) |
| (b) | Incident handling | 62443-2-1 §4.3.4.5 | Shift-pattern escalation paths; OT zone isolation playbook; Art.23 24-hour early warning workflow integrated with operations | Incident playbook (tested, dated); OT incident log with timestamps; NCA notification records if threshold triggered |
| (c) | Business continuity, backup management, disaster recovery, crisis management | 62443-2-1 §4.3.2.5 | PLC configuration snapshots (versioned, encrypted); SCADA historian data backups (off-site); OT RTO/RPO defined per critical system separately from IT systems | Backup schedule with last-run timestamps; recovery test record showing date, system, and RTO achieved |
| (d) | Supply chain security — direct suppliers and service providers | IEC 62443-2-4 (IACS service provider security requirements) | OEM remote access agreements; contractual security clauses for all vendors with OT network access; pre-access screening; session-level logging for integrators holding admin credentials | Vendor contracts with security clauses; third-party session log; pre-access screening records |
| (e) | Security in acquisition, development, and maintenance, including vulnerability handling and disclosure | 62443-2-1 §4.3.4.3 | CVE tracking for PLC and SCADA firmware versions; patch scheduling within maintenance windows; formal patch exception register for vendor-locked or safety-certified assets | Vulnerability register (CVE ID, asset, status, exception reason); patch exception log with compensating controls and management sign-off |
| (f) | Policies and procedures to assess the effectiveness of cybersecurity risk-management measures | 62443-2-1 §4.2.3 (CSMS review cycle) | Minimum quarterly review for entities with significant OT exposure; board-level KPI reporting; review triggered by any material change to production systems, suppliers, or technology | KPI dashboard (last update date, responsible owner); board meeting minutes confirming effectiveness review |
| (g) | Basic cyber hygiene practices and cybersecurity training | 62443-2-1 §4.3.3.2 | Role-specific training for plant operators, OT engineers, shift supervisors, and maintenance contractors — not only IT staff; management training is a separate Art.20 obligation independently enforceable | Training completion logs (participant name, module, date, assessment score); management training records; contractor induction records |
| (h) | Policies and procedures regarding cryptography and, where appropriate, encryption | IEC 62443-3-3 (system-level cryptographic requirements) | Protocol exception register for unencrypted OT protocols (Modbus, DNP3, older PROFINET versions); TLS/IPsec minimum for IT/OT boundary communications; hardware-backed keys (TPM/HSM) for SCADA data at rest where technically feasible | Cryptography policy document; encryption inventory; exception register with compensating controls and board sign-off |
| (i) | Human resources security, access control policies, and asset management | 62443-2-1 §4.3.3.2; §4.3.3.5 | Every PLC, HMI, SCADA server, historian, engineering workstation, and RTU inventoried with criticality classification; least-privilege vendor accounts revoked between maintenance windows; ex-contractor offboarding executed on termination day | SCADA/ICS asset register (make, model, firmware, Purdue level, criticality, last patch date); access review log (quarterly, timestamped); offboarding records |
| (j) | Multi-factor authentication or continuous authentication; secured communications | 62443-2-1 §4.3.3.6; IEC 62443-3-3 SR 1.1, SR 1.2 | MFA enforced at IT/OT boundary (VPN gateway, jump server) even where legacy PLCs cannot natively support it; documented MFA exceptions for safety-critical systems with response-time constraints, with compensating controls stated | MFA implementation record (systems covered, enforcement point); jump server session logs; exceptions register with compensating controls |
Three items warrant additional explanation for OT environments, because generic compliance guidance consistently gets them wrong.
Art.21(2)(d) — Supply Chain: The OEM Persistent Credential Problem
Automation vendors and system integrators regularly hold persistent administrative credentials on production control networks, established during commissioning years or decades before NIS2 took effect. Article 21(2)(d) requires supply chain security “including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” In OT terms, this means documenting every active OEM credential, establishing pre-access screening, and logging every remote session. Accounts that persist indefinitely between maintenance windows represent an uncontrolled access vector that no other control in the checklist above compensates for. For a detailed treatment of supply chain obligations, see our NIS2 supply chain security guide.
Art.21(2)(e) — Vulnerability Handling: The Patch Exception That Must Be Written Down
Most manufacturing entities cannot patch PLCs or safety-certified control systems without vendor authorisation, extended maintenance windows, or regulatory recertification. NIS2 Art.21(1)’s proportionality principle means an unpatched 20-year-old PLC is not automatically a compliance failure. An undocumented exception is. Every unpatched OT asset requires: the CVE reference (or a statement that no active CVE applies), the reason for non-remediation, the compensating control applied, the management risk acceptance signature, and the next scheduled review date. A missing patch exception log is consistently among the most common findings in OT-environment NIS2 inspections. See our vulnerability and patch management guide for the full framework.
Art.21(2)(i) — Asset Management: The Register Comes Before the Policies
An OT-environment audit does not begin with your policies — it begins with your asset register. An auditor who counts 47 active PLCs on the production floor and finds 23 entries in your register treats the gap as an Art.21(2)(i) failure regardless of how well-written your information security policy is. The register must cover every PLC, HMI, SCADA server, engineering workstation, historian, RTU, and OT network device, each with make, model, firmware version, IP/MAC address, location (Purdue level 0–3), assigned owner, criticality tier, and last patch date or exception reference. For access control and identity management, see our NIS2 access control guide.
OT Evidence Items Auditors and Enforcement Authorities Request From Manufacturing Plants
Policy documents satisfy the framework requirement. What OT-environment auditors actually request on inspection day is a different list entirely — six categories of operational evidence that generic NIS2 audit preparation guides do not cover at OT-specific depth.
1. SCADA/ICS Asset Register
Every PLC, HMI, SCADA server, historian, engineering workstation, RTU, and OT network device with: asset ID, make, model, firmware version, IP/MAC address, plant and zone location (Purdue level 0–3), criticality tier (A = production stops without this asset; B = significant operational impact; C = minor impact), assigned owner, and last patch date or patch exception reference. A gap between the physical asset count on the floor and the register count is the most common Art.21(2)(i) finding in manufacturing OT audits.
2. Network Topology Documentation
A current, version-controlled network diagram showing: the IT/OT boundary, DMZ architecture and firewall placement, zone and conduit boundaries per IEC 62443-3-2, VLAN configuration, and all remote access entry points. The diagram must carry a version number and date — an undated diagram cannot demonstrate that it reflects current operational state. The firewall ruleset and VLAN configuration accompany the diagram as supplementary evidence; auditors comparing your diagram against a live configuration audit will verify both match.
3. Patch Exception Log with Compensating Controls
For every OT asset carrying an unpatched firmware version: the CVE reference (or a statement that no active CVE applies), the specific reason for non-remediation (vendor-locked firmware, safety recertification required, production-uptime constraint), the compensating control applied (network isolation, passive monitoring, manual configuration review cycle), the management sign-off (CISO and/or board), and the next scheduled review date. “Cannot patch” without this documentation is an Art.21(2)(e) finding. “Cannot patch, here is the exception log with board sign-off and compensating controls” is a defensible compliance position. Every control you claim must leave a traceable digital record an auditor can follow.
4. Maintenance Access Log
Every vendor, OEM, and system integrator remote session: date, time window, duration, technician name and organisation, pre-authorisation ticket reference, system accessed (asset ID from your register), and actions performed. Where a jump server is in place, session recordings accompany the text log. The maintenance access log closes two Art.21 requirements simultaneously: Art.21(2)(d) supply chain control and Art.21(2)(i) access management. The most common gap in manufacturing plants is that automation engineer maintenance happens on direct console connections to PLCs that are never routed through any logging infrastructure. That gap will appear in an inspection.
5. Backup and Recovery Test Records
Not backup schedule documents — evidence of tested recovery. A PLC configuration snapshot entry records: device asset ID, configuration version, snapshot date, storage location, and responsible operator. A SCADA historian backup record shows: backup frequency, last backup date, storage location (off-site or air-gapped), and encryption status. The recovery test log records: the date of the test, the system restored, the actual recovery time achieved, and whether it met the defined Recovery Time Objective. Untested backups satisfy Art.21(2)(c) on paper; an auditor will ask when the last restoration drill occurred. See our manufacturing business continuity guide for the full framework including RTO/RPO planning.
6. OT Incident Log
Every anomaly that could indicate a cyber event — unexpected PLC programme change, unusual SCADA login attempt, unexplained process variable deviation, firmware modification outside a scheduled maintenance window — must be logged, classified, and reviewed. This log feeds both Art.21(2)(b) incident handling and the Art.23 significance assessment. A manufacturing entity that receives an NCA enquiry and cannot produce a timestamped log of the anomaly chain leading to the incident has failed two obligations simultaneously. For Art.23 notification timelines and significance thresholds, see our Article 23 incident notification guide.
Structuring Your OT Evidence Package for Audit Readiness
Audit readiness in OT environments comes down to one operating principle: living documentation, not static policies. Evidence must be version-controlled, owner-assigned, and retrievable on demand. In practice: any auditor request for any document should be met by navigating two levels of a centralised evidence repository.
Three structural requirements apply across all six OT evidence categories above:
- Version control everything. Network topology diagrams, firewall rulesets, asset registers, and exception logs must carry version numbers and change dates. An undated diagram or a register with no revision history cannot demonstrate it reflects current operational state.
- Assign owners by name, not by role title. “IT Security Team” is not an evidence owner. Each document must name a specific responsible individual. When that person leaves the organisation, the evidence package updates within the offboarding window — or the Art.21(2)(i) HR security control fails at that exact moment.
- Management sign-off on every risk exception. Every patch exception, every MFA waiver, every unencrypted protocol in your cryptography exception register must carry a signed management acceptance statement. Under Article 20 of the Directive, management bodies bear personal accountability for approving cybersecurity risk management measures. Exceptions not approved at the appropriate level may not survive an enforcement review.
For brownfield plants where full documentation is a multi-year project, regulators across the EU have consistently signalled that a credible roadmap with documented exceptions, assigned owners, and staged closure dates satisfies audit more readily than an undocumented claim of full compliance. Start with the six OT evidence categories in Section 4 — they are where auditors begin, and building them reveals which policy gaps to address next. For the risk assessment foundation, see our NIS2 risk assessment guide.
Frequently Asked Questions
Are Annex II manufacturing entities required to comply with CIR 2024/2690?
No. Commission Implementing Regulation (EU) 2024/2690 establishes specific technical requirements for a defined subset of Annex I entities: DNS providers, TLD registries, cloud service providers, data centre operators, CDN providers, managed service providers, online marketplaces, and trust service providers. Annex II manufacturing entities apply NIS2 Art.21 under the risk-based proportionality standard of Art.21(1). CIR 2024/2690’s technical measures are widely referenced as a state-of-the-art baseline, but adopting them for manufacturing OT is voluntary.
What does “state of the art” mean for legacy OT that cannot run modern security tools?
State of the art under Art.21(1) is explicitly calibrated against “implementation costs, the size of the entity, […] the likelihood and severity of incidents.” For a PLC that cannot support endpoint agents or encrypted firmware, state-of-the-art measures are network zone isolation from internet-facing segments, passive network monitoring, and a documented compensating control register — not system replacement. The compensating controls must be documented, tested, and management-approved. Undocumented compensating controls are treated the same as absent controls.
Does ISO 27001 certification satisfy NIS2 for manufacturing entities with OT environments?
ISO 27001 provides a strong foundation but does not automatically satisfy NIS2 for OT environments. ISO 27001 addresses IT-focused information security management; IEC 62443-2-1 provides the OT complement covering zone-and-conduit architecture, OT personnel security, and maintenance access governance. Neither certification addresses NIS2’s Art.23 incident reporting obligations or Art.20’s management accountability requirements directly. An entity holding both still needs an Art.23-compliant incident reporting procedure and documented management approval of cybersecurity measures.
Do I need to register with a national competent authority?
In most member states, yes. Registration requirements depend on national transposition: several member states require self-registration by entities meeting Annex II scope criteria. Each EU-based legal entity performing covered manufacturing activities may need to register separately with the competent authority in the member state where it operates. Contact the NCA in each relevant member state to confirm the registration process and timeline. For an overview of incident reporting obligations, see the linked guide.
This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.
Key Takeaways
Manufacturing entities face a NIS2 compliance reality that generic checklists miss. PLCs, SCADA systems, and OT networks require a different evidence stack than IT environments: one built around zone-based asset registers, patch exception logs, and maintenance access trails, not just policy documents and training records.
The 10-item Art.21(2) checklist above maps your obligations to IEC 62443-2-1’s CSMS framework. The six OT evidence categories in Section 4 are where auditors start on inspection day. Begin with those — SCADA asset register, network topology documentation, patch exception log, maintenance access log, backup test record, and OT incident log — then build the policy layer above. A credible, documented, management-approved programme — even one with staged closure dates and acknowledged gaps — demonstrates proportionate compliance more effectively than a stack of unsigned policies.
Sources
- Article 21 — Cybersecurity Risk-Management Measures, NIS2 Directive (EU) 2022/2555: https://nis-2-directive.com/NIS_2_Directive_Article_21.html
- Article 34 — Administrative Fines, NIS2 Directive (EU) 2022/2555: https://nis-2-directive.com/NIS_2_Directive_Article_34.html
- Article 3 — Essential and Important Entities, NIS2 Directive (EU) 2022/2555: https://nis-2-directive.com/NIS_2_Directive_Article_3.html
- Shieldworkz, “Mapping IEC 62443 to NIS2 & CRA for EU Manufacturers”: https://shieldworkz.com/blogs/mapping-iec-62443-to-nis2-cra-for-eu-manufacturers
- DNV, “Leverage IEC 62443 for EU NIS2 Directive Compliance”: https://www.dnv.com/cyber/insights/articles/leverage-iec-62443-for-eu-nis2-directive-compliance/
- ISMS.online, “NIS 2 Requirements for Manufacturing (NACE C26–C30)”: https://www.isms.online/nis-2/sectors/manufacturing/requirements/
- Kymatio, “NIS2 Audit Evidence Guide: Logs, Training Records & KPIs”: https://kymatio.com/blog/nis2-audit-evidence-checklist
- ISMS.online, “NIS 2 Legacy Systems: Audit-Proof Compensating Controls”: https://www.isms.online/nis-2/requirements/measures/secure-acquisition-development-maintenance/
- Software Defined Automation, “NIS2 & OT Security: From Compliance Risk to Management Strength”: https://www.softwaredefinedautomation.io/resources/blog/nis2-ot-security/
- ENISA, “NIS2 Technical Implementation Guidance”: https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance
Get the NIS2 Article 21 Compliance Checklist
90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.
