CLC/TS 50701:2021

SLOVENSKI STANDARD
01-september-2021
Železniške naprave - Kibernetska varnost
Railway applications - Cybersecurity
Bahnanwendungen - Cybersecurity
Applications ferroviaires - Cybersécurité
Ta slovenski standard je istoveten z: CLC/TS 50701:2021
ICS:
35.030 Informacijska varnost IT Security
45.020 Železniška tehnika na Railway engineering in
splošno general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION CLC/TS 50701

SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
July 2021
ICS 35.030; 45.020
English Version
Railway applications - Cybersecurity
Applications ferroviaires - Cybersécurité Bahnanwendungen - IT-Sicherheit
This Technical Specification was approved by CENELEC on 2021-05-11.

CENELEC members are required to announce the existence of this TS in the same way as for an EN and to make the TS available promptly
at national level in an appropriate form. It is permissible to keep conflicting national standards in force.

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
© 2021 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. CLC/TS 50701:2021 E
Contents Page
European foreword . 6
Introduction . 7
1 Scope . 8
2 Normative references . 8
3 Terms, definitions and abbreviations. 8
3.1 Terms and definitions . 8
3.2 Abbreviations .24
4 Railway system overview .26
4.1 Introduction .26
4.2 Railway asset model .27
4.3 Railway physical architecture model .28
4.4 High-level railway zone model .29
5 Cybersecurity within a railway application lifecycle .31
5.1 Introduction .31
5.2 Railway application and product lifecycles .31
5.3 Activities, synchronization and deliverables .31
5.4 Cybersecurity context and cybersecurity management plan .35
5.5 Relationship between cybersecurity and essential functions .35
5.5.1 General .35
5.5.2 Defence in depth .35
5.5.3 Security-related application conditions .36
5.5.4 Interfaces between the safety and the cybersecurity processes .37
5.6 Cybersecurity assurance process .38
6 System definition and initial risk assessment .39
6.1 Introduction .39
6.2 Identification of the system under consideration .40
6.2.1 Definition of the SuC.40
6.2.2 Overall functional description .41
6.2.3 Access to the SuC .41
6.2.4 Essential functions.41
6.2.5 Assets supporting the essential functions .42
6.2.6 Threat landscape .42
6.3 Initial risk assessment .42
6.3.1 Impact assessment.42
6.3.2 Likelihood assessment .43
6.3.3 Risk evaluation .44
6.4 Partitioning of the SuC .45
6.4.1 Criteria for zones and conduits breakdown . 45
6.4.2 Process for zones and conduits breakdown . 45
6.5 Output and documentation . 46
6.5.1 Description of the system under consideration . 46
6.5.2 Documentation of the initial risk assessment . 46
6.5.3 Definition of zones and conduits . 46
7 Detailed risk assessment . 47
7.1 General aspects . 47
7.2 Establishment of cybersecurity requirements . 48
7.2.1 General . 48
7.2.2 Threat identification and vulnerability identification . 49
7.2.3 Vulnerability identification . 51
7.2.4 Risk acceptance principles . 51
7.2.5 Derivation of SL-T by explicit risk evaluation . 53
7.2.6 Determine initial SL . 55
7.2.7 Determine countermeasures from EN IEC 62443-3-3 . 56
7.2.8 Risk estimation and evaluation . 56
7.2.9 Determine security level target . 58
7.2.10 Cybersecurity requirements specification for zones and conduits . 58
8 Cybersecurity requirements . 59
8.1 Objectives . 59
8.2 System security requirements . 59
8.3 Apportionment of cybersecurity requirements . 74
8.3.1 Objectives . 74
8.3.2 Break down of system requirements to subsystem level . 75
8.3.3 System requirement allocation at component level . 75
8.3.4 Specific consideration for implementation of cybersecurity requirement on components . 76
8.3.5 Requirement breakdown structure as verification . 76
8.3.6 Compensating countermeasures . 77
9 Cybersecurity assurance and system acceptance for operation . 78
9.1 Overview . 78
9.2 Cybersecurity case . 79
9.3 Cybersecurity verification . 80
9.3.1 General . 80
9.3.2 Cybersecurity integration and verification . 80
9.3.3 Assessment of results . 82
9.4 Cybersecurity validation . 82
9.5 Cybersecurity system acceptance . 83
9.5.1 Independence . 83
9.5.2 Objectives . 83
9.5.3 Activities . 83
9.5.4 Cybersecurity handover .83
10 Operational, maintenance and disposal requirements .83
10.1 Introduction .83
10.2 Vulnerability management .84
10.3 Security patch management .85
10.3.1 General .85
10.3.2 Patching systems while ensuring operational requirements .86
Annex A (informative) Handling conduits . 89
Annex B (informative) Handling legacy systems . 92
Annex C (informative) Cybersecurity design principles . 98
Annex D (informative) Safety and security . 127
Annex E (informative) Risk acceptance methods . 131
Annex F (informative)  Railway architecture and zoning . 140
Annex G (informative) Cybersecurity deliverables content . 158
Bibliography . 161

Figures
Figure 1 — Segregation of IT and OT . 27
Figure 2 — Railway asset model (example) . 28
Figure 3 — Railway physical architecture model (example) . 29
Figure 4 — Generic high-level railway zone model (example) . 30
Figure 5 — Defence in depth with example of measures . 36
Figure 6 — Relationship TRA and SA . 39
Figure 7 — Initial risk assessment flowchart . 40
Figure 8 — Detailed risk assessment flowchart . 49
Figure 9 — Explicit risk evaluation flowchart . 54
Figure 10 — Handling of SL-C . 77
Figure 11 — Cybersecurity assurance . 78
Figure 12 — Cybersecurity case concept . 79
Figure 13 — Cybersecurity assurance during integration and validation activities . 81
Figure 14 — General vulnerability handling flowchart . 85
Figure 15 — Vulnerability and outage time during system update (maintenance phase)
[example] . 87
Figure 16 — Vulnerability and outage time during system update with observation phases
[example] . 88
Figure A.1 — Zones and conduits example . 90
Figure D.1 — Security as an environmental condition for safety . 128
Figure F.1 — Adopted generic high-level railway zone model (example) . 148
Figure F.2 — Example of a railway system zone model . 149
Tables
Table 1 — Security-related activities within a railway application lifecycle (EN 50126-1) . 32
Table 2 — Examples of function related supporting assets in regard to the defence in depth

layers . 36
Table 3 — Qualitative Impact Assessment example . 43
Table 4 — Likelihood assessment matrix – Example . 44
Table 5 — Risk matrix example . 44
Table 6 — System Security Requirements and Foundational Classes . 61
Table E.1 — Risk acceptance categories acc. EN 50126-1 . 131
Table E.2 — Mapping severity categories acc. EN 50126-1 to cybersecurity severity . 132
Table E.3 — Likelihood assessment criteria . 132
Table E.4 — Mapping Likelihood to accessibility and Probability . 133
Table E.5 — Impact assessment matrix – Example 2 . 134
Table E.6 — Likelihood assessment matrix – Example 2 . 135
Table E.7 — Risk acceptance matrix – Example 2 . 136
Table E.8 — Impact assessment matrix – Example 3 . 137
Table E.9 — Likelihood assessment matrix – Example 3 . 138
Table E.10 — Likelihood conversion table – Example 3 . 138
Table E.11 — Risk acceptance matrix – Example 3 . 138
Table E.12 — Risk Severity / Mitigation matrix – Example 3 . 139
Table F.1 — Railway system glossary . 140
Table F.2 — Example – Evaluating groups of criticalities for landside-landside

communication . 143
Table F.3 — Example – Zone criticality definition for landside-landside communication. 144
Table F.4 — Example – Landside-landside communication matrix basic structure . 145
Table F.5 — Example – Communication matrix - landside to landside . 146
Table F.6 — Example – Rolling stock zone model . 150
Table F.7 — Example – Communication matrix - rolling stock to rolling stock . 151
Table F.8 — Example – Communication matrix - landside to rolling stock . 154
Table F.9 — Example – Communication matrix - rolling stock to landside . 155

European foreword
This document (CLC/TS 50701:2021) has been prepared by CLC/TC 9X “Electrical and electronic
applications for railways”.
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.
Any feedback and questions on this document should be directed to the users’ national committee. A
complete listing of these bodies can be found on the CENELEC website.
Introduction
The aim of this document is to introduce the requirements as well as recommendations to address
cybersecurity within the railway sector.
Due to digitization and the need for more performance and better maintainability, previously isolated
industrial systems are now connected to large networks and increasingly use standard protocols and
commercial components. Because of this evolution, cybersecurity becomes a key topic for these industrial
systems, including critical systems such as railway systems.
The purpose of this document is that, when a railway system is compliant to this document, it can be
demonstrated that this system is at the state of the art in terms of cybersecurity, that it fulfils its targeted
Security Level and that its security is maintained during its operation and maintenance.
This document intends to:
— provide requirements and guidance on cybersecurity activities and deliverables
— be adaptable and applicable to various system lifecycles
— be applicable for both safety and non-safety related systems
— identify interfaces between cybersecurity and other disciplines contributing to railway system
lifecycles
— be compatible and consistent with EN 50126-1 when it is applied to the system under consideration
— due to lifecycle differences between safety and cybersecurity, separate safety approval and
cybersecurity acceptance as much as possible
— identify the key synchronization points related to cybersecurity between system integrator and asset
owner
— provide harmonized and standardized way to express technical cybersecurity requirements
— provide cybersecurity design principles promoting simple and modular systems
— allow the usage of market products such as industrial COTS compliant with the 62443 series.
1 Scope
This document provides the railway operators, system integrators and product suppliers, with guidance
and specifications on how cybersecurity will be managed in the context of EN 50126-1 RAMS lifecycle
process. This document aims at the implementation of a consistent approach to the management of the
security of the railway systems. This document can also be applied to the security assurance of systems
and components/equipment developed independently of EN 50126-1:2017.
This document applies to Communications, Signalling and Processing domain, to Rolling Stock and to
Fixed Installations domains. It provides references to models and concepts from which requirements and
recommendations can be derived and that are suitable to ensure that the residual risk from security
threats is identified, supervised and managed to an acceptable level by the railway system duty holder.
It presents the underlying security assumptions in a structured manner.
This document does not address functional safety requirements for railway systems but rather additional
requirements arising from threats and related security vulnerabilities and for which specific measures and
activities need to be taken and managed throughout the lifecycle. The aim of this document is to ensure
that the RAMS characteristics of railway systems / subsystems / equipment cannot be reduced, lost or
compromised in the case of intentional attacks.
The security models, the concepts and the risk assessment process described in this document are based
on or derived from IEC/EN IEC 62443 series standards. This document is consistent with the application
of security management requirements contained within IEC 62443-2-1 which in turn are based on
EN ISO/IEC 27001 and EN ISO 27002.
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.
EN 50126-1:2017, Railway Applications - The Specification and Demonstration of Reliability, Availability,
Maintainability and Safety (RAMS) - Part 1: Generic RAMS Process
EN IEC 62443-3-2:2020, Security for industrial automation and control systems - Part 3-2: Security risk
assessment for system design
EN IEC 62443-3-3:2019 , Industrial communication networks - Network and system security - Part 3-3:
System security requirements and security levels
IEC 62443-2-1:2010, Industrial communication networks - Network and system security - Part 2-1:
Establishing an industrial automation and control system security program
3 Terms, definitions and abbreviations
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:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online Browsing Platform: available at http://www.iso.org/obp
NOTE The correspondence of the terms IACS, Solution and System used in EN IEC 62443 series with the
terms in this document can need further clarification in future issues of the TS. Particularly, when using EN IEC 62443

Document impacted by EN IEC 62443-3-3:2019/AC:2019-10.
definitions and requirements, the term “IACS” is to be understood and replaced by, “railway application” or “railway
system” as relevant in the context.
3.1.1
acceptance

status achieved by a product, system or process once it has been agreed that it is suitable for its intended
purpose
[SOURCE: EN 50126-1:2017, 3.1]
3.1.2
access

ability and means to communicate with or otherwise interact with a system in order to use system
resources
Note 1 to entry: Access may involve physical access (authorization to be allowed physically in an area, possession
of a physical key lock, PIN code, or access card or biometric attributes that allow access) or logical access
(authorization to log in to a system and application, through a combination of logical and physical means).
3.1.3
access control

protection of system resources against unauthorized access
[SOURCE: EN IEC 62443-4-1:2018, 3.1.2]
3.1.4
access control

process by which use of system resources is regulated according to a security policy and is permitted by
only authorized entities (users, programs, processes, or other systems) according to that policy
Note 1 to entry: Access control includes identification and authentication requirements specified in other parts of
the IEC 62443 series.
[SOURCE: EN IEC 62443-4-1:2018, 3.1.3]
3.1.5
accident
unintended event or series of events that results in death, injury, loss of a system or service, or
environmental damage
[SOURCE: IEC 60050 821:2017, 821-12-02]
3.1.6
achieved security level
measure of the security level achieved in the deployed security architecture, elsewhere, sometimes
referred to as the “as-built” security level
Note 1 to entry: Actual security level will vary over time based on natural degradations, induced events and
maintenance of security mechanisms.
3.1.7
application
software programs executing on the infrastructure that are used to interface with the process of the control
system itself
Note 1 to entry: Attributes include executable, typically execute on personal computers (PCs) or embedded
controllers
Note 2 to entry: This definition doesn't apply to the term “Railway Application”
3.1.8
approval
permission for a product or process to be marketed or used for stated purposes or under stated conditions
Note 1 to entry: Approval can be based on fulfilment of specified requirements or completion of specified
procedures.
[SOURCE: IEC 60050-902:2013, 902-06-01]
3.1.9
asset
physical or logical object owned by or under the custodial duties of an organization and having either a
perceived or actual value to the organization
[SOURCE: IEC 62443-2-1:2010, 3.1.3]
3.1.10
asset owner
individual or organization responsible for one or more IACS
Note 1 to the entry: In the context of this document, an asset owner is a railway duty holder.
[SOURCE: EN IEC 62443-4-1:2018, 3.1.6, modified – Note 1 to entry has been added]
3.1.11
attack
attempt to gain access to an information processing system in order to produce damage
Note 1 to entry: The damage can be e.g. destruction, disclosure, alteration, unauthorized use.
[SOURCE: IEC 60050-171:2019, 171-08-12]
3.1.12
attack surface
physical and functional interfaces of a system that can be accessed and, therefore, 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.
[SOURCE: EN IEC 62443-2-4:2019, 3.1.2]
3.1.13
attack vector
method or means by which an attacker can gain access to the system under consideration in order to
deliver a payload or malicious outcome
Note 1 to entry: Attack vectors enable attackers to exploit the vulnerabilities of the system under consideration,
including the human element.
Note 2 to entry: Examples of attack vectors include and not limited to USB key, e-mail attachment, wireless
connection, compromised credentials, phishing, man in the middle attack, etc.
3.1.14
audit
systematic, independent, documented process for obtaining records, statements of fact or other relevant
information and assessing them objectively to determine the extent to which specified requirements are
fulfilled
[SOURCE: IEC 60050-902:2013, 902-03-04, modified – Note 1 to entry has been removed]
3.1.15
authentication
provision of assurance that a claimed characteristic of an identity is correct
Note 1 to entry: Not all credentials used to authenticate an identity are created equally. The trustworthiness of the
credential is determined by the configured authentication mechanism. Hardware or software-based mechanisms can
force users to prove their identity before accessing data on a device. A typical example is proving the identity of a
user usually through an identity provider.
Note 2 to entry: Authentication is usually a prerequisite to allowing access to resources in a control system.
[SOURCE: EN IEC 62443-4-1:2018, 3.1.9]
3.1.16
authorization

right or a permission that is granted to a system entity to access a system resource
[SOURCE: IEC/TR 62443-3-1:2009, 3.1.7]
3.1.17
boundary
software, hardware, or other physical barrier that limits access to a system or part of a system
3.1.18
boundary device
communication security asset, within a zone or conduit, that provides a protected interface between a
zone and a conduit
3.1.19
communication channel

specific logical or physical communication link between assets
Note 1 to entry: A channel facilitates the establishment of a connection.
[SOURCE: EN IEC 62443-3-3:2019 , 3.1.9]
3.1.20
communication path
logical connection between a source and one or more destinations, which could be devices, physical
processes, data items, commands, or programmatic interfaces
Note 1 to entry: The communication path is not limited to wired or wireless networks, but includes other means of
communication such as memory, procedure calls, state of physical plant, portable media, and human interactions.
3.1.21
compensating countermeasure
countermeasure employed in lieu of or in addition to inherent security capabilities to satisfy one or more
security requirements
EXAMPLE
— (component-level): locked cabinet around a controller that does not have sufficient cyber access control
countermeasures.
— (control system/zone-level): physical access control (guards, gates and guns) to protect a control room to restrict
access to a group of known personnel to compensate for the technical requirement for personnel to be uniquely
identified by the IACS.
— (component-level): a vendor’s programmable logic controller (PLC) cannot meet the access control capabilities
from an end-user, so the vendor puts a firewall in front of the PLC and sells it as a system.
[SOURCE: EN IEC 62443-4-2:2019, 3.1.9]
3.1.22
compromise
violation of the security of a system such that an unauthorized disclosure or modification on sensitive
information may have occurred, or unauthorized behaviour of the controlled physical process may have
occurred
3.1.23
conduit

logical grouping of communication channels, between connecting two or more zones, that share common
security requirements
Note 1 to entry: A conduit is allowed to traverse a zone as long as the security of the channels contained within the
conduit is not impacted by the zone.
[SOURCE: EN IEC 62443-4-2:2019, 3.1.11]
3.1.24
confidentiality

assurance that information is not disclosed to unauthorized individuals, processes, or devices
Note 1 to entry: When used in the context of an IACS, confidentiality refers to protecting IACS data and information
from unauthorized access.
[SOURCE: EN IEC 62443-4-2:2019, 3.1.12]
3.1.25
connection

association established between two or more endpoints which supports the establishment of a session
[SOURCE: EN IEC 62443-4-2:2019, 3.1.13]
3.1.26
control network
time-critical network that is typically connected to equipment that controls physical processes
Note 1 to entry: The control network can be subdivided into zones, and there can be multiple separate control
networks within one company or site.
3.1.27
control system

hardware and software components of an IACS
Note 1 to entry: Control systems are composed of field devices, embedded control devices, network devices, and
host devices (including workstations and servers.
[SOURCE: EN IEC 62443-3-3:2019 , 3.1.16, modified – Note 1 to entry has been added]
3.1.28
countermeasure
action, device, procedure, or technique that reduces a threat, a vulnerability, or 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 standard to avoid confusion with the term “control” in the context of “process
control” and “control system”.
[SOURCE: EN IEC 62443-3-3:2019 , 3.1.17]
3.1.29
cybersecurity

set of activities and measures taken with the objective to prevent, detect, react to unauthorized access or
cyberattack which could lead to an accident, an unsafe situation, or railway application performance
degradation
Note 1 to entry: It is recognized that the term “cybersecurity” has a broader meaning in other standards and
guidance, often including non-malevolent threats, human errors, and protection against natural disasters. Those
aspects, except human errors degrading security controls, are not included in this document.
3.1.30
data diode
boundary device which ensures that data between two separate networks is only transmitted in one
direction
Note 1 to entry: data diode can be either of the physical or logical type (firewall)
3.1.31
defence in depth
approach to defend the system against any particular attack using several independent methods
Note 1 to entry: Defence in depth implies layers of security and detection, even on single systems, and provides
the following features:
—  is based on the idea that any one layer of protection, may and probably will be defeated;
—  attackers are faced with breaking through or bypassing each layer without being detected;
—  a flaw in one layer can be mitigated by capabilities in other layers;
—  system security becomes a set of layers within the overall network security; and
—  each layer should be autonomous and not rely on the same functionality nor have the same failure modes as the
other layers.
[SOURCE: EN IEC 62443-4-1:2018, 3.1.15, modified – defense has been replaced by defence]
3.1.32
demilitarized zone
common, limited network of servers joining two or more zones for the purpose of controlling data flow
between zones
Note 1 to entry: Demilitarized zones (DMZs) are typically used to avoid direct connections between different zones.
[SOURCE: EN IEC 62443-3-3:2019 , 3.1.19]
3.1.33
denial of service
prevention or interruption of authorized access to a system resource or the delaying of system operations
and functions
[SOURCE: IEC/TR 62443-3-1:2009, 3.1.21]
3.1.34
digital signature
result of a cryptographic transformation of data which, when properly implemented, provides the services
of origin authentication, data integrity, and signer non-repudiation
[SOURCE: IEC/TR 62443-3-1:2009, 3.1.22]
3.1.35
encryption

transformation of data in order to hide their semantic content using cryptography
Note 1 to entry: The reverse process is called decryption.
[SOURCE: IEC 60050-171:2019, 171-08-09]
3.1.36
essential function
function or capability that is required to maintain health, safety, the environment and availability for the
equipment under control
Note 1 to the entry: Essential functions include, but are not limited to, the safety instrumented function (SIF),
the control function and the ability of the operator to view and manipulate the equipment under control. The loss of
essential functions is commonly termed loss of protection, loss of control and loss of view respectively. In some
industries additional functions such as history may be considered essential.
[SOURCE: EN IEC 62443-4-2:2019, 3.1.20]
3.1.37
firewall
functional unit that mediates all traffic between two networks and protects one of them or some part
thereof against unauthorized access
[SOURCE: IEC 60050-732:2010, 732-06-01, modified – The notes to entry have been omitted]
3.1.38
gateway

functional unit that connects two computer networks with different network architectures and protocols
[SOURCE: IEC 60050-732:2019, 732-01-17, modified – The notes to entry have been omitted]
3.1.39
handover

act of turning a railway solution over to the asset owner
Note 1 to entry: Handover effectively transfers responsibility for operations and maintenance of a railway 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.40
host computer
host
in a computer network, a computer that provides end users with services such as computation and data
base access and that may perform network control functions
[SOURCE: IEC 60050-732:2010, 732-01-14]
3.1.41
impact
evaluated consequence of a particular event
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.
[SOURCE: EN IEC 62443-3-3:2019 , 3.1.27, modified – Note 1 to entry has been added]
3.1.42
incident

event that is not part of the expected operation of a system or service that causes, or may cause, an
interruption to, or a reduction in, the quality of the service provided by the control system
[SOURCE: EN IEC 62443-3-3:2019 , 3.1.28]
3.1.43
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).
[SOURCE: EN IEC 62443-2-4:2019, 3.1.9]
3.1.44
integrity

property that sensitive data has not been modified or deleted in an unauthorized and undetected manner
[SOURCE: IEC 60050-171:2019, 171-08-05, modified – “of data that have not been altered or destroyed”
has been replaced with “that sensitive data has not been modified or deleted”]
3.1.45
intrusion

unauthorized act of compromising a system
Note 1 to entry: See “attack”.
3.1.46
intrusion detection
security service that monitors and analyses system events for the purpose of finding, and providing real-
time or near real-time warning of, attempts to access system resources in an unauthorized manner
3.1.47
least privilege
basic principle that holds that users (humans, software processes or devices) should be assigned the
fewest privileges consistent with their assigned duties and functions
Note 1 to entry: Least privilege is commonly implemented as a set of roles in an IACS.
[SOURCE: EN IEC 62443-4-2:2019, 3.1.28]
3.1.48
legacy system
any kind of system which is already in operation
3.1.49
likelihood

weighted factor based on a subjective analysis of the proba
...