NIS2 OT Security: ISO 27001 and IEC 62443 Map

At 02:17 on a Monday, a water treatment operator receives an alarm from a dosing system. The chemical feed is still within safety limits, but one PLC is reporting irregular commands, the engineering workstation is showing failed logins from a vendor VPN account, and the SOC analyst on duty is asking a question nobody wants to answer under pressure.

Is this an IT incident, an OT incident, a safety event, or a NIS2-reportable significant incident?

The plant has firewalls. It has ISO documentation. It has a supplier spreadsheet. It even has an incident response plan. But the plan was written for email compromise and cloud outages, not for a legacy controller that cannot be patched during production, a vendor who needs remote access to restore service, and a regulator who expects evidence within the NIS2 reporting clock.

The same problem appears in boardrooms. A CISO at a regional energy provider may have an ISO/IEC 27001:2022 certified Information Security Management System for corporate IT, while the operational technology estate remains a spaghetti junction of PLCs, RTUs, HMIs, historians, engineering workstations, industrial switches and vendor access paths. The CEO’s question is simple: “Are we covered? Can you prove it?”

For many essential and important entities, the honest answer is uncomfortable. They are partly covered. They can partly prove it. But NIS2 OT security requires more than generic IT compliance.

It requires a unified operating model that connects ISO/IEC 27001:2022 governance, ISO/IEC 27002:2022 control language, IEC 62443 industrial engineering practices, NIS2 Article 21 cybersecurity risk management measures and NIS2 Article 23 incident reporting evidence.

That is the bridge this guide builds.

Why NIS2 OT security is different from ordinary IT compliance

NIS2 applies to many public and private entities that provide in-scope services in the EU, including essential and important entities across sectors such as energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space, postal services, waste management, manufacturing, chemicals, food, digital providers and research.

The Directive requires appropriate and proportionate technical, operational and organisational measures to manage cyber risks, prevent or minimise incident impact and protect continuity of services. Article 21 includes an all-hazards approach covering risk analysis, security policies, incident handling, business continuity, crisis management, supply chain security, secure acquisition and maintenance, vulnerability handling and disclosure, effectiveness assessment, cyber hygiene, training, cryptography, HR security, access control, asset management, MFA or continuous authentication, secure communications and emergency communications where appropriate.

Those requirements sound familiar to an ISO/IEC 27001:2022 team. In OT, every one of them behaves differently.

A vulnerability in a web server can often be patched within days. A vulnerability in a turbine controller may require vendor validation, a maintenance window, a safety review and fallback operating procedures. A laptop can be rebuilt. A production HMI may depend on a legacy operating system because the industrial application has not been certified for a newer platform. A SOC playbook may say “isolate the host,” while the OT engineer replies, “not until we know whether isolation affects pressure control.”

The difference is not only technical. IT typically prioritizes confidentiality, integrity and availability. OT prioritizes availability, process integrity and safety. A security control that introduces latency, requires a reboot or interrupts a physical process may be unacceptable without engineering approval.

NIS2 does not exempt OT from cybersecurity risk management. It expects the organization to prove that controls are appropriate for the risk and proportionate to the operational reality.

The control stack: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 and IEC 62443

A defensible NIS2 OT security program starts with a layered control stack.

ISO/IEC 27001:2022 provides the management system. It requires the organization to define context, interested parties, regulatory obligations, ISMS scope, interfaces and dependencies. It also requires leadership ownership, an information security policy, risk assessment, risk treatment, a Statement of Applicability, documented information, internal audit, management review and continual improvement.

ISO/IEC 27002:2022 provides the control vocabulary. For OT, the most important controls often include supplier security, ICT supply chain risk management, incident planning, business continuity readiness, legal and contractual requirements, asset management, access control, vulnerability management, backups, logging, monitoring, network security and segregation of networks.

IEC 62443 provides the industrial security engineering model. It helps translate management system requirements into OT practices such as zones, conduits, security levels, asset owner responsibilities, system integrator responsibilities, product supplier expectations, remote access restrictions, least functionality, account management, hardening and lifecycle controls.

Clarysec uses this stack because it avoids two common failures. First, it prevents ISO implementation from becoming too generic for OT. Second, it prevents IEC 62443 engineering work from becoming disconnected from board accountability, NIS2 reporting duties and audit evidence.

Clarysec’s IoT / OT Security Policy states the bridge directly:

To ensure that all deployments align with ISO/IEC 27001 controls and applicable sector-specific guidance (e.g. IEC 62443, ISO 27019, NIST SP 800-82).

That sentence matters. The policy is not only a device hardening checklist. It connects ISO governance, OT sector guidance and operational security.

Start with scope: what OT service must be protected?

Before mapping controls, define the OT service in business and regulatory language.

A plant manager may say, “We operate the packaging line.” A NIS2 assessment should say, “This production process supports an essential or important service and depends on PLCs, HMIs, engineering workstations, historians, industrial switches, remote vendor access, a maintenance contractor, a cloud analytics feed and an enterprise identity service.”

ISO/IEC 27001:2022 clauses 4.1 to 4.4 are useful because they force the organization to identify internal and external issues, interested parties, legal and contractual requirements, ISMS boundaries, interfaces and dependencies. For NIS2 OT security, that means mapping not only the headquarters network but also the industrial systems and service dependencies that affect continuity, safety and regulated delivery.

NIST CSF 2.0 reinforces the same logic. Its GOVERN function calls for understanding mission, stakeholders, dependencies, legal and regulatory obligations, critical services and services the organization depends on. Organizational Profiles provide a practical method for scoping a current state, defining a target state, analysing gaps and producing a prioritized action plan.

For an OT environment, Clarysec typically starts with five questions:

1. Which regulated or critical service does this OT environment support?
2. Which OT assets, networks, data flows and third parties are required for that service?
3. Which safety, availability and operational constraints affect security controls?
4. Which legal, contractual and sector obligations apply, including NIS2, GDPR, DORA where relevant, customer contracts and national rules?
5. Which parts of the environment are inside the ISMS, and which are external dependencies requiring supplier controls?

Many NIS2 programs fail here. They scope around corporate IT because it is easier to inventory. Auditors and regulators will not be impressed if the most critical service dependency appears only as a vague line item called “factory network.”

A practical NIS2 OT control map

The table below shows how to turn NIS2 Article 21 themes into ISO/IEC 27001:2022, ISO/IEC 27002:2022 and IEC 62443 evidence. It is not a replacement for a formal risk assessment, but it gives CISOs, OT managers and compliance teams a practical starting point.

This map is intentionally evidence-focused. Under NIS2, saying “we have segmentation” is not enough. You need to show why segmentation is appropriate, how it is implemented, how exceptions are approved and how the design reduces impact on the regulated service.

Segmentation: the first OT control auditors will test

If the 02:17 incident involved an attacker moving from an office laptop to an engineering workstation, the first audit question would be obvious: why could that path exist?

The IoT / OT Security Policy is explicit:

OT systems must operate within dedicated networks isolated from enterprise IT and internet-facing systems.

For smaller environments, the Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME gives a practical baseline:

All Internet of Things (IoT) and Operational Technology (OT) devices must be placed on a separate Wi-Fi or VLAN network

For a mature critical infrastructure operator, segmentation should be designed around OT zones and conduits. Enterprise users should not directly access PLC networks. Vendor connections should terminate in controlled access zones. Historian replication should use approved pathways. Safety systems should be isolated according to risk and engineering requirements. Wireless OT networks should be justified, hardened and monitored.

Zenith Blueprint: An Auditor’s 30-Step Roadmap, in the Controls in Action phase, Step 20, explains the principle behind ISO/IEC 27002:2022 network security:

Industrial control systems should be isolated from office traffic.

It also warns that network security requires secure architecture, segmentation, access control, encryption in transit, monitoring and defence in depth.

In Zenith Controls: The Cross-Compliance Guide, ISO/IEC 27002:2022 control 8.22, Segregation of Networks, is treated as a preventive control supporting confidentiality, integrity and availability, aligned to the Protect cybersecurity concept, with system and network security as its operational capability and Protection as its security domain.

That classification is useful for NIS2 evidence because segmentation is not a decorative diagram. It is a preventive control designed to reduce blast radius and preserve essential service continuity.

Vulnerability management when OT systems cannot just be patched

NIS2 requires secure acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure. In IT, vulnerability management often means scan, prioritise, patch and verify. OT adds constraints.

A critical HMI might only be patchable during a planned outage. A PLC firmware update might require vendor involvement. A safety-certified system might lose certification if modified incorrectly. Some legacy devices may have no vendor support at all.

Zenith Blueprint, Controls in Action phase, Step 19, provides the right audit logic for technical vulnerabilities:

For systems that cannot be patched immediately, perhaps due to legacy software or downtime restrictions, implement compensating controls. This might include isolating the system behind a firewall, limiting access, or increasing monitoring. And in all cases, record and formally accept the residual risk , showing that the issue is not forgotten.

The SME policy baseline is similarly practical:

The inventory must be reviewed quarterly to identify outdated, unsupported, or unpatched devices

In Zenith Controls, ISO/IEC 27002:2022 control 8.8, Management of Technical Vulnerabilities, is mapped as a preventive control supporting confidentiality, integrity and availability, aligned to Identify and Protect, with threat and vulnerability management as its operational capability across Governance, Ecosystem, Protection and Defense domains.

A strong OT vulnerability file should include:

• Asset identifier, owner, zone and criticality
• Vulnerability source, such as vendor advisory, scanner, integrator notice or threat intelligence
• Safety and availability constraints
• Patch feasibility and planned maintenance window
• Compensating controls, such as isolation, access control lists, disabled services or increased monitoring
• Risk owner approval and residual risk acceptance
• Verification evidence after remediation or compensating control implementation

This turns “we cannot patch” from an excuse into auditable risk treatment.

Remote vendor access: the NIS2 and IEC 62443 flashpoint

Most OT incidents have a third-party dimension somewhere. A vendor account. An integrator laptop. A remote maintenance tool. A shared credential. A firewall exception that was temporary three years ago.

NIS2 Article 21 explicitly includes supply chain security, supplier-specific vulnerabilities, supplier cybersecurity practices and secure development procedures. NIST CSF 2.0 is also detailed on this point through supplier criticality, contract requirements, due diligence, ongoing monitoring, incident coordination and exit provisions.

Clarysec’s Third-Party and Supplier Security Policy - SME states the principle in plain language:

Suppliers must be granted access only to the minimum systems and data required to perform their function.

For OT, minimum access means more than role-based access in an application. Vendor access should be:

• Pre-approved for a defined maintenance purpose
• Time-bound and disabled by default
• Protected by MFA or continuous authentication where appropriate
• Routed through a secure jump host or controlled remote access platform
• Limited to the relevant OT zone or asset
• Logged, monitored and, for high-risk access, session-recorded
• Reviewed after completion
• Covered by contractual security and incident notification obligations

The enterprise IoT / OT Security Policy includes a dedicated remote access requirement:

Remote access (for management or vendor servicing) must:

That clause anchors the governance point, while the detailed requirements should be implemented in access procedures, supplier agreements, technical configuration and monitoring workflows.

In Zenith Controls, ISO/IEC 27002:2022 control 5.21, Managing information security in the ICT supply chain, is classified as a preventive control supporting confidentiality, integrity and availability, aligned to the Identify concept, with supplier relationships security as its operational capability and Governance, Ecosystem and Protection as domains.

For OT, that mapping helps explain why remote access evidence belongs in supplier risk, identity governance, network security, incident response and continuity files at the same time.

Incident response: the NIS2 clock meets the control room

Back to the 02:17 alarm. The organization has to decide whether the event is significant under NIS2. Article 23 requires notification without undue delay of significant incidents affecting service provision. The sequence includes an early warning within 24 hours of awareness, an incident notification within 72 hours, intermediate updates if requested and a final report no later than one month after the incident notification, or a progress report if the incident is still ongoing.

In OT, incident response must answer questions IT playbooks often ignore:

• Can the affected device be isolated without creating a safety risk?
• Who has authority to stop production or switch to manual mode?
• Which logs are volatile and need immediate preservation?
• Which vendor or integrator must be contacted?
• Is the event malicious, accidental, environmental or caused by misconfiguration?
• Could there be cross-border impact or impact on service recipients?
• Is personal data involved, such as badge logs, CCTV, employee data or customer service records?

The SME OT policy gives a simple anomaly escalation rule:

Any anomalies must be reported immediately to the General Manager for further action

It also includes a safety-aware containment principle:

The device must be disconnected from the network immediately, where safe to do so

Those last five words are critical. OT response cannot blindly copy IT containment actions. “Where safe to do so” should be reflected in runbooks, escalation matrices, training and tabletop exercises.

NIST CSF 2.0 maps well here. Its Respond and Recover outcomes cover triage, categorisation, escalation, root cause analysis, evidence integrity, stakeholder notification, containment, eradication, restoration, backup integrity checks and recovery communications.

Build a risk-to-control evidence line

A practical way to avoid fragmented compliance is to build one evidence line from risk to regulation to control to proof.

Scenario: a remote compressor vendor requires access to an engineering workstation in the OT network. The workstation can modify PLC logic. The vendor account is always enabled, shared by multiple vendor engineers and protected only by a password. The workstation runs software that cannot be upgraded until the next maintenance outage.

Write the risk scenario in the risk register:

“Unauthorized or compromised vendor remote access to OT engineering workstation could lead to unauthorized PLC logic changes, production disruption, safety impact and NIS2-reportable service interruption.”

Then map the controls and obligations.

The treatment plan should disable standing vendor access, require named vendor identities, enforce MFA, route access through a controlled jump server, limit access to the engineering workstation, require maintenance ticket approval, record privileged sessions, monitor commands and abnormal traffic, document the unpatched workstation as a vulnerability exception and test incident response for suspicious vendor activity.

Zenith Blueprint, Risk Management phase, Step 13, gives the SoA traceability logic:

Cross-reference regulations: If certain controls are implemented specifically to comply with GDPR, NIS2, or DORA, you can note that in either the Risk Register (as part of risk impact justification) or in the SoA notes.

The practical lesson is simple. Do not keep NIS2, ISO and OT engineering evidence in separate silos. Add columns in the risk register and SoA for NIS2 Article 21 theme, ISO/IEC 27002:2022 control, IEC 62443 requirement family, evidence owner and audit status.

Where GDPR and DORA fit in OT security

OT security is not always only about machines. Critical infrastructure environments often process personal data through CCTV, access control systems, badge logs, workforce safety systems, maintenance tickets, vehicle tracking, visitor systems and customer service platforms.

GDPR requires personal data to be processed lawfully, fairly and transparently, collected for specified purposes, limited to what is necessary, kept accurate, retained only as long as needed and protected with appropriate technical and organisational measures. It also requires accountability, meaning the controller must be able to demonstrate compliance.

For OT, this means access logs and monitoring records should not become uncontrolled surveillance data stores. Retention, access rights, purpose limitation and breach assessment must be designed into logging and monitoring.

DORA may apply where financial entities are involved, or where an ICT third-party service provider supports financial-sector operational resilience. DORA covers ICT risk management, incident reporting, resilience testing and ICT third-party risk. For financial entities that are also essential or important entities under NIS2 transposition rules, DORA can act as the sector-specific regime for overlapping obligations, while coordination with NIS2 authorities may remain relevant.

The same evidence disciplines apply: asset identification, protection, detection, continuity, backup, third-party risk, testing, training and management oversight.

The audit lens: one control, multiple assurance perspectives

A strong NIS2 OT security implementation should survive multiple audit perspectives.

This is why Clarysec treats Zenith Controls as a cross-compliance compass. Its control attributes help explain the purpose of official ISO/IEC 27002:2022 controls, while the mapping approach connects those controls to NIS2, NIST CSF, supplier governance, continuity and audit evidence.

Common NIS2 OT implementation pitfalls

The most common OT security failures are rarely caused by a lack of documents. They are caused by documents that do not match the plant.

Pitfall 1: IT owns the NIS2 program, but OT owns the risk. Operations, engineering, safety and maintenance must be involved.

Pitfall 2: The asset inventory stops at servers. An OT inventory must include PLCs, RTUs, HMIs, historians, engineering workstations, industrial switches, sensors, gateways, remote access appliances and vendor-managed components.

Pitfall 3: Segmentation exists on a diagram but not in firewall rules. Auditors will ask for enforcement, change control and monitoring evidence.

Pitfall 4: Vulnerability exceptions are informal. Legacy constraints are acceptable only when documented, approved, monitored and revisited.

Pitfall 5: Vendor access is treated as a supplier issue only. It is also an access control, logging, monitoring, network security, incident response and continuity issue.

Pitfall 6: Incident response ignores safety. OT playbooks must define who can isolate devices, stop processes, switch modes or contact regulators.

Pitfall 7: NIS2 reporting is not rehearsed. The 24-hour and 72-hour decision process should be tested before a real event.

Clarysec’s implementation path from board accountability to OT evidence

A practical NIS2 OT security implementation can follow this sequence:

1. Confirm NIS2 scope, entity classification and service criticality.
2. Define OT scope inside the ISMS, including interfaces and dependencies.
3. Build an OT asset and data flow inventory.
4. Identify legal, contractual, safety, privacy and sector obligations.
5. Run OT-specific risk assessment workshops with engineering, operations, IT, SOC, procurement and management.
6. Map risk treatment to ISO/IEC 27002:2022 controls, NIS2 themes and IEC 62443 implementation patterns.
7. Update the Statement of Applicability with OT justification and evidence owners.
8. Implement priority controls: segmentation, vendor access, vulnerability handling, monitoring, backups and incident response.
9. Update policies and procedures, including OT security, supplier security, remote access, incident response and business continuity.
10. Run tabletop and technical validation exercises.
11. Prepare audit packs for NIS2, ISO/IEC 27001:2022, customer assurance and internal governance.
12. Feed findings into management review and continual improvement.

This reflects the operating model in Zenith Blueprint, especially Step 13 for risk treatment and SoA traceability, Step 14 for policy development and regulatory cross-references, Step 19 for vulnerability management and Step 20 for network security.

The same approach uses Clarysec policies to turn framework language into operational rules. The enterprise IoT / OT Security Policy requires security architecture review before deployment:

All new IoT/OT devices must undergo a Security Architecture Review before deployment. This review must validate:

It also states:

All traffic within and between IoT/OT networks must be continuously monitored using:

Those clauses create governance anchors. Implementation evidence may include OT IDS alerts, firewall logs, SIEM correlation, baseline traffic profiles, anomaly tickets and response records.

What good NIS2 OT evidence looks like

A NIS2 OT evidence pack should be practical enough for engineers and structured enough for auditors.

For segmentation, include approved architecture, zone and conduit diagrams, firewall rule exports, change records, periodic rule reviews, exception records and monitoring alerts.

For vendor access, include supplier criticality assessment, contract clauses, approved access procedure, named accounts, MFA evidence, access logs, session recordings, periodic access review and offboarding records.

For vulnerability management, include inventory, advisory sources, passive discovery outputs, vulnerability tickets, patch plans, compensating controls, risk acceptance and closure evidence.

For incident response, include playbooks, escalation contacts, NIS2 reporting decision tree, tabletop results, incident tickets, authority notification drafts, evidence handling rules and lessons learned.

For continuity, include OT backup strategy, offline or protected backups, restore test results, critical spare parts list, manual operating procedures, recovery priorities and crisis communication plans.

For governance, include board or management approval, role assignments, training records, internal audit results, KPIs, risk review minutes and management review decisions.

This evidence model aligns with ISO/IEC 27001:2022 because it supports risk treatment, documented information, performance evaluation and continual improvement. It aligns with NIS2 because it demonstrates appropriate and proportionate measures. It aligns with IEC 62443 because it can be traced to OT architecture and engineering controls.

Turn your OT security program into auditable NIS2 readiness

If your OT environment supports a critical or regulated service, waiting for a regulator, customer or incident to expose the gaps is the wrong strategy.

Start with one high-impact use case: remote vendor access to a critical OT zone, vulnerability handling for unsupported industrial assets, or segmentation between enterprise IT and OT. Build the risk scenario, map it to NIS2 Article 21, select ISO/IEC 27002:2022 controls, translate them into IEC 62443 implementation patterns and collect the evidence.

Clarysec can help you accelerate that work with Zenith Blueprint, Zenith Controls, the IoT / OT Security Policy, the Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME and the Third-Party and Supplier Security Policy - SME.

Your next action: choose one OT service, map its assets and dependencies, and create a risk-to-control evidence line this week. If you want a structured implementation path, Clarysec’s 30-step roadmap and cross-compliance toolkit can turn that first line into a complete NIS2 OT security program.