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.