# 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… - Canonical URL: https://wiki.aspotomasyon.com/article/ics-security-governance - Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki) - Category: Industrial Cybersecurity - Published: 2026-08-11 · Updated: 2026-09-13 - Reading time: 4 min · Language: English 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. ![Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment.](https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-context.svg) *Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment.* ## 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. ## Apply this to your project - Identify asset owners, permitted communications, operational dependencies, and consequences of losing the function. - Test access restrictions and visibility without disrupting plant operations; agree the activity with the OT owner. - Validate an offline recovery path and document who can authorize isolation, restoration, and return to service. [Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance. ![Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration.](https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-review.svg) *Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration.* ## 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](https://csrc.nist.gov/pubs/sp/800/82/r3/final) - [ISA — ISA/IEC 62443 series](https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards) --- Cite the canonical article: https://wiki.aspotomasyon.com/article/ics-security-governance (ICS Security Governance: Policies, Procedures and IEC 62443-2-1, ASP OTOMASYON, updated 2026-09-13).