A Statement of Applicability (SoA) is a formal document that lists which controls from a reference standard your organization has decided to implement, tailor, or exclude, and why. It is most commonly associated with ISO/IEC 27001, but the same idea is used for other control frameworks (for example, cybersecurity controls for industrial control systems aligned with IEC 62443).
What a Statement of Applicability contains
In practice, an SoA usually includes:
- The full set of controls from a chosen baseline (for example, ISO/IEC 27001 Annex A, local cybersecurity policies, or corporate control catalogues).
- For each control: a status such as “applicable & implemented,” “applicable & planned,” or “not applicable.”
- Justification for the status, especially when controls are marked as not applicable or only partially implemented.
- References to where the control is realized in your environment: policies, procedures, system configurations, or specific technologies.
- Scope information, clarifying which plants, systems, and processes are covered.
In regulated industrial environments, a robust SoA also tends to be linked to risk assessments, validation documentation, and change records, so you can show why decisions were made and how they were maintained over time.
Why it is important in manufacturing and industrial operations
The SoA is important because it provides structured, evidence-backed answers to four critical questions:
- Which controls did you choose to use? It shows your selected controls across OT, IT, and supporting business systems, instead of leaving this implied or tribal.
- Why did you choose them? It links control decisions to risk assessments, regulatory drivers, and operations constraints (for example, safety, uptime, supplier requirements).
- Where and how are they applied? It points to real assets and processes, so you can trace from a control requirement down to specific PLC networks, MES instances, QMS workflows, or procedures.
- What is out of scope or not implemented? It documents justified gaps so they are visible and can be managed, instead of discovered ad hoc in an audit or incident.
For manufacturing plants operating in brownfield environments, this matters because controls are rarely applied uniformly. Different lines, vendors, and generations of equipment support different capabilities. The SoA is often the only place where those differences are systematically recorded and justified.
How an SoA supports audits and assurance
The SoA is frequently reviewed during internal audits, external assessments, and customer due diligence, but it should not be treated as a guarantee of compliance. Instead, it serves to:
- Clarify the intended control set before auditors look at specific evidence.
- Provide a traceable map from standard requirements to policies, configurations, and records.
- Show that exclusions or partial implementations are risk-based and approved, not accidental.
- Structure sampling: auditors can select controls from the SoA and trace them into the plant or system.
Audit outcomes still depend on whether controls are actually implemented and effective in day-to-day operations, not just on their presence in the SoA.
SoA in brownfield, long-lifecycle environments
In industrial and regulated settings, the SoA has additional practical uses:
- Managing coexistence of legacy and new systems: It makes clear where older equipment or legacy MES/SCADA/ERP systems limit which controls are feasible, and which compensating controls are in place instead.
- Avoiding unrealistic full-replacement assumptions: Instead of assuming every legacy system can be replaced to meet a modern standard, the SoA documents where you will rely on network segmentation, procedural controls, or monitoring to manage risk.
- Supporting change control and validation: When a control implementation changes (for example, new firewall, new MES module, revised QMS workflow), the SoA should be updated in step with change control and, where required, validation.
- Providing continuity across programs and sites: It helps coordinate different plants or programs that share corporate standards but operate with different vendors and constraints.
This is particularly relevant for cybersecurity programs aligned with frameworks like IEC 62443, where control implementation on a 25-year-old DCS will look different from a new PLC line, and full technology replacement may be economically or operationally unrealistic.
Key dependencies and limitations
The usefulness of a Statement of Applicability depends on several factors:
- Accurate scope and asset understanding: If the plant, system, or data flows are poorly understood, the SoA will be incomplete or misleading.
- Integration with risk management: Control decisions should be traceable to risk assessments, not just copied from templates.
- Maintenance and change control: An SoA that is not updated when systems, controls, or boundaries change quickly loses credibility.
- Linkage to real configurations and procedures: Without references to actual evidence (for example, system hardening guides, alarm configurations, SOPs), the SoA becomes a theoretical list, not an assurance tool.
An SoA is important, but it is only one artifact in a broader assurance ecosystem that includes risk analysis, system design, configuration standards, validation, monitoring, and incident response. It does not, by itself, satisfy regulatory requirements or guarantee passing any audit or certification.
