IEC PAS 62443-2-2:2025

IEC PAS 62443-2-2 ®
Edition 1.0 2025-03
PUBLICLY AVAILABLE
SPECIFICATION
Security for industrial automation and control systems –
Part 2-2: IACS security protection scheme

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - webstore.iec.ch/advsearchform IEC Products & Services Portal - products.iec.ch
The advanced search enables to find IEC publications by a Discover our powerful search engine and read freely all the
variety of criteria (reference number, text, technical publications previews, graphical symbols and the glossary.
committee, …). It also gives information on projects, replaced With a subscription you will always have access to up to date
and withdrawn publications. content tailored to your needs.

IEC Just Published - webstore.iec.ch/justpublished
Electropedia - www.electropedia.org
Stay up to date on all new IEC publications. Just Published
The world's leading online dictionary on electrotechnology,
details all new publications released. Available online and once
containing more than 22 500 terminological entries in English
a month by email.
and French, with equivalent terms in 25 additional languages.

Also known as the International Electrotechnical Vocabulary
IEC Customer Service Centre - webstore.iec.ch/csc
(IEV) online.
If you wish to give us your feedback on this publication or need

further assistance, please contact the Customer Service
Centre: sales@iec.ch.
IEC PAS 62443-2-2 ®
Edition 1.0 2025-03
PUBLICLY AVAILABLE
SPECIFICATION
Security for industrial automation and control systems –

Part 2-2: IACS security protection scheme

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 25.040.40; 35.100.05 ISBN 978-2-8327-0299-4

– 2 – IEC PAS 62443-2-2:2025 © IEC 2025
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 7
2 Normative references . 7
3 Terms, definitions, abbreviated terms and acronyms . 8
3.1 Terms and definitions . 8
3.2 Abbreviated terms and acronyms . 10
4 Relationship between this document and other documents . 10
5 Security program and security protection scheme . 11
5.1 Relationship between security program and security protection scheme. 11
5.2 Process steps for the generation of a Security Protection Scheme . 12
6 Security protection ratings . 14
6.1 Overview. 14
6.2 Use of the maturity model defined in IEC 62443-2-1 for the determination of
SPR values . 15
6.3 Use of alternative SPR matrixes for internal purposes . 17
6.4 Grouping of security requirements . 18
6.5 Tracing to SPEs and sub-SPEs . 18
6.6 Views . 19
6.7 SPR and SL types . 20
6.7.1 General . 20
6.7.2 SL types for products . 20
6.7.3 SPR types used in an IACS life cycle . 20
7 Principal roles. 22
7.1 Overview. 22
7.2 Asset owner . 23
7.3 Integration service provider . 24
7.4 Maintenance service provider . 24
7.5 Product supplier . 24
7.6 Other roles . 25
8 Duties and activities in the IACS life cycle related to the security protection
scheme . 25
8.1 Overview. 25
8.2 Generation of the cybersecurity requirement specification (CRS) . 26
8.3 Design and implementation of the security measures . 27
8.4 Generation and documentation of the process security measures . 30
8.5 Validation of the security protection scheme . 30
8.5.1 Overview . 30
8.5.2 Validation of the technical security measures . 31
8.5.3 Validation of the process security measures . 32
8.5.4 Prediction of the SPR values, SPR-I . 32
8.6 Periodic revalidation of the SPS during operation . 33
Annex A (informative) Example of methodology for SPR verification . 34
A.1 Overview. 34
A.2 Detailed assessment, requirements-based . 34
A.3 Detailed assessment, risk-based . 35

A.4 Simplified evaluation, questions-based . 35
Annex B (informative) Maturity level assessment . 36
B.1 General . 36
B.2 Overall assessment work process . 36
B.3 Maturity level assessment procedure . 36
B.4 Security program maturity level assessment attributes . 39
B.5 ML assessment documentation . 42
Bibliography . 44

Figure 1 – Simplified asset owner security protection scheme (SPS) life cycle . 7
Figure 2 – Security program and security protection scheme . 12
Figure 3 – Process steps for generating a security protection scheme . 13
Figure 4 – Maturity model . 15
Figure 5 – Determination of the SPR value by using the maturity model of
IEC 62443-2-1 . 16
Figure 6 – Example of visualizing the fulfilment of a system security requirement with
an SPR value . 17
Figure 7 – Examples of alternative SPR matrix for internal purposes . 18
Figure 8 – Example of a dashboard for the generic view . 20
Figure 9 – Use of SPR and SL types in the IACS life cycle . 22
Figure 10 – Roles and responsibilities overview . 23
Figure 11 – Life cycle phases and roles . 26
Figure 12 – Iterations in the IACS life cycle . 26
Figure 13 – Activities and responsibilities for the generation of the CRS (simplified
view) . 27
Figure 14 – Activities and responsibilities for the design and implementation of the
technical security measures applied to the automation solution (simplified view). 28
Figure 15 – Activities and responsibilities for the documentation of process security
measures (simplified view) . 30
Figure 16 – Example of the determination of the SL value which can be met with
capabilities provided by the technical security measures . 31
Figure 17 – Example of the prediction of the SPR value . 32
Figure B.1 – Example ML assessment based on IEC 62443-2-1 . 43

Table B.1 – Assessment MLs . 36
Table B.2 – Maturity level assessment procedure . 37
Table B.3 – Security program maturity level assessment attributes . 39

– 4 – IEC PAS 62443-2-2:2025 © IEC 2025
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
SECURITY FOR INDUSTRIAL AUTOMATION AND CONTROL SYSTEMS –

Part 2-2: IACS security protection scheme

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Their
preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with
may participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between
any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in
respect thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s), which
may be required to implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at https://patents.iec.ch. IEC
shall not be held responsible for identifying any or all such patent rights.
IEC 62443-2-2 has been prepared by IEC technical committee 65: Industrial-process
measurement, control and automation. It is a Publicly Available Specification.
IEC PAS 62443-2-2 has been developed by IEC TC 65 and the liaison ISA99: ISA committee
on Security for industrial automation and control systems.
The text of this Publicly Available Specification is based on the following documents:
Draft Report on voting
65/1051/DPAS 65/1121/RVDPAS
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this Publicly Available Specification is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, and the
ISO/IEC Directives, JTC 1 Supplement available at www.iec.ch/members_experts/refdocs. The
main document types developed by IEC are described in greater detail at
www.iec.ch/publications.
A list of all parts in the IEC 62443 series, published under the general title Security for industrial
automation and control systems, can be found on the IEC website.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
• reconfirmed,
• withdrawn, or
• revised.
NOTE In accordance with ISO/IEC Directives, Part 1, IEC PASs are automatically withdrawn after 4 years.

– 6 – IEC PAS 62443-2-2:2025 © IEC 2025
INTRODUCTION
This document is the part of the IEC 62443 series that 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. In the context of this document, asset owner
also includes the operator of the IACS.
The purpose of the document is to provide input to support 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.
SECURITY FOR INDUSTRIAL AUTOMATION AND CONTROL SYSTEMS –

Part 2-2: IACS security protection scheme

1 Scope
This part of IEC 62443 provides guidance on the development, validation, operation, and
maintenance of a set of technical, physical, and process security measures called Security
Protection Scheme (SPS). The document’s goal is to provide the asset owner implementing an
IACS Security Program (SP) with 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.
The document is based on contents specified in other documents of the IEC 62443 series and
explains how these contents can be used to support the development of technical, physical,
and process security measures addressing the risks to the IACS during the operation phase.
Figure 1 illustrates the content of this document using a simplified IACS life cycle.

Figure 1 – Simplified asset owner security protection scheme (SPS) life cycle
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies.
For undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC TS 62443-1-1:2009, Industrial communication networks – Network and system security –
Part 1-1: Terminology, concepts and models

– 8 – IEC PAS 62443-2-2:2025 © IEC 2025
IEC 62443-2-1:— , Security for industrial automation and control systems – Part 2-1: Security
program requirements for IACS asset owners
IEC 62443-2-4:2023, Security for industrial automation and control systems – Part 2-4: Security
program requirements for IACS service providers
IEC 62443-3-2:2020, Security for industrial automation and control systems – Part 3-2: Security
risk assessment for system design
IEC 62443-3-3:2013, Industrial communication networks – Network and system security –
Part 3-3: System security requirements and security levels
3 Terms, definitions, abbreviated terms and acronyms
For the purposes of this document, the terms and definitions given in IEC TS 62443‑1‑1 and
the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at https://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
NOTE Terms and definitions are defined in IEC TS 62443-1-1. The purpose of this clause is to provide supplemental
guidance for some key terms used in this document, to improve clarity for the reader.
3.1 Terms and definitions
3.1.1
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
Note 1 to entry: The SP for IACS asset owners refers to the policies and procedures defined by them to address
cybersecurity concerns of the IACS. This can include technical, process, physical and compensating security
measures used to reduce the cybersecurity attack surface.
[SOURCE: IEC 62443-2-1:—, 3.1.15]
3.1.2
security protection scheme
SPS
set of technical, physical, and process security measures designed to address cyber security
concerns of an IACS during operation
Note 1 to entry: The SP for IACS asset owners refers to the policies and procedures defined by them to address
cybersecurity concerns of the IACS. This can include technical, process, physical and compensating security
measures used to reduce the cybersecurity attack surface.
___________
Under preparation. Stage at the time of publication: IEC/FDIS 62443-2-1:2024.

3.1.3
system security requirement
security requirements based on requirements specified in IEC 62443-3-3:2013
Note 1 to entry: When applied to products, the system security requirements are specified in IEC 62443-3-3:2013.
Each requirement is formulated as "The control system shall provide the capability to …".
Note 2 to entry: When applied to automation solutions, the system security requirements are defined as "The zone
of the automation solution shall provide the capability to …", instead of "The control system shall provide the
capability to …":
Note 3 to entry: When applied to IACS in operation, the system security requirements are defined as "The IACS in
operation shall provide the capability to …", instead of "The control system shall provide the capability to …".
3.1.4
security level
measure of confidence that the IACS is free from vulnerabilities and functions in the intended
manner
Note 1 to entry: The definition of security levels is expected to evolve. In the context of this document, the security
levels are the levels to which the system security requirements are mapped to according to IEC 62443-3-3.
[SOURCE: IEC 62443-3-3:2013: 3.1.38, modified – The Note to entry has been changed.]
3.1.5
target security protection ratings
levels of the system security requirements that an asset owner desires to be fulfilled during
operation
3.1.6
implemented security protection ratings
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
3.1.7
operated security protection ratings
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
3.1.8
maturity level
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
Note 1 to entry: In the context of this document, maturity levels express the level of confidence that process security
measures are executed by the personnel in charge during operation of the IACS with a demonstrated repeatability
and effectiveness.
[SOURCE: IEC 62443-2-1:—, 3.1.7, modified – The Note to entry has been added.]
3.1.9
security measure
measure taken for an IACS to protect the safety, integrity, availability, and confidentiality
[SOURCE: IEC TS 62443-1-1:—, 3.1.110]

– 10 – IEC PAS 62443-2-2:2025 © IEC 2025
3.2 Abbreviated terms and acronyms
AO asset owner
CRS cybersecurity requirements specification
IACS industrial automation and control systems
IEC International Electrotechnical Commission
ISA International Society of Automation
ISO International Organization for Standardization
KPI key performance indicator
ML maturity level
MS maintenance service provider
NIST National Institute of Standards and Technology
PS product supplier
SI integration service provider
SL security level
SL-C security level capability
SP security program
SPE security program element
SPR security protection rating
SPR-I security protection rating implemented
SPR-O security protection rating operational
SPR-T security protection rating target
SPS security protection scheme
SR security requirement
SuC system under consideration

4 Relationship between this document and other documents
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.
The concepts described in this document are not all reflected in currently published documents
of the IEC 62443 series. None of these concepts contradicts contents of the IEC 62443
documents. They provide input for evolutions, which are expected to be reflected in further
editions of IEC 62443 series documents.

5 Security program and security protection scheme
5.1 Relationship between security program and security protection scheme
IEC 62443-2-1 specifies security program (SP) requirements for IACS asset owners. The SP of
IACS asset owners refers to technical, physical, and process security measures defined by
them to address cyber security concerns of all the IACS during their respective life cycle. The
SP can include technical, physical, and process security measures to reduce the cyber security
attack surface. The SP also includes physical measures to reduce access to the assets of the
IACS.
IEC 62443-2-1 has a requirement for the SP to implement an information security management
system ensuring the execution of actions to reduce the risks. For an asset owner, risk reduction
means the implementation of the necessary security measures for the protection of its operating
facility against cyberthreats. It is not unusual that an operating facility includes several IACS,
each of them controlling a part of the physical process. According to the criticality for the
business of the asset owner, each IACS can have different target levels for security protection.
The risk reduction actions include for each IACS the development of a set of technical, physical,
and process security measures – the security protection scheme (SPS) – to meet the required
target security protection levels. An asset owner establishing a security program ensures that
a SPS is designed and applied during operation for each IACS, involving all roles defined in the
IEC 62443 series.
The SPS life cycle is identical to the life cycle of the IACS to which the SPS is applied. In
addition to security measures applied to each IACS, the SP includes security measures to meet
corporate organization requirements of the operating facility. These are linked to the enterprise
life cycle of the operating facility which is decoupled from the IACS / SPS life cycles. Examples
of those measures are security management policies and procedures, security measurements
such as KPIs, escalation procedures, top management reports, etc.
It is necessary to align the corporate organization requirements of the operating facility with
those which apply to each IACS.
The latter leads to specific technical, physical, and process security measures for each IACS
resulting from a risk-based approach considering the criticality of the considered IACS. In the
context of IEC 62443, the asset owner role also includes the operator of each IACS. During
operation, the execution of process security measures of the SPS by the personnel in charge
are the responsibility of the asset owner.
Figure 2 illustrates the relationship between the SP and the SPS.

– 12 – IEC PAS 62443-2-2:2025 © IEC 2025

Figure 2 – Security program and security protection scheme
5.2 Process steps for the generation of a Security Protection Scheme
The primary process steps for the generation of an SPS are illustrated in Figure 3. Based on
the process steps of IEC 62443-3-2, a partitioning of the IACS in zones and conduits is
performed and the technical, physical, and process security measures are designed.
A cybersecurity requirement specification (CRS) is created for documenting the system security
requirements for each zone and conduit. These are derived from the application to a specific
IACS of the requirements of IEC 62443-2-1, to meet the tolerable cybersecurity residual risks
which are specific to the considered IACS. The system security requirements are formulated by
applying IEC 62443-3-3 requirements to zones and conduits of the IACS instead of capabilities
of control systems. They should be grouped according to the security program elements (SPEs)
and sub-SPEs defined in IEC 62443-2-1, to provide tracing to the asset owner security program
requirements. The mapping of system security requirements to levels supports the required
strength of security measures to meet the tolerable cybersecurity residual risks.
The CRS further includes enterprise, business, and operational constraints which are
considered when designing the security measures. They include but are not limited to:
• operating environment assumptions,
• physical access to the assets of the IACS,
• assumptions and external dependencies,
• demarcation between OT and IT,
• company or site-specific policies,
• standards,
• regulatory requirements,
• operational availability and performance constraints,
• safety requirements,
• cost constraints.
The process starts with a risk-based system partitioning along the process steps described in
IEC 62443-3-2, leading to zones and conduits.

For each zone and its conduits and SPE / sub-SPE, the CRS includes:
a) applicable IEC 62443-2-1 requirements,
b) derived system security requirements (IEC 62443-3-3) to meet the tolerable cybersecurity
residual risks,
c) enterprise, business, and operational constraints.
For each zone and its conduits, a set of technical, physical, and process security measures are
designed to fulfil the security requirements of the zone and its conduits. Some of the security
measures are specific to only one zone and its conduits, others are effective for several or all
zones and conduits. The SPS includes all technical, physical, and process security measures
to fulfil the security requirements of each zone and its conduits.
In general, technical security measures, including, if any, compensating technical security
measures, are not sufficient to fulfil the system security requirements during the operation of
the IACS. The technical capabilities are operated according to associated process security
measures. As the operation phase often lasts many years, these associated process security
measures significantly impact the fulfilment of the requirements. For example, the
implementation of a firewall is a technical security measure supporting the fulfilment of the
system security requirement SR 1.13 (see IEC 62443-3-3) to "monitor and control all methods
of access via untrusted networks". The security protection is given by the configured firewall
according to the asset owner’s requirements. During operation, the protection is directly
impacted by the management of the firewall configuration, which constitutes the associated
process security measures.
Figure 3 – Process steps for generating a security protection scheme

– 14 – IEC PAS 62443-2-2:2025 © IEC 2025
6 Security protection ratings
6.1 Overview
Security protection ratings (SPR) are used when assessing the fulfilment of system security
requirements by the security measures included in the Security Protection Scheme. The content
of the system security requirements, including their mapping to security levels (SL), is provided
by IEC 62443-3-3.
The goal of the SPR is to support the target risk mitigation determined for the IACS solution
during operation. Consequently, the system security requirements are defined as "The IACS in
operation shall provide the capability to …", instead of "The control system shall provide the
capability to …".
A system security requirement is assessed as fulfilled when the security measures provide the
capability to fulfil it and the organizational part of the security measures are practiced reliably.
The SPR describes the outcome of the assessment process in values from 0 to 4, which reflect
the level of compliance with the system security requirement.
The SPR value combines two parts:
a) the mapping of the considered system security requirement to the security level (SL), and
b) the repeatability to execute the organizational measures necessary to sustain the required
security measures during operation.
The first step is to evaluate the capability to fulfil the system security requirement. In many
cases the security measures necessary to provide risk mitigation are a combination of technical
measures implemented in the automation solution and organizational measures. The
organizational measures include those sustaining the technical measures, as well as
compensating risk mitigation organizational measures, if any. If the system security requirement
can be fulfilled, the SL value is equal to the mapping of the considered system security
requirement. The second part focuses on the repeatability of executing the organizational
measures necessary to sustain the required security measures. The effectiveness of these is
taken as a prerequisite and is not considered in this document. If the process security measures
are executed reliably, the SPR value is equal to the mapping of the considered system security
requirement.
System security requirements can also be fulfilled by purely organizational measures. In this
situation, the assessment focuses on the repeatability of execution. The SL and the SPR values
are equal to the mapping of the considered system security requirement if the process security
measures are executed reliably.
EXAMPLE Regarding the system security requirement SR 1.1 – which is mapped to SL 1 –, the assessor will
evaluate the fulfilment of the requirement: "The IACS in operation shall provide the capability to identify and
authenticate all human users". The SL value is equal to 1, if the technical, physical, and process security measures
provide the capability to fulfil this requirement. Fulfilment is achieved if the responsible personnel execute reliably
the organizational measures necessary for the identification and authentication of human users, thus leading to the
SPR value equal to 1.
The assessment evaluates the fulfilment of each system security requirement by one or several
security measures, resulting in either "fulfilled" or "not fulfilled". Partial fulfilment is not
considered in the determination of the SPR values but could be used to measure progress. How
fulfilment is assessed depends on the methodology, which is not specified in this document.
Any used methodology should show consistency and repeatability of the assessment results.
Annex A provides example(s) of methodologies that could be considered.

6.2 Use of the maturity model defined in IEC 62443-2-1 for the determination of SPR
values
Maturity models are commonly used to evaluate organizations regarding the ability of their
personnel to repeatably act according to defined policies and procedures. Organizations can
apply an existing model or define their own model. A maturity model to be used for the
evaluation of the repeatability of execution of the process security measures should satisfy the
following criteria, as shown in Figure 4:
• Maturity levels should be described with a clear differentiation of the levels.
• Each level should be progressively more advanced than the previous level.
• The model should include a threshold in the scale defining a repeatable execution of the
process security measures when the threshold is exceeded.

Figure 4 – Maturity model
IEC 62443-2-1 defines a maturity model that sets benchmarks for the execution of the process
security measures by the asset owner. Based on this maturity model, the definitions of the
maturity levels for the evaluation of the repeatability of execution of the process security
measures are:
ML 1: Processes are performed in an ad-hoc and often undocumented (or not fully
documented) manner. As a result, consistency over time can be difficult to be shown.
ML 2: Documentation exists and how to manage the delivery and performance of the
capability. This documentation can be in form of written procedures or written training
programs for performing the capability. There can be a significant delay between
defining a process and executing it.
ML 3: A process at Level 3 is a Level 2 process that is being practiced on the IACS. The
performance of a Level 3 practice can be shown to be repeatable over time within the
IACS.
ML 4: Using suitable process metrics, the effectiveness and/or performance improvements
of the process security measures for operation can be demonstrated. This results in a
SP that improves the process through technological / procedural / management
changes.
According to this maturity model, the threshold defining a repeatable execution of process
security measures is between ML 2 and ML 3. At ML 3, documentation exists that describes
how to execute the process security measures as well as proof on on-going repeatable
execution. This documentation can be in the form of written policies and procedures, and written
training programs that establish the basis that the practices are repeatable, even during times
of stress. When these practices are in place, measured performance, e.g., training records,
focused audits, key performance indicators, etc. provides evidence that their execution is
performed and managed according to their documented plans. The execution can be shown to
be repeatable over time within the IACS.

– 16 – IEC PAS 62443-2-2:2025 © IEC 2025
Figure 5 shows the determination of the SPR value using a matrix. The horizontal axis
represents the security level to which the considered system security requirement is mapped.
The vertical axis differentiates the maturity level for the execution of the process security
measures. The SPR value is "not defined" if there is no assurance about repeatable execution
of the process security measures.

Figure 5 – Determination of the SPR value by using the maturity model
of IEC 62443-2-1
As IACS are often operated over many years, it is important to ensure that the process security
measures are reliably practiced over time. If this is not the case, the level of protection of the
IACS during operation can be degraded. Human behaviour has a great impact on the protection
of the IACS during operation and can significantly increase attack surfaces. Referring to the
example of identification and authentication, a significant weakness is created if an authorized
human user does not handle its credentials confidentially. The reason could be that there is no
password policy prescribing the confidential handling of passwords, or that employees are not
aware of or don’t follow the policy. The ML value would be rated as less than 3. Due to this
weakness, the protection of the IACS can be significantly lowered, even if the access control
capabilities of the automation solution would allow a higher level of protection to be achieved.
Figure 6 shows the use of the SPR matrix to visualize the assessment of the fulfilment of a
system security requirement mapped at Level 3. The first step is to assess if the technical and
process security measures provide the capability to fulfil the system security requirement. This
leads to a SL value of 3 in case of a positive result. In a second step, the repeatability of
execution of the process security measures is assessed, which is reflected in the ML value.
When the maturity level is above the threshold (ML 3 or ML 4), the system security requirement
is fulfilled, which is reflected by an SPR value of 3.

Figure 6 – Example of visualizing the fulfilment of a system security
requirement with an SPR value
6.3 Use of alternative SPR matrixes for internal purposes
Some risk reduction should be available even for ML 1 and ML 2; however, it will be less than
if ML 3 or ML 4 were applicable for the same SL capability. Organizations can define for internal
purposes their own set of SPR values for ML 1 and ML 2, leading to alternative SPR matrixes
that are helpful with respect to an asset owner’s risk management program when it comes to
making recommendations intended to provide improvements. Another benefit of estimating SPR
values for all MLs is to show progress in the evolution of the organization’s maturity level.
When assigned to fields of the matrix at ML 1 and ML 2, SPR values should match the following
rules:
• For a given SL which can be matched, the SPR values should not decrease when the
maturity improves, as the maturity level reflects the reliability of the organization to use the
capabilities provided by the technical security measures during operation.
• The SPR values in the rows for ML 3 and ML 4 are equal to the corresponding SL values.
Organizations can differentiate improvements in effectiveness and performance of the
process security measures by claiming ML 4 in addition to the SPR values.
The left side of Figure 7 shows an example of a SPR matrix with SPR values fulfilling the rules.
An alternative possibility to show progress is to visualize in each field below ML 3 the SL values
which can be matched and the ML values, as illustrated in the example on the right of Figure 7.

– 18 –
...