{"data":{"slug":"ics-security-governance","title":"ICS Security Governance: Policies, Procedures and IEC 62443-2-1","summary":"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…","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/ics-security-governance","markdown_url":"https://wiki.aspotomasyon.com/article/ics-security-governance.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/ics-security-governance","published":"2026-08-11T13:05:24+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":806,"image":"https://wiki.aspotomasyon.com/assets/social/ics-security-governance-1c14fa9306fc.png","html":"<p>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. <strong>ICS security governance</strong> — the policies, procedures, roles, and responsibilities that make security a managed activity rather than a set of devices — is where durable protection actually lives. <strong>IEC 62443-2-1</strong> (\"Security program requirements for IACS asset owners\") is the standard framework for exactly this program.</p><figure class=\"article-figure\"><img src=\"https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-context.svg\" width=\"1100\" height=\"460\" loading=\"lazy\" decoding=\"async\" alt=\"Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment.\"><figcaption>Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment. <a href=\"https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-context.svg\" target=\"_blank\" rel=\"noopener\">View full size</a></figcaption></figure>\n\n<h2 id=\"what-governance-means-for-ot\">What Governance Means for OT</h2>\n\n<p>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:</p>\n\n<ul>\n  <li><strong>Roles and accountability</strong> — 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.</li>\n  <li><strong>Policies</strong> — the top-level rules: acceptable use of OT systems, remote access rules, change management, incident reporting, vendor access, portable media control.</li>\n  <li><strong>Procedures</strong> — the how: patching procedure with OT-specific testing, backup and restore procedure, account lifecycle procedure (request, review, removal), incident response procedure with OT scope.</li>\n  <li><strong>Verification</strong> — audits and reviews that confirm the rules are followed; a policy nobody verifies is a suggestion.</li>\n</ul>\n\n<h2 id=\"iec-62443-2-1-program-requirements\">IEC 62443-2-1 Program Requirements</h2>\n\n<p>IEC 62443-2-1 organizes the program into requirements families, including:</p>\n\n<ul>\n  <li><strong>Security management system</strong> — the program's own structure: policy, organization, training, and continuous improvement.</li>\n  <li><strong>Risk management</strong> — assessment and treatment feeding the program (see the risk assessment article).</li>\n  <li><strong>Asset management</strong> — the inventory that every other control depends on: hardware, software, firmware, network, and data assets.</li>\n  <li><strong>Access control</strong> — accounts, roles, and authentication for humans and systems; the review cycle that removes the dead accounts.</li>\n  <li><strong>Change management</strong> — security-relevant changes assessed, approved, tested, and recorded — the control that makes OT changes predictable.</li>\n  <li><strong>Incident response</strong> — detection, response, and recovery procedures specific to OT, trained and exercised.</li>\n  <li><strong>Supply chain security</strong> — requirements on vendors and integrators (see the supply chain article).</li>\n</ul>\n\n<p>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.</p>\n\n<h2 id=\"adapting-it-governance-to-ot-reality\">Adapting IT Governance to OT Reality</h2>\n\n<p>Copying the enterprise security program onto OT fails; the differences are structural:</p>\n\n<ul>\n  <li><strong>Patch windows</strong> — 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.</li>\n  <li><strong>Availability rules</strong> — 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.</li>\n  <li><strong>Skill ownership</strong> — 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.</li>\n  <li><strong>Vendor and contractor reality</strong> — OT depends on external parties more than IT does; supplier access and maintenance procedures are core governance, not edge cases.</li>\n</ul>\n\n<h2 id=\"building-the-program-practically\">Building the Program Practically</h2>\n\n<ol>\n  <li><strong>Start with the risk register</strong> — the program's priorities come from the assessment, not from a policy template.</li>\n  <li><strong>Write the five procedures that matter first</strong> — change management, access management (including remote), patching, incident response, and backup/restore. Five working procedures beat fifty approved ones.</li>\n  <li><strong>Assign owners and review dates</strong> — every policy and procedure has an owner and a review cycle; orphaned documents are worse than none.</li>\n  <li><strong>Verify with audits</strong> — quarterly spot checks (accounts, patches, changes) with findings fed back; the audit is the program's immune system.</li>\n  <li><strong>Report to management in their language</strong> — risk reduction, incidents, and compliance status, quarterly — the program survives on management attention.</li>\n</ol>\n\n<h2 id=\"summary\">Summary</h2>\n\n<p>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.</p><section class=\"engineering-check\"><h2 id=\"apply-this-to-your-project\">Apply this to your project</h2><ul><li>Identify asset owners, permitted communications, operational dependencies, and consequences of losing the function.</li><li>Test access restrictions and visibility without disrupting plant operations; agree the activity with the OT owner.</li><li>Validate an offline recovery path and document who can authorize isolation, restoration, and return to service.</li></ul><p><a href=\"https://wiki.aspotomasyon.com/guides\">Follow an ASP project guide</a> to connect the fundamentals with implementation and acceptance.</p></section><figure class=\"article-figure\"><img src=\"https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-review.svg\" width=\"1100\" height=\"460\" loading=\"lazy\" decoding=\"async\" alt=\"Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration.\"><figcaption>Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration. <a href=\"https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-review.svg\" target=\"_blank\" rel=\"noopener\">View full size</a></figcaption></figure><h2 id=\"primary-references-and-further-reading\">Primary references and further reading</h2><p>Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.</p><ul><li><a href=\"https://csrc.nist.gov/pubs/sp/800/82/r3/final\" rel=\"noopener noreferrer\" target=\"_blank\">NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security</a></li><li><a href=\"https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards\" rel=\"noopener noreferrer\" target=\"_blank\">ISA — ISA/IEC 62443 series</a></li></ul><!-- asp-editorial-202609 -->","markdown":"# ICS Security Governance: Policies, Procedures and IEC 62443-2-1\n\n> 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…\n\n- Canonical URL: https://wiki.aspotomasyon.com/article/ics-security-governance\n- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)\n- Category: Industrial Cybersecurity\n- Published: 2026-08-11 · Updated: 2026-09-13\n- Reading time: 4 min · Language: English\n\nMost 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.\n\n![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)\n\n*Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment.*\n\n## What Governance Means for OT\n\nGovernance 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:\n\n- **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.\n- **Policies** — the top-level rules: acceptable use of OT systems, remote access rules, change management, incident reporting, vendor access, portable media control.\n- **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.\n- **Verification** — audits and reviews that confirm the rules are followed; a policy nobody verifies is a suggestion.\n\n## IEC 62443-2-1 Program Requirements\n\nIEC 62443-2-1 organizes the program into requirements families, including:\n\n- **Security management system** — the program's own structure: policy, organization, training, and continuous improvement.\n- **Risk management** — assessment and treatment feeding the program (see the risk assessment article).\n- **Asset management** — the inventory that every other control depends on: hardware, software, firmware, network, and data assets.\n- **Access control** — accounts, roles, and authentication for humans and systems; the review cycle that removes the dead accounts.\n- **Change management** — security-relevant changes assessed, approved, tested, and recorded — the control that makes OT changes predictable.\n- **Incident response** — detection, response, and recovery procedures specific to OT, trained and exercised.\n- **Supply chain security** — requirements on vendors and integrators (see the supply chain article).\n\nThe 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.\n\n## Adapting IT Governance to OT Reality\n\nCopying the enterprise security program onto OT fails; the differences are structural:\n\n- **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.\n- **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.\n- **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.\n- **Vendor and contractor reality** — OT depends on external parties more than IT does; supplier access and maintenance procedures are core governance, not edge cases.\n\n## Building the Program Practically\n\n1. **Start with the risk register** — the program's priorities come from the assessment, not from a policy template.\n2. **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.\n3. **Assign owners and review dates** — every policy and procedure has an owner and a review cycle; orphaned documents are worse than none.\n4. **Verify with audits** — quarterly spot checks (accounts, patches, changes) with findings fed back; the audit is the program's immune system.\n5. **Report to management in their language** — risk reduction, incidents, and compliance status, quarterly — the program survives on management attention.\n\n## Summary\n\nICS 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.\n\n## Apply this to your project\n\n- Identify asset owners, permitted communications, operational dependencies, and consequences of losing the function.\n- Test access restrictions and visibility without disrupting plant operations; agree the activity with the OT owner.\n- Validate an offline recovery path and document who can authorize isolation, restoration, and return to service.\n\n[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.\n\n![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)\n\n*Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration.*\n\n## Primary references and further reading\n\nUse the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.\n\n- [NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security](https://csrc.nist.gov/pubs/sp/800/82/r3/final)\n- [ISA — ISA/IEC 62443 series](https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards)\n\n---\n\nCite 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).\n","headings":[{"id":"what-governance-means-for-ot","title":"What Governance Means for OT"},{"id":"iec-62443-2-1-program-requirements","title":"IEC 62443-2-1 Program Requirements"},{"id":"adapting-it-governance-to-ot-reality","title":"Adapting IT Governance to OT Reality"},{"id":"building-the-program-practically","title":"Building the Program Practically"},{"id":"summary","title":"Summary"},{"id":"apply-this-to-your-project","title":"Apply this to your project"},{"id":"primary-references-and-further-reading","title":"Primary references and further reading"}],"faq":[],"references":[{"name":"NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security","url":"https://csrc.nist.gov/pubs/sp/800/82/r3/final"},{"name":"ISA — ISA/IEC 62443 series","url":"https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards"}],"related":[{"slug":"ot-identity-access-management-mfa","title":"OT Identity and Access Management: Accounts, Roles, and MFA","summary":"OT access works best with named identities, roles matched to jobs, and MFA placed at remote entry points rather than at every operator console.","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/ot-identity-access-management-mfa","markdown_url":"https://wiki.aspotomasyon.com/article/ot-identity-access-management-mfa.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/ot-identity-access-management-mfa","published":"2026-10-11T11:46:21+00:00","modified":"2026-10-11T11:46:21+00:00","reading_minutes":9,"word_count":1907,"image":"https://wiki.aspotomasyon.com/assets/social/ot-identity-access-management-mfa-2f4bbf8c3dfc.png"},{"slug":"nis2-directive-operational-technology-compliance","title":"NIS2 and Operational Technology: What Plant Operators Need to Prepare","summary":"NIS2 can reach plant operators through their size and sector, and its risk-management and reporting duties extend to the OT systems that run production.","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/nis2-directive-operational-technology-compliance","markdown_url":"https://wiki.aspotomasyon.com/article/nis2-directive-operational-technology-compliance.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/nis2-directive-operational-technology-compliance","published":"2026-10-11T11:46:21+00:00","modified":"2026-10-11T11:46:21+00:00","reading_minutes":9,"word_count":1896,"image":"https://wiki.aspotomasyon.com/assets/social/nis2-directive-operational-technology-compliance-3d941770fc05.png"},{"slug":"mitre-attack-for-ics-threat-informed-defense","title":"MITRE ATT&CK for ICS: Using the Matrix for Threat-Informed OT Defense","summary":"ATT&CK for ICS gives OT teams a shared catalog of adversary behavior, so detection and control gaps can be tested against plausible scenarios instead of…","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/mitre-attack-for-ics-threat-informed-defense","markdown_url":"https://wiki.aspotomasyon.com/article/mitre-attack-for-ics-threat-informed-defense.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/mitre-attack-for-ics-threat-informed-defense","published":"2026-10-11T11:46:21+00:00","modified":"2026-10-11T11:46:21+00:00","reading_minutes":8,"word_count":1676,"image":"https://wiki.aspotomasyon.com/assets/social/mitre-attack-for-ics-threat-informed-defense-dd88cfe7cb9b.png"},{"slug":"ics-security-awareness-training","title":"ICS Security Awareness and Training Programs","summary":"In industrial security, the human is both the weakest link and the first line of defense: the operator who notices a USB stick that should not be there, the…","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/ics-security-awareness-training","markdown_url":"https://wiki.aspotomasyon.com/article/ics-security-awareness-training.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/ics-security-awareness-training","published":"2026-08-11T13:05:24+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":832,"image":"https://wiki.aspotomasyon.com/assets/social/ics-security-awareness-training-dbbe2629a46c.png"}],"citation":"ASP OTOMASYON. ICS Security Governance: Policies, Procedures and IEC 62443-2-1. Updated 2026-09-13. https://wiki.aspotomasyon.com/article/ics-security-governance"}}