Annex A controls from ISO/IEC 27001 do apply to manufacturing equipment and OT, but they are not applied one-to-one as if OT were standard IT. You normally interpret each control in an OT context, decide what is feasible for each asset class, and document exceptions and compensating measures where direct implementation is not possible.
1. Scope: what counts as OT for Annex A
In a typical plant, Annex A will touch at least:
- PLC/RTU/drive networks and safety controllers
- CNC machines, robots, and test stands with embedded controllers
- SCADA, HMI stations, historians, batch/PCS, and MES interfaces
- Data diodes, firewalls, switches, and wireless used for OT connectivity
- Engineering workstations, programming terminals, and maintenance laptops
OT devices are usually in scope where they process, store, or transmit information relevant to safety, quality, IP, or regulated data, or where compromise could affect production or product integrity.
2. How Annex A controls are typically interpreted for OT
Most Annex A controls are technology-neutral. For OT you focus on how they change in the presence of legacy systems, safety and availability constraints, and validation requirements.
2.1 Organizational and process controls (A.5, A.6, A.7)
- Policies and roles (A.5): Extend information security policies to explicitly cover OT networks, equipment, and third-party OEM access. Define who owns risk decisions for production systems (OT, IT, quality, safety).
- Duties and conflicts (A.6): Address conflicts between production uptime and security. For example, prevent single individuals from both administering OT systems and approving their own changes without oversight.
- Human resources security (A.6/A.7): Ensure onboarding, training, and offboarding cover OT-specific topics such as use of engineering laptops, removable media on machines, and vendor remote access.
2.2 Asset management for OT (A.8)
- Inventory: Maintain an asset register for OT equipment (controllers, HMIs, field devices, gateways), including firmware/OS versions, criticality, and network location. In brownfield environments this is often incomplete; Annex A pushes you to improve it over time.
- Ownership and classification: Assign clear owners for production cells, lines, and systems, and classify OT assets based on impact on safety, quality, IP, and regulatory data, not just business IT impact.
- Acceptable use & handling: Define rules for connecting laptops, tools, and removable media to machines, and for handling configuration backups and recipes.
2.3 Access control in OT (A.9)
Annex A access controls must be adapted to OT constraints and vendor capabilities.
- Logical access to OT: Where possible, use unique accounts for HMI/SCADA and engineering workstations. Where shared accounts or roles are unavoidable (typical on older HMIs), document this limitation and use compensating measures like physical controls and activity logging where available.
- Network access: Implement network segmentation between corporate IT and OT, and between OT zones and cells, even if devices cannot support strong host-based controls. Firewalls, VLANs, and one-way links are common tools.
- Remote access: Strictly govern vendor and integrator access to machines, including pre-authorization, time-bound access, and monitoring. In many regulated plants this becomes one of the highest priority Annex A controls for OT.
- Physical access: Badge controls, locked cabinets, or tool check-out for engineering programming devices can be used when fine-grained logical controls are not feasible.
2.4 Cryptography and communications (A.10, A.13)
- Use of cryptography (A.10): Many legacy controllers and fieldbuses cannot support modern encryption or authentication. For these, Annex A is typically addressed through network zoning, traffic monitoring, and strict change control rather than device-level cryptography.
- Secure channels (A.13): Apply encryption where supported (for example, secure protocols for historian, MES, or remote access gateways). For devices that only support insecure protocols, document the constraint, restrict exposure, and use defense in depth.
2.5 Physical security around OT (A.11)
- Plant layout and access zones: Map secure areas to OT zones. Control access to control rooms, MCCs, network rooms, and cabinets containing controllers and switches.
- Environmental controls: Ensure power, cooling, and environmental protections for OT racks and panels are understood as information security controls as well as safety/operations controls.
2.6 Operations security and change control (A.12)
This is where Annex A most directly intersects with day-to-day OT work and regulated change control.
- Change management: Treat PLC logic, CNC programs, robot paths, and OT server configurations as controlled software. Align changes with existing engineering change processes and, where applicable, validation and qualification procedures.
- Patch management: Many OT assets cannot be patched frequently due to uptime, validation, or vendor support limits. Annex A does not require unrealistic patching; it requires you to manage risk. Common patterns include approved patch windows, extended vendor-tested patch baselines, and compensating measures (segmentation, monitoring) when patches are delayed.
- Malware protection: Full endpoint protection may be impossible on real-time systems or unsupported OS versions. Often you focus on protecting jump hosts, engineering workstations, and file transfer points, plus scanning removable media and software updates before they reach the OT zone.
- Backups and recovery: Back up PLC programs, machine parameters, recipes, and OT servers. In regulated environments, ensure backups are validated or at least tested and that restore procedures preserve traceability and configuration state.
2.7 Supplier relationships and OEMs (A.15)
- Contracts and SLAs: Extend supplier security requirements to OEMs, integrators, and service providers who install or remotely support OT systems. This includes remote connectivity terms, vulnerability management expectations, and notification obligations.
- Lifecycle support: Many OT systems outlive standard IT support windows. Annex A is addressed by planning for obsolescence, maintaining spares, and adding compensating controls around unsupported equipment.
2.8 Incident management and business continuity (A.16, A.17)
- Incident processes for OT: Include OT-specific playbooks (for example, loss of historian, suspected manipulation of recipes, unauthorized logic changes) in your information security incident process.
- Forensics vs uptime: Balance incident evidence gathering with safety and production constraints. Often you define in advance how far you will go before shutting down a line.
- Continuity and disaster recovery: Map critical OT systems into business continuity plans, including realistic recovery times that consider requalification and validation when systems are restored or rebuilt.
3. Brownfield realities and partial implementation
In brownfield plants, you rarely achieve full Annex A alignment across all OT equipment in a single step. Typical constraints include:
- Legacy devices with fixed, insecure protocols or no user management
- Unsupported operating systems that cannot run current security software
- Production schedules that allow very limited downtime for changes
- Validation and qualification overhead for any system modification
- Complex dependencies with MES, ERP, and QMS that complicate integration changes
In these environments, Annex A is normally addressed through:
- Risk-based zoning: Segmenting and isolating high-risk or legacy OT components instead of trying to harden them like IT servers.
- Compensating controls: Use firewalls, monitoring, procedures, and physical controls where device-level changes are infeasible.
- Documented exceptions: Record what cannot be implemented today, why, the associated risk, and planned remediation or end-of-life strategies.
- Incremental modernization: When replacing or upgrading OT systems, include Annex A and broader cybersecurity requirements in the user requirements and vendor selection, but avoid wholesale rip-and-replace, which often fails due to downtime, validation cost, and integration risk.
4. Interaction with other OT security standards
For OT, many organizations map Annex A to more OT-specific cybersecurity standards such as IEC 62443. This does not replace Annex A but helps translate it into technical and architectural requirements more suitable for control systems, while still maintaining the documentation, risk treatment, and audit trail that Annex A expects.
5. Practical starting points for applying Annex A to OT
For an established manufacturing site, pragmatic early steps are:
- Define OT security scope and roles within your information security management system.
- Build or improve an OT asset inventory and simple network zone diagram.
- Harden remote access paths and maintenance laptops used on the line.
- Bring OT changes (logic, configuration, patches) into existing change and validation processes, with appropriate risk assessment.
- Prioritize controls for systems that affect product quality, regulated data, or safety-critical functions.
Applied in this way, Annex A becomes a structured framework for managing OT security risks within the real constraints of production, validation, and legacy equipment, rather than a checklist that all devices must meet immediately.
