PLC/SCADA documentation and NIS2 compliance in 3 seconds.

IT-OT convergence — connecting operational technology networks (PLCs, SCADA, DCS, sensors) to enterprise IT networks (ERP, MES, cloud) — dramatically expands the attack surface of industrial facilities. The principal risks include: lateral movement from IT to OT networks (an attacker who compromises the corporate IT network can reach OT if there is no adequate segmentation); introduction of malware through removable media or remote access tools common in IT but not designed for OT environments; exploitation of legacy OT systems that cannot be patched without production downtime; and supply chain attacks via vendors who have remote access to OT assets. IEC 62443 provides the defence-in-depth framework to address these risks systematically, while NIS2 (Directive EU 2022/2555) makes their management mandatory for operators of essential and important entities.

NIS2 Directive (EU 2022/2555), transposed in Spain as RD-Law [pending transposition], imposes cybersecurity obligations on operators classified as essential entities (energy, water, transport, digital infrastructure, healthcare, space) and important entities (manufacturing with revenue over €10M or 50+ employees in certain sectors). Key obligations include: risk management measures proportionate to the risk (art. 21), including network segmentation, access controls, supply chain security, vulnerability management and encryption; incident reporting to the competent national authority within 24 hours (early warning) and 72 hours (full notification) of becoming aware of a significant incident; business continuity plans and crisis management; and management body accountability — senior management can be held personally liable for NIS2 non-compliance.

Best practice for OT-IT network segmentation follows the Purdue Model adapted for modern industrial environments. At minimum: a DMZ (demilitarised zone) with unidirectional data diodes or tightly controlled firewalls between the OT network (Level 3-0 of the Purdue Model) and the enterprise IT network (Level 4-5); no direct internet access to OT assets; dedicated OT jump servers for any remote access, with multi-factor authentication and session recording; separate VLANs for safety systems (SIS), control systems (DCS/SCADA), field devices and historian servers. NIS2 art. 21(2)(d) specifically requires network segmentation as a mandatory risk management measure. IEC 62443-3-3 formalises the zones and conduits model for OT network design.

Management of Change (MOC) in OT environments is the formal process that must be followed before making any change to a control system, network configuration, PLC program, SCADA software or field device. In OT the consequences of an uncontrolled change can be catastrophic — production shutdown, safety system bypass, or creation of a security vulnerability. A rigorous MOC process includes: change request with technical scope and risk assessment; impact analysis on process safety, production continuity and cybersecurity; staged testing (simulation, test environment, controlled production rollout); approval by process safety, OT cybersecurity and operations; rollback plan; and post-change verification with documented evidence. IEC 62443-2-3 (patch management) and IEC 62443-2-4 (IACS service provider security requirements) provide the framework for OT change management.

Patch management for continuously operating SCADA systems requires a different approach from IT. The core challenge is that OT vendors often require testing patches before approving them, and production downtime has a direct cost. Best practices include: maintain an accurate OT asset inventory with firmware and software versions; subscribe to vendor security advisories and ICS-CERT alerts; assess each patch for applicability, priority (CVSS score in OT context) and vendor approval status; test patches in a representative test environment (not directly on production) and document test results; use planned maintenance windows for production patching; where patching is not feasible, apply compensating controls (network segmentation, enhanced monitoring, access controls); document the risk acceptance decision for systems that remain unpatched with management sign-off. IEC 62443-2-3 provides the framework; NIS2 art. 21 requires a vulnerability management policy.

A PLC backup and recovery procedure must cover: regular automated backup of all PLC programs (ladder logic, function block diagrams), HMI configurations, SCADA database and historian archives — stored offline in a network-isolated location; backup of firmware versions and device configuration files; versioned storage so previous known-good states can be restored; tested restoration procedure with documented recovery time objective (RTO) — how quickly the plant can resume production after a PLC failure or cyberattack; and annual or post-change restoration drills to verify the procedure actually works. An untested backup is not a backup — this is one of the most common gaps found in OT cybersecurity assessments. NIS2 requires business continuity measures including backup management (art. 21(2)(c)), and IEC 62443-3-3 SR 7.3 addresses system backup.