ISA/IEC 62443-2-2 (published 2025) defines the
Security Protection Scheme (SPS) for an IACS — the set of technical, physical
and process security measures that address cybersecurity concerns while that system is in
operation. The asset owner designs and applies an SPS for each IACS, involving the roles defined
across the ISA/IEC 62443 series.
Part 2-2 is the bridge from organisation-wide strategy to site action: it turns Security Program
expectations into concrete measures for a specific Automation Solution, then keeps those measures
alive across the IACS lifecycle.
Teaching note: Content paraphrases ISA training material and ISA/IEC 62443-2-2
themes for learning. Always refer to the published standard for normative wording, SPR scoring
and conformity language. Companion lifecycle teaching notes remain on
Automation Solution Security Lifecycle.
Figure – SPS through the IACS lifecycle: Cybersecurity Requirements Specification feeds SPS
design (technical + process measures); validation produces an approved SPS at handover;
operation applies and periodically revalidates the SPS against the Asset Owner Security
Program, with integration, maintenance and product-supplier support.
Learning objectives
Define the SPS and how it relates to the Asset Owner Security Program (Part 2-1).
Explain how SPS design is driven by risk-based zoning (Part 3-2) and a Cybersecurity Requirements Specification.
Describe SPS lifecycle behaviour — design, approval, operation and revalidation.
Summarise Security Protection Ratings (SPR) as a way to score how well the SPS meets system security requirements in practice.
From strategy to action — Part 2-1 and Part 2-2
IEC 62443-2-1 is how the asset owner manages an organisation-wide OT
Security Program (SP) — policies, process expectations and governance that span
the enterprise and every IACS under control.
IEC 62443-2-2 supplies concrete guidance for implementing
technical, physical and procedural security measures for a specific IACS.
The resulting SPS is how that broad SP shows up on a particular Automation Solution in operation.
In teaching terms: Part 2-1 sets the organisational strategy; Part 2-2 turns strategy into the
living scheme of measures on the plant floor. The asset owner owns and executes the SPS, while
integrators, maintainers and product suppliers contribute under contract and role definitions.
Figure – Asset Owner Security Program spans enterprise ISMS/lifecycle topics and each IACS.
For a given IACS, the SPS packages process and technical security measures — some common
across sites, some risk-based and specific — fulfilling Part 2-1 / ISMS expectations for
that system.
What the SPS contains
An SPS is the combination of:
Technical security measures applied to the Automation Solution (drawing on Parts such as 2-4, 3-3, 4-1 and 4-2 for capabilities, integration and product support).
Process (and related physical/organisational) security measures needed to operate and sustain those technical controls — aligned to the Asset Owner SP under Part 2-1.
Some measures are zone- or conduit-specific; others apply across all zones. The SPS also reaches
enterprise-facing topics that sit on the enterprise lifecycle — policies, KPIs, escalation
paths — so local IACS security stays wired to organisational priorities, not a disconnected
plant checklist.
How an SPS is generated
Typical process flow (example pattern from Part 2-2 teaching material):
Start from Asset Owner SP requirements (Part 2-1), enterprise/business/operational constraints, and tolerable cybersecurity residual risk.
Perform risk-based system partitioning into zones and conduits (Part 3-2).
Build a Cybersecurity Requirements Specification per zone (and conduits as needed), including applicable Part 2-1 expectations, derived system security requirements (Part 3-3) sized to residual-risk targets, and local constraints.
Design the SPS — technical and process measures for each zone/conduit, plus measures that apply everywhere.
During design, the requirements specification is the basis for the SPS. In operation, the SPS
must continue to comply with that specification — or the specification and SPS
must be updated together when the world changes.
Figure – Example process steps for generating an SPS: SP / constraints / tolerable risk
→ Part 3-2 partitioning → Cybersecurity Requirements Specification by zone → SPS
(zone-specific and common measures), with ongoing compliance between specification and SPS.
SPS lifecycle mirrors the IACS
The SPS is a living document. It evolves whenever the system changes, threats
shift, or compliance needs update — just as the IACS itself moves through specification, design
and implementation, verification and validation, operation and maintenance, and eventually
decommissioning.
Key teaching points along that path:
Specification — Part 2-1 and Part 3-2 feed a Cybersecurity Requirements Specification (system security requirements) that bases SPS design.
Design & implementation — SPS guidance from Part 2-2 shapes technical measures on the Automation Solution and process measures from the Asset Owner SP.
Verification & validation — SPS is validated; an approved SPS shows it meets the Asset Owner SP before handover from engineering to operations/maintenance.
Operation & maintenance — the approved SPS runs on the live IACS; periodic revalidation (Part 2-2) may be driven by management of change, incidents, or set intervals. On brownfield sites, an early revalidation cycle may be the first formal SPS validation.
Integration service providers typically support engineering contracts through design and V&V;
maintenance service providers support operations contracts thereafter; product suppliers underpin
the whole lifecycle with capabilities, guidelines and product support. Accountability for the SPS
remains with the asset owner.
Security Protection Ratings (SPR)
Security Protection Ratings (SPR) evaluate how well the SPS has been put into
practice — how effectively it meets the system’s security requirements in operation. SPR
compares actual implementation against predefined security expectations grounded in system need.
Requirements under consideration are typically mapped using the
Part 3-3 Security Level model: they
state what the operational system must achieve to keep cybersecurity at the intended level.
SPR brings together two ideas:
Mapping of the considered system security requirements to Security Levels based on threat/risk analysis.
Repeatability of the organisational measures needed to sustain the required security measures during normal operations.
Illustrative scoring themes (0–4)
Teaching materials describe a 0–4 style scale for how thoroughly requirements are met. Exact
normative labels live in the published Part 2-2 text; the progression below is a learning aid:
Score theme
Intent (teaching summary)
0 – Not addressed
Requirement has not been taken up in the operational SPS picture.
Target
Desired fulfilment level of system security requirements the asset owner wants during operation.
Implemented
Goes beyond target definition: process security measures are executed in operation with proven repeatability and effectiveness.
Operated
Adds demonstration that those process measures are repeated and effective under actual operating conditions.
Fully operational / repeatable
Highest maturity of sustained practice — the SPS measures hold as repeatable operations, not a one-off project delivery.
Teaching tip: Do not treat SPR as a replacement for Security Levels (SL) or
Maturity Levels (ML). SPR asks whether the operational SPS actually delivers and
sustains the security the system requires — technical capability and organisational
repeatability together.
Key takeaways
Part 2-2 (2025) defines the SPS — technical, physical and process measures for a specific IACS in operation.
Part 2-1 is the organisation-wide Security Program; Part 2-2 is how that program becomes concrete for each IACS.
SPS design is driven by Part 3-2 zoning/risk work and a Cybersecurity Requirements Specification; the SPS must stay compliant with that specification.
The SPS lifecycle tracks the IACS lifecycle and is a living document through MoC, incidents and revalidation.
The asset owner owns the SPS; integrators, maintainers and product suppliers support delivery and sustainment.
SPR scores how well the SPS meets system security requirements in practice (SL-mapped expectations + operational repeatability).
