EN IEC 62443-3-2:2020

SLOVENSKI STANDARD
01-december-2020
Zaščita sistemov industrijske avtomatizacije in nadzora - 3-2. del: Ocena
varnostnega tveganja in načrtovanje sistema (IEC 62443-3-2:2020)
Security for industrial automation and control systems - Part 3-2: Security risk
assessment and system design (IEC 62443-3-2:2020)
IT-Sicherheit für industrielle Automatisierungssysteme - Teil 3-2:
Sicherheitsrisikobeurteilung und Systemgestaltung (IEC 62443-3-2:2020)
Sécurité des systèmes d'automatisation et de commande industriels - Partie 3-2:
Évaluation des risques de sécurité pour la conception des systèmes (IEC 62443-3-
2:2020)
Ta slovenski standard je istoveten z: EN IEC 62443-3-2:2020
ICS:
25.040.01 Sistemi za avtomatizacijo v Industrial automation
industriji na splošno systems in general
35.030 Informacijska varnost IT Security
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN IEC 62443-3-2

NORME EUROPÉENNE
EUROPÄISCHE NORM
August 2020
ICS 25.040.40; 35.030
English Version
Security for industrial automation and control systems - Part 3-2:
Security risk assessment for system design
(IEC 62443-3-2:2020)
Sécurité des systèmes d'automatisation et de commande IT-Sicherheit für industrielle Automatisierungssysteme - Teil
industriels - Partie 3-2: Évaluation des risques de sécurité 3-2: Sicherheitsrisikobeurteilung und Systemgestaltung
pour la conception des systèmes (IEC 62443-3-2:2020)
(IEC 62443-3-2:2020)
This European Standard was approved by CENELEC on 2020-07-29. CENELEC members are bound to comply with the CEN/CENELEC
Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2020 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN IEC 62443-3-2:2020 E

European foreword
The text of document 65/799/FDIS, future edition 1 of IEC 62443-3-2, prepared by IEC/TC 65
"Industrial-process measurement, control and automation" was submitted to the IEC-CENELEC
parallel vote and approved by CENELEC as EN IEC 62443-3-2:2020.
The following dates are fixed:
• latest date by which the document has to be implemented at national (dop) 2021-04-29
level by publication of an identical national standard or by endorsement
• latest date by which the national standards conflicting with the (dow) 2023-07-29
document have to be withdrawn
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC shall not be held responsible for identifying any or all such patent rights.

Endorsement notice
The text of the International Standard IEC 62443-3-2:2020 was approved by CENELEC as a
European Standard without any modification.
In the official version, for Bibliography, the following notes have to be added for the standards
indicated:
IEC 62443-2-1 NOTE Harmonized as EN IEC 62443-2-1
IEC 62443-2-4:2015 NOTE Harmonized as EN IEC 62443-2-4:2019 (not modified)
IEC 62443-4-1:2018 NOTE Harmonized as EN IEC 62443-4-1:2018 (not modified)
IEC 62443-4-2:2019 NOTE Harmonized as EN IEC 62443-4-2:2019 (not modified)
IEC 61511-2:2016 NOTE Harmonized as EN 61511-2:2017 (not modified)
IEC 62264-1:2013 NOTE Harmonized as EN 62264-1:2013 (not modified)

To be published. Stage at the time of publication: prEN IEC 62443-2-1:2019.
Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications
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.
NOTE 1  Where an International Publication has been modified by common modifications, indicated by (mod), the relevant
EN/HD applies.
NOTE 2  Up-to-date information on the latest versions of the European Standards listed in this annex is available here:
www.cenelec.eu.
Publication Year Title EN/HD Year
IEC 62443-3-3 2013 Industrial communication networks - Network EN IEC 62443-3-3 2019
and system security - Part 3-3: System
security requirements and security levels

IEC 62443-3-2 ®
Edition 1.0 2020-06
INTERNATIONAL
STANDARD
colour
inside
Security for industrial automation and control systems –

Part 3-2: Security risk assessment for system design

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 25.040.40; 35.030 ISBN 978-2-8322-8501-5

– 2 – IEC 62443-3-2:2020 © IEC 2020
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 7
2 Normative references . 7
3 Terms, definitions, abbreviated terms, acronyms and conventions . 7
3.1 Terms and definitions . 7
3.2 Abbreviated terms and acronyms . 10
3.3 Conventions . 11
4 Zone, conduit and risk assessment requirements . 11
4.1 Overview. 11
4.2 ZCR 1: Identify the SUC . 13
4.2.1 ZCR 1.1: Identify the SUC perimeter and access points . 13
4.3 ZCR 2: Initial cyber security risk assessment . 13
4.3.1 ZCR 2.1: Perform initial cyber security risk assessment . 13
4.4 ZCR 3: Partition the SUC into zones and conduits . 14
4.4.1 Overview . 14
4.4.2 ZCR 3.1: Establish zones and conduits . 14
4.4.3 ZCR 3.2: Separate business and IACS assets . 14
4.4.4 ZCR 3.3: Separate safety related assets . 14
4.4.5 ZCR 3.4: Separate temporarily connected devices . 15
4.4.6 ZCR 3.5: Separate wireless devices . 15
4.4.7 ZCR 3.6: Separate devices connected via external networks . 15
4.5 ZCR 4: Risk comparison . 16
4.5.1 Overview . 16
4.5.2 ZCR 4.1: Compare initial risk to tolerable risk . 16
4.6 ZCR 5: Perform a detailed cyber security risk assessment . 16
4.6.1 Overview . 16
4.6.2 ZCR 5.1: Identify threats . 17
4.6.3 ZCR 5.2: Identify vulnerabilities . 18
4.6.4 ZCR 5.3: Determine consequence and impact . 18
4.6.5 ZCR 5.4: Determine unmitigated likelihood . 19
4.6.6 ZCR 5.5: Determine unmitigated cyber security risk . 19
4.6.7 ZCR 5.6: Determine SL-T . 19
4.6.8 ZCR 5.7: Compare unmitigated risk with tolerable risk . 20
4.6.9 ZCR 5.8: Identify and evaluate existing countermeasures . 20
4.6.10 ZCR 5.9: Reevaluate likelihood and impact . 20
4.6.11 ZCR 5.10: Determine residual risk . 21
4.6.12 ZCR 5.11: Compare residual risk with tolerable risk . 21
4.6.13 ZCR 5.12: Identify additional cyber security countermeasures . 21
4.6.14 ZCR 5.13: Document and communicate results . 22
4.7 ZCR 6: Document cyber security requirements, assumptions and constraints . 22
4.7.1 Overview . 22
4.7.2 ZCR 6.1: Cyber security requirements specification . 22
4.7.3 ZCR 6.2: SUC description . 23
4.7.4 ZCR 6.3: Zone and conduit drawings . 23
4.7.5 ZCR 6.4: Zone and conduit characteristics. 23
4.7.6 ZCR 6.5: Operating environment assumptions . 24

IEC 62443-3-2:2020 © IEC 2020 – 3 –
4.7.7 ZCR 6.6: Threat environment . 25
4.7.8 ZCR 6.7: Organizational security policies . 25
4.7.9 ZCR 6.8: Tolerable risk . 25
4.7.10 ZCR 6.9: Regulatory requirements . 26
4.8 ZCR 7: Asset owner approval . 26
4.8.1 Overview . 26
4.8.2 ZCR 7.1: Attain asset owner approval . 26
Annex A (informative) Security levels . 27
Annex B (informative) Risk matrices . 28
Bibliography . 31

Figure 1 – Workflow diagram outlining the primary steps required to establish zones
and conduits, as well as to assess risk . 12
Figure 2 – Detailed cyber security risk assessment workflow per zone or conduit . 17

Table B.1 – Example of a 3 x 5 risk matrix . 28
Table B.2 – Example of likelihood scale . 28
Table B.3 – Example of consequence or severity scale . 29
Table B.4 – Example of a simple 3 x 3 risk matrix . 29
Table B.5 – Example of a 5 x 5 risk matrix . 30
Table B.6 – Example of a 3 x 4 matrix . 30

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

Part 3-2: Security risk assessment for system design

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) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62443-3‑2 has been prepared by IEC technical committee 65:
Industrial-process measurement, control and automation.
The text of this standard is based on the following documents:
FDIS Report on voting
65/799/FDIS 65/804/RVD
Full information on the voting for the approval of this International Standard can be found in
the report on voting indicated in the above table.
This document has been drafted in accordance with the ISO/IEC Directives, Part 2.
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.

IEC 62443-3-2:2020 © IEC 2020 – 5 –
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related to
the specific document. At this date, the document will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
– 6 – IEC 62443-3-2:2020 © IEC 2020
INTRODUCTION
There is no simple recipe for how to secure an industrial automation and control system (IACS)
and there is good reason for this. It is because security is a matter of risk management. Every
IACS presents a different risk to the organization depending upon the threats it is exposed to,
the likelihood of those threats arising, the inherent vulnerabilities in the system and the
consequences if the system were to be compromised. Furthermore, every organization that
owns and operates an IACS has a different tolerance for risk.
This document strives to define a set of engineering measures that will guide an organization
through the process of assessing the risk of a particular IACS and identifying and applying
security countermeasures to reduce that risk to tolerable levels.
A key concept in this document is the application of IACS security zones and conduits. Zones
and conduits are introduced in IEC TS 62443-1-1.
This document has been developed in cooperation with the ISA99 liaison. ISA99 is the
committee on Industrial Automation and Control Systems Security of the International Society
of Automation (ISA).
The audience for this document is intended to include the asset owner, system integrator,
product supplier, service provider, and compliance authority.
This document provides a basis for specifying security countermeasures by aligning the target
security levels (SL-Ts) identified in this document with the required capability security levels
(SL-Cs) specified in IEC 62443-3-3.

IEC 62443-3-2:2020 © IEC 2020 – 7 –
SECURITY FOR INDUSTRIAL AUTOMATION AND CONTROL SYSTEMS –

Part 3-2: Security risk assessment for system design

1 Scope
This part of IEC 62443 establishes requirements for:
• defining a system under consideration (SUC) for an industrial automation and control
system (IACS);
• partitioning the SUC into zones and conduits;
• assessing risk for each zone and conduit;
• establishing the target security level (SL-T) for each zone and conduit; and
• documenting the security requirements.
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 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, acronyms and conventions
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• ISO Online browsing platform: available at https://www.iso.org/obp
• IEC Electropedia: available at http://www.electropedia.org/
3.1.1
channel
specific logical or physical communication link between assets
Note 1 to entry: A channel facilitates the establishment of a connection.
3.1.2
compliance authority
entity with jurisdiction to determine the adequacy of a security assessment or the
effectiveness of implementation as specified in a governing document
Note 1 to entry: Examples of compliance authorities include government agencies, regulators, external and
internal auditors.
– 8 – IEC 62443-3-2:2020 © IEC 2020
3.1.3
conduit
logical grouping of communication channels that share common security requirements
connecting two or more zones
3.1.4
confidentiality
preservation of authorized restrictions on information access and disclosure, including means
for protecting personal privacy and proprietary information
3.1.5
consequence
result of an incident, usually described in terms of health and safety effects, environmental
impacts, loss of property, loss of information (for example, intellectual property), and/or
business interruption costs, that occurs from a particular incident
3.1.6
countermeasure
action, device, procedure, or technique that reduces a threat, a vulnerability, or the
consequences of an attack by eliminating or preventing it, by minimizing the harm it can
cause, or by discovering and reporting it so that corrective action can be taken
Note 1 to entry: The term “control” is also used to describe this concept in some contexts. The term
countermeasure has been chosen for this document to avoid confusion with the word control in the context of
“process control.”
3.1.7
cyber security
measures taken to protect a computer or computer system against unauthorized access or
attack
Note 1 to entry: IACS are computer systems.
3.1.8
dataflow
movement of data through a system comprised of software, hardware, or a combination of
both
3.1.9
external network
network that is connected to the SUC that is not part of the SUC
3.1.10
impact
measure of the ultimate loss or harm associated with a consequence
EXAMPLE: The consequence of the incident was a spill. The impact of the spill was a $100 000 fine and $25 000
in clean-up expenses.
Note 1 to entry: Impact may be expressed in terms of numbers of injuries and/or fatalities, extent of
environmental damage and/or magnitude of losses such as property damage, material loss, loss of intellectual
property, lost production, market share loss, and recovery costs.
3.1.11
likelihood
chance of something happening
Note 1 to entry: In risk management terminology, the word “likelihood” is used to refer to the chance of something
happening, whether defined, measured or determined objectively or subjectively, qualitatively or quantitatively, and
described using general terms or mathematically (such as a probability or a frequency over a given time period).

IEC 62443-3-2:2020 © IEC 2020 – 9 –
Note 2 to entry: A number of factors are considered when estimating likelihood in information system risk
management such as the motivation and capability of the threat source, the history of similar threats, known
vulnerabilities, the attractiveness of the target, etc.
[SOURCE: ISO Guide 73:2009 [13] , 3.6.1.1 and ISO/IEC 27005:2018 [12], 3.7]
3.1.12
process hazard analysis
set of organized and systematic assessments of the potential hazards associated with an
industrial process
3.1.13
residual risk
risk that remains after existing countermeasures are implemented (such as, the net risk or risk
after countermeasures are applied)
3.1.14
risk
expectation of loss expressed as the likelihood that a particular threat will exploit a particular
vulnerability with a particular consequence
3.1.15
security level
SL
measure of confidence that the SUC, security zone or conduit is free from vulnerabilities and
functions in the intended manner
3.1.16
security perimeter
logical or physical boundary surrounding all the assets that are controlled and protected by
the security zone
3.1.17
system under consideration
SUC
defined collection of IACS assets that are needed to provide a complete automation solution,
including any relevant network infrastructure assets
Note 1 to entry: An SUC consists of one or more zones and related conduits. All assets within a SUC belong to
either a zone or conduit.
3.1.18
threat
circumstance or event with the potential to adversely impact organizational operations
(including mission, functions, image or reputation) and/or organizational assets including
IACS
Note 1 to entry: Circumstances include individuals who, contrary to security policy, intentionally or unintentionally
prevent access to data or cause the destruction, disclosure, or modification of data such as control
logic/parameters, protection logic/parameters or diagnostics.
3.1.19
threat environment
summary of information about threats, such as threat sources, threat vectors and trends, that
have the potential to adversely impact a defined target (for example, company, facility or SUC)
_______________
Numbers in square brackets refer to the bibliography.

– 10 – IEC 62443-3-2:2020 © IEC 2020
3.1.20
threat source
intent and method targeted at the intentional exploitation of a vulnerability or a situation and
method that can accidentally exploit a vulnerability
3.1.21
threat vector
path or means by which a threat source can gain access to an asset
3.1.22
tolerable risk
level of risk deemed acceptable to an organization
Note 1 to entry: Organizations should include consideration of legal requirements when establishing tolerable risk.
Additional guidance on establishing tolerable risk can be found in ISO 31000 [14] and NIST 800-39 [16].
3.1.23
unmitigated cyber security risk
level of cyber security risk that is present in a system before any cyber security
countermeasures are considered
Note 1 to entry: This level helps identify how much cyber security risk reduction is required to be provided by any
countermeasure.
3.1.24
vulnerability
flaw or weakness in a system's design, implementation or operation and management that
could be exploited to violate the system's integrity or security policy
3.1.25
zone
grouping of logical or physical assets based upon risk or other criteria, such as criticality of
assets, operational function, physical or logical location, required access (for example, least
privilege principles) or responsible organization
Note 1 to entry: Collection of logical or physical assets that represents partitioning of a system under
consideration on the basis of their common security requirements, criticality (for example, high financial, health,
safety, or environmental impact), functionality, logical and physical (including location) relationship.
3.2 Abbreviated terms and acronyms
The list below defines the abbreviated terms and acronyms used in this document.
ANSI American National Standards Institute
BPCS Basic process control system
CERT Computer emergency response team
CRS Cyber security requirements specification
DCS Distributed control system
HMI Human machine interface
HSE Health, safety and environment
HVAC Heating, ventilation and air-conditioning
IACS Industrial automation and control system(s)
ICS-CERT Industrial control system CERT
IEC International Electrotechnical Commission
IIoT Industrial Internet of Things
IPL Independent protection layer

IEC 62443-3-2:2020 © IEC 2020 – 11 –
ISA International Society of Automation
ISAC Information Sharing and Analysis Centers
ISO International Organization for Standardization
MES Manufacturing execution system
NIST [US] National Institute of Standards and Technology
PHA Process hazard analysis
PLC Programmable logic controller
RTU Remote terminal unit
SCADA Supervisory control and data acquisition
SIS Safety instrumented system
SUC System under consideration
SL Security level
SL-A Achieved SL
SL-C Capability SL
SL-T Target SL
SP [US NIST] Special Publication
USB Universal serial bus
ZCR Zone and conduit requirement

3.3 Conventions
This document uses flowcharts to illustrate the workflow between requirements. These
flowcharts are informative. Alternate workflows may be used.
4 Zone, conduit and risk assessment requirements
4.1 Overview
Clause 4 describes the requirements for partitioning an SUC into zones and conduits as well
as the requirements for assessing the cyber security risk and determining the SL-T for each
defined zone and conduit. The requirements introduced in Clause 4 are referred to as zone
and conduit requirements (ZCR). Clause 4 also provides rationale and supplemental guidance
on each of the requirements. Figure 1 is a workflow diagram outlining the primary steps
required to establish zones and conduits, as well as to assess risk. The steps are numbered
to indicate their relationship to the ZCRs.

– 12 – IEC 62443-3-2:2020 © IEC 2020

Figure 1 – Workflow diagram outlining the primary steps required
to establish zones and conduits, as well as to assess risk

IEC 62443-3-2:2020 © IEC 2020 – 13 –
4.2 ZCR 1: Identify the SUC
4.2.1 ZCR 1.1: Identify the SUC perimeter and access points
4.2.1.1 Requirement
The organization shall clearly identify the SUC, including clear demarcation of the security
perimeter and identification of all access points to the SUC.
4.2.1.2 Rationale and supplemental guidance
Organizations typically own and operate multiple control systems, especially larger
organizations with multiple industrial facilities. Any of these control systems may be defined
as a SUC. For example, there is generally at least one control system at an industrial facility,
but oftentimes there are several systems that control various functions within the facility.
This requirement specifies that SUCs are identified for the purpose of performing cyber
security analysis. The definition of a SUC is intended to include all IACS assets that are
needed to provide a complete automation solution.
System inventory, architecture diagrams, network diagrams and dataflows can be used to
determine and illustrate the IACS assets that are included in the SUC description.
NOTE The SUC can include multiple subsystems such as basic process control systems (BPCSs), distributed
control systems (DCSs), safety instrumented systems (SISs), supervisory control and data acquisition (SCADA)
and IACS product supplier’s packages. This could also include emerging technologies such as the industrial
Internet of Things (IIoT) or cloud-based solutions.
4.3 ZCR 2: Initial cyber security risk assessment
4.3.1 ZCR 2.1: Perform initial cyber security risk assessment
4.3.1.1 Requirement
The organization shall perform a cyber security risk assessment of the SUC or confirm a
previous initial cyber security risk assessment is still applicable in order to identify the worst
case unmitigated cyber security risk that could result from the interference with, breach or
disruption of, or disablement of mission critical IACS operations.
4.3.1.2 Rationale and supplemental guidance
The purpose of the initial cyber security risk assessment is to gain an initial understanding of
the worst-case risk the SUC presents to the organization should it be compromised. This is
typically evaluated in terms of impacts to health, safety, environmental, business interruption,
production loss, product quality, financial, legal, regulatory, reputation, etc. This assessment
assists with the prioritization of detailed risk assessments and facilitates the grouping of
assets into zones and conduits within the SUC.
For potentially hazardous processes, the results of the process hazard analysis (PHA) and
functional safety assessments as defined in IEC 61511-2 [8] should be referenced as part of
the initial cyber security risk assessment to identify worst-case impacts. Organizations should
also take into consideration threat intelligence from governments, sector specific Information
Sharing and Analysis Centers (ISACs) and other relevant sources.
Assessment of initial risk is often accomplished using a risk matrix that establishes the
relationship between likelihood, impact and risk (such as, a corporate risk matrix). Examples
of risk matrices can be found in Annex B.

– 14 – IEC 62443-3-2:2020 © IEC 2020
4.4 ZCR 3: Partition the SUC into zones and conduits
4.4.1 Overview
Subclauses 4.4.2 through 4.8.1 describe the ZCRs for partitioning the SUC into zones and
conduits and provide rationale and supplemental guidance for each requirement. Subclause
4.4.2, sets out the base requirement for establishing zones and conduits within the SUC.
Subclauses 4.4.3 through 4.4.7 are intended to provide guidance on assignment of assets to
zones based upon industry best practices. This is not intended to be an exhaustive list.
4.4.2 ZCR 3.1: Establish zones and conduits
4.4.2.1 Requirement
The organization shall group IACS and related assets into zones or conduits as determined by
risk. Grouping shall be based upon the results of the initial cyber security risk assessment or
other criteria, such as criticality of assets, operational function, physical or logical location,
required access (for example, least privilege principles) or responsible organization.
4.4.2.2 Rationale and supplemental guidance
The intention of grouping assets into zones and conduits is to identify those assets which
share common security requirements and to permit the identification of common security
measures required to mitigate risk. The assignment of IACS assets to zones and conduits
may be adjusted based upon the results of the detailed risk assessment. This is a general
requirement, but special attention should be given to the safety related systems including
safety instrumented systems, wireless systems, systems directly connected to Internet
endpoints, systems that interface to the IACS but are managed by other entities (including
external systems) and mobile devices.
For example, a facility might first be divided into operational areas, such as materials storage,
processing, finishing, etc. Operational areas can often be further divided into functional layers,
such as manufacturing execution systems (MESs), supervisory systems (for example, human
machine interfaces [HMIs]), primary control systems (for example, BPCS, DCS, remote
terminal units [RTUs] and programmable logic controllers [PLCs]) and safety systems. Models
such as the Purdue reference model as defined in IEC 62264-1 [9] are often used as a basis
for this division. IACS product supplier reference architectures can also be helpful.
4.4.3 ZCR 3.2: Separate business and IACS assets
4.4.3.1 Requirement
IACS assets shall be grouped into zones that are logically or physically separated from
business or enterprise system assets.
4.4.3.2 Rationale and supplemental guidance
Business and IACS are two different types of systems that need to be divided into separate
zones as their functionality, responsible organization, results of initial risk assessment and
location are often fundamentally different. It is important to understand the basic difference
between business and IACS, and the ability of IACS to impact health, safety and environment
(HSE).
4.4.4 ZCR 3.3: Separate safety related assets
4.4.4.1 Requirement
Safety related IACS assets shall be grouped into zones that are logically or physically
separated from zones with non-safety related IACS assets. However, if they cannot be
separated, the entire zone shall be identified as a safety related zone.

IEC 62443-3-2:2020 © IEC 2020 – 15 –
4.4.4.2 Rationale and supplemental guidance
Safety related IACS assets usually have different security requirements than basic control
system components or systems, and components interfaced to the control system
components. Safety related zones typically require a higher-level of security protection due to
the higher potential for health, safety and environmental consequences if the zone is
compromised.
4.4.5 ZCR 3.4: Separate temporarily connected devices
4.4.5.1 Recommendation
Devices that are permitted to make temporary connections to the SUC should be grouped into
a separate zone or zones from assets that are intended to be permanently connected to the
IACS.
4.4.5.2 Rationale and supplemental guidance
Devices that are temporarily connected to the SUC (for example, maintenance portable
computers, portable processing equipment, portable security appliances and universal serial
bus [USB] devices) are more likely exposed to a different and wider variety of threats than
devices that are permanently part of the zone. Therefore, these devices should be modelled in
a separate zone or zones. The primary concern with these devices is that, because of the
temporary nature of the connection, they may also be able to connect to other networks
outside the zone. However, there are exceptions. For example, a hand-held device that is only
used within a single zone and never leaves the physical boundary of the zone may be
included in the zone.
4.4.6 ZCR 3.5: Separate wireless devices
4.4.6.1 Recommendation
Wireless devices should be in one or more zones that are separated from wired devices.
4.4.6.2 Rationale and supplemental guidance
Wireless signals are not controlled by fences or cabinets and are therefore more accessible
than normal wired networks. Because of this increased access potential, they are more likely
exposed to a different and wider variety of threats than devices that are wired.
Typically, a wireless access point is modelled as the conduit between a wireless zone and a
wired zone. Depending upon the capabilities of the wireless access point additional security
controls (for example, firewall) may be required to provide appropriate level of separation.
4.4.7 ZCR 3.6: Separate devices connected via external networks
4.4.7.1 Recommendation
Devices that are permitted to make connections to the SUC via networks external to the SUC
should be grouped into a separate zone or zones.
4.4.7.2 Rationale and supplemental guidance
It is not uncommon for organizations to grant remote access to personnel such as employees,
suppliers and other business partners for maintenance, optimization and reporting purposes.
Because remote access is outside the physical boundary of the SUC, it should be modelled as
a separate zone or zones with its own security requirements.

– 16 – IEC 62443-3-2:2020 © IEC 2020
4.5 ZCR 4: Risk comparison
4.5.1 Overview
Subclause 4.5.2 includes one ZCR to compare initial risk to tolerable risk.
4.5.2 ZCR 4.1: Compare initial risk to tolerable risk
4.5.2.1 Requirement
The initial risk determined in 4.3 shall be compared to the organization’s tolerable risk. If the
initial risk exceeds the tolerable risk, the organization shall perform a detailed cyber security
risk assessment as defined in 4.6.
4.5.2.2 Rationale and supplemental guidance
The purpose of this step is to determine if the initial risk is tolerable or requires further
mitigation.
4.6 ZCR 5: Perform a detailed cyber security risk assessment
4.6.1 Overview
This ZCR discusses the detailed risk assessment requirements for an IACS and provides
rationale and supplemental guidance on each requirement. The requirements in this ZCR
apply to every zone and conduit. If zones or conduits share similar threat(s), consequences
and/or similar assets, it is allowable to analyse groups of zones or conduits together if such
grouping enables optimized analysis. It is permissible to use existing results if the zone is
standardized (for example, replication of multiple instances of a reference design). The
flowchart shown in Figure 2 illustrates the cyber security risk assessment workflow.
Any detailed risk assessment methodology (such as, ISO 31000 [14], NIST SP 800-39 [16],
and ISO/IEC 27005 [12]) may be followed provided the risk assessment requirements are
satisfied by the methodology selected. The initial and detailed risk assessment methodologies
should be derived from the same framework, standard or source and have to use a consistent
risk ranking scale in order to produce consistent and coherent results.

IEC 62443-3-2:2020 © IEC 2020 – 17 –

Figure 2 – Detailed cyber security risk assessment workflow per zone or conduit
4.6.2 ZCR 5.1: Identify threats
4.6.2.1 Requirement
A list of the threats that could affect the assets contained within the zone or conduit shall be
developed.
4.6.2.2 Rationale and supplemental guidance
It is important to prepare a comprehensive and realistic list of threats in order to perform a
security risk assessment. A threat description should include but is not limited to the following:
a) a description of the threat source;
b) a description of the capability or skill-level of the threat source;
c) a description of possible threat vectors;

– 18 – IEC 62443-3-2:2020 © IEC 2020
d) an identification of the potentially affected asset(s).
Some examples of threat descriptions are:
• A non-malicious employee physically accesses the process control zone and plugs a USB
memory stick into one of the computers;
• An authorized support person logically accesses the process control zone using an
infected laptop; and
• A non-malicious employee opens a phishing email compromising their access credentials.
Given the potential for a large
...