ICS Security Governance: Policies, Procedures and IEC 62443-2-1

Most industrial security incidents do not begin with a zero-day exploit; they begin with an absent policy: a contractor plugged a laptop in, a vendor account was never removed, a change was made without review. ICS security governance — the policies, procedures, roles, and responsibilities that make security a managed activity rather than a set of devices — is where durable protection actually lives. IEC 62443-2-1 ("Security program requirements for IACS asset owners") is the standard framework for exactly this program.

What Governance Means for OT

Governance is the decision-making system for security: who is accountable, what is allowed, what is required, and how compliance is verified. For industrial organizations it covers:

• Roles and accountability — a named security owner for OT (often the automation manager with a dotted line to IT security), asset owners per area, and a steering body that decides risk acceptance. Security with no owner is a project, not a program.
• Policies — the top-level rules: acceptable use of OT systems, remote access rules, change management, incident reporting, vendor access, portable media control.
• Procedures — the how: patching procedure with OT-specific testing, backup and restore procedure, account lifecycle procedure (request, review, removal), incident response procedure with OT scope.
• Verification — audits and reviews that confirm the rules are followed; a policy nobody verifies is a suggestion.

IEC 62443-2-1 Program Requirements

IEC 62443-2-1 organizes the program into requirements families, including:

• Security management system — the program's own structure: policy, organization, training, and continuous improvement.
• Risk management — assessment and treatment feeding the program (see the risk assessment article).
• Asset management — the inventory that every other control depends on: hardware, software, firmware, network, and data assets.
• Access control — accounts, roles, and authentication for humans and systems; the review cycle that removes the dead accounts.
• Change management — security-relevant changes assessed, approved, tested, and recorded — the control that makes OT changes predictable.
• Incident response — detection, response, and recovery procedures specific to OT, trained and exercised.
• Supply chain security — requirements on vendors and integrators (see the supply chain article).

The standard also defines maturity levels (1–4): from informal, ad-hoc practice to fully managed, continuously improving programs. Most plants start at level 1–2; the standard's path makes the improvement explicit.

Adapting IT Governance to OT Reality

Copying the enterprise security program onto OT fails; the differences are structural:

• Patch windows — OT patches require testing against the control system's stability and scheduling around production; the governance must define the OT-specific exception process, not forbid exceptions.
• Availability rules — security controls that can stop the process (network scans, aggressive AV, account lockouts) are themselves risks; the procedures must include the safe-rollback of security measures.
• Skill ownership — OT staff understand the process; IT security staff understand threats; governance must create the collaboration (joint reviews, shared incident response) instead of a turf boundary.
• Vendor and contractor reality — OT depends on external parties more than IT does; supplier access and maintenance procedures are core governance, not edge cases.

Building the Program Practically

1. Start with the risk register — the program's priorities come from the assessment, not from a policy template.
2. Write the five procedures that matter first — change management, access management (including remote), patching, incident response, and backup/restore. Five working procedures beat fifty approved ones.
3. Assign owners and review dates — every policy and procedure has an owner and a review cycle; orphaned documents are worse than none.
4. Verify with audits — quarterly spot checks (accounts, patches, changes) with findings fed back; the audit is the program's immune system.
5. Report to management in their language — risk reduction, incidents, and compliance status, quarterly — the program survives on management attention.

Summary

ICS security governance turns security from a device list into a management system: named owners, policies, procedures, and verification, structured per IEC 62443-2-1 and adapted to OT's availability-first reality. Start with the risk register, write the five core procedures, verify compliance, and report progress. The devices matter; the system that operates them matters more — because the next incident will not wait for a perfect tool, it will exploit the absent procedure.

Primary references and further reading

Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.

• NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security
• ISA — ISA/IEC 62443 series