IEC 62443-2-1, second edition: building the asset owner’s security programme inside the quality system

The group security policy has just been reissued, and one line in it has changed. Where it used to say that production sites “should consider IEC 62443”, it now says that each site’s OT security programme “shall conform to IEC 62443-2-1:2024”. On the site, the OT engineer opens the binder written for the previous edition years ago, with its business rationale, its risk analysis and its element groups. The quality manager opens something else: the periodic review reports of the control systems, the change control log, the CAPA list. Each of them thinks the other has the programme.

Both are partly right. This article looks at what the second edition of IEC 62443-2-1 asks of an asset owner, what it changed, and how a pharmaceutical site can build the programme so that it runs through its quality system instead of sitting next to it.

What was published

The IEC published IEC 62443-2-1:2024, edition 2.0, on 7 August 2024, under the title Security for industrial automation and control systems, Part 2-1: Security program requirements for IACS asset owners. IEC technical committee 65 prepared it with the ISA99 committee as liaison, and it cancels and replaces the first edition of 2010, which the IEC lists as withdrawn on the same day. The American twin, ANSI/ISA-62443-2-1-2024, was announced by the International Society of Automation in January 2025.

The new title tells you a lot. The 2010 edition was called Establishing an industrial automation and control system security program; it defined the elements of a “cyber security management system” (CSMS) and gave guidance on developing them. The 2024 edition states requirements. Its scope is the asset owner’s security programme policies and procedures for an IACS in operation, and the asset owner includes the operator. If you run the line, it is addressed to you.

What changed from the 2010 edition

The foreword lists three significant technical changes. The requirements are restructured into security programme elements (SPEs). They are revised to remove duplication with an information security management system (ISMS). And a maturity model is defined to evaluate them.

The 2010 text read like a management-system standard, with roughly a hundred pages of informative guidance in its Annex A. The 2024 text reads like a requirements catalogue. Each requirement has an identifier, cross-referenced to IEC 62443-2-4, 3-3 and 4-2, so a supplier’s compliance matrix can now point at “NET 3.3” and mean the same thing as your procedure.

The ISMS change matters wherever corporate IT already runs one. The very first requirement, ORG 1.1, deals with it. The ISA Global Cybersecurity Alliance, in its 2025 white paper on the subject, reads it as a requirement to coordinate the IACS programme with any established ISMS, and recommends extending an ISO/IEC 27001 management system to the OT infrastructure rather than duplicating it. The plant inherits the management cycle and adds what is specific to the shop floor.

The eight elements

The requirements are grouped into eight SPEs. Most of them will look familiar to anyone who has worked on a GMP site.

1. SPE 1, organisational security measures. Roles, training, background checks, supply chain (ORG 1), risk mitigation and programme reviews (ORG 2), physical access (ORG 3).
2. SPE 2, configuration management. Inventory baseline, drawings, settings, change control.
3. SPE 3, network and communications security. Segmentation and zone documentation (NET 1), wireless (NET 2), remote access down to session termination (NET 3).
4. SPE 4, component security. Hardening and portable media, malware protection, patching, with mitigation when a patch cannot be installed.
5. SPE 5, protection of data. Classification, retention, cryptography and, as DATA 1.7, data integrity.
6. SPE 6, user access control. Identities, multifactor authentication (USER 1), authorisation and separation of duties (USER 2).
7. SPE 7, event and incident management. Detection, logging, incident response, vulnerability handling.
8. SPE 8, system integrity and availability. Continuity (AVAIL 1) and backup, up to restoration (AVAIL 2).

Put that list next to EU GMP Annex 11: an up-to-date inventory (4.3), backups whose restore is checked (7.2), controlled changes (10), recorded access authorisations (12.1, 12.3), incidents traced to root cause (13). Half of the programme already sits in your procedures. What they lack is a security reading.

Maturity: a requirement is no longer pass or fail

The 2010 edition asked whether a CSMS contained an element. The 2024 edition asks how well each requirement is met: clause 4.2 defines the maturity levels, clause 5 the conformity evidence, and Annex C how to evaluate maturity. The ISA Global Cybersecurity Alliance summarises the shared scale this way: maturity levels measure processes (people, policies and procedures), security levels measure technical strength, parts 2-1, 2-2, 2-4 and 4-1 use them, and the model is derived from CMMI with its levels 4 and 5 merged. ML1, Initial, is ad hoc and often undocumented. ML2, Managed, works from written policies with trained people. ML3, Defined (Practiced), means the process is repeatable across the organisation. ML4, Improving, means it is in practice, with documented evidence, and measured for effectiveness.

On a GMP site the boundary that matters is the one between a written procedure and a practised one, because inspectors already probe it. An approved SOP for quarterly account reviews, with trained reviewers, describes ML2. The same review done the same way on every line, quarter after quarter, is what the higher levels ask for; once its records are measured and used to improve the process, the programme is at the top of the scale. The SOP is identical at every one of those levels. Only the evidence changes. The newest document in the series, IEC PAS 62443-2-2, uses this same maturity input to rate how well a zone is protected in operation, as explained in rating each zone as it runs.

What the standard accepts about old plants

A site with a fifteen-year-old DCS may read the eight elements and despair. The scope recognises that an IACS can stay in service for more than twenty years, that many legacy systems are no longer supported, and that the programme for most of them will therefore cover only a subset of the requirements. Where a system lacks the native capability, compensating security measures can be part of the policies and procedures. The definition gives a plain example: a locked cabinet around a controller that has no adequate cyber access control.

Nor does every requirement apply to every IACS. A line without wireless has no NET 2 to meet, and the asset owner identifies the requirements that apply. Validation people will recognise the reasoning of a risk-based scope: state what applies, justify what does not, and keep the justification where an inspector can read it. Annex 11 itself says that the extent of security controls depends on the criticality of the system (12.2).

Running the programme through the quality system

The introduction to the standard warns against a frequent mistake, dealing with cybersecurity “one system at a time”. A pharmaceutical site already has a structure built to avoid exactly that for quality, and the programme can borrow it.

ICH Q10 describes the elements of the pharmaceutical quality system that carry most of the load: process performance and product quality monitoring, CAPA, change management (3.2) and management review of the quality system itself (4.1). Map the programme onto them. A failed backup restore becomes a deviation and a CAPA, not an email. A new remote access conduit goes through change control, with a security impact question on the form. The programme review that ORG 2.4 asks for becomes an agenda item of management review, with the maturity baseline as its input.

The regulators are heading the same way. The Commission’s draft of a revised Annex 11, consulted on from 7 July to 7 October 2025, has a full security chapter. Its first clause asks regulated users to ensure that “an effective information security management system is implemented and maintained” (15.1), and its periodic review chapter lists access reviews, security incidents, new security threats and restore tests among the things to follow up (14.2). The EudraLex page still lists Annex 11 in its January 2011 revision. The draft shows where things are going; it is not yet an obligation, and a programme run inside the quality system will fit either text.

Eight lines for the programme document

The programme needs a short governing document that points to the procedures doing the work. A manual is not needed. In practice it comes down to eight lines:

1. Scope. The IACS covered, by reference to the computerised system inventory, and the boundary with the IT ISMS.
2. Owner and roles. Who is accountable as asset owner, who executes, who checks, and which service providers carry part of the requirements.
3. Applicability. For each SPE, the requirements that apply, those that do not and why, and where a compensating measure replaces a missing capability.
4. Procedures. For each applicable requirement, the SOP or work instruction that meets it, usually an existing one with a security section added.
5. Evidence. The record that proves each procedure is done: review sheets, change records, restore test reports, access logs.
6. Maturity baseline. The current level per requirement, assessed once and dated, with the target level and when it is expected.
7. Links to the quality system. Deviations, CAPA, change control and periodic review: which security events enter which process.
8. Review. How often the programme is reviewed, by whom, and how the results reach management review.

Line 3 is where most of the thinking happens. Line 5 is where most programmes are weakest. Roles deserve care too; who decides, who executes, who checks sets out a split that works on a plant.

Where to start

Start with an honest baseline rather than a policy. Take the eight elements, list the requirements that apply to one production area, and for each one find the record that shows it is done. If the record exists on every line and goes back a year, the requirement is practised. If there is a procedure but no records, it is managed on paper. If neither exists, it is at best initial: a finding, not a failure. Do this with the OT engineer and the computerised systems validation lead in the same room, because one knows the systems and the other knows where the records live. Then take the three gaps with the worst consequence for the product and put them into CAPA with owners and dates. Backup restoration is often one of them, for reasons set out in a backup is a hypothesis.

Five common mistakes

• Rewriting the 2010 binder. Adding SPE numbers to the old CSMS document gives the same gaps a new cover. Start from the requirements and the evidence.
• Building a second management system. If the company already runs an ISO/IEC 27001 ISMS, extend it to the plant and coordinate with it, as ORG 1.1 expects. Two review cycles on the same risks will drift apart within a year or two.
• Treating maturity as a grade. A maturity baseline is a measurement. Use it to rank sites against each other and people learn to report the score instead of producing the records.
• Skipping the applicability step. Claiming every requirement on a legacy line invites findings you cannot close. The scope allows a requirement to be declared not applicable, with a reason and a compensating measure.
• Leaving quality out. When the programme sits only with engineering, a failed restore or an unapproved remote session never becomes a deviation, and on a GMP site that is where the programme should show its value.

The OT engineer and the quality manager from the opening each held half of the programme. The second edition gives them a way to join the halves: eight elements, a record per requirement, a maturity level.

A security programme is not the binder that describes it. It is the records that show, requirement by requirement, that it is done.

References

• automation.com, *ISA Standards Update Addresses Organization-Wide Cybersecurity in Industrial and Critical Infrastructure Operations*, 28 January 2025 (the item that prompted this article).
• IEC, *IEC 62443-2-1:2024, Security program requirements for IACS asset owners*, edition 2.0, 7 August 2024.
• ISA Global Cybersecurity Alliance, *Quick Start Guide: An Overview of ISA/IEC 62443 Standards*, maturity model.
• ISA Global Cybersecurity Alliance, *Applying ISO/IEC 27001, ISO/IEC 27002 and the ISA/IEC 62443 Series*, white paper, 2025.
• European Commission, *EudraLex Volume 4, Annex 11: Computerised Systems*, 2011, and the 2025 consultation on its revision, draft §14 and §15.
• ICH, *Q10 Pharmaceutical Quality System*, 2008, §3.2 and §4.1.