ISA/IEC 62443-2-1:2010 defined the elements needed to establish a standalone Cyber Security Management System (CSMS) for Industrial Automation and Control System (IACS) environments, and provided guidance on how to develop those elements.
The official title of the 2010 edition is Establishing an industrial automation and control system security program. In practice that edition is widely known as the CSMS standard: its normative Clause 4 sets out what shall or should be in a CSMS, Annex A gives guidance for developing those elements, and Annex B describes a recommended process for building the CSMS.
Reference: IEC 62443-2-1:2010, Clauses 0–4, Annex A, Annex B
Business and IT teams often already run a structured cybersecurity management approach (commonly aligned to ISO/IEC 27001). As plants adopted COTS computing in control rooms and controller networks, the attack surface against physical processes grew — including risks to people, the environment and production that a purely IT-focused programme may not weight heavily enough.
Re-using office IT controls unchanged in an OT setting can also create operational side effects. The 2010 Part 2-1 therefore outlined an IACS-oriented CSMS while still urging organisations to keep OT cybersecurity aligned with existing enterprise security practice where that is sensible.
A useful teaching point from that edition still holds: engineers like to decompose hard problems into disciplined work packages — but cybersecurity fails if each system is secured in isolation. OT risk spans the connected fleet of automation assets together with the people, procedures and ways of working around them. Putting that breadth in place can mean a real culture shift, not just a project deliverable.
Per the ISA 62443-2-1 Key Points job aid (First Edition – 2010), the edition:
The CSMS elements are mostly policy, procedure, practice and personnel related. Other documents in the ISA/IEC 62443 series address specific technologies and technical solutions in more detail.
In teaching terms: there is no universal checklist that fits every plant. Chasing “perfect” security usually means stripping out needed function. Real programmes balance investment against risk — and in OT that risk can include irreversible HSE harm, not only short-term business loss.
Clause 4 presents the CSMS elements in three main categories. The job aid maps those categories to the classic PDCA cycle:
| PDCA | CSMS category | Focus |
|---|---|---|
| Plan | Risk analysis | Understand why cybersecurity investment matters and what risks exist. |
| Do | Addressing risk with the CSMS | Govern, design and implement the organisational and technical response. |
| Check | Monitoring and improving the CSMS — Conformance | Validate that the organisation follows the CSMS it defined. |
| Act | Monitoring and improving the CSMS — Review, improve and maintain | Refine the CSMS so it remains effective as the environment changes. |
This is the largest category and is organised into three element groups:
| Element group | Elements |
|---|---|
| Security policy, organization and awareness |
CSMS scope; Organise for security; Staff training and security awareness; Business continuity plan; Security policies and procedures |
| Selected security countermeasures |
Personnel security; Physical and environmental security; Network segmentation; Access control — account administration; Access control — authentication; Access control — authorization |
| Implementation |
Risk management and implementation; System development and maintenance; Information and document management; Incident planning and response |
Annex A mirrors the Clause 4 structure and provides informative guidance for developing each element (descriptions, supporting practices, baseline practices, additional practices and references). Organisations tailor that guidance to their culture, size and existing security maturity — a small company may run similar activities with less formality than a large multinational.
Clause 4 lists what belongs in a CSMS; it does not force one fixed project sequence. Annex B offers a teaching-friendly order that many organisations have found workable. Building a working CSMS usually unfolds over months or years, not a single sprint.
Figure B.1 in the standard groups the journey into six top-level activities:
Treat the list as a loop, not a one-way waterfall: outputs from earlier work feed later steps, and maintenance loops back into risk views and programme scope.
| # | Activity | Intent | Teaching tip / common trap |
|---|---|---|---|
| 1 | Initiate CSMS program | Secure sponsorship and a clear charter: why the work matters to the business, what is in or out of scope, who the stakeholders are, and what funding and authority exist. | Launching on “cyber is important” alone usually stalls when other projects compete for time. Start smaller if needed and widen scope as results appear. |
| 2 | High-level risk assessment | Agree how risk will be spotted and ranked, then capture the big-picture threat, likelihood, vulnerability themes and consequence view — with stakeholders present — and record the reasoning. | Build the storyline before deep scanning. Without shared context, technical findings rarely drive decisions. |
| 3 | Establish policy, organization and awareness | Turn risk appetite into workable rules: write and communicate policy, assign ownership, and train people. Keep this work in step with the countermeasure choices that follow. | Writing rules before anyone has a view of risk often produces paper that nobody can (or should) follow. |
| 4 | Detailed risk assessment | Inventory what is actually installed, focus effort where it matters, dig into specific weaknesses, tie them to risks, and refresh the high-level picture when new issues appear. | Diving straight into vulnerability scans without the high-level narrative often yields long technical lists that leaders ignore. |
| 5 | Select and implement countermeasures | Choose and deploy technical and non-technical defences that match risk appetite and assessment results; update continuity and incident plans when the plant changes. | A control without owners, procedures and training is rarely effective — keep policy/organisation work and countermeasure work joined up. |
| 6 | Maintain the CSMS | Check that people still follow the programme, measure whether it works, watch for new threats and obligations, and push improvements back into risk views, policy, training and controls. | Maintenance is easy to deprioritise once the initial project ends. Skip it and the gains fade as the plant and threat landscape move on. |
In teaching terms, Annex B helps organisations:
Each top-level activity breaks into dependent sub-steps (Figures B.2–B.8). Typical flows:
Cross-discipline engagement is normal: operations, process control, HSE, physical security, IT security, legal and HR all touch the outcome. Treat CSMS delivery as change management as much as engineering.
IEC 62443-2-1:2010 explicitly builds on ISO/IEC 17799 and ISO/IEC 27001 while highlighting IACS differences — especially continuous operation, safety, and HSE-linked risk. Annex C maps CSMS requirements to ISO/IEC 27001 references so organisations can reuse existing ISMS structures rather than inventing a parallel management system from scratch.
Economies are realised by keeping IACS cybersecurity practices consistent with business/IT cybersecurity practices, while still addressing OT-specific constraints.
The 2024 edition of Part 2-1 cancels and replaces the first edition (2010).
Significant changes include:
In short, the 2024 edition is written for keeping an IACS secure while it runs: set up the programme, operate it, and improve it so residual risk stays acceptable. How you implement each expectation is left open, so plants can choose controls that fit their constraints.
Design-time risk methods (notably ISA/IEC 62443-3-2) still matter — they help choose zones, targets and capabilities that the asset-owner programme then has to sustain in operations.