IEC 62443-2-4:2015

IEC 62443-2-4 ®
Edition 1.1 2017-08
CONSOLIDATED VERSION
INTERNATIONAL
STANDARD
colour
inside
Security for industrial automation and control systems –
Part 2-4: Security program requirements for IACS service providers

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 Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00

CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
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 corrigenda or an amendment might have been published.

IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing 20 000 terms and definitions in
Technical Specifications, Technical Reports and other English and French, with equivalent terms in 16 additional
documents. Available for PC, Mac OS, Android Tablets and languages. Also known as the International Electrotechnical
iPad. Vocabulary (IEV) online.

IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a 65 000 electrotechnical terminology entries in English and
variety of criteria (reference number, text, technical French extracted from the Terms and Definitions clause of
committee,…). It also gives information on projects, replaced IEC publications issued since 2002. Some entries have been
and withdrawn publications. collected from earlier publications of IEC TC 37, 77, 86 and

CISPR.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: csc@iec.ch.
IEC 62443-2-4 ®
Edition 1.1 2017-08
CONSOLIDATED VERSION
INTERNATIONAL
STANDARD
colour
inside
Security for industrial automation and control systems –

Part 2-4: Security program requirements for IACS service providers

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 25.040.40; 35.110 ISBN 978-2-8322-4679-5

IEC 62443-2-4 ®
Edition 1.1 2017-08
CONSOLIDATED VERSION
REDLINE VERSION
colour
inside
Security for industrial automation and control systems –
Part 2-4: Security program requirements for IACS service providers

– 2 – IEC 62443-2-4:2015+AMD1:2017 CSV

© IEC 2017
CONTENTS
FOREWORD . 3

INTRODUCTION . 5

1 Scope . 6

2 Normative references . 7

3 Terms, definitions, abbreviated terms and acronyms . 7

3.1 Terms and definitions. 7

3.2 Abbreviations . 10
4 Concepts . 11
4.1 Use of IEC 62443-2-4 . 11
4.1.1 Use of IEC 62443-2-4 by IACS service providers . 11
4.1.2 Use of IEC 62443-2-4 by IACS asset owners . 12
4.1.3 Use of IEC 62443-2-4 during negotiations between IACS asset owners
and IACS service providers . 12
4.1.4 Profiles . 13
4.1.5 IACS integration service providers . 13
4.1.6 IACS maintenance service providers . 14
4.2 Maturity model . 14
5 Requirements overview . 16
5.1 Contents . 16
5.2 Sorting and filtering . 16
5.3 IEC 62264-1 hierarchy model . 16
5.4 Requirements table columns . 16
5.5 Column definitions . 17
5.5.1 Req ID column . 17
5.5.2 BR/RE column . 17
5.5.3 Functional area column . 18
5.5.4 Topic column . 19
5.5.5 Subtopic column . 20
5.5.6 Documentation column . 22
5.5.7 Requirement description column . 22
5.5.8 Rationale column . 22
Annex A (normative) Security requirements . 23

Bibliography . 90

Figure 1 – Parts of the IEC 62443 Series . 5
Figure 2 – Scope of service provider capabilities . 6

Table 1 – Maturity levels . 15
Table 2 – Columns . 17
Table 3 – Functional area column values . 19
Table 4 – Topic column values . 20
Table 5 – Subtopic column values . 21
Table A.1 – Security program requirements . 23

© IEC 2017
INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________
SECURITY FOR INDUSTRIAL AUTOMATION

AND CONTROL SYSTEMS –
Part 2-4: Security program requirements

for IACS service providers
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.
This consolidated version of the official IEC Standard and its amendment has been prepared
for user convenience.
IEC 62443-2-4 edition 1.1 contains the first edition (2015-06) [documents 65/545/CDV and
65/561A/RVC] and its corrigendum 1 (2015-08), and its amendment 1 (2017-08) [documents
65/637A/CDV and 65/661/RVC].
In this Redline version, a vertical line in the margin shows where the technical content is
modified by amendment 1. Additions are in green text, deletions are in strikethrough red text. A
separate Final version with all changes accepted is available in this publication.

– 4 – IEC 62443-2-4:2015+AMD1:2017 CSV

© IEC 2017
International Standard IEC 62443-2-4 has been prepared by IEC technical committee 65:

Industrial-process measurement, control and automation.

This publication contains an attached file in the form of an Excel 97-2003 spreadsheet version

of Table A.1. This file is intended to be used as a complement and does not form an integral

part of the publication.
This publication 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.

Future standards in this series will carry the new general title as cited above. Titles of existing
standards in this series will be updated at the time of the next edition.
The committee has decided that the contents of the base publication and its amendment will
remain unchanged until the stability date indicated on the IEC web site under
"http://webstore.iec.ch" in the data related to the specific publication. At this date, the
publication 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.
© IEC 2017
INTRODUCTION
This standard is the part of the IEC 62443 series that contains security requirements for

providers of integration and maintenance services for Industrial Automation and Control

Systems (IACS). It has been developed by IEC Technical Committee 65 in collaboration with

the International Instrumentation Users Association, referred to as the WIB from its original

and now obsolete Dutch name, and ISA 99 committee members.

Figure 1 illustrates the relationship of the different parts of IEC 62443 being developed. Those

that are normatively referenced are included in the list of normative references in Clause 2,

and those that are referenced for informational purposes or that are in development are listed

in the Bibliography.
IEC 62443-1.1 IEC TR-62443-1.2 IEC 62443-1.3 IEC TR-62443-1.4
Terminology, Master glossary of
System security IACS security
concepts and models terms and abbreviations
compliance metrics lifecycle and use-case
IEC 62443-2.1 IEC TR-62443-2.2 IEC TR-62443-2.3 IEC 62443-2.4
Requirements for an Security program
Implementation guidance
Patch management in
IACS security requirements for
for an IACS security
the IACS environment
management system IACS service providers
management system
IEC TR-62443-3.1 IEC 62443-3.2 IEC 62443-3.3
System security
Security technologies Security levels for
requirements and
for IACS zones and conduits
security levels
IEC 62443-4.1 IEC 62443-4.2
Technical security
Product development
requirements for IACS
requirements
components
IEC
Figure 1 – Parts of the IEC 62443 Series
Policies and
Component System
General
procedures
– 6 – IEC 62443-2-4:2015+AMD1:2017 CSV

© IEC 2017
SECURITY FOR INDUSTRIAL AUTOMATION

AND CONTROL SYSTEMS –
Part 2-4: Security program requirements

for IACS service providers
1 Scope
This part of IEC 62443-2-4 specifies a comprehensive set of requirements for security
capabilities for IACS service providers that they can offer to the asset owner during
integration and maintenance activities of an Automation Solution. Because not all
requirements apply to all industry groups and organizations, Subclause 4.1.4 provides for the
development of Profiles that allow for the subsetting of these requirements. Profiles are used
to adapt this document to specific environments, including environments not based on an
IACS.
NOTE 1 The term “Automation Solution” is used as a proper noun (and therefore capitalized) in this part of
IEC 62443 to prevent confusion with other uses of this term.
Collectively, the security capabilities offered by an IACS service provider are referred to as its
Security Program. In a related specification, IEC 62443-2-1 describes requirements for the
Security Management System of the asset owner.
NOTE 2 In general, these security capabilities are policy, procedure, practice and personnel related.
Figure 2 illustrates how the integration and maintenance capabilities relate to the IACS and
the control system product that is integrated into the Automation Solution. Some of these
capabilities reference security measures defined in IEC 62443-3-3 that the service provider
must ensure are supported in the Automation Solution (either included in the control system
product or separately added to the Automation Solution).
Industrial Automation and Control System (IACS)
Operational and maintenance
Asset
operates
capabilities (policies and
Owner
procedures)
+
Automation Solution
System
integration capabilities
Safety
Basic Process
Integrator Complementary
Instrumented
(design and deployment) Control System
hardware and
System (SIS)
(BPCS)
software
IACS environment / project specific
Includes a configured instance of the Control System Product
Control System Product as a combination of
Product
develops
Supplier Supporting Embedded Network Host
Applications devices components devices
Independent of IACS environment
IEC
Figure 2 – Scope of service provider capabilities

© IEC 2017
In Figure 2, the Automation Solution is illustrated to contain a Basic Process Control System

(BPCS), optional Safety Instrumented System (SIS), and optional supporting applications,

such as advanced control. The dashed boxes indicate that these components are “optional”.

NOTE 3 The term “process” in BPCS may apply to a variety of industrial processes, including continuous

processes and manufacturing processes.

NOTE 4 Clause 4.1.4 describes profiles and how they can be used by industry groups and other organizations to

adapt this International Standard to their specific environments, including environments not based on an IACS.

NOTE 5 4 Automation Solutions typically have a single control system (product), but they are not restricted to do

so. In general, the Automation Solution is the set of hardware and software, independent of product packaging, that

is used to control a physical process (e.g. continuous or manufacturing) as defined by the asset owner.

2 Normative references
The following referenced documents are indispensable for the application 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.
“None”
3 Terms, definitions, abbreviated terms and acronyms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1.1
asset owner
individual or organization responsible for one or more IACSs
Note 1 to entry: Used in place of the generic word end user to provide differentiation.
Note 2 to entry: This definition includes the components that are part of the IACS.
Note 3 to entry: In the context of this standard, asset owner also includes the operator of the IACS.
3.1.2
attack surface
physical and functional interfaces of a system that can be accessed and through which the
system can be potentially exploited
Note 1 to entry: The size of the attack surface for a software interface is proportional to the number of methods

and parameters defined for the interface. Simple interfaces, therefore, have smaller attack surfaces than complex
interfaces.
Note 2 to entry: The size of the attack surface and the number of vulnerabilities are not necessarily related to
each other.
3.1.3
Automation Solution
control system and any complementary hardware and software components that have been
installed and configured to operate in an IACS
Note 1 to entry: Automation Solution is used as a proper noun in this part of IEC 62443.
Note 2 to entry: The difference between the control system and the Automation Solution is that the control system
is incorporated into the Automation Solution design (e.g. a specific number of workstations, controllers, and
devices in a specific configuration), which is then implemented. The resulting configuration is referred to as the
Automation Solution.
Note 3 to entry: The Automation Solution may be comprised of components from multiple suppliers, including the
product supplier of the control system.

– 8 – IEC 62443-2-4:2015+AMD1:2017 CSV

© IEC 2017
3.1.4
basic process control system
system that responds to input signals from the process, its associated equipment, other

programmable systems and/or an operator and generates output signals causing the process

and its associated equipment to operate in the desired manner but does not perform any

safety integrated functions (SIF)

Note 1 to entry: Safety instrumented functions are specified in the IEC 61508 series.

Note 2 to entry: The term “process” in this definition may apply to a variety of industrial processes, including

continuous processes and manufacturing processes.

3.1.5
consultant
subcontractor that provides expert advice or guidance to the integration or maintenance
service provider
3.1.6
control system
hardware and software components used in the design and implementation of an IACS
Note 1 to entry: As shown in Figure 2, control systems are composed of field devices, embedded control devices,
network devices, and host devices (including workstations and servers.
Note 2 to entry: As shown in Figure 2, control systems are represented in the Automation Solution by a BPCS and
an optional SIS.
3.1.7
handover
act of turning an Automation Solution over to the asset owner
Note 1 to entry: Handover effectively transfers responsibility for operations and maintenance of an
Automation Solution from the integration service provider to the asset owner and generally occurs after successful
completion of system test, often referred to as Site Acceptance Test (SAT).
3.1.8
industrial automation and control system
collection of personnel, hardware, software, procedures and policies involved in the operation
of the industrial process and that can affect or influence its safe, secure and reliable operation
Note 1 to entry: The IACS may include components that are not installed at the asset owner’s site.
Note 2 to entry: The definition of IACS was taken from in IEC-62443-3-3 and is illustrated in Figure 2. Examples
of IACSs include Distributed Control Systems (DCS) and Supervisory Control and Data Acquisition (SCADA)
systems. IEC 62443-2-4 also defines the proper noun “Solution” to mean the specific instance of the control system
product and possibly additional components that are designed into the IACS. The Automation Solution, therefore,
differs from the control system since it represents a specific implementation (design and configuration) of the
control system hardware and software components for a specific asset owner.
3.1.9
integration service provider
service provider that provides integration activities for an Automation Solution including
design, installation, configuration, testing, commissioning, and handover
Note 1 to entry: Integration service providers are often referred to as integrators or Main Automation Contractors
(MAC).
3.1.10
maintenance service provider
service provider that provides support activities for an Automation Solution after handover
Note 1 to entry: Maintenance is often considered to be distinguished from operation (e.g. in common colloquial
language it is often assumed that an Automation Solution is either in operation or under maintenance).
Maintenance service providers can perform support activities during operations, e.g. managing user accounts,
security monitoring, and security assessments.

© IEC 2017
3.1.11
portable media
portable devices that contain data storage capabilities that can be used to physically copy

data from one piece of equipment and transfer it to another

Note 1 to entry: Types of portable media include but are not limited to: CD / DVD / BluRay Media, USB memory
devices, smart phones, flash memory, solid state disks, hard drives, handhelds, and portable computers.

3.1.12
product supplier
manufacturer of hardware and/or software product

Note 1 to entry: Used in place of the generic word vendor to provide differentiation.
3.1.13
remote access
access to a control system through an external interface of the control system
Note 1 to entry: Examples of applications that support remote access include RDP, OPC, and Syslog.
Note 2 to entry: In general, remote access applications and the Automation Solution will reside in different
security zones as determined by the asset owner. See IEC 62443-3-2 for the application of zones and conduits to
the Automation Solution by the asset owner.
3.1.14
safety instrumented system
system used to implement functional safety
Note 1 to entry: See IEC 61508 and IEC 61511 for more information on functional safety.
Note 2 to entry: Not all industry sectors use this term. This term is not restricted to any specific industry sector,
and it is used generically to refer to systems that enforce functional safety. Other equivalent terms include safety
systems and safety related systems.
3.1.15
security compromise
violation of the security of a system such that an unauthorized (1) disclosure or modification
of information or (2) denial of service may have occurred
Note 1 to entry: A security compromise represents a breach of the security of a system or an infraction of its
security policies. It is independent of impact or potential impact to the system.
3.1.16
security incident
security compromise that is of some significance to the asset owner or failed attempt to
compromise the system whose result could have been of some significance to the asset

owner
Note 1 to entry: The term “of some significance’ is relative to the environment in which the security compromise is
detected. For example, the same compromise may be declared as a security incident in one environment and not in
another. Triage activities are often used by asset owners to evaluate security compromises and identify those that
are significant enough to be considered incidents.
Note 2 to entry: In some environments, failed attempts to compromise the system, such as failed login attempts,
are considered significant enough to be classified as security incidents.
3.1.17
security patch
software patch that is relevant to the security of a software component
Note 1 to entry: For the purpose of this definition, firmware is considered software.
Note 2 to entry: Software patches may address known or potential vulnerabilities, or simply improve the security
of the software component, including its reliable operation.

– 10 – IEC 62443-2-4:2015+AMD1:2017 CSV

© IEC 2017
3.1.18
security program
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 security program for IACS service providers refers to the policies and procedures defined by
them to address security concerns of the IACS.

3.1.19
service provider
individual or organization (internal or external organization, manufacturer, etc.) that provides

a specific support service and associated supplies in accordance with an agreement with the

asset owner
Note 1 to entry: This term is used in place of the generic word “vendor” to provide differentiation.
3.1.20
subcontractor
service provider under contract to the integration or maintenance service provider or to
another subcontractor that is directly or indirectly under contract to the integration or
maintenance service provider
3.1.21
system
interacting, interrelated, or interdependent elements forming a complex whole
Note 1 to entry: A system may be packaged as a product.
Note 2 to entry: In practice, the interpretation of its meaning is frequently clarified by the use of an adjective,
such as control system. In the context of a control system, the elements are largely hardware and software
elements.
3.1.22
verify
check that the specified requirement was met
3.1.23
vulnerability
flaw or weakness in the design, implementation, or operation and management of a
component that can be exploited to cause a security compromise
Note 1 to entry: Security policies typically include policies to protect confidentiality, integrity, and availability of
system assets.
3.2 Abbreviations
AES_GCM Advanced Encryption Standard Galois/Counter Mode
BPCS Basic Process Control System
BR Base Requirement
CEF Common Event Format
DCOM Distributed Common Object Model
DCS Distributed Control System
EWS Engineering Workstation
IACS Industrial Automation and Control System
RE Requirement Enhancement
RDP Remote Desktop Protocol
RFC Request For Comment
RFQ Request For Quote
© IEC 2017
SCADA Supervisory Control And Data Acquisition

SIEM Security Information and Event Management

SIF Safety Instrumented Function

SIL Safety Integrity Level
SIS Safety Instrumented System

SNMP Simple Network Management Protocol

SOW Statement Of Work
SSID Service Set Identifier
SP Security Program
TR Technical Report
VPN Virtual Private Network
4 Concepts
4.1 Use of IEC 62443-2-4
4.1.1 Use of IEC 62443-2-4 by IACS service providers
This part of the IEC 62443 series defines requirements for security capabilities to be
supported by security programs of integration and maintenance service providers (see 4.1.3
and 4.1.6). Support for these capabilities means that the service provider can provide them to
the asset owner upon request. The terms and conditions for providing these capabilities are
beyond the scope of this standard. In addition, IEC 62443-2-4 can be used by these IACS
service providers to structure and improve their security programs.
In addition, IACS service providers can use IEC 62443-3-3 and IEC 62443-4-2 in conjunction
with IEC 62443-2-4 to work with suppliers of underlying control systems/components. This
collaboration can assist the service provider in developing policies and procedures around a
capability of a system/component, e.g. backup and restore based on the recommendations
from the suppliers of the systems/components used.
The security programs implementing these requirements are expected to be independent of
different releases of the control system that is embedded in the Automation Solution. That is a
new release of the control system product does not necessarily require a change to the
service provider’s security program. However, changes to the security program will be
required when changes to the underlying control system make the existing security program
deficient with respect to these IEC 62443-2-4 requirements.
EXAMPLE 1 A service provider may have experience with a specific control system line of products. Developing
policies and procedures for that line of products will be based on the recommendations of the product supplier and
the capabilities of the product line. Therefore, when the product capabilities for backup and restore are changed,
the corresponding capabilities of the service provider's security program (corresponding to SP.12.XX) may have to
be changed to remain consistent with the updated product capabilities. On the other hand, the service provider's
policies and procedures around non-disclosure agreements or personnel background checks (corresponding to
SP.01.03 and SP.01.04) and are very likely independent of the control system product used in the
Automation Solution.
This collaboration can also be used to improve security in these systems/components. First,
the service provider can recommend new or updated security features to the
system/component supplier. Second, the service provider can gain knowledge about the
system/component that allows it to add its own compensating security measures to the
Automation Solution during deployment or maintenance.
The requirements are specified in Annex A, and are defined in terms of the capabilities that
these security programs are required to provide. Clause 4.1.4 discusses the ability of industry
groups to subset these capabilities into profiles to address risk reduction. See IEC 62443-3-2
for more detail on security risks.

– 12 – IEC 62443-2-4:2015+AMD1:2017 CSV

© IEC 2017
IEC 62443-2-4 also recognizes that security programs evolve and that capabilities go through

a lifecycle of their own, often starting as completely manual and evolving over time to become

more formal, more consistent, and more effective. Clause 4.2 addresses this issue of evolving

capabilities by defining a maturity model to be used with the application of this standard.

EXAMPLE 2 A specific capability might be introduced as a set of manual procedures and then later supplemented
with automated tools.
As a result, the requirements in Annex A are stated abstractly, allowing for a wide range of

implementations. It is expected that service providers and asset owners will negotiate and

agree on which of these required capabilities are to be provided and how they are to be

provided. These aspects of fulfilling the requirements are beyond the scope of IEC 62443-2-4,

although the use of profiles should make this easier.
EXAMPLE 3 A service provider capable of supporting complex passwords has to be capable of supporting
specific variations of complex passwords as defined by the password policies of asset owners.
EXAMPLE 4 Many capabilities have a timeliness aspect related to their performance. What is considered timely
should be agreed to by both the asset owner and the service provider.
4.1.2 Use of IEC 62443-2-4 by IACS asset owners
IEC 62443-2-4 can be used by asset owners to request specific security capabilities from the
service provider. More specifically, prior to such a request, IEC 62443-2-4 can be used by
asset owners to determine whether or not a specific service provider’s security program
includes the capabilities that the asset owner needs.
In general, IEC 62443-2-4 recognizes that asset owner requirements vary, so it has been
written to encourage service providers to implement the required capabilities so that they can
be adaptable to a wide variety of asset owners. The maturity model also allows asset owners
to better understand the maturity of a specific service provider’s capabilities.
4.1.3 Use of IEC 62443-2-4 during negotiations between IACS asset owners and IACS
service providers
Prior to the IACS service provider starting work on the Automation Solution, the asset owner
will normally issue a Request for Quote (RFQ)) that includes a document (e.g. a Statement of
Work (SOW)) that defines its security policies and requirements, including which of the
requirements specified in Annex A apply. See IEC 62443-3-2 for more information on defining
security requirements. Service providers respond to the RFQ and negotiations follow in which
the service provider and the asset owner come to agreement on the details of the SOW (or
similar document). Typically the specific responsibilities and capabilities of the service
provider for supporting asset owner security policies and requirements will be included in or
referenced by this agreement/contract between the IACS service provider and the asset
owner.
NOTE 1 When the service provider is part of the asset owner’s organization, there may not be such a contract.
Additionally, the asset owner does not normally specify how its security requirements (e.g.
backup and restore) will be implemented – that is what the service provider has already
specified in its policies and procedures. However, the asset owner may define constraints and
parameters (e.g. password timeout values) for how the service provider’s policies and
procedures will be applied in its specific project.
In cases where the asset owner does not specify security requirements, the service provider
may propose them to the asset owner based on its own security analysis, and then negotiate
which are included in the SOW.
It is also expected that the IACS service provider will have some ability to customize its
capabilities to meet the needs of the asset owner. However, specification of this
customization is beyond the scope of IEC 62443-2-4.

© IEC 2017
4.1.4 Profiles
Profiles are capability sets defined by selecting a specific subset of the requirements in Annex

A. Profiles are intended to be written for different industry groups/sectors and other

organizations to define one or more capability sets most appropriate to their needs.

This document recognizes that not all of the requirements in Annex A apply to all industry

sectors/environments. To allow subsetting and adaptation of these requirements, this

document provides for the use of “Profiles”.

Profiles are written as IEC Technical Reports (TRs) by industry groups/sectors or other

organizations, including asset owners and service providers, to select/adapt Annex A
requirements that are most appropriate to their specific needs.
IEC Technical Reports (TRs) can be created by industry groups/sectors or other organizations
to define profiles. Each TR may define one or more profiles, and each profile identifies a
subset of the requirements defined in Annex A and specifies, where necessary, how specific
requirements are to be applied in the environment where they are to be used.
It is anticipated that asset owners will select existing these profiles to specify the
requirements that they need for apply to their Automation Solutions.
4.1.5 IACS integration service providers
An IACS integration service provider is an organization, typically separate from and under
contract to the asset owner that provides capabilities to implement/deploy
Automation Solutions according to asset owner requirements. Integration service provider
activates generally occur in the time frame starting with the design phase and ending in
handover of the Automation Solution to the asset owner.
NOTE 1 The integration service provider can be an organization within the asset owner’s organization.
IACS integration service provider activities typically include:
a) analyzing the physical, electrical, or mechanical environment the Automation Solution is to
control (e.g. the physical process to be controlled, such as those used in manufacturing,
refining and pharmaceutical processes),
b) developing an Automation Solution architecture in terms of devices and control loops and
their interconnectivity with engineering and operator workstations, and possibly the
inclusion of a Safety Instrumented System (SIS),
c) defining how the Automation Solution will connect to external (e.g. plant) networks,
d) installing, configuring, patching, backing up, and testing that lead to the handover of the

Automation Solution to the asset owner for operation.
e) gaining approval of the asset owner for many of the decisions made and outputs
generated during the execution of these activities.
This description of integration service provider activates is abstract and may exclude some of
these activities or include other activities that generally precede the handover of the
Automation Solution. Also, these activities include participation with the asset owner to
ensure the asset owner requirements are met.
From the perspective of IEC 62443, integration service providers are also expected to
participate in the assessment of security risks for the Automation Solution or to use the
results of such an assessment provided by the asset owner. The service provider is also
expected to use capabilities required by 62443-2-4 in its security program to address these
risks.
NOTE 2 See IEC 62443-3-2 for guidance on the use of risk assessments and the definition of security
requirements.
– 14 – IEC 62443-2-4:2015+AMD1:2017 CSV

© IEC 2017
4.1.6 IACS maintenance service providers

An IACS maintenance service provider is any organization, typically separate from and under

contract to the asset owner, that performs activities to maintain and service

Automation Solutions according to asset owner requirements.

Maintenance activities are separate from activities used to operate the Automation Solution

and generally fall into two categories, those that apply specifically to maintaining the security

of the Automation Solution, and those that apply to maintaining other aspects of the
Automation Solution, such as device and equipment maintenance, but that have the

responsibility to ensure that security is not degraded as a result of these activities.

NOTE 1 The maintenance service provider can be an organization within the asset owner’s organization.
NOTE 2 There can be one or more maintenance service providers maintaining the Automation Solution at the
same time or in sequence.
Maintenance activities generally start after handover of the Automation Solution to the asset
owner has occurred and may continue until the asset owner no longer requires them. They
are typically short and frequently recurring, and typically include one of more of the following:
a) patching and anti-virus updates,
b) equipment upgrades and maintenance, including small engineering adjustments not
directly related to control algorithms,
c) component and system migration,
d) change management,
e) contingency plan management.
All maintenance activities include some level of security awareness independent of whether or
not they are directly security related. No activity should reduce the security posture of the
after it has been completed.
This description of maintenance activates is abstract and may include other activities
generally following the handover of the Automation Solution. Also, these activities include
participation with the asset owner to ensure the asset owner requirements are met.
From the perspective of the IEC 62443 series, maintenance service providers, like integration
service providers, are expected to participate in the assessment of security risks for the
Automation Solution (such as for proposed changes) or to use the r
...