ISA/IEC 62443-2-1:2024 specifies asset-owner requirements for establishing, implementing, maintaining and continually improving an Industrial Automation and Control System (IACS) Security Program (SP) while the IACS is in operation. In this context, “asset owner” also includes the operator of the IACS.
The second edition cancels and replaces the first edition (ISA 2009 / IEC 2010). That earlier edition defined a standalone Cyber Security Management System (CSMS). The 2024 edition restructures requirements into Security Program Elements (SPEs), removes duplicated ISMS content, and introduces a maturity model for evaluating how requirements are met.
Related: IEC 62443-2-1 Cybersecurity Management System (CSMS) (2010) | Maturity Levels (Clause 4.2) | Conformance and Assessment (Clause 5) | Cybersecurity Awareness Training (SPE1-ORG1.4/1.5) | ISO/IEC 27001/27002 and ISA/IEC 62443
Think of the IACS Security Program as the plant’s operating playbook for cybersecurity: the mix of rules, ways of working, services and products used to keep the control system safe enough to run. Part 2-1 tells you what outcomes the programme needs to cover; it does not prescribe a single product stack or architecture.
Real plants often run decades-old controllers and unsupported OS images. The programme still needs a stance on topics such as patching and backup even when native tools are weak — compensating arrangements are normal. Likewise, skip wireless or remote-access themes if those capabilities are not in the system. The asset owner decides what applies by looking at the live operating environment.
Accountability stays with the asset owner, even when integrators, maintainers and product vendors do much of the work. Part 2-1 therefore helps owners write clear expectations into supply arrangements and points to related series parts for technical and service capability (for example 2-4, 3-3 and 4-2).
ISA/IEC 62443-2-1:2024 carefully separates the broad management-system idea from the operational IACS programme. Both terms appear in Clause 3.
Reference: ISA/IEC 62443-2-1, Clause 3.1.13
A Security Management System (SMS) is a set of interrelated or interacting elements of an organisation used to establish security policies and objectives, together with systematic processes to achieve those objectives. The definition follows the ISO/IEC 27000 notion of a management system: governance, objectives, planned processes and continual improvement — not a single product or tool.
In many organisations the SMS takes the form of an Information Security Management System (ISMS) aligned with ISO/IEC 27001. The SMS sets the organisational frame; it is not by itself the IACS-specific operating programme.
Reference: ISA/IEC 62443-2-1, Clause 3.1.15
A Security Program (SP) is a portfolio of security services — including integration and maintenance services — and their associated policies, procedures and products applicable to the IACS. For asset owners, the SP is the set of policies and procedures defined to address IACS cybersecurity concerns. It can include technical, process, physical and compensating security measures used to reduce the cybersecurity attack surface.
In short: the SMS (often an ISMS) is the organisational management system; the IACS SP is the operational cybersecurity programme for industrial systems. Where an ISMS already exists, ORG 1.1 requires the IACS SP to be coordinated with it. Where no ISMS exists, appropriate management processes must be incorporated into the SP itself.
| Concept | In plain terms | Typical focus |
|---|---|---|
| SMS | Organisation-wide management system for security policy, objectives and systematic processes. | Governance, objectives, continual improvement (often ISO/IEC 27001 ISMS). |
| IACS SP | Operational programme of policies, procedures, services and products that protect a specific IACS. | HSE-aware OT protection, availability/integrity priorities, SPE requirements. |
Securing each PLC or workstation in isolation is a common trap. OT cybersecurity only works when the connected plant, the operating rules and the people who use the system are treated together — which often means behaviour and culture change, not just firewalls. There is no universal recipe: squeezing risk toward zero usually costs function you still need. Aim for risk that leadership has consciously decided it can live with.
Office IT tools and COTS platforms often arrive with assumptions that clash with process safety and uptime. Many of those tools are still useful in OT, but only when configured for industrial priorities (availability and integrity usually come first). Decide the Security Program as a management choice for the plant, scale it to the IACS, and keep it aligned with the corporate ISMS where one exists.
Significant technical changes in the 2024 edition include:
ISA/IEC 62443-2-1 and ISO/IEC 27001 are complementary. The ISMS typically protects enterprise information environments; the IACS SP addresses industrial operations where safety, availability and process integrity dominate.
| ISA/IEC 62443-2-1 (IACS SP) | ISO/IEC 27001 (ISMS) |
|---|---|
| Industrial automation and control systems (OT) | Organisation-wide information security management |
| Industrial operations, process control, HSE outcomes | Confidentiality, integrity and availability of information |
| SPE requirements tailored to IACS in operation | ISMS clauses and Annex A control themes for IT/business systems |
Where practical, IACS SPs should be compatible with the organisation’s ISMS, but complete sameness is often impossible because of conflicting operational constraints (patch windows, anti-malware updates, remote access, DMZ design). Documenting similarities and differences reduces IT/OT friction. Annex A of Part 2-1 cross-references ISO/IEC 27001:2013 and other frameworks to support that coordination.
Reference: ISA/IEC 62443-2-1, Clauses 6–13
Requirements are grouped into eight Security Program Elements — top-level activity areas of the SP. Each SPE combines organisational and technical controls that together support a defence-in-depth strategy. Requirements remain implementation-independent so the asset owner can choose suitable architectures, policies and technologies.
Detailed normative requirements for each SPE are on dedicated pages linked below.
| SPE | Title | Clause | Purpose (overview) |
|---|---|---|---|
| SPE 1 | Organizational security measures | 6 | Prepare the organisation: policies, trained people, risk reviews and physical access (ORG 1–ORG 3). |
| SPE 2 | Configuration management | 7 | Know and control the as-built IACS: inventory, drawings, settings and change control (CM 1). |
| SPE 3 | Network and communications security | 8 | Segment and protect communications, including wireless and remote access (NET 1–NET 3). |
| SPE 4 | Component security | 9 | Harden devices and software; manage portable media, malware and patches (COMP 1–COMP 3). |
| SPE 5 | Protection of data | 10 | Classify and protect data confidentiality and integrity, including cryptography and keys (DATA 1). |
| SPE 6 | User access control | 11 | Identify, authenticate and authorise human users, processes and devices (USER 1–USER 2). |
| SPE 7 | Event and incident management | 12 | Detect, log, analyse and respond to security events, incidents and vulnerabilities (EVENT 1). |
| SPE 8 | System integrity and availability | 13 | Sustain intended function and recover via continuity, backup and restore (AVAIL 1–AVAIL 2). |
SP requirements are scored with maturity levels (ML 1–4): Initial, Managed, Defined/Practiced and Improving. MLs apply per requirement, support phased programme growth, and are distinct from Security Levels. From ML 2 upward, documentation is implied; Annex C guides how to evaluate scores in practice.
→ Full teaching page: IEC 62443-2-1 Maturity Levels (Clause 4.2)
Clause 5 frames conformance versus assessment, catalogues typical evidence (Table 2), and explains how risk evaluation and security profiles decide which requirements apply before an assessment.
→ Full teaching page: IEC 62443-2-1 Conformance and Assessment (Clause 5)