IEC PAS 62443-2-2:2025, "Security for industrial automation and control systems — Part 2-2: IACS security protection scheme," is the part of the IEC 62443 series that tells an asset owner how to turn a paper security program into an operating, measurable set of controls on a specific industrial automation and control system (IACS). Published as a Publicly Available Specification — a faster-track, pre-standard publication type, not yet a full International Standard — on 11 March 2025, it introduces the Security Protection Scheme (SPS) and a three-stage Security Protection Rating (SPR) model that connects 62443-2-1's security-program maturity concepts to 62443-3-3's technical security levels.
Why a new part, and why a PAS rather than a standard
The Introduction states plainly that this document "provides guidance on the development and validation of a set of technical, physical, and process security measures to address risk associated with cyberthreats when operating IACS," aimed at supporting "asset owners, integration service providers, maintenance service providers as well as product suppliers in their activities to provide a combination of technical, physical, and organizational capabilities for protecting IACS against cyberthreat." IEC publishes a PAS — rather than going straight to an International Standard — when a technical committee wants to put emerging, not-yet-fully-consensus content into public circulation faster. Clause 4 is candid about that status here: "the concepts described in this document are not all reflected in currently published documents of the IEC 62443 series," though "none of these concepts contradicts contents of the IEC 62443 documents" — the stated intent is that this PAS's concepts "are expected to be reflected in further editions of IEC 62443 series documents."
That provisional status has a hard deadline attached. The Foreword states the committee has set a 2026 stability date at which the document will be "reconfirmed, withdrawn, or revised," and separately notes that "in accordance with ISO/IEC Directives, Part 1, IEC PASs are automatically withdrawn after 4 years" if no further action is taken — so this PAS has, structurally, until 2029 at the latest before it is either superseded by a full International Standard or lapses. ISA published its own parallel edition, ISA-TR62443-2-2-2025, on 4 December 2025; ISA99 co-chair Eric Cosman described its purpose in ISA's press release: "ISA-TR62443-2-2 gives asset owners and operators a risk-based approach for day-to-day security actions. By bringing together technical controls, process maturity and clear accountability, this guidance ... can help organizations sustain cyber protection across the entire IACS lifecycle."
The Security Protection Scheme (SPS): what an asset owner actually builds
Clause 1's Scope defines the SPS as "a set of technical, physical, and process security measures" whose design, implementation and operation is meant to "manage the risks resulting from cyberthreats to each of the IACS included in [the asset owner's] operating facility." Figure 1 lays this out across a simplified IACS life cycle — Specification, Design & Implementation, Verification & Validation, Operation & Maintenance, and Decommissioning — with the SPS taking shape as "technical security measures applied to automation solution" plus "process security measures," validated before an "Approved SPS" hands over from engineering to operations, and then periodically revalidated during operation (Clause 8.6 notes revalidation "can be triggered by MOC [management of change], following incidents and/or at a defined time interval").
Clause 3.1.1 and 3.1.2 draw a precise line between two terms that are easy to conflate:
| Term | Definition (verbatim) | Scope |
|---|---|---|
| Security Program (SP) | "portfolio of security services, including integration services and maintenance services, and their associated policies, procedures and products that are applicable to the IACS" | Organization-wide, per IEC 62443-2-1 |
| Security Protection Scheme (SPS) | "set of technical, physical, and process security measures designed to address cyber security concerns of an IACS during operation" | Per-IACS, operational output of the SP |
Security Protection Ratings: target, implemented, operated
Clause 6 introduces the document's central measurement concept: a three-stage rating that tracks a system security requirement's fulfillment across the life cycle, rather than a single pass/fail check at commissioning. Verbatim from Clause 3.1.5-3.1.7:
| Rating | Definition (verbatim) | When it applies |
|---|---|---|
| Target SPR (SPR-T) | "levels of the system security requirements that an asset owner desires to be fulfilled during operation" | Specification |
| Implemented SPR (SPR-I) | "levels of the system security requirements which can be fulfilled during implementation by the designed technical, physical, and process security measures, under the assumption that the process security measures will be executed during operation with a demonstrated repeatability and effectiveness" | Design/implementation, predicted ahead of operation (Clause 8.5.4) |
| Operated SPR (SPR-O) | "levels of system security requirements that have been fulfilled by the technical, physical, and process security measures at a given point of time during operation, with demonstrated process security measures that are repeatable and effective" | Operation, re-assessed periodically |
Clause 6.2 ties the SPR value for a given requirement to two inputs: the technical Security Level (SL) that the deployed controls can support (Clause 3.1.4, sourced from 62443-3-3: "measure of confidence that the IACS is free from vulnerabilities and functions in the intended manner"), and the maturity level of the process measures sustaining it — defined in Clause 3.1.8 (sourced from 62443-2-1) as a "qualitative method of characterizing the capability of an organization to implement security requirements according to documented policies and procedures and their historical performance in doing so." A requirement with strong technical controls but weak, undocumented process discipline around them does not earn a high SPR under this model — the rating is explicitly a combination of both, not the technical capability alone. Clause 6.3 also allows asset owners to define "alternative SPR matrixes for internal purposes," and Clause 6.6 introduces "views" (including a dashboard-style "generic view," per Figure 8) for presenting SPR status across a set of requirements.
Five roles, and how this part connects the rest of the series
Clause 7 names the principal parties involved in building and sustaining an SPS: the asset owner (the Introduction specifies this "also includes the operator of the IACS"), the integration service provider, the maintenance service provider, the product supplier, and an open "other roles" category. Clause 8 walks through the duties each role carries across the life cycle — generating the cybersecurity requirement specification (CRS), designing and implementing technical security measures, documenting process security measures, validating the SPS, and periodically revalidating it during operation.
Clause 4 states this part's function directly: it "describes the activities for the design, implementation, and validation of an SPS and the use of IEC 62443-2-1, IEC 62443-2-4, IEC 62443-3-2, IEC 62443-3-3, IEC 62443-4-1, and IEC 62443-4-2 for supporting these activities." In other words, 62443-2-2 does not introduce a competing set of requirements — it is the connective document showing how an asset owner's security-program maturity work (62443-2-1), a system's risk assessment (62443-3-2), its technical security requirements (62443-3-3), and the supplier-side secure-development and component requirements (62443-4-1, 62443-4-2) all feed into one operating, rated scheme for a specific IACS.
One dating quirk is worth flagging for anyone citing this PAS directly: its own Clause 2 normative references list "IEC 62443-2-1:—" as a document still "under preparation," footnoted at the time of this PAS's drafting as having reached stage "IEC/FDIS 62443-2-1:2024." IEC 62443-2-1:2024 has since been finalized and published (6 August 2024, ahead of this PAS's own March 2025 publication date) — a reminder that a PAS's reference list reflects the drafting committee's state of knowledge at submission, not necessarily the publication status by the time readers see the final text.
A workable starting point
- Treat SPS as the deliverable, not the Security Program itself. If your 62443-2-1 security program exists only as policy documents with no per-IACS technical-plus-process-plus-physical package behind it, you have a Security Program but not yet a Security Protection Scheme in this document's sense.
- Don't rate SPR on technical controls alone. Clause 6.2's model combines a requirement's Security Level with the maturity of the process measures keeping it effective — a well-configured firewall rule set backed by no change-control discipline does not earn a high operated rating under this framework.
- Separate the three SPR stages explicitly in your documentation. Target (what you want), Implemented (what design predicts you'll get), and Operated (what's demonstrably true right now) answer different questions; conflating them hides the gap between design intent and operational reality that Clause 8.5.4's "prediction of SPR-I" is meant to surface before handover.
- Put a revalidation trigger on the calendar, not just an interval. Clause 8.6 ties periodic SPS revalidation to management-of-change events and incidents as well as a defined time interval — a fixed annual review misses the scheme drifting out of alignment after an unplanned change.
- Check the PAS's 2026 stability date and withdrawal clock before building long-term tooling on its exact clause numbers. As a Publicly Available Specification rather than a finalized International Standard, 62443-2-2's content is explicitly provisional input to future 62443-2-1/3-x/4-x editions; confirm current status at webstore.iec.ch before citing a clause number in a compliance claim.
SoftWSP's OT Snapshot gives asset owners a passive, non-intrusive baseline of what technical security measures are actually deployed on an operating IACS — evidence that feeds directly into the kind of operated Security Protection Rating assessment this document describes, without requiring agent installation on live control systems: see OT Snapshot.
This guide quotes IEC's own published text of IEC PAS 62443-2-2:2025 (Foreword, Introduction, Scope, Normative references, Terms and definitions, and Clause 4) as reproduced in its iTeh Standards document preview, and ISA's official press release announcing the parallel ISA-TR62443-2-2-2025 edition; it is not a substitute for the full specification and its Annexes A and B, and does not constitute compliance advice.
More guides
Frequently asked questions
What is IEC 62443-2-2, and what kind of document is it?
IEC PAS 62443-2-2:2025, "Security for industrial automation and control systems — Part 2-2: IACS security protection scheme," is a Publicly Available Specification (PAS) — not yet a full International Standard — published by IEC Technical Committee 65 in liaison with ISA99 (the ISA committee on security for industrial automation and control systems). Per its own Clause 1 scope text, it "provides guidance on the development, validation, operation, and maintenance of a set of technical, physical, and process security measures called Security Protection Scheme (SPS)," with the goal of giving "the asset owner implementing an IACS Security Program (SP) ... mechanisms and procedures to ensure that the design, implementation and operation of an SPS manage the risks resulting from cyberthreats to each of the IACS included in its operating facility." It was published 11 March 2025, Edition 1.0, 44 pages, ISBN 978-2-8327-0299-4, with a stability date of 2026 on the IEC webstore. As a PAS rather than an International Standard, it also carries a specific expiry rule: per its own Foreword, "IEC PASs are automatically withdrawn after 4 years" unless reconfirmed, withdrawn or revised into a full standard first.
What is a Security Protection Scheme (SPS), and how does it relate to an asset owner's Security Program?
The standard's own terms and definitions (Clause 3.1.2) define SPS as a "set of technical, physical, and process security measures designed to address cyber security concerns of an IACS during operation," distinct from the broader Security Program (SP, Clause 3.1.1): a "portfolio of security services, including integration services and maintenance services, and their associated policies, procedures and products that are applicable to the IACS," sourced from [IEC 62443-2-1](/guides/iec-62443-2-1-asset-owner-security-program/)'s own definition. In plain terms: the asset owner's Security Program is the organization-wide policy and procedure framework; the Security Protection Scheme is what that program produces for one specific IACS — the actual combination of technical controls, physical controls and documented process measures protecting that system during operation. Clause 5.1 and Figure 2 depict the SPS as the operational output that a Security Program generates and sustains for each IACS in a facility, not a separate, parallel activity.
What are Security Protection Ratings (SPR), and how do they differ from 62443-3-3's Security Levels (SL)?
Clause 6 introduces Security Protection Ratings as a three-stage rating applied over an IACS's life cycle, defined verbatim in Clause 3.1.5-3.1.7: **target security protection ratings (SPR-T)** are "levels of the system security requirements that an asset owner desires to be fulfilled during operation"; **implemented security protection ratings (SPR-I)** are the levels "which can be fulfilled during implementation by the designed technical, physical, and process security measures, under the assumption that the process security measures will be executed during operation with a demonstrated repeatability and effectiveness"; and **operated security protection ratings (SPR-O)** are the levels "that have been fulfilled by the technical, physical, and process security measures at a given point of time during operation, with demonstrated process security measures that are repeatable and effective." This differs from [62443-3-3](/guides/iec-62443-3-3-system-security-requirements/)'s Security Level (SL), which Clause 3.1.4 (sourced from 62443-3-3) defines as a "measure of confidence that the IACS is free from vulnerabilities and functions in the intended manner" — SL is fundamentally a technical-capability rating, whereas SPR layers in the maturity of the process measures (drawn from [62443-2-1](/guides/iec-62443-2-1-asset-owner-security-program/)'s maturity model) needed to sustain that capability operationally. Clause 6.2 states SPR values are determined by combining a system security requirement's SL with the maturity level of the process measures that keep it effective in practice.
Who are the five principal roles, and how does 62443-2-2 fit with the rest of the 62443 series?
Clause 7 names five principal roles involved in building and sustaining an SPS: the **asset owner** (which the Introduction clarifies "also includes the operator of the IACS"), the **integration service provider**, the **maintenance service provider**, the **product supplier**, and unspecified "other roles." Clause 4 states the document "describes the activities for the design, implementation, and validation of an SPS and the use of IEC 62443-2-1, IEC 62443-2-4, IEC 62443-3-2, IEC 62443-3-3, IEC 62443-4-1, and IEC 62443-4-2 for supporting these activities" — in other words, 62443-2-2 does not replace those parts, it is the connective layer showing an asset owner how to combine 62443-2-1's security-program/maturity model, [62443-3-2](/guides/iec-62443-3-2-security-risk-assessment/)'s risk assessment, 62443-3-3's system security requirements, and [62443-4-1](/guides/iec-62443-4-1-secure-development-lifecycle/)/[62443-4-2](/guides/iec-62443-4-2-component-requirements/)'s supplier-side requirements into one operational scheme. Clause 4 also notes candidly that "the concepts described in this document are not all reflected in currently published documents of the IEC 62443 series" and "none of these concepts contradicts" them — 62443-2-2 is explicitly forward-looking input intended to shape future editions of the other parts, not a finalized cross-reference to settled text. One normative-reference quirk worth flagging: this PAS cites "IEC 62443-2-1:—" as a reference still "under preparation" (footnoted, at time of publication, as "IEC/FDIS 62443-2-1:2024") — [IEC 62443-2-1:2024](/guides/iec-62443-2-1-asset-owner-security-program/) has since been finalized and published (6 August 2024), so readers should treat 62443-2-2's own normative-reference list as slightly dated relative to the now-published 2-1 edition.
Sources
- IEC: IEC PAS 62443-2-2:2025 — Security for industrial automation and control systems — Part 2-2: IACS security protection scheme (webstore record: Edition 1.0, 11 March 2025, 44 pages, ISBN 978-2-8327-0299-4, TC 65, stability date 2026)
- IEC PAS 62443-2-2:2025 — Document Preview (Foreword, Introduction, full Scope Clause 1 with Figure 1 SPS life cycle, Normative references Clause 2, Terms/definitions Clause 3 including SPR-T/SPR-I/SPR-O, abbreviated terms, Clause 4 relationship to other 62443 documents; iTeh Standards sample PDF, reproduced here under IEC's short-quotation allowance)
- ISA: "Update to ISA/IEC 62443 Series Includes Guidance on Security Protection Schemes for IACS" — official press release (4 December 2025) announcing ISA-TR62443-2-2-2025, with quote from ISA99 co-chair Eric Cosman
- Wikipedia: IEC 62443 (series structure, part-by-part summary; cross-checked against the IEC webstore and ISA press release above for this guide)
