Annex A control selection must be documented in a way that an independent reviewer (auditor, regulator, internal assurance) can see how you moved from risk to specific, justified controls. The exact format is not prescribed by standards, but several documentation elements are consistently expected.
Core documents usually expected
Most organizations in regulated manufacturing environments maintain at least the following:
-
Information security risk assessment report
- Scope and boundaries (sites, systems, production cells, OT/IT interfaces).
- Identified assets, threats, vulnerabilities, and existing safeguards.
- Risk analysis and evaluation criteria (likelihood, impact, risk acceptance criteria).
- Identified risks that require treatment, including OT-specific risks (e.g., loss of recipe integrity, unauthorized process changes, historian tampering).
-
Risk treatment plan
- Selected risk treatment option for each risk (mitigate, transfer, avoid, accept).
- Proposed controls mapped to each risk, including Annex A controls where applicable.
- Implementation responsibilities, target dates, and dependencies on plant downtime or project windows.
- Residual risk description and acceptance route (who can sign off, under what conditions).
-
Statement of Applicability (SoA)
- List of all Annex A controls relevant to your reference standard (e.g., ISO/IEC 27001:2022 Annex A).
- Status for each control (implemented, planned, not applicable).
- Justification for implementation or exclusion, aligned to your risk assessment.
- References to where each control is implemented (policies, procedures, technical configurations, OT and IT systems).
Justification requirements for each Annex A control
For Annex A control selection specifically, reviewers will look for:
- Traceable linkage to risk: It should be clear which risk scenarios drove the decision to implement, strengthen, or not apply a control.
- Business and technical justification: Where you do not implement a control, the reason should go beyond cost or convenience and reference risk acceptance, compensating controls, or technical infeasibility in the current environment.
- Scope clarity: Many controls are partially implemented. You should document where they apply (e.g., corporate IT only, or selected plants, or certain production lines) and where they do not.
- Dependencies and constraints: If a control is delayed or downgraded due to validation requirements, long equipment lifecycle, vendor limitations, or downtime windows, that constraint should be explicit.
Evidence of how controls are realized
Beyond the SoA, you typically need documentary evidence of how selected controls are implemented:
- Policies and standards that formalize the intent of controls (e.g., access control policy, secure configuration standard for OT assets, remote access policy).
- Procedures and work instructions that show how Annex A controls operate in practice (account provisioning, backup and restore tests, change management for PLC logic, patch review boards).
- System-level records and configurations, such as:
- Access control lists, firewall rules, and network zoning diagrams for OT/IT segregation.
- Logs and monitoring configurations for critical control points (MES, historians, QMS, SCADA).
- Backup schedules and restore test reports for control systems and recipe databases.
- Training and awareness records relevant to control operation (operators, maintenance, engineers, system administrators).
Brownfield and coexistence considerations
In mixed OT/IT, brownfield manufacturing environments, documentation of Annex A control selection also needs to acknowledge:
- Legacy and vendor constraints: Where specific controls (for example, strong authentication, modern encryption, continuous patching) are not technically or contractually feasible on older equipment, document this and describe compensating measures (network isolation, strict physical access, manual verification steps).
- Validation and qualification impact: For GxP, aerospace, or nuclear contexts, many changes to control systems require formal validation or requalification. Annex A control choices should reference these impacts and show that change control and validation have been considered.
- Downtime and safety limits: If a control cannot be implemented immediately due to production or safety constraints, the documentation should show interim measures and a realistic implementation window tied to turnarounds or capital projects.
- Coexistence with MES/ERP/QMS/PLM: Where Annex A controls require data or enforcement from enterprise systems, note integration limits (for example, delayed identity synchronization to OT domains) and how you manage the resulting risk.
Governance and change control documentation
Annex A control selection is not a one-time exercise. Reviewers typically expect:
- Change control records for material updates to controls, especially in validated or safety-critical environments.
- Periodic SoA reviews that show how new risks, incidents, or system changes have been evaluated and reflected in Annex A control decisions.
- Management review minutes or equivalent evidence showing that leadership has visibility into residual risks, deferred controls, and resource constraints.
What is not strictly required but often useful
Standards generally do not mandate specific templates, but the following can make Annex A control selection more robust and auditable:
- A control-to-risk mapping matrix that links each Annex A control to the risks it addresses and the systems or processes it covers.
- A control implementation roadmap that sequences control upgrades across plants and systems, aligned with outages, projects, and validation cycles.
- Clear ownership assignments for each control (IT, OT, engineering, quality, site leadership) in a RACI-style view.
Ultimately, the requirement is not for a particular document format, but for demonstrable, traceable logic: why you chose each Annex A control state (implemented, partial, not applicable), how that relates to your specific risks and constraints, and where there is objective evidence that the chosen controls exist and operate as described.
