Technical security controls alone are not enough to secure an Industrial Automation and Control System (IACS). A successful cybersecurity program also depends on clear governance that defines responsibilities, standardises processes and promotes consistent security practices. In ISA/IEC 62443-1-1, Subclause 5.7 – Policies covers enterprise-level policy, operational policies and procedures, and the topics those documents should address. Reference: ISA/IEC 62443-1-1, Subclause 5.7
Within IEC 62443-1-1, policies and procedures form the governance framework that supports implementation of cybersecurity models, security controls and organisational processes. They ensure personnel understand:
In practice, organisations often also publish guidelines as recommended best-practice material that supports policy and procedure without creating additional mandatory requirements. That three-layer view is a useful teaching model; the standard itself focuses on policies and procedures as the enforceable governance basis.
A well-developed governance framework helps organisations:
An enterprise-level cybersecurity policy is management’s written commitment to protect the IACS and related information assets. It sets direction and mandatory expectations so operational policies, procedures, standards and technical controls have a common foundation.
In teaching terms, enterprise policy answers: what is in scope, what security outcomes the organisation requires for safety and production continuity, who is accountable at management level, who must comply (including contractors and relevant third parties), and what auditors will use as the benchmark. It states what must be achieved — not the shop-floor steps for achieving it.
Rather than listing every clause topic, treat enterprise policy as covering four themes: governance (commitment, roles and accountability); risk expectations; access and connectivity boundaries (including remote and third-party paths); and readiness for change, disruption and incidents (change control, recovery and reporting).
Operational policies and procedures translate enterprise direction into workable rules and repeatable steps for engineering, operations, maintenance, IT/OT and supporting teams.
Operational policy elaborates mandatory requirements for specific activities (for example remote access, removable media or patching). Procedures then define the detailed steps needed to implement those requirements consistently, regardless of who performs the work.
| Document | Purpose | Mandatory |
|---|---|---|
| Policy | Defines organisational direction and mandatory requirements (what must be achieved). | Yes |
| Procedure | Defines the detailed steps required to implement policy (how work is performed). | Yes, where referenced by policy |
| Guideline | Provides recommended methods and best practices that support policy objectives. | No (advisory) |
Procedures sit wherever inconsistent practice would create cyber or operational risk — for example account lifecycle, patching and validation, backup restore drills, remote-access approval, incident handling, authorised maintenance and vulnerability assessment. The exact procedure set follows the plant’s activities; the teaching point is repeatable execution, not a fixed catalogue.
Good procedures are step-by-step and repeatable, reduce variation between people and shifts, support training and audit evidence, and live as controlled documents that change when the system or risk picture changes.
A guideline provides recommended best practice that supports cybersecurity objectives. Unlike policies and procedures, guidelines are advisory rather than mandatory. They allow local flexibility while encouraging recognised industry practice that improves security and operational performance.
Guidelines are useful where multiple acceptable methods exist, or where detailed design choices depend on technology, vendor constraints or site conditions. They normally cannot be audited as hard compliance requirements unless a policy explicitly elevates selected guidance into mandatory practice.
Guidelines are well suited to design and configuration choices that can validly differ by vendor or site — hardening and secure build advice, authenticator hygiene, firewall design patterns, segmentation patterns, logging expectations and secure development practices. They steer teams toward recognised good practice without pretending there is only one acceptable method.
Subclause 5.7.4 expects policies and procedures to span the work needed to manage IACS cybersecurity risk — not a one-page abstract statement. In teaching terms, cover the program end to end:
Those themes are expanded into enforceable Security Program requirements in the ISA/IEC 62443-2 series, especially for asset owners under IEC 62443-2-1.