text: June 2025, version 1.0

text: June 2025, version 1.0

text: (1) https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2690&qid=1729254262885.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) A few requirements might not have one or more of these elements because their implementation was considered straightforward. 3 ( ) A recommendation is defined as an ‘expression, in the content of a document, that conveys a suggested possible choice or course of action deemed to be particularly suitable without necessarily mentioning or excluding others’. A requirement is defined as an ‘expression, in the content of a document, that conveys objectively verifiable criteria to be fulfilled and from which no deviation is permitted if conformance with the document is to be claimed’ (ISO/IEC Directives, Part 2 – Principles and rules for the structure and drafting of ISO and IEC documents, 9th edition, 2021).

text: June 2025, version 1.0 3. In some technical and methodological requirements, extra general tips are also offered for additional consideration by the entity.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) The information security controls listed in Table A.1 of Annex A to this standard are directly derived from and aligned with those listed in ISO/IEC 27002:2022. Clauses 5 to 8 are to be used in context with clause 6.1.3 (information security risk treatment) of ISO/IEC 27001:2022. 5 ( ) The mapping is based on the information that the representatives of the Member States in the NIS Cooperation Group work stream on security measures have provided to ENISA. 6 ( ) ENISA Technical implementation guidance mapping table (Excel file), https://www.enisa.europa.eu/publications/nis2-technical-implementationguidance (7)

text: Article 21(2)

text: , point (a) of the NIS2 Directive.

text: June 2025, version 1.0

text: ( ) According to ISO/IEC 27002:2022, topic-specific policy includes ‘intentions and direction on a specific subject or topic, as formally expressed by the appropriate level of management’.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) The occurrence of the indicative events provided does not automatically require a covered entity to update its policy. Instead, the occurrence of such events should be considered through the risk-assessment process, allowing the entity to determine whether new policy updates are necessary to address its unique security risks identified by the risk assessment. (10) In accordance with Articles

text: and

text: of the regulation.

text: June 2025, version 1.0

text: (11) https://www.enisa.europa.eu/topics/skills-and-competences/skills-development/european-cybersecurity-skills-framework-ecsf.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) The remaining risk after management has implemented a risk response. Source: ISACA Glossary, https://www.isaca.org/resources/glossary. 13 ( ) For example, ISO/IEC 27005:2022 – Information security, cybersecurity and privacy protection – Guidance on managing information security risks. A collection of frameworks and methodologies that provide high-level guidelines for risk-management processes that can be applied in all types of organisations is available at https://www.enisa.europa.eu/publications/compendium-of-risk-management-frameworks.

text: June 2025, version 1.0

text: ( ) There are many risk-management standards, frameworks and methodologies. A non-exhaustive list of them can be found in the ENISA publication Compendium of risk-managements frameworks with potential interoperability, https://www.enisa.europa.eu/publications/compendium-of-riskmanagement-frameworks.

text: June 2025, version 1.0

text: ( ) More information on risk criteria can be found in ISO/IEC 27005:2022, paragraph 6.4. It is important to understand that risk appetite, defined as the amount of risk an entity is willing to pursue or accept, can vary considerably from entity to entity. For instance, factors affecting an entity’s risk appetite include size, complexity and sector.

text: June 2025, version 1.0

text: (16) Vulnerabilities of network and information systems may also arise from human, organizational, and procedural weaknesses.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) In addition, consider the ‘Incident response recommendations and considerations for cybersecurity risk management’ from NIST, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf.

text: June 2025, version 1.0

text: ( ) The ISO/IEC 27035 series provides further guidance on incident management: ISO/IEC 27035-1:2023(en) Information technology – Information security incident management – Part 1: Principles and process. For the categorisation of incidents, please also consult the ENISA guidelines related to

text: Article 23(9)

text: summary reporting for the NIS2 Directive or information provided by the national computer security incident response teams (CSIRTs). 19 ( ) A cyberattack involves deliberate and malicious attempts to compromise the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by or accessible via, network and information systems. The attack can be due to insider activity or external perpetrators.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) Most software today builds on the rich foundation of infrastructure that has been provided freely by free and open source software (FOSS) projects and communities. In line with the approach to FOSS in

text: Regulation (EU) 2024/2487

text: , this document includes guidance on the responsible use of free and open source software in relevant sections, for example in sections 5.1 and 6.1. (21) Article 3(6) of the Cyber Resilience Act.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) The thresholds are subject to the operational environment. There are several assumptions about the environment that would need to be true for these controls/thresholds to be relevant. For certain entities, we expect that these entities will be under constant attack by bad actors and, accordingly, should be permitted to leverage continuous, automated and immediate responses. 23 ( ) Privileged access alarms shall distinguish between (a) administrative privilege assignment events (e.g. creation or promotion of accounts to privileged status) and (b) the use of existing privileged accounts by authorized personnel. The system shall generate an immediate alert upon detection of unauthorized or unexpected privilege assignments and a behavioural threshold alert (e.g. ≥2 privilege elevations within 24 hours) for monitoring legitimate administrative access patterns.

text: June 2025, version 1.0

text: ( ) For public NTP servers, see https://ntp.org/. (25) Entity risk analysis should include definition on the stratum level required for the chosen sources of time synchronisation.

text: June 2025, version 1.0

text: ( ) ISO 8601-1:2019/Amd 1:2022 Date and time – Representations for information interchange, 2022 edition. 27 ( ) RFC3339, Date and time on the internet: Timestamps, July 2002, https://doi.org/10.17487/RFC3339. (28) RFC9557, Date and time on the internet: Timestamps with additional information, April 2024, https://doi.org/10.17487/RFC9557.

text: June 2025, version 1.0

text: (29) Seek consistency with the reporting templates required by the national CSIRT or, where applicable, the competent authority.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) An example of good practice for such playbooks is the OASIS Collaborative Automated Course of Action Operations (CACAO) Security Playbooks Version Specification, v2.0, https://docs.oasis-open.org/cacao/security-playbooks/v2.0/security-playbooks-v2.0.html. 31 ( ) More information on information security incident root cause analysis can be found in Forum of Incident Response and Security Teams, ‘FIRST CSIRT services framework’, Version 2.1, ‘6.2.4 Function: Information security incident root cause analysis’, https://www.first.org/standards/frameworks/csirts/csirt_services_framework_v2.1#6-Service-Area-Information-Security-Incident-Management. (32) For the criteria on recurring incidents, see Article 4 of Commission Implementing

text: Regulation (EU) 2024/2690 of 17 October 2024

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) In addition to those mentioned in the mapping table at the end of this section, consider the following: • ISO/IEC 27035-1:2023, Information technology – Information security incident management, Part 1: Principles and process; • ISO/IEC 27035-2:2023, Information technology – Information security incident management, Part 2: Guidelines to plan and prepare for incident response; • NIST SP 800-61 Rev. 2, ‘Computer security incident handling guide’, https://csrc.nist.gov/pubs/sp/800/61/r2/final.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) More information on information security incident root cause analysis can be found in Forum of Incident Response and Security Teams, ‘FIRST CSIRT services framework’, Version 2.1, ‘6.2.4 Function: Information security incident root cause analysis’, https://www.first.org/standards/frameworks/csirts/csirt_services_framework_v2.1#6-Service-Area-Information-Security-Incident-Management.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) For example, • ISO 22301:2019 - Security and resilience — Business continuity management systems — Requirements, • ISO 22313:2020 - Security and resilience — Business continuity management systems — Guidance on the use of ISO 2230 and • NIST SP 800-34 Rev. 1 – Contingency Planning Guide for Federal Information Systems.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: (36) Consider the following standards: ISO/TS 22317:2021 and NIST special publication 800-34. For definitions of terms, refer to ISO 22300:2021.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: (37) This term is usually used to identify the first system affected by an attack.

text: June 2025, version 1.0

text: ( ) Additionally, consider: • ISO 22361:2022, Security and resilience – Crisis management – Guidelines; • ENISA Best Practices for Cyber Crisis Management, https://www.enisa.europa.eu/publications/best-practices-for-cyber-crisismanagement; • NIST Special Publication 800-61 Revision 2.

text: June 2025, version 1.0

text: ( ) According to ISO 22361, a crisis is an ‘abnormal or extraordinary event or situation which threatens an organisation or community and requires a strategic, adaptive and timely response in order to preserve its viability and integrity’.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) In addition, consider the following: • ISO/IEC 27036-1:2021, Cybersecurity – Supplier relationships Part 1: Overview and concepts; • ISO/IEC 27036-2:2022, Cybersecurity – Supplier relationships Part 2: Requirements; • NIST SP 800-161 Rev. 1, ‘Cybersecurity supply chain risk management practices for systems and organizations’, https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final; • ENISA, Good Practices for Supply Chain Cybersecurity, https://www.enisa.europa.eu/publications/good-practices-for-supply-chaincybersecurity. (41) The list aligns with the draft EU ICT Supply Chain Toolbox from the NIS Cooperation Group workstream on supply chain, as of February 2025.

text: June 2025, version 1.0

text: (42) ‘NIS Cooperation Group’, https://digital-strategy.ec.europa.eu/en/policies/nis-cooperation-group.

text: June 2025, version 1.0

text: ( ) The entity remains fully accountable for the integrity, availability and confidentiality of services provided by suppliers. SLAs must be clearly defined, actively managed and aligned with the entity’s business continuity, security and compliance obligations.

text: June 2025, version 1.0

text: (44) For example, for procuring security services or for recurring purchases in large quantities.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: (45) OSS, also known as free software or FOSS, guarantees its users the essential four freedoms: use, study, share and improve. OSS can be used for any purpose and is free of restrictions such as licence expiry or geographic limitations. Its software code can be studied by anyone, without non‐ disclosure agreements or similar restrictions. It can be shared and copied at virtually no cost. It be modified by anyone, and these improvements can be shared publicly. The absence or weakening of at least one of these freedoms means an application is proprietary, so non‐OSS. The four freedoms are given by a software licence. Software licences define the conditions under which a programme can be used and reused. For it to be free software, the licence text must contain at least the four freedoms. The Free Software Foundation and the Open Source Initiative maintain lists of reviewed and approved licences. An application can usually not be considered OSS if its licence does not appear in one of these lists. (46)

text: Regulation (EU) 2024/2847

text: , Art. 3(14).

text: June 2025, version 1.0

text: ( ) Suppliers do not necessarily need to perform security audits (and the resulting remediation efforts) themselves, but they can fund existing initiatives that perform open source security audits at scale (e.g. Sovereign Tech Agency, Alpha-Omega and the Open Source Technology Improvement Fund) or upstream (e.g. by funding a maintainer or by establishing contractual relationships with relevant Open Source Software Stewards to do that work). Additionally, suppliers and service providers should make any code reviews reusable for others to align with manufacturer obligations under Article 13(6) of the Cyber Resilience Act. The term ‘upstream’ and ‘downstream’ denotes whether a component is being depended on (is upstream of) or is a dependent of (is downstream of) a component.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) See section 5.1 (Tips), for additional guidance on the use of free and open source software supply chain. 49 ( ) In addition, to those mentioned in the mapping table at the end of this section, consider the following: • https://www.enisa.europa.eu/publications/indispensable-baseline-security-requirements-for-the-procurement-of-secure-ict-products-and services; • Department of the Environment, Climate and Communications, ‘Guidelines on cyber security specifications (ICT procurement for public service bodies)’, https://www.ncsc.gov.ie/pdfs/Guidelines_on_Cyber_Security_Specifications.pdf.

text: June 2025, version 1.0

text: (50) Criteria for open source components should take into account the voluntary nature of open source projects. Acquirers of such components must constructively engage with project maintainers in addressing Identified security requirements and introducing mitigations and/or improvements. These improvements should be shared with the open source project under their license and terms.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: (51) In addition, to those mentioned in the mapping table at the end of this section, consider the following: • ‘OWASP ASVS (Application Security Verification Standard)’, https://owasp.org/www-project-application-security-verification-standard/ , as updated from time to time. • ISO/IEC 27034 family, Information technology - Security techniques - Application security. • NIST SP 800-53, https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final, as updated from time to time.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) In addition to the standards in the mapping table, consider the following: • ISO/IEC 20000, which is the international standard for IT service management and consists of 17 parts; • Information Technology Infrastructure Library; • Institute of Electrical and Electronics Engineers 828, Standard for configuration management in systems and software engineering.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) The decision about the update should be based on the actual technical capabilities and specific needs of the entity, taking into account the results of a risk assessment before implementing the update.

text: June 2025, version 1.0

text: ( ) In addition to those mentioned in the mapping table at the end of this section, consider the following: • ISO 21500:2021, Project, programme and portfolio management - Context and concepts; • ISO 21502:2020, Project, programme and portfolio management - Guidance on project management.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) Also known as a roll-back or backout plan, it refers to a set of pre-planned actions or procedures designed to revert a system or a service to a previous, stable, state in case the change does not work as expected.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) In addition to the standards in the mapping table, consider the following: • ISO/IEC 27034 series of standards on application security. • OWASP Web Security Testing Guide, https://owasp.org/www-project-web-security-testing-guide/. • Open Source Security Testing Methodology Manual (OSSTMM), https://www.isecom.org/OSSTMM.3.pdf. 57 ( ) CyberFundamentals, ID.RA-1, Centre for Cyber Security Belgium, https://atwork.safeonweb.be/sites/default/files/2024-12/cyfun_basic_v2023-03- 01_e_update_2024.pdf.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) NIST SP 800-40 Rev. 4, ‘Guide to enterprise patch management planning: preventive maintenance for technology’, https://csrc.nist.gov/pubs/sp/800/40/r4/final.

text: June 2025, version 1.0

text: ( ) ‘Canary deployment’ is an example of this and refers to a gradual rollout strategy for software updates or patches. To minimise the risk of the patch introducing new problems, the entity might apply the patch to a small number (e.g. 5%) of servers or systems and then gradually apply it to the entire system. It is ideal for rolling out changes slowly and monitoring for problems without affecting many users. 60 ( ) A release candidate is a ‘pre-publication’ or ‘trial publication’ of a software component, usually done in preparation before the publication of a software update with significant changes.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) In addition to those mentioned in the mapping table at the end of this section, consider the following: a) NIST Special Publication NIST SP 800-215, Guide to a Secure Enterprise Network Landscape, https://doi.org/10.6028/NIST.SP.800-215, accessed 7 May 2025. b) ISO/IEC 27033 series of standards on network security.

text: June 2025, version 1.0

text: ( ) Zero-trust is a security model that assumes no user, device, application or network is trusted by default — even if it's inside the corporate perimeter. It's particularly relevant to remote access, service provider access, network segmentation and device control. Key components to implement zero trust are (indicative, non-exhaustive list): - Identity and access management supported by MFA (11.6.1), role based access control (11.1.3) and just in time access; - Device security supported by a policy which allows only known devices and EDR (6.9.2); - Network microsegmentation supported by logical segmentation (6.8), Next Generation Firewalls and a policy which prevents lateral movement; - Zero trust network access (ZTNA) supported by replacement of VPNs by ZTNA platforms, monitoring off all access requests and a policy which grants access to resources based on the combination of identity/device trust/context; - Application and data protection supported by cloud access security brokers (CASBs), data loss prevention (DLP) and encryption as well as monitoring of user activity; and - Continuous monitoring supported by a SIEM, user and entity behaviour analytics. 63 ( ) https://ec.europa.eu/internet-standards/email.html. 64 ( ) ‘Secure Domain Name System (DNS) Deployment Guide’, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf, as updated from time to time; Olaf Kolkman, ‘DNSSEC HOWTO, a tutorial in disguise’, https://www.dns-school.org/Documentation/dnssec_howto.pdf, as updated from time to time.

text: June 2025, version 1.0

text: (65) ENISA, , https://www.enisa.europa.eu/publications/7-steps-to-shore-up-bgp.

text: Steps to shore up the Border Gateway Protocol (BGP)

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) In addition to those mentioned in the mapping table at the end of this section, consider the following: • NIST, ‘Guide to a Secure Enterprise Network Landscape’, NIST SP 800-215, https://csrc.nist.gov/pubs/sp/800/215/final. • ISO/IEC 27033 series of standards on network security. • NIST SP 800-215 and 1800-35 propose a zero-trust model, which assumes that no part of the network is trusted. 67 ( ) Different organisations use different terminology for the term ‘operational network’, for example ‘enterprise network’, ‘corporate network’, ‘IT network’, ‘OT network’ and ‘administration network’. However, the fundamental concept remains focused on the interconnectedness and functionality of components working together towards common objectives set by the management of the entity. 68 ( ) The network for administration of a network and information system, often referred to as network administration, involves managing, monitoring and maintaining an entity’s network infrastructure to ensure its optimal performance and security.

text: June 2025, version 1.0

text: ( ) Technical method for segmentation should be considered, the usage of VLAN, physical separate switches or other methods should be defined. However physically separating subnets is not feasible in entirely software-defined environments (container clusters, cloud environments, etc.). 70 ( ) A perimeter network, also known as a demilitarised zone (DMZ), is a subnetwork that separates an entity’s internal network from untrusted external networks, such as the internet. The primary purpose of a perimeter network is to add an extra layer of security by isolating external-facing services from the internal network.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) Cyber fundamentals, PR.IP-12, Centre for Cyber Security Belgium, available at: https://atwork.safeonweb.be/sites/default/files/2024- 12/cyfun_basic_v2023-03-01_e_update_2024.pdf.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) In addition to those mentioned in the mapping table at the end of this section, consider the following: • ISO/IEC 27004:2016, Information technology - Security techniques - Information security management - Monitoring, measurement, analysis and evaluation. • Information Technology Infrastructure Library (ITIL). 73 ( ) For example, NIST SP 800-53A available at: https://csrc.nist.gov/pubs/sp/800/53/a/r5/final.

text: June 2025, version 1.0

text: ( ) ENISA’s cybersecurity investment reports offer a good reference for measuring effectiveness of measures, for example the 2023 NIS investments report, https://www.enisa.europa.eu/publications/nis-investments-2023. 75 ( ) The security culture framework (CSF) is an example source of KPIs for measuring the effectiveness of training.

text: June 2025, version 1.0

text: ( ) More information on information security incident root cause analysis can be found in Forum of Incident Response and Security Teams, ‘FIRST CSIRT services framework’, Version 2.1, ‘6.2.4 Function: Information security incident root cause analysis’, https://www.first.org/standards/frameworks/csirts/csirt_services_framework_v2.1#6-Service-Area-Information-Security-Incident-Management

text: June 2025, version 1.0

text: ( ) Refer to recitals 49, 50 and 89 of the NIS2 Directive for clarifications of the term ‘cyber hygiene’.

text: June 2025, version 1.0

text: ( ) https://www.enisa.europa.eu/topics/awareness-and-cyber-hygiene/ar-in-a-box. 79 ( ) Communication from the Commission to the European Parliament and the Council – Closing the cybersecurity talent gap to boost the EU’s competitiveness, growth and resilience ('The Cybersecurity Skills Academy'), COM(2023) 207 final, https://eur-lex.europa.eu/legalcontent/EN/TXT/?uri=COM%3A2023%3A207%3AFIN.

text: June 2025, version 1.0

text: ( ) https://www.enisa.europa.eu/topics/skills-and-competences/skills-development/european-cybersecurity-skills-framework-ecsf. 81 ( ) https://www.enisa.europa.eu/topics/skills-and-competences/skills-development/european-cybersecurity-skills-framework-ecsf.

text: June 2025, version 1.0

text: (82) In its simplest form, the exercise can mean simulating the continuity and recovery procedures through discussion (known as a tabletop exercise).

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) Non-exhaustive list of standards: • NIST special publications: SP 800-175A, SP 800-175B, SP 800-56A/B, SP 800-57; • Federal Information Processing Standards 197, 202, 186-4; • ISO/IEC: 19790, 18033; • BSI TR-02102-1 ‘Cryptographic Mechanisms: Recommendations and Key Lengths’, Version: 2025-1, January 31, 2025.

text: June 2025, version 1.0

text: ( ) Key digital signature use case areas are (indicative, non-exhaustive list): document/software code signing, authentication, data integrity and workflow automation and compliance. 85 ( ) Use cases for the use of secure hash algorithms are (indicative, non-exhaustive list): backup integrity, secure password storage, log integrity. 86 ( ) Cryptographic agility, or crypto-agility, is the ability of a system to quickly and seamlessly switch between different cryptographic algorithms and protocols without significant changes to the system’s infrastructure. For example, the X.509 public key certificate system demonstrates cryptoagility by allowing the use of different cryptographic parameters, such as key types and hash algorithms.

text: June 2025, version 1.0

text: ( ) For example NIST 800-175 and 800-57. 88 ( ) A cryptographic protocol is a set of rules and procedures that use cryptographic algorithms to achieve specific security objectives in communication and data exchange. Examples of such protocols are secure sockets layer / transport layer security (SSL/TLS) and secure shell protocol (SSH). 89 ( ) A family of cryptographic protocols is a group of related protocols that share common cryptographic techniques and principles to achieve various security objectives. Examples are (a) key establishment (e.g. Diffie-Helman and RSA), (b) identification (e.g. Kerberos), (c) message authentication (e.g. hash-based message authentication code), (d) secret sharing (e.g. Shamir’s Secret Sharing) and (e) zero knowledge proof (e.g. Schnorr) protocols.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) Implementing a unique centralised database would require major interfacing work with systems that, in many cases, were not designed for it.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: “Privileged access rights are access rights provided to an identity, a role or a process that allows the performance of activities that typical users or processes cannot perform. System administrator roles typically require privileged access rights.” ISO/IEC 27002, 8.2. Privileged access rights.

text: June 2025, version 1.0

text: ( ) In environments such as Microsoft 365 where enforcing separate identities may conflict with Conditional Access, device compliance or session controls, privileged users may use a single identity provided that some additional compensating measures are in place e.g. MFA, just-in-time access, session logging, context-aware controls (e.g. location, device compliance, app enforcement) etc.

text: June 2025, version 1.0

text: ( ) Administration systems refer to the tools and processes used to manage, monitor and maintain the hardware, software and network components of an entity’s IT infrastructure. Typical key functions of administration systems include (indicative, non-exhaustive list): system monitoring, configuration management, security management, user management and back-up and recovery.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) Wherever possible, the organization shall implement Role-Based Access Control (RBAC) to assign privileges to individual identities based on defined business or operational functions. RBAC must be used to avoid the creation of shared accounts unless a technical or operational constraint makes their use unavoidable.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) When implementing, the entity should take into account MFA fatigue, which can occur when users are overwhelmed when they receive numerous authentication prompts. Consider techniques to mitigate this, such as adaptive MFA, passkeys, MFA combined with SSO and short session timeouts.

text: June 2025, version 1.0

text: ( ) Password complexity can be a good cybersecurity practice, but it is not the only factor to consider. Recent guidelines, such as those from NIST, emphasise password length over complexity; see https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.2pd.pdf, line 725.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) Some types of MFA are vulnerable to phishing attacks, and the relevant entities should select MFA that can stand up to these attacks. For more information (indicative), see https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf and https://doubleoctopus.com/blog/general/phishing-resistant-mfa-guide/.

text: June 2025, version 1.0

text: ( ) Unlike traditional authentication, which verifies users only at the time of login, continuous authentication dynamically assesses developing risk factors such as location, device status and behavioural patterns throughout the session. Different authentication methods (see section 11.6.1) can be combined during continuous authentication. 99 ( ) CyberFundamentals, PR.AC-3, Centre for Cyber Security Belgium, https://atwork.safeonweb.be/sites/default/files/2024-12/cyfun_basic_v2023-03- 01_e_update_2024.pdf.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) For example, the entity could assess the direct replacement cost associated with an asset and, where possible, the known indirect cost of total loss.

text: June 2025, version 1.0

text: ( ) Vehicles that can store data locally on the vehicle and/or share data externally by means of telematics are included. 102 ( ) BSI, ‘SYS.3.2.1 Mobile Device Management, IT-Grundschutz-Compendium’, English version, 1 February 2022, https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Grundschutz/International/bsi_it_gs_comp_2022.html. NIST Special Publication 800-46, ‘Guide to Enterprise Telework, Remote Access and Bring Your Own Device (BYOD) Security’, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-46r2.pdf.

text: June 2025, version 1.0

text: ( ) Vehicles that can store data locally on the vehicle and/or share data externally by means of telematics are included. 104 ( ) Data that moves between systems, users, or devices, often temporarily or for processing purposes.

text: June 2025, version 1.0

text: ( ) Including ‘bring your own device’, if personal devices are used to store corporate data. Vehicles that can store data locally on a vehicle and/or share data externally by means of telematics are also included.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: (106) In the case of external provider(s), a reference to the SLA covering this relation will also be useful.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) In cases where an entity operates with a fully remote workforce and does not maintain any on-premises servers or infrastructure, the requirement for supporting utility services at a centralized location may be rendered unnecessary. Remote work inherently introduces geographical and infrastructural diversification, thereby reducing the overall utility-related risk. By distributing operations across various locations, the organization benefits from a decentralized utility dependency, which enhances resilience against localized disruptions.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) Where a company operates with a fully remote workforce and lacks centralized on-premises infrastructure, traditional physical and environmental threat protections at a single location may be less critical. The distributed nature of remote work inherently provides resilience by diversifying exposure to localized physical and environmental risks. Consequently organizations should focus on ensuring that remote employees’ home work environments meet minimum security and safety standards and consider leveraging cloud service providers’ robust physical security controls. This distributed operational model reduces dependency on any single physical site, thereby mitigating the impact of localized environmental or physical incidents.

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) In a fully remote operating model where the organization does not maintain centralized office spaces or on-premises infrastructure, traditional perimeter and physical access control measures (e.g. badge systems, mantraps, on-site security personnel) may not be applicable. Instead, the focus should shift to ensuring that access to corporate resources is governed through strong logical access controls, such as multi-factor authentication (MFA), endpoint compliance checks and secure connectivity (e.g. VPN or Zero Trust Network Access). For personnel working from home organizations should provide guidance on securing home workspaces—such as restricting unauthorized physical access to work devices and using locked rooms or cabinets when necessary. Where third-party cloud or co-location facilities are used, physical access controls should be reviewed and enforced contractually through SLAs and verified via audit reports (e.g. ISO 27001, SOC 2).

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: June 2025, version 1.0

text: ( ) ISO 22361: 2022, 3.2. 111 ( )

text: Recital 20

text: of

text: the regulation

text: addresses cyber hygiene practices for two target groups under Directive 2022/2555: essential and important entities; and their users. 112 ( ) ISO/IEC 27002:2022, 3.1.14. (113) ISO/IEC 27002:2022, 3.1.8.

text: June 2025, version 1.0

text: ( ) ISO/IEC 27002:2022, 3.1.20. 115 ( ) ISO 30000:2009, 3.12. (116) ISO/IEC 27002:2022, 3.1.32.

identifier: NIS2 Technical Implementation Guidance

title: NIS2 Technical Implementation Guidance

text: EUROPEAN UNION AGENCY FOR CYBERSECURITY

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: On Commission Implementing

text: laying down rules for the application of NIS2 Directive as regards technical and methodological requirements of cybersecurity risk-management measures JUNE 2025, VERSION 1.0 TECHNICAL IMPLEMENTATION GUIDANCE ABOUT ENISA

text: The European Union Agency for Cybersecurity, ENISA, is the Union’s agency dedicated to achieving a high common level of cybersecurity across Europe. Established in 2004 and strengthened by the EU Cybersecurity Act, the European Union Agency for Cybersecurity contributes to EU cyber policy, enhances the trustworthiness of ICT products, services and processes with cybersecurity certification schemes, cooperates with Member States and EU bodies and helps Europe prepare for the cyber challenges of tomorrow. Through knowledge sharing, capacity building and awareness raising, the agency works together with its key stakeholders to strengthen trust in the connected economy, to boost the resilience of the Union’s infrastructure and, ultimately, to keep Europe’s society and citizens digitally secure. More information about ENISA and its work can be found here: www.enisa.europa.eu.

text: CONTACT

text: To contact the authors, use ENISA-NIS-Directive@enisa.europa.eu. For media enquiries about this paper, use press@enisa.europa.eu.

text: AUTHORS

text: Konstantinos Moulinos, Marianthi Theocharidou, ENISA

text: ACKNOWLEDGEMENTS

text: This publication was developed by ENISA, in collaboration with the European Commission and the Network and Information Systems Cooperation Group. ENISA would like to thank for their efforts the Network and Information Systems Cooperation Group, along with the ENISA European Competent Authorities for Trust Services Expert Group and the European Competent Authorities for Secure Electronic Communications. Moreover, ENISA would like to recognise the valuable feedback of the individuals, private organisations, associations and members of the open source software community that contributed to the open consultation.

text: LEGAL NOTICE

text: This publication represents the views and interpretations of ENISA, unless stated otherwise. It does not endorse a regulatory obligation of ENISA or of ENISA bodies pursuant to

text: Regulation (EU) 2019/881

text: . ENISA has the right to alter, update or remove the publication or any of its contents. It is intended for information purposes only and must be accessible free of charge. All references to it or its use as a whole or in part must mention ENISA as its source. Third-party sources are quoted as appropriate. ENISA is not responsible or liable for the content of the external sources, including external websites, referenced in this publication. Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication. ENISA maintains its intellectual property rights in relation to this publication.

text: Luxembourg: Publications Office of the European Union, 2025

text: COPYRIGHT NOTICE

text: © European Union Agency for Cybersecurity (ENISA), 2025

text: Unless otherwise noted, the reuse of this document is authorised under the Creative Commons Attribution 4.0 International (CC BY 4.0) licence (https://creativecommons.org/licenses/by/4.0/). This means that reuse is allowed, provided appropriate credit is given and any changes are indicated. For any use or reproduction of elements that are not owned by the European Union Agency for Cybersecurity, permission may need to be sought directly from the respective rights holders.

text: ISBN 978-92-9204-704-7, doi:10.2824/2702548

text: TECHNICAL IMPLEMENTATION GUIDANCE EXECUTIVE SUMMARY

text: Under the NIS2 Directive, EU member states set requirements for cybersecurity risk management measures at national level in critical sectors, for example digital infrastructures, energy, transport or health. However, for several subsectors of the digital infrastructures and the ICT service management sectors, these requirements are set at European Union level due to their cross-border nature. For this purpose, the European Commission published the Implementing

text: Regulation (EU) 2024/2690

text: on 17 October 2024 ( ), which lays down the technical and methodological requirements of the measures referred to in

text: Article 21(2) of Directive (EU) 2022/2555

text: . The technical and methodological requirements are set out in

text: Article 2

text: and in the Annex to this implementing regulation.

text: This technical guidance supports this implementing regulation by providing:

text: • guidance, that is, indicative and actionable advice on parameters to consider when implementing a requirement; • examples of evidence, that is, the types of evidence that a requirement is in place; and • mappings from security requirements to industry good practices, European and international standards, and national frameworks.

text: The document, as well as the implementing regulation, refers to the following type of entities: • domain name system service providers, • top-level domain name registries, • cloud computing service providers, • data centre service providers, • content delivery network providers, • managed service providers and managed security service providers, • providers of online marketplaces, online search engines and social networking services platforms and • trust service providers.

text: The document covers the following technical and methodological requirements:

text: 1. policy on the security of network and information systems,

text: 2. risk management policy,

text: 3. incident handling,

text: 4. business continuity and crisis management,

text: 5. supply chain security,

text: 6. security in network and information systems acquisition, development and maintenance,

text: 7. policies and procedures to assess the effectiveness of cybersecurity risk-management measures,

text: 8. basic cyber hygiene practices and security training,

text: 9. cryptography,

text: 10. human resources security,

text: 11. access control,

text: 12. asset management and

text: 13. environmental and physical security.

text: To develop this technical guidance, ENISA worked closely with the European Commission and the Network and Information Systems Cooperation Group, and ENISA held a public consultation to get input from the private sector. This guidance is a living document because it maps the technical and methodological requirements referred to in

text: Article 2

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: and the Annex to the implementing regulation, to European and international standards and to national cybersecurity management frameworks. Both the standards and the management frameworks are constantly subject to change. Therefore, a review process should be initiated at regular intervals by ENISA in collaboration with the European Commission and the Network and Information Systems Cooperation Group, for instance to add additional mappings industry good practices, international standards and national frameworks.

text: DISCLAIMER

text: This document is not legally binding and is only of an advisory character. It is not intended to replace the frameworks, guidance, tools or other mechanisms provided by Member States at national level.

text: It should be clarified that the Member States retain the freedom to determine their approach to the supervision of the requirements under this implementing regulation. Therefore, this ENISA technical guidance is not able to define whether an entity needs to have all or just some of the ‘evidence’ listed (although requiring all the ‘evidence’ listed here would be a very strict approach to supervision). This document also does not determine the appropriateness of such measures or evidence. However, it can help the national competent authorities develop their approach to the supervision of the requirements.

text: Entities in scope of the regulation should check under whose jurisdiction they fall and they should follow any guidance by national competent authorities (see recital 7 of the implementing regulation).

text: TECHNICAL IMPLEMENTATION GUIDANCE TABLE OF CONTENTS INTRODUCTION 7 1. POLICY ON THE SECURITY OF NETWORK AND INFORMATION SYSTEMS 13

text: 1.1 POLICY ON THE SECURITY OF NETWORK AND INFORMATION SYSTEMS 13

text: 1.2 ROLES, RESPONSIBILITIES AND AUTHORITIES 16

text: 2. RISK MANAGEMENT POLICY 21

text: 2.1 RISK MANAGEMENT FRAMEWORK 21

text: 2.2 COMPLIANCE MONITORING 26

text: 2.3 INDEPENDENT REVIEW OF INFORMATION AND NETWORK SECURITY 28

text: 3. INCIDENT HANDLING 32

text: 3.1 INCIDENT HANDLING POLICY 32

text: 3.2 MONITORING AND LOGGING 35

text: 3.3 EVENT REPORTING 41

text: 3.4 EVENT ASSESSMENT AND CLASSIFICATION 43

text: 3.5 INCIDENT RESPONSE 45

text: 3.6 POST-INCIDENT REVIEWS 48

text: 4. BUSINESS CONTINUITY AND CRISIS MANAGEMENT 51

text: 4.1 BUSINESS CONTINUITY AND DISASTER RECOVERY PLAN 51

text: 4.2 BACKUP AND REDUNDANCY MANAGEMENT 56

text: 4.3 CRISIS MANAGEMENT 60

text: 5. SUPPLY CHAIN SECURITY 66

text: 5.1 SUPPLY CHAIN SECURITY POLICY 66

text: 5.2 DIRECTORY OF SUPPLIERS AND SERVICE PROVIDERS 73

text: TECHNICAL IMPLEMENTATION GUIDANCE 6. SECURITY IN NETWORK AND INFORMATION SYSTEMS ACQUISITION, DEVELOPMENT AND MAINTENANCE 76

text: 6.1 SECURITY IN ACQUISITION OF ICT SERVICES OR ICT PRODUCTS 76

text: 6.2 SECURE DEVELOPMENT LIFE CYCLE 79

text: 6.3 CONFIGURATION MANAGEMENT 82

text: 6.4 CHANGE MANAGEMENT, REPAIRS AND MAINTENANCE 85

text: 6.5 SECURITY TESTING 89

text: 6.6 SECURITY PATCH MANAGEMENT 91

text: 6.7 NETWORK SECURITY 94

text: 6.8 NETWORK SEGMENTATION 98

text: 6.9 PROTECTION AGAINST MALICIOUS AND UNAUTHORISED SOFTWARE 101

text: 6.10VULNERABILITY HANDLING AND DISCLOSURE 103

text: 7. POLICIES AND PROCEDURES TO ASSESS THE EFFECTIVENESS OF CYBERSECURITY RISK-MANAGEMENT MEASURES 107 8. BASIC CYBER HYGIENE PRACTICES AND SECURITY TRAINING 111

text: 8.1 AWARENESS RAISING AND BASIC CYBER HYGIENE PRACTICES 111

text: 8.2 SECURITY TRAINING 113

text: 9. CRYPTOGRAPHY 117 10.HUMAN RESOURCES SECURITY 122

text: 10.1HUMAN RESOURCES SECURITY 122

text: 10.2VERIFICATION OF BACKGROUND 124

text: 10.3TERMINATION OR CHANGE OF EMPLOYMENT PROCEDURES 126

text: 10.4DISCIPLINARY PROCESS 127

text: 11.ACCESS CONTROL 130

text: 11.1ACCESS CONTROL POLICY 130

text: 11.2MANAGEMENT OF ACCESS RIGHTS 132

text: 11.3PRIVILEGED ACCOUNTS AND SYSTEM ADMINISTRATION ACCOUNTS 135

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 11.4ADMINISTRATION SYSTEMS 137

text: 11.5IDENTIFICATION 138

text: 11.6AUTHENTICATION 141

text: 11.7MULTI-FACTOR AUTHENTICATION 144

text: 12.ASSET MANAGEMENT 148

text: 12.1ASSET CLASSIFICATION 148

text: 12.2HANDLING OF ASSETS 149

text: 12.3REMOVABLE MEDIA POLICY 151

text: 12.4ASSET INVENTORY 152

text: 12.5DEPOSIT, RETURN OR DELETION OF ASSETS UPON TERMINATION OF EMPLOYMENT 154

text: 13.ENVIRONMENTAL AND PHYSICAL SECURITY 157

text: 13.1SUPPORTING UTILITIES 157

text: 13.2PROTECTION AGAINST PHYSICAL AND ENVIRONMENTAL THREATS 159

text: 13.3PERIMETER AND PHYSICAL ACCESS CONTROL 161

text: ANNEX I NATIONAL FRAMEWORKS 165 ANNEX II GLOSSARY 167 TECHNICAL IMPLEMENTATION GUIDANCE INTRODUCTION BACKGROUND

text: On 18 October 2024, the European Commission published Commission Implementing Regulation 2024/2690 of 17 October 2024, hereafter the regulation, pursuant to

text: Articles 21(5)

text: , first subparagraph and 23(11), second subparagraph, of

text: Directive (EU) 2022/2555

text: (hereafter the NIS2 Directive). Article 2 of this regulation specifies that, for the essential and important entities in scope of the regulation (hereafter ‘relevant entities’), the technical and methodological requirements of cybersecurity risk-management measures referred to in

text: Article 21(2)

text: , points (a) to (j), of the NIS2 Directive are set out in the Annex to the regulation.

text: According to recital 7, the European Union Agency for Cybersecurity (ENISA) can support relevant entities by providing guidance on the implementation of the technical and methodological requirements referred to in the Annex to the regulation. This implementation guidance was developed by ENISA is collaboration with the Network and Information Systems Cooperation Group (NIS CG) and the European Commission. ENISA published an early draft of this guidance as part of a public consultation, to solicit feedback and input from the private sector. ENISA also consulted with various relevant workstreams of the NIS Cooperation group, as well as the ENISA expert group for European Competent Authorities for Trust Services (ECATS) and the ENISA expert group for European Competent Authorities for Secure Electronic Communications (ECASEC).

text: GOAL

text: The document provides non-binding guidance for relevant entities to the regulation on the technical and methodological requirements of the cybersecurity risk management measures.

text: TARGET AUDIENCE

text: Beyond the relevant entities to the regulation, this guidance may provide indications on the technical and methodological requirements of the cybersecurity risk management measures of the NIS2 Directive, which may be considered useful by other public or private bodies for improving their cybersecurity.

text: STRUCTURE

text: The Annex to the regulation consists of 13 titles with a varying number of technical and methodological requirements (see Figure 1). Each technical and methodological requirement is highlighted (blue font and grey background) and is included in this document for readability.

text: Each requirement is followed by three elements: guidance, examples of evidence and tips ( ). This part of the document is not legally binding and is only recommendations ( ).

text: 1. The guidance section contains indicative and actionable advice on parameters to consider when implementing a technical and methodological requirement or further explanation of concepts found in the legal text. 2. Examples of evidence are indicative types of evidence showing that a technical and methodological requirement is in place.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: Figure 1: Technical and methodological requirements of the cybersecurity risk-management measures

text: (Annex to Commission Implementing Regulation 2024/2690) 8

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: Figure 2: Technical and methodological measures structure

text: The guidance, examples of evidence and tips are non-exhaustive. Their partial or complete implementation does not assume compliance or conformity with the requirements of the regulation. Relevant entities may choose alternative methods to fulfil a requirement or use different evidence to demonstrate compliance. Moreover, a single piece of evidence may support various requirements; for example, an organisational chart can demonstrate both ‘roles and responsibilities’ and ‘segregation of duties’. Consequently, evidence may appear multiple times within the text.

text: Finally, each requirement is mapped to (a) requirements of European and international standards or frameworks (International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) 27001:2022,

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: ISO/IEC 27002:2022 ( ), NIST Cybersecurity Framework 2.0, ETSI EN 319 401 V3.1.1 (2024–06), European Committee for Standardization Technical Specification (CEN/TS) 18026:2024) and (b) to the NIS2 national 5 6 frameworks ( ). The mapping to standards and frameworks is available on the ENISA website in Excel format ( ). It should be noted that the mapping was done only to horizontal standards and for specific topics. Detailed standards or technical specifications are referenced in footnotes, where available. These standards are included as examples, as they are commonly used. The choice of which standards and good practices to apply should be made by the entity, as they may relate to the context of the entity’s activities and characteristics.

text: To implement the requirements, the relevant entities may build upon their current usage of standards or frameworks, if available. Annex I of this document provides details for each national framework submitted to ENISA during the consultation phases, while some terms are explained in Annex II. The document does not aim to establish a new standard or to duplicate existing ones (e.g. ISO, IEC and CEN). The guidance is written in a technology-neutral and standards-neutral way.

text: The mapping should not be interpreted as a measure of equivalency among different standards or frameworks. It simply refers to relevant requirements in these standards or frameworks without assessing whether these fully cover the requirements of the regulation. Cybersecurity standards or frameworks often address the same cybersecurity concerns but use different language, structures or levels of specificity or detail. Understanding these relationships may help relevant entities use and integrate multiple standards or frameworks efficiently, to maintain compliance, reduce duplication and streamline audits.

text: Relevant entities subject to the regulation can use national frameworks, guidance, standards or other mechanisms equivalent to the requirements of the regulation to demonstrate their compliance to national competent authorities. Depending on the national framework, compliance with the requirements set out by the regulation could be demonstrated by means of assessment or certification by relevant accredited conformity assessment bodies or by independent auditors authorised by the national competent authorities or certification bodies authorised by the national competent authorities, against the national frameworks, guidelines, standards or other mechanisms equivalent to technical and methodological requirements for cybersecurity risk-management measures. To keep the current guidance up to date, Member States can inform ENISA of those equivalent national frameworks, guidance, standards or other mechanisms, if available.

text: TOPIC-SPECIFIC POLICIES

text: As described in preamble 9 of the regulation, the policy on the security of network and information systems ( ) (Annex to the regulation, point 1.1) should be the highest-level document setting out the relevant entities’ overall approach to the security of their network and information systems and should be approved by the management bodies of the entities.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: In addition to this overarching corporate policy, the following topic-specific, documented policies ( ) are required.

text: 1. Risk management policy (Annex to the regulation, point 2). 2. Incident handling policy (Annex to the regulation, point 3.1.1). 3. Supply chain security policy (Annex to the regulation, point 5.1.1). 4. Security testing policy (Annex to the regulation, point 6.5.1). 5. Policy to assess the effectiveness of cybersecurity risk management measures (Annex to the regulation, point 7.1.1). 6. Policy related to cryptography (Annex to the regulation, point 9.1). 7. Access control policy (Annex to the regulation, point 11.1.1). 8. Policies for the management of privileged accounts and system administration accounts (Annex to the regulation, point 11.3) 9. Handling of information and assets policy (Annex to the regulation, point 12.2.1). 10. Removable media policy (Annex to the regulation, point 12.3.1).

text: Documenting the aforementioned topic-specific policies is mandatory. However, the relevant entity should use its discretion to determine the format of documentation, whether it be through separate documents, updates to existing policies or a single comprehensive document.

text: Chapter I

text: ON THE

text: POLICY

text: OF

text: SECURITY

text: AND

text: NETWORK INFORMATION SYSTEMS

text: TECHNICAL IMPLEMENTATION GUIDANCE 1. POLICY ON THE SECURITY OF NETWORK AND INFORMATION SYSTEMS 1.1 POLICY ON THE SECURITY OF NETWORK AND INFORMATION SYSTEMS

text: 1.1.1. For the purpose of

text: Article 21(2)

text: , point (a) of

text: Directive (EU) 2022/2555

text: , the policy on the security of network and information systems shall: (a) set out the relevant entities’ approach to managing the security of their network and information systems; (b) be appropriate to and complementary with the relevant entities’ business strategy and objectives; (c) set out network and information security objectives; (d) include a commitment to continual improvement of the security of network and information systems; (e) include a commitment to provide the appropriate resources needed for its implementation, including the necessary staff, financial resources, processes, tools and technologies; (f) be communicated to and acknowledged by relevant employees and relevant interested external parties; (g) lay down roles and responsibilities pursuant to point 1.2; (h) list the documentation to be kept and the duration of retention of the documentation; (i) list the topic-specific policies; (j) lay down indicators and measures to monitor its implementation and the current status of relevant entities’ maturity level of network and information security; (k) indicate the date of the formal approval by the management bodies of the relevant entities (the ‘management bodies’).

text: GUIDANCE

text: • Set a policy on the security of network and information systems, covering all systems, assets and procedures that fall within the scope of the policy. • Make sure that relevant personnel and relevant interested external parties, acknowledge the policy on the security of network and information systems, typically through a signed document or digital acknowledgement, where applicable. o Depending on the context, external parties may mean suppliers, service providers, shareholders, authorities, visitors, external interest groups or forums. o The acknowledgement may be included in other contracts, such as employment contracts or service provision contracts. o The policy should be communicated to relevant personnel and interested external parties in a form that is relevant, accessible and understandable to the intended reader. o Relevant personnel and relevant interested external parties may not be made aware of the full text of the policy. Depending on their role, an extract or a summary containing only relevant information should be communicated and acknowledged. If the policy is distributed outside the entity, care should be taken not to disclose confidential information. o For contractual requirements of direct suppliers and service providers, point 5.1.4 of the Annex to the regulation.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Make sure that personnel are aware of their responsibilities for the security of network and information systems. • Make sure that the policy on the security of network and information systems is approved by the management bodies. • Make sure that the topic-specific policies are approved by an appropriate level of management. • Make sure that the policy includes detailed guidance on the procedures for managing policy exceptions.

text: EXAMPLES OF EVIDENCE

text: • Documented policy on the security of network and information systems which contains the elements required by points 1.1.1 (a) to 1.1.1 (k) of the Annex to the regulation. • The date of the formal approval by the management bodies of the relevant entities, indicated in the policy on the security of network and information systems. • Where applicable, acknowledgement forms or employment contracts, signed by personnel, which confirm they have read and understood the security policies. • Where applicable, acknowledgement forms, service provision contracts or other contracts, signed by relevant interested external parties, which confirm they have read and understood the security policies. • Evidence that the management bodies understand their role, responsibilities and authorities regarding network and information security. This can include but is not limited to: o allocation of resources for policy implementation; o requests (e.g. announcements, emails and documents) to personnel to apply network and information security in accordance with the established policies and procedures; and o any initiatives that indicate that management bodies promote improvement in the area of network and information security.

text: 1.1.2. The network and information system security policy shall be reviewed and, where appropriate, updated by management bodies at least annually and when significant incidents or significant changes to operations or risks occur. The result of the reviews shall be documented.

text: GUIDANCE

text: • Review the policy on the security of network and information systems at least annually, taking into account (indicative, non-exhaustive list): o updates to the risk assessment results and the risk treatment plan (Annex to the regulation, point 2.1.4); o relevant changes in legislation (laws, regulations and other measures imposed by national competent authorities); o recommendations provided by relevant authorities; o relevant changes in industry good practices; o feedback from interested parties; o findings of compliance monitoring (section 2.2) and of independent reviews (Annex to the regulation, point 2.3), including policy violations or policy exceptions; o incidents, even those affecting similar entities in the sector.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Update the policy on the security of network and information systems and topic-specific policies, in line with new findings that could affect the entity’s approach to managing information security, including ( ): o updates to the risk assessment results and the risk treatment plan (Annex to the regulation, point 2.1.4); o changes to the network and information systems; o changes to the environment of operation; o problems identified during the implementation of the policy; o findings of compliance monitoring (Annex to the regulation, point 2.2.1) and of independent reviews (Annex to the regulation, point 2.3), including policy violations or policy exceptions; o the status of preventive and corrective actions; o trends related to threats and vulnerabilities; and o known reported security incidents. • All updates to the policy should be based on the covered entity's unique security risks identified through its risk assessment. • Obtain approval for the revised policy and the policy exceptions by the management bodies.

text: EXAMPLES OF EVIDENCE

text: • Review comments or change logs for the policy on the security of network and information systems and topic-specific policies. • Documentation of the review process of the requirements listed in point 1.1.1 of the Annex to the regulation. • Up-to-date policy on the security of network and information systems and topic-specific policies. • Evidence that any updates to the policy on the security of network and information systems and any policy exceptions, are approved by management bodies and a record is kept. • Evidence that any updates to the topic-specific policies are approved by an appropriate level of management and a record is kept. • Records of the management review.

text: TIPS

text: GUIDANCE

text: • Analyse the policy on the security of network and information systems for compliance with: o legislative, regulatory and contractual requirements; o awareness and training requirements (Annex to the regulation, points 8.1 and 8.2); and o business continuity requirements (Annex to the regulation, point 4.1). • Define procedures to facilitate the implementation of the policy on the security of network and information systems and associated measures. • Examine documentation of post-incident reviews for significant incidents ( ) that include participation and input from management bodies. • Ensure that the policy is:

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o protected in terms of confidentiality (on a need-to-know basis), integrity, availability and authenticity; o managed properly so the information is complete, correct, understandable, easily identifiable and retrievable.

text: EXAMPLES OF EVIDENCE

text: • Documented policy on the security of network and information systems, including networks and services in scope, assets supporting them and the security objectives, including applicable laws and regulations, accessible to personnel. • Documented topic-specific policies, including applicable laws and regulations, accessible to relevant personnel. • Evidence of cybersecurity training of management, for instance: o training records; o workshop and seminar attendance; and o continuous learning materials. • Internal communication logs, ad hoc reports or communication policy or records showing regular briefings or updates provided to management bodies regarding cybersecurity matters or during significant incidents.

text: 1.2 ROLES, RESPONSIBILITIES AND AUTHORITIES

text: 1.2.1. As part of their policy on the security of network and information systems referred to in point 1.1, the relevant entities shall lay down responsibilities and authorities for network and information system security and assign them to roles, allocate them according to the relevant entities’ needs and communicate them to the management bodies.

text: GUIDANCE

text: • Write job descriptions in a way that clearly outlines rights and responsibilities. • Assign security roles and responsibilities to personnel and include these roles in the organisational chart. • Describe roles and assign corresponding responsibilities (e.g. chief information security officer), based on the guidance of international frameworks and standards, including the European cybersecurity skills framework (ECSF) ( ). • Ensure that the roles allocated are suitable for the size and business needs of the entity. • Formally appoint competent personnel in security roles. Ensure that these assigned persons are competent on the basis of appropriate education, training or experience.

text: EXAMPLES OF EVIDENCE

text: • Job descriptions. • List of security roles, who occupies them and contact information. • Formal appointment of the key security roles and responsibilities, for example, listed in the company organigram or management decision, etc. • List of appointments and description of responsibilities and tasks for security roles. • Evidence of competence of the assigned persons.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 1.2.2. The relevant entities shall require all personnel and third parties to apply network and information system security in accordance with the established network and information security policy, topic-specific policies and procedures of the relevant entities.

text: GUIDANCE

text: • Make personnel aware of the security roles in the entity and when each role should be contacted. • Make personnel aware of their network and information system security obligations, according to their role. For the disciplinary process, see point 10.4 in the Annex to the regulation. • Make relevant interested external parties aware of their network and information system security obligations. o For contractual requirements of direct suppliers and service providers, see point 5.1.4 in the Annex to the regulation. o Consider third parties, which means external entities or organisations not directly involved in the operations of the entity in scope but that may still affect its network and information security. For examples of relevant interested external parties, consider the guidance in section 1.1. • The requirement that all personnel and third parties apply network and information system security should be communicated in a form that is relevant, accessible and understandable to the intended reader. o The network and information security policy, topic-specific policies and procedures of the relevant entities do not necessarily need to be communicated in their entirety.

text: EXAMPLES OF EVIDENCE

text: • Awareness/dissemination material for personnel, explaining security roles and when/how they should be contacted. • Service level agreements (SLAs), contracting contracts, data-processing agreements or other types of contracts or agreements with third parties. • Acknowledgement from third parties in various forms (letters, emails, portals or other online options) confirming that they have received and understand their obligations related to network and information system security, where such requirements are not covered by contractual arrangements.

text: 1.2.3. At least one person shall report directly to the management bodies on matters of network and information system security.

text: GUIDANCE

text: • Appoint a person (e.g. chief information security officer or information security manager) responsible for overseeing network and information security matters. • Make sure that this role is recognized and duly authorized by management bodies.

text: EXAMPLES OF EVIDENCE

text: • Up-to-date documentation of the structure of security role assignments and responsibilities. • Minutes from meetings with the management. • Evidence of business decisions made (e.g. investments in cybersecurity).

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 1.2.4. Depending on the size of the relevant entities, network and information system security shall be covered by dedicated roles or duties carried out in addition to existing roles.

text: GUIDANCE

text: • It is often practical to have dedicated information security roles (e.g. a chief information security officer or security analysts) who focus solely on protecting the entity’s data and systems. • In entities with limited resources, information security responsibilities may be distributed among existing roles. For instance, information technology (IT) staff might take on security duties alongside their regular tasks. However, the persons assigned should have relevant experience and training to perform the roles and to exercise their responsibilities.

text: EXAMPLES OF EVIDENCE

text: • Verify the presence of dedicated security roles in larger entities. • Check if security responsibilities are assigned to existing roles in smaller entities.

text: 1.2.5. Conflicting duties and conflicting areas of responsibility shall be segregated, where applicable.

text: GUIDANCE

text: • Consider segregating conflicting duties and areas of responsibility to reduce opportunities for unauthorized or unintentional modification or misuse of the entity’s asset. As a minimum, consider that the reviewer (auditor) must be different from the personnel or the line of authority of the area under review. • The results of the risk assessment or the business impact analysis (BIA) could be used to identify potential conflicting duties and areas of responsibility.

text: EXAMPLES OF EVIDENCE

text: • Up-to-date documentation of the structure of security role assignments and responsibilities.

text: 1.2.6. Roles, responsibilities and authorities shall be reviewed and, where appropriate, updated by management bodies at planned intervals and when significant incidents or significant changes to operations or risks occur.

text: GUIDANCE

text: • Regularly review and revise the structure of security roles and responsibilities, based on (indicative, nonexhaustive list): o significant incidents, if any; o changes to the environment of operation, including changes to the network and information systems; o organisational changes. • Where appropriate, updates should be approved by management bodies.

text: EXAMPLES OF EVIDENCE

text: • Up-to-date documentation of the structure of security role assignments and responsibilities, including version history. • Documentation of the review process, taking into account changes and past incidents.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: TIPS

text: GUIDANCE

text: • Make sure that the roles responsible for security roles are contactable in case of incidents. • Make sure that each role has its deputy or that measures ensuring continuity in the event of the role representative’s absence are in place, where possible. • Establish a clear reporting line from the designated security officer to senior management. • Ensure that security reporting is integrated into the entity’s overall risk management framework.

text: EXAMPLES OF EVIDENCE

text: • Documented incident response procedures (Annex to the regulation, point 3.5.1) including clear procedures for contacting security roles during an incident. • Logs and records of past incidents to check if the security roles were contacted promptly and effectively. • Crisis management process and incident response records to check the involvement of the management. • Up-to-date organisational chart to check if it clearly shows the reporting structure, including the designated security officer and their direct line to senior management. The organisational chart should be dated and the person making the update should be noted.

text: Chapter 2

text: RISK MANAGEMENT POLICY

text: TECHNICAL IMPLEMENTATION GUIDANCE 2. RISK MANAGEMENT POLICY 2.1 RISK MANAGEMENT FRAMEWORK

text: 2.1.1. For the purpose of

text: Article 21(2)

text: , point (a) of

text: Directive (EU) 2022/2555

text: , the relevant entities shall establish and maintain an appropriate risk management framework to identify and address the risks posed to the security of network and information systems. The relevant entities shall perform and document risk assessments and, based on the results, establish, implement and monitor a risk treatment plan. Risk assessment results and residual risks ( ) shall be accepted by management bodies or, where applicable, by persons who are accountable and have the authority to manage risks, provided that the relevant entities ensure adequate reporting to the management bodies.

text: GUIDANCE

text: • The entity can use its current risk management framework or adopt a new one ( ). A risk management framework is the structured approach used by an entity to identify, assess, manage and mitigate its cybersecurity risks. • Create a risk treatment plan that associates the identified risks with assets and the measures mitigating the associated risks and takes into account, at least, elements (g) to (h) in point 2.1.2 of the Annex to the regulation. The plan should at least include: o a description of the identified risk and how it can negatively affect security objectives; o a risk treatment option (for example risk avoidance, risk mitigation, risk transfer or sharing or risk acceptance); o the assets associated with the risk; o the measures which mitigate the risk; o a procedure for assessing the effectiveness of implementation of the measure(s); o implementation timelines; and o responsible roles. • Consider residual risks from third parties, for example, data breaches, unaddressed vulnerabilities, regulatory non-compliance from the from the third-party side and over-reliance on a single third party. • Ensure residual risks are accepted by management bodies or, where applicable, persons who are accountable and have the authority to manage risks, in line with the acceptable residual risk levels of the entity. • Make sure that management bodies or, where applicable, persons who are accountable and have the authority to manage risks approve the risk-assessment results and risk-treatment plan.

text: EXAMPLES OF EVIDENCE

text: • Documented risk management framework. • Documented results from previous risk assessments. • Documented risk treatment plan.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Record of approval of risk assessment results by management bodies or by persons who are accountable and have the authority to manage risks. • Record of approval of residual risks by management bodies or, where applicable, by persons who are accountable and have the authority to manage risks.

text: 2.1.2. For the purpose of point 2.1.1, the relevant entities shall establish procedures for identification, analysis, assessment and treatment of risks (‘cybersecurity risk management process’). The cybersecurity risk management process shall be an integral part of the relevant entities’ overall risk management process, where applicable. As part of the cybersecurity risk management process, the relevant entities shall: (a) follow a risk management methodology; (b) establish the risk tolerance level in accordance with the risk appetite of the relevant entities; (c) establish and maintain relevant risk criteria; (d) in line with an all-hazards approach, identify and document the risks posed to the security of network and information systems, in particular in relation to third parties and risks that could lead to disruptions in the availability, integrity, authenticity and confidentiality of the network and information systems, including the identification of single point of failures; (e) analyse the risks posed to the security of network and information systems, including threat, likelihood, impact and risk level, taking into account cyber threat intelligence and vulnerabilities; (f) evaluate the identified risks based on the risk criteria; (g) identify and prioritise appropriate risk treatment options and measures; (h) continuously monitor the implementation of the risk treatment measures; (i) identify who is responsible for implementing the risk treatment measures and when they should be implemented; (j) document the chosen risk treatment measures in a risk treatment plan and the reasons justifying the acceptance of residual risks in a comprehensible manner.

text: GUIDANCE

text: • Select a risk management methodology ( ). • Establish the entity's risk appetite, that is the amount of risk that the entity is strategically willing to accept to achieve its objectives. Criteria may include (indicative, non-exhaustive list): o business strategic objectives; o stakeholder expectations; o regulatory requirements; and o organizational culture. • Define the risk tolerance level, which refers to the level of risk that an entity is willing to accept in pursuit of its long-term objectives. Examples may include (indicative, non-exhaustive list): o acceptable downtime for systems for which criticality is high (e.g. up to two hours of downtime per month); o tolerance for data loss (e.g. loss of data with low criticality within a 24-hour window); o maximum financial loss that can be absorbed without jeopardizing operations (e.g. up to EUR 100,000 in recovery costs);

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o willingness to invest a certain percentage of revenue in measures (e.g. 5% of annual revenue); o adherence to regulatory obligations with specific penalties or fines influencing risk acceptance; o acceptable level of customer dissatisfaction or negative media exposure from a data breach (e.g. tolerating one major incident every few years); o acceptance of certain vulnerabilities based on risk mitigation measures in place (e.g. outdated software provided that it is monitored and patched regularly); o time frame for responding to and recovering from incidents (e.g. a maximum of 48 hours for containment); and o acceptance of minor incidents as part of normal operations while prioritizing major threats. • Define risk acceptance criteria, which may include (indicative, non-exhaustive list) ( ): o accepting risks categorized as low severity, such as minor data leaks that don't expose sensitive information; o accepting risks assessed as having a low likelihood of occurrence (e.g. certain rare types of cyberattacks); o accepting risks if the cost of mitigation exceeds the potential impact (e.g. not upgrading legacy systems if the upgrade cost is significantly higher than potential losses); o accepting specific compliance risks if there is a plan in place to address them within a defined timeframe (e.g. temporarily accepting minor non-compliance with a commitment to remediate within six months); o allowing certain risks in low-criticality systems or departments that do not affect core business operations (e.g. accepting a risk in a test environment); o accepting certain vulnerabilities for a defined period while planning for remediation (e.g. accepting the risk of outdated software for three months until a full upgrade can be completed); o accepting risks where the expected incident impact falls below a predetermined financial threshold (e.g. losses under EUR 50,000 accepted without further action); o accepting risks after informing stakeholders and receiving their agreement, particularly if they understand the trade-offs involved; and o accepting residual risks where existing measures reduce the likelihood or impact to an acceptable level (e.g. using encryption for sensitive data but accepting risks of loss due to user error). • Define risk criteria, that is, how the entity evaluates the significance of the risks that it identifies and makes decisions concerning risks. Risk criteria may include (indicative, non-exhaustive list): o alignment with risk appetite: accepting risks that align with the organization's overall risk appetite, such as delays in internal reporting processes that do not impact customer service or compliance; o regulatory and legal exposure: prioritizing risks based on potential legal or regulatory consequences, such as treating violations of the General Data Protection Regulation (GDPR) involving customer data as high-risk due to potential fines and reputational damage; o reputational impact: escalating risks that could significantly harm the organization's public image, such as incidents likely to attract media attention; o risk velocity: giving higher priority to risks with high velocity, such as zero-day exploits that can be weaponised before patches are available;

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o recovery complexity: treating risks as critical if they involve complex or time-consuming recovery, such as cyber-attacks on legacy systems with limited vendor support; o emerging technology risks: Considering risks involving emerging technologies as higher priority, such as AI systems producing unexplainable or non-compliant decisions due to lack of transparency; o stakeholder sensitivity: re-evaluating risks that concern key stakeholders, such as risks flagged by the board, regulators or major customers, even if the assessed technical risk is low. • Criteria for performing cybersecurity risk assessments refer to consequences, likelihood or level of risk. These may refer to (indicative, non-exhaustive list): o the importance of assets; o the severity of threats; o the vulnerability of network and information systems ( ); o impact analysis; o existing measures; and o stakeholders concerns or requirements. • Make a list of the main risks for the security of network and information systems, taking into account the main threats to the assets in scope. • Make sure that each risk is associated with at least one: o of the risk treatment options or a combination of them, in line with the results of the risk assessment and in accordance with the entity’s policy on the security of network and information systems (

text: recital 11

text: of

text: the regulation

text: ); and o specific risk treatment measure. • Develop risk-treatment plans to address the elements in points (i) and (j) in point 2.1.2 of the Annex to the regulation. • Assign responsibilities to appropriate individuals or teams for executing these risk treatment plans.

text: EXAMPLES OF EVIDENCE

text: • Documented cybersecurity risk-management process that takes into account elements referred to in point 2.1.2 of the Annex to the regulation. • Documented risk-management methodology and/or tools that take into account at least elements (a) to (f) in point 2.1.2 of the Annex to the regulation. • List of the main risks described at a high level, including underlying threat(s) and unaddressed vulnerabilities and their potential impact on the security of networks and services. • Make sure that the entity follows an all-hazards approach (check that the risk-assessment approach addresses a wide range of potential threats and risks, not just the cyber ones, but natural or man-made, accidental or intentional threats and risks). • Evidence that residual risks resulting from dependencies on third parties are listed and mitigated.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 2.1.3. When identifying and prioritising appropriate risk treatment options and measures, the relevant entities shall take into account the risk assessment results, the results of the procedure to assess the effectiveness of cybersecurity riskmanagement measures, the cost of implementation in relation to the expected benefit, the asset classification referred to in point 12.1 and the business impact analysis referred to in point 4.1.3.

text: GUIDANCE

text: • Make sure that personnel take into account the elements referred to in point 2.1.3 of the Annex to the regulation.

text: EXAMPLES OF EVIDENCE

text: • Guidance for personnel on assessing risks that takes into account the elements referred to in point 2.1.3 of the Annex to the regulation.

text: 2.1.4. The relevant entities shall review and, where appropriate, update the risk assessment results and the risk treatment plan at planned intervals and at least annually and when significant changes to operations or risks or significant incidents occur.

text: GUIDANCE

text: • Review risk assessment results and risk treatment at least annually taking into account: o results of audits and previous reviews, o status of implementation of the measures described in the risk treatment plan (see the policy on the assessment of the effectiveness of measures in line with the Annex to Regulation, point 7.1.1); o changes to the information systems; o changes to the environment of operation; o post-incident review findings (section 3.6); and o trends and changes related to threats and vulnerabilities, as they may affect risks.

text: EXAMPLES OF EVIDENCE

text: • Documentation of the review process. • Review comments or change logs for the risk assessment and risk treatment plan.

text: TIPS

text: GUIDANCE

text: • Ensure that key personnel use the risk management methodology and tools. • Overall, the entity has four risk treatment options associated with each risk. Each option should be accompanied by specific risk treatment measures (indicative, non-exhaustive list of examples): o Risk avoidance: as a measure to treat this risk, the entity might choose to eliminate activities or conditions that expose the entity to this risk, for example, discontinuing the use of a vulnerable software application. o Risk mitigation: as a measure to treat this risk, the entity might choose to implement measures to reduce the likelihood or impact of such a risk. This can include installing firewalls, using encryption and conducting regular security training for employees.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o Risk transfer or sharing: as a measure to treat this risk, the entity might choose to shift parts of the risk impact to another party, typically through insurance or outsourcing certain functions to third-party providers. However, it is important to note that such arrangements do not eliminate the entity’s overall accountability or legal obligations regarding the risk. For instance, purchasing cyber insurance may cover potential data breach costs, but the entity remains responsible for implementing appropriate security measures and complying with data protection regulations. o Risk acceptance: as a measure to treat this risk, the entity might choose to acknowledge the risk and decide to accept it without taking any specific action, often because the cost of mitigation is higher than the potential impact. This approach is usually accompanied by a contingency plan to manage the risk if it materialises. The approach should be clearly documented, supported by a realistic estimation of potential costs and including financial provisions to address the impact should the risk materialise. • Make sure that the risk from vulnerabilities assigned to the highest classification (e.g. ‘critical’ in the common vulnerability scoring system (CVSS)) or equivalent is not accepted, if possible (section 6.10). • Concerning the risk treatment plans, the entity might additionally take into account: o findings of the review; o implementation steps; and o resources needed. • Manage any exceptions in the risk treatment plans’ implementation.

text: EXAMPLES OF EVIDENCE

text: • Documented action plans developed in response to review findings. • Key personnel knowing the main risks (e.g. evidence from emails, interviews and awareness-raising sessions). • Documented risk treatment plan implementation exceptions. • Risk register.

text: 2.2 COMPLIANCE MONITORING

text: 2.2.1. The relevant entities shall regularly review the compliance with their policies on network and information system security, topic-specific policies, rules and standards. The management bodies shall be informed of the status of network and information security on the basis of the compliance reviews by means of regular reporting.

text: GUIDANCE

text: • Develop a standardized report format for reporting to management bodies. Consider the following elements (indicative, non-exhaustive list): o key metrics, o compliance status, including policy exceptions, o identified risks and o recommended actions. • Reports are generated and presented to management bodies at least annually.

text: EXAMPLES OF EVIDENCE

text: • Recent compliance review reports.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Logs of policy exceptions. Examples of such exceptions include, among others, the situations mentioned in the second paragraph of

text: Article 2(2)

text: and those under

text: recital 5

text: of

text: the regulation

text: . Other examples include (indicative, non-exhaustive list): o software updates: if a system relies on an older version of software that is incompatible with the latest update, an exception might be granted to delay the update until a compatible solution is found; o access control: if a particular user or system cannot support an authentication mechanism (e.g. multi-factor authentication (MFA)) due to technical limitations, an exception might be granted while alternative measures are implemented; and o encryption: if a legacy system does not support encryption, an exception might be granted until the system is replaced. • Records of the exception request and approval, along with details of the compensatory controls implemented.

text: 2.2.2. The relevant entities shall put in place an effective compliance reporting system which shall be appropriate to their structures, operating environments and threat landscapes. The compliance reporting system shall be capable to provide to the management bodies an informed view of the current state of the relevant entities’ management of risks.

text: GUIDANCE

text: • Set up procedures for compliance monitoring, including (indicative, non-exhaustive list): o objectives and a high-level approach to compliance monitoring; o relevant security policies that are subject to compliance monitoring; o the frequency of compliance reviews; o who should carry out compliance reviews (internal or external); and o templates for compliance review reports. • Analyse and evaluate the results of the compliance review.

text: EXAMPLES OF EVIDENCE

text: • Documented procedures for monitoring compliance. • Documented analysis and evaluation of the results, including the current state of the entity’s risk management. • Detailed compliance monitoring plans, including long-term, high-level objectives and planning.

text: 2.2.3. The relevant entities shall perform the compliance monitoring at planned intervals and when significant incidents or significant changes to operations or risks occur.

text: GUIDANCE

text: • Compliance monitoring should take place at least annually, taking into account: o significant incidents, if any; o changes to the environment of operation; o changes to the threat landscape and cybersecurity legal and regulatory requirements; o changes to standards; and o changes to the policy on the security of network and information systems and/or topic-specific policies.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: EXAMPLES OF EVIDENCE

text: • Any corrective actions resulting from the assessments and tests, including changes to the measures made by the entity once the effectiveness of the measures has been assessed in line with the Annex to the regulation, point 7.1.1. • Evidence that reports of lessons learned or root cause analysis of past incidents, if any, were taken into account.

text: 2.3 INDEPENDENT REVIEW OF INFORMATION AND NETWORK SECURITY

text: 2.3.1. The relevant entities shall review independently their approach to managing network and information system security and its implementation including people, processes and technologies.

text: GUIDANCE

text: • Make sure that the independent review is conducted by a person or persons with the appropriate competences (indicative, non-exhaustive list): o cybersecurity technical knowledge, for example cybersecurity frameworks (ISO/IEC 27001, National Institute of Standards and Technology (NIST) cybersecurity framework, etc.), o industry knowledge, o risk assessment skills, o compliance and regulatory knowledge, for example the NIS2 Directive, the GDPR and the Digital Operational Resilience Act, o good understanding of good practices in auditing and o good understanding of when technical certification and conformance are required and must be documented in the conformance and compliance report, to ensure that global standards are implemented correctly.

text: EXAMPLES OF EVIDENCE

text: • Documented results of the review or audit. • Evidence of the competences of the independent reviewers, for example professional experience and academic qualifications, certifications such as certified information systems auditor, certified information systems security professional, certified information security manager, etc.

text: 2.3.2. The relevant entities shall develop and maintain processes to conduct independent reviews which shall be carried out by individuals with appropriate audit competence. Where the independent review is conducted by staff members of the relevant entity, the persons conducting the reviews shall not be in the line of authority of the personnel of the area under review. If the size of the relevant entities does not allow such separation of line of authority, the relevant entities shall put in place alternative measures to guarantee the impartiality of the reviews.

text: GUIDANCE

text: • Set up a process for independent review of information and network security, including (indicative and non-exhaustive list): o scope and purpose of the independent reviews (e.g. compliance, risk assessment, policy adherence); o methodology of the reviews (e.g. standardised checklist, standard based, ad hoc, how it addresses processes that will be tested in real time for conformance (e.g. cloud service) or those that will be periodically evaluated);

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o review committee’s role; o frequency of the independent reviews; o who should carry out independent reviews (internal or external); and o templates for independent review reports. • Maintain independence in line with point 2.3.2 of the Annex to the regulation; • Where appropriate, consider alternative measures to the separation of line of authority (indicative and nonexhaustive list): o review personnel rotation; o set up a review committee with members from different departments; o external third-party review service provider.

text: EXAMPLES OF EVIDENCE

text: • Documented process for independent review of information and network security. • Conflict of interest declarations. • Contracts with external third-party review service providers. • Detailed independent review plans.

text: 2.3.3. The results of the independent reviews, including the results from the compliance monitoring pursuant to point 2.2. and the monitoring and measurement pursuant to point 7, shall be reported to the management bodies. Corrective actions shall be taken or residual risk accepted according to the relevant entities’ risk acceptance criteria.

text: GUIDANCE

text: • Analyse and evaluate the results of the independent review. • Report results to management bodies. • Use a standardized report format for reporting to the management bodies. Consider the following elements (indicative, non-exhaustive list): o executive summary, including the scope and key findings, o methodology, o detailed findings, including gaps identified and non-compliance issues, o recommendations and o conclusions. • Reports are generated and presented to management bodies at least annually. • Take corrective actions or justify, accept and document residual risks. • The outcomes of independent reviews should be systematically reflected in the risk assessment results and risk treatment plans (Annex to the regulation, point 2.1). Specifically, when a risk is identified or reassessed through an independent review, the corresponding risk assessment should be updated accordingly. This ensures that the risk profile remains accurate and that any emerging or evolving risks are adequately captured and addressed in the overall risk management framework.

text: EXAMPLES OF EVIDENCE

text: • Documented analysis and evaluation of the results, including any residual risks. • Minutes from past reviews.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Any corrective actions resulting from the assessments and tests, including changes to the measures made by the entity once the effectiveness of the measures has been assessed in line with the Annex to the regulation, point 7.1.1. • Documentation of any corrective actions. • Budget approval for any corrective actions. • The most recent results of compliance monitoring and auditing. • Records from updated risk register.

text: 2.3.4. The independent reviews shall take place at planned intervals and when significant incidents or significant changes to operations or risks occur.

text: GUIDANCE

text: • Independent reviews should take place at least annually, taking into account: o significant incidents, if any; o changes to the environment of operation; o changes to the threat landscape and cybersecurity legal and regulatory requirements; and o changes to the policy on the security of network and information systems and/or topic-specific policies.

text: EXAMPLES OF EVIDENCE

text: • Independent review reports documenting findings, recommendations and actions taken in response. • Summaries of previous independent reviews, highlighting the scope and frequency. • Records of significant incidents that occurred in the past year, along with any corresponding review or analysis documentation. • Annual independent review plans or schedules that outline the scope of independent reviews and the specific measures being evaluated.

text: TIPS

text: GUIDANCE

text: • Make sure that the independent review process is approved by management bodies. • Make sure that the results of the review are approved by management bodies.

text: EXAMPLES OF EVIDENCE

text: • Documented procedures approved by management bodies. • Approval of the residual risks by management bodies.

text: Chapter 3

text: INCIDENT HANDLING

text: TECHNICAL IMPLEMENTATION GUIDANCE 3. INCIDENT HANDLING 3.1 INCIDENT HANDLING POLICY

text: 3.1.1. For the purpose of

text: Article 21(2)

text: , point (b) of

text: Directive (EU) 2022/2555

text: , the relevant entities shall establish and implement an incident handling policy laying down the roles, responsibilities and procedures for detecting, analysing, containing or responding to, recovering from, documenting and reporting of incidents in a timely manner.

text: GUIDANCE

text: • Define clear objectives for the incident handling policy. • Ensure the policy complies with relevant laws, regulations and industry standards ( ).

text: EXAMPLES OF EVIDENCE

text: • Documented incident handling policy that contains, at least, the elements referred to in point 3.1.2 of the Annex to the regulation. • Documented standards and/or good practices that are taken into consideration for this policy.

text: 3.1.2. The policy referred to in point 3.1.1 shall be coherent with the business continuity and disaster recovery plan referred to in point 4.1. The policy shall include: (a) a categorisation system for incidents that is consistent with the event assessment and classification carried out pursuant to point 3.4.1; (b) effective communication plans including for escalation and reporting; (c) assignment of roles to detect and appropriately respond to incidents to competent employees; (d) documents to be used in the course of incident detection and response such as incident response manuals, escalation charts, contact lists and templates.

text: GUIDANCE

text: • Align the incident handling policy with the business continuity and disaster recovery plan (Annex to the regulation, point 4.1) by (indicative, non-exhaustive list): o ensuring that they aim to minimise disruptions, protect assets and ensure a swift return to normal operations; o identifying interfaces between the incident handling policy and business continuity management; o describing workflows which trigger business continuity (Annex to the regulation, points 4.1, 4.2 or 4.3) during an incident; and o developing scenarios that test the interaction between these processes and describe the result of this interaction in the incident handling policy.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Set up a categorisation system for incidents, which refers to the scheme that the entity uses to identify the consequences and the priority of an incident, together with the criteria for categorising events as incidents ( ). An indicative, non-exhaustive list of criteria might include one or more of the following: o impact on business operations, o data sensitivity in accordance with risk management, o legal and regulatory impact, including reporting timelines stemming from regulatory framework e.g. GDPR, national regulations, o scope and scale meaning the evaluation of how widespread the event is, o type of attack ( ), o malicious software/vulnerability exploitation, o criticality of the systems affected, o incident containment urgency, o potential of data exfiltration or corruption, such as in the case of ransomware, o likelihood of recovery, o impact on human lives and safety and o other criteria on what constitutes a significant incident as per this regulation. • Ensure that the incident handling policy refers to different types of incidents such as (indicative, nonexhaustive list): o system failures and loss of service availability; o malicious code; o denial of service; o errors; o breaches of confidentiality and integrity; and o misuse of network and information systems. • Communicate the incident to relevant stakeholders and personnel according to a communication plan. The communication plan should consider the event reporting mechanism (Annex to the regulation, point 3.3) and may include (indicative, non-exhaustive list) the following: o purpose and scope of the plan, o roles and responsibilities for communication tasks, o list of internal and external stakeholders to be informed, o reporting timelines stemming from regulatory framework, e.g. GDPR, national regulations, o conditions and procedures for escalation of incidents, o channels to be used for communication (e.g. email, intranet, phone calls, social media, press releases), o channels of communication need to be tailored based on the target audience (that is internal, client or general public, etc.), o methods for stakeholders to provide feedback or ask questions and

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o guidelines for when to communicate and the frequency of updates, along with pre-drafted message templates for various scenarios and the core messages to be communicated. • Identify the necessary roles and responsibilities to be assigned for incident handling. The entities can use already established skills frameworks, for example the ECSF, to assist them in identifying the necessary skills and knowledge.

text: EXAMPLES OF EVIDENCE

text: • Cross references between the incident handling policy and the business continuity and disaster recovery plan, if available. • Records of testing and drills that involve both incident handling and business continuity / disaster recovery. • Interviews with key personnel involved in incident response, business continuity and disaster recovery. • An incident categorisation system. • Evidence that the incident handling policy is in place and communicated to employees. • Evidence that a communication plan for incident handling is in place. • Procedures for how to communicate the incident to relevant authorities and the computer security incident response team (CSIRT) are in place. • Procedures for how to communicate the incident to customers or how and when to involve a supplier (if applicable).

text: 3.1.3. The roles, responsibilities and procedures laid down in the policy shall be tested and reviewed and, where appropriate, updated at planned intervals and after significant incidents or significant changes to operations or risks.

text: GUIDANCE

text: • Consider one or more of the following to test the entity’s incident handling policy (indicative, nonexhaustive list): o tabletop exercise, o simulation of an incident, preferably based on a selected attack scenario based on identified risks and the current threat landscape, o red team/blue team exercise and o past incident walk-through. • Test the roles, responsibilities and procedures laid down in the policy at least annually. • Review and update roles, responsibilities and procedures laid down in the policy at least annually, taking into account the following, in addition to the elements referred to in point 3.1.3 of the Annex to the regulation: o results from the policy tests, o changes to the threat landscape and cybersecurity legal and regulatory requirements and o changes to the policy on the security of network and information systems and/or topic-specific policies.

text: EXAMPLES OF EVIDENCE

text: • Periodic simulations and awareness raising activities to assess the readiness of personnel and the adequacy of the procedures. • Incident handling policy testing plans or schedules. • Incident handling policy review plans or schedules. • Procedure updates (version history), if available.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: TIPS

text: GUIDANCE

text: • Identify and consider all internal and external resources required in the event of an incident and ensure their availability at any time: o make sure that personnel are properly trained to handle and manage incidents; o identify and consider all external stakeholders (e.g. operators, technology suppliers, free and open source ( ) project contacts, national competent authorities or CSIRTs) necessary for incident handling. • Changes in the policy should be communicated to the relevant personnel. • Ensure a clear overview of the various incident reporting obligations that the entity must fulfil under different reporting regimes.

text: EXAMPLES OF EVIDENCE

text: • Detailed procedures for the incident handling policy communicated to personnel as appropriate. • A list of reporting obligations and deadlines, which may cover both legal and contractual obligations.

text: 3.2 MONITORING AND LOGGING

text: 3.2.1. The relevant entities shall lay down procedures and use tools to monitor and log activities on their network and information systems to detect events that could be considered as incidents and respond accordingly to mitigate the impact.

text: GUIDANCE

text: • Identify one or more objectives of monitoring and logging (indicative, non-exhaustive list): o threat detection, o compliance assurance, o incident response support, o performance optimisation, o anomaly detection, o monitor for new vulnerability reports issued for any free and open source software components ( ) used by the entity, o data loss prevention, o forensic investigations support and o network health monitoring. • Procedures should describe (indicative, non-exhaustive list): o objectives, o data for collection and relevant tools, o description of data algorithms and o mechanisms for notifying the relevant personnel.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Select tools that serve the objectives of monitoring and logging according to specific criteria (indicative, non-exhaustive list): o ease of use, o integration with the existing network and information system, including cross-border operations and the associated regulatory, security and performance considerations, o minimisation of manual intervention, o capability of collecting data from various sources, for example networks, systems and applications, o security features offered, for example encryption and access control and o costs and licencing.

text: EXAMPLES OF EVIDENCE

text: • Procedures in place. • Tools in place. • Configuration settings of the logging function that serve the identified objectives. • Configuration settings of the logging function in line with documented standards and/or good practices. • Safeguards to protect the confidentiality, integrity and availability of logs.

text: 3.2.2. To the extent feasible, monitoring shall be automated and carried out either continuously or in periodic intervals, subject to business capabilities. The relevant entities shall implement their monitoring activities in a way which minimises false positives and false negatives.

text: GUIDANCE

text: • To minimise false positives and false negatives, to the extent feasible, consider one or more of the following (indicative, non-exhaustive list): o establish network traffic patterns; o use analytics and machine learning algorithms; o continuously update the automated monitoring tools to adapt to new threats and changes in the environment; and o fine-tune the parameters and thresholds based on the latest data and feedback. • Where appropriate, ensure that all potential risks are properly covered by relevant use cases, for example use case for access to critical data, use case for data exfiltration or use case for ransomware infection, so that no critical threat goes undetected.

text: EXAMPLES OF EVIDENCE

text: • Acceptable log monitoring, collection, storage and analysis tools, in line with the state of the art. • Security Incident and Event Management (SIEM) systems used to analyse data and identify deviations from established patterns. • Endpoint detection and response (EDR) and Extended Detection and Response (XDR) tools in place. • Mechanisms that aim to minimise false positives and false negatives are in place. • Where appropriate, mapping use cases to potential risks to ensure comprehensive and effective monitoring.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 3.2.3. Based on the procedures referred to in point 3.2.1., the relevant entities shall maintain, document and review logs. The relevant entities shall establish a list of assets to be subject to logging based on the results of the risk assessment carried out pursuant to point 2.1. Where appropriate, logs shall include: (a) relevant outbound and inbound network traffic; (b) creation, modification or deletion of users of the relevant entities’ network and information systems and extension of the permissions; (c) access to systems and applications; (d) authentication-related events; (e) all privileged access to systems and applications and activities performed by administrative accounts; (f) access or changes to critical configuration and backup files; (g) event logs and logs from security tools, such as antivirus, intrusion detection systems or firewalls; (h) use of system resources, as well as their performance; (i) physical access to facilities; (j) access to and use of their network equipment and devices; (k) activation, stopping and pausing of the various logs; (l) environmental events.

text: GUIDANCE

text: • With regard to critical configuration, consider the settings and parameters that are vital for the proper functioning, security and performance of the entity’s network and information system. These configurations are vital because any changes or misconfigurations might have a significant impact, including system outages, security vulnerabilities or reduced performance of the entity’s network and information system. • Consult the risk assessment results to determine which network traffic needs to be logged. For example, if certain assets are identified as high risk (e.g. due to being potentially vulnerable or crucial to the business operation) their inbound and outbound traffic should be logged for monitoring and analysis.

text: EXAMPLES OF EVIDENCE

text: • Samples of log files containing the elements referred to in point 3.2.3 of the Annex to the regulation. • Samples of log files containing current and historical domain name system (DNS) and dynamic host configuration protocol (DHCP) logs.

text: 3.2.4. The logs shall be regularly reviewed for any unusual or unwanted trends. Where appropriate, the relevant entities shall lay down appropriate values for alarm thresholds. If the laid down values for alarm threshold are exceeded, an alarm shall be triggered, where appropriate, automatically. The relevant entities shall ensure that, in case of an alarm, a qualified and appropriate response is initiated in a timely manner.

text: GUIDANCE

text: • Consider the use of anomaly detection or adaptive alarm thresholds to complement traditional static rules. • Make sure that procedures are designed to detect network-based attacks based on anomalous inbound and outbound ingress or egress traffic patterns and/or denial of service (DoS) attacks, in a timely manner.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Make sure that alarm thresholds, where appropriate, have been set in alignment with the results of the risk assessment carried out pursuant to point 2.1, covering at least the situations in point 3.2.3 of the Annex to the regulation. An indicative, non-exhaustive list of examples with thresholds ( ) follows: o relevant outbound and inbound network traffic: traffic volume spikes exceeding 50% of normal traffic in a 10-minute period on a specific port; o access to systems and applications: three or more account lockouts within 15 minutes; o privileged access: two or more instances of privilege escalation (e.g. normal user to admin) within 24 hours ( ); o antivirus: malware is detected on multiple endpoints within a short timeframe; o use of system resources: installations of unauthorised software within a short timeframe.

text: EXAMPLES OF EVIDENCE

text: • Regular reports that summarize log data and highlight any anomalies detected. • Alarm thresholds set. • Records from past alarm triggers when thresholds were exceeded. • Existing workflows that trigger event reporting (section 3.3).

text: 3.2.5. The relevant entities shall maintain and back up logs for a predefined period and shall protect them from unauthorised access or changes.

text: GUIDANCE

text: • Make sure that the log retention period is defined in accordance with business needs, the risk assessment results and legal requirements/obligations. • The backup logs’ maintenance period shouldn’t be shorter than the logs’ review period, referred to in point 3.2.4 of the Annex to the regulation. • The retention period should be in line with what is referred to in point 4.2.2 (f) of the Annex to the regulation. • Delete data when the retention period ends. • Consider mechanisms to protect logs from unauthorised access or changes (indicative, non-exhaustive list): o encryption, o access control, o hashing (section 9.2) and o logging of all access and changes to log files. • The access control should be in line with what is referred to in point 4.2.2 (d) of the Annex to the regulation.

text: EXAMPLES OF EVIDENCE

text: • A retention period is set.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • The retention period is in line with what is referred to in point 4.2.2 (f) of the Annex to the regulation and is shorter than the logs’ review period, referred to in point 3.2.4 of the Annex to the regulation. • Log management is in place. • Logs do not contain data about which retention periods have expired. • Access control mechanisms are in place. • Access control is in line with what is referred to in point 4.2.2 (d) of the Annex to the regulation.

text: 3.2.6. To the extent feasible, the relevant entities shall ensure that all systems have synchronised time sources to be able to correlate logs between systems for event assessment. The relevant entities shall establish and keep a list of all assets that are being logged and ensure that monitoring and logging systems are redundant. The availability of the monitoring and logging systems shall be monitored independent of the systems they are monitoring.

text: GUIDANCE

text: • Consider the following for time synchronisation: o Utilize Network Time Protocol (NTP) servers or Precision Time Protocol (PTP) for accurate and reliable time synchronization ( ). o Use authenticated NTP to prevent malicious entities from tampering with your time synchronization. o Configure a central time server within the entity ( ). This server should synchronize with a reliable external time source and then distribute the time to all other systems within the network. o Use multiple time sources to avoid a single point of failure. o Plan how time synchronization is handled across on-premises systems (for example servers in a company's own data centre), cloud services, and software-as-a-service (SaaS) platforms especially if the organization uses a hybrid environment (a mix of on-premises and cloud-based systems). • Assets being logged should be marked as such in the asset inventory, in line with what is referred to in point 12.4 of the Annex to the regulation. • Implement measures to protect log data against loss, including but not limited to redundant storage across multiple locations (e.g. cloud, secondary servers), retention of processed log events in structured systems and preservation of derived security insights (e.g. alerts, metrics) in line with what is referred to in point 4.2 of the Annex to the regulation. These complementary approaches ensure both data integrity and operational continuity in security monitoring and incident response. • Deploy separate tools to monitor the capacity and availability of the entity’s primary monitoring and logging systems.

text: EXAMPLES OF EVIDENCE

text: • Mechanisms for logs’ time synchronisation. • Mechanisms for logs’ redundant storage. • Logs from the activity of the tools that monitor the capacity and availability of the entity’s primary monitoring and logging systems.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 3.2.7. The procedures as well as the list of assets that are being logged shall be reviewed and, where appropriate, updated at regular intervals and after significant incidents.

text: GUIDANCE

text: • Determine the frequency of reviews based on the risk assessment results related to the criticality of the assets, ensuring that reviews are conducted at least annually. • Include the testing of monitoring and logging procedures in security testing (section 6.5). • Review a random sample of logs to verify that all the assets that should be subject to the log are actually considered.

text: EXAMPLES OF EVIDENCE

text: • Review plans or schedules.

text: TIPS

text: GUIDANCE

text: • In addition to the elements mentioned in point 3.2.3 of the Annex to the regulation, last login for every account should be logged. • Document monitoring and logging procedures. • Assess the frequency of monitoring activities to ensure they are sufficient to support risk-based security decisions for adequately protecting the entity’s network and information systems. • Make sure that personal data that are included in the logs is not processed unnecessarily. When required, an additional level of protection is deployed after performing a data protection impact assessment. • Determine the log baselines in line with the needs and the capabilities of the business (indicative, nonexhaustive list): o structured or semi-structured, if possible, instead of unstructured format; o consistent data format in line with the selected tools and well-known standards, for example JavaScript Object Notation and extensible markup language (XML); o log level in line with the classification level of the asset being logged – the entity should assign a higher log level, for example ‘error’/‘fatal’, to highly classified assets while the lower log levels, for example ‘info’/‘debug’, should be used for assets with a lower classification; and 26 27 28 o the standard for the timestamps, for example ISO-8601 ( ), RFC 3339 ( ) or RFC 9557 ( ). • Each log entry should contain necessary metadata such as (indicative, non-exhaustive list): o log level; o timestamp; o source identifier, for example the application or the device relevant to the entry; and o a unique identifier for the entry. • Correlate data from different sources, if applicable. • Select tools that monitor and protect end point devices. • Select tools that can collect and analyse network traffic in real time to detect anomalies, data exfiltration and even the most advanced threats, while offering the option of automatic remediation.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: EXAMPLES OF EVIDENCE

text: • Documented procedures. • Log baselines in place. • Logs (samples) containing necessary metadata. • EDR tools. • Network detection and response (NDR) tools.

text: 3.3 EVENT REPORTING

text: 3.3.1. The relevant entities shall put in place a simple mechanism allowing their employees, suppliers and customers to report suspicious events.

text: GUIDANCE

text: • Define what constitutes a suspicious event based on criteria (indicative, non-exhaustive list): o if the confidentiality or the integrity or the availability of the network or the information system has been affected; o persistence, meaning whether the event is ongoing or not; o impact, for example. the number of assets (potentially) affected; and o compliance violation of a regulation or the entity’s policies. • Develop clear and concise guidelines for what information should be included in a report. Align this information with the information that might be submitted to the CSIRT or, where applicable to the competent authority, if the event is notified in accordance with the NIS2 Directive Articles

text: or

text: . As good practice, the following should be reported as a minimum (indicative, non-exhaustive list): o date and time of the event, o description of the event, o any relevant screenshots, logs or other evidence, o contact information for follow-up if necessary. • Provide multiple channels for reporting, such as email, a web form, a dedicated phone line or a mobile app. Ensure that these channels are easily accessible and intuitive to use.

text: EXAMPLES OF EVIDENCE

text: • Documented mechanism that outlines the process for reporting security events. • Examples of templates for reporting ( ). • Personnel aware of the mechanism and who to contact if they notice something suspicious. • Existence of multiple reporting channels such as email addresses, web forms, phone numbers or dedicated reporting portals.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 3.3.2. The relevant entities shall, where appropriate, communicate the event reporting mechanism to their suppliers and customers and shall regularly train their employees how to use the mechanism.

text: GUIDANCE

text: • Make appropriate means for reporting available to personnel and the entity’s suppliers and customers. • Consider anonymous reporting to encourage individuals to report security events without fear of reprisal. • Take into account legal obligations to report an incident to the competent authorities (and CSIRTs) in line with the NIS2 Directive Articles

text: and

text: , including any obligations about when the incident should be reported. • Regularly remind stakeholders of the reporting mechanism through email newsletters, posters and other communication channels. • Conduct regular exercises or simulations to test the effectiveness of the reporting mechanism.

text: EXAMPLES OF EVIDENCE

text: • Evidence of past communications and event reporting. • Documented procedures for communicating about events, describing (indicative, non-exhaustive list: o reasons/motivations for communicating or reporting (business reasons and legal reasons, etc.), o the type of events in scope, o the required content of communications, o notifications or reports, o the channels to be used and o the roles responsible for communicating, notifying and reporting. • Training materials provided to employees, suppliers and customers regarding the reporting mechanism. • Periodic simulations and awareness raising activities to assess the readiness of personnel and the adequacy of the mechanism for reporting an event.

text: TIPS

text: GUIDANCE

text: • Maintain a record of all reported events. • Ensure compliance with other relevant regulations and laws regarding data privacy, confidentiality and incident reporting. • Ask for legal advice, if necessary, to understand any legal implications of the reporting mechanism. • Evaluate past communications and reporting about events. • Review and update the reporting mechanism and the communication plans (Annex to the regulation, point 3.3), based on changes or past events.

text: EXAMPLES OF EVIDENCE

text: • Record of events and, for each event, the impact, cause, actions taken and lessons learnt. • Summaries of previous reviews, if any.

text: TECHNICAL IMPLEMENTATION GUIDANCE 3.4 EVENT ASSESSMENT AND CLASSIFICATION

text: 3.4.1. The relevant entities shall assess suspicious events to determine whether they constitute incidents and, if so, determine their nature and severity.

text: GUIDANCE

text: • Use criteria to assess whether a suspicious event is an incident or not. The guidance in section 3.1.2 provides an indicative, non-exhaustive list of such criteria. • Determine the nature and severity of the event based on a categorisation system referred to in point 3.1.2 (a) of the Annex to the regulation.

text: EXAMPLES OF EVIDENCE

text: • Defined criteria in place. • A categorisation system referred to in point 3.1.2 (a) of the Annex to the regulation.

text: 3.4.2. For the purpose of point 3.4.1, the relevant entities shall act in the following manner: (a) carry out the assessment based on predefined criteria laid down in advance and on a triage to determine prioritisation of incident containment and eradication; (b) assess the existence of recurring incidents as referred to in Article 4 of this Regulation on a quarterly basis; (c) review the appropriate logs for the purposes of event assessment and classification; (d) put in place a process for log correlation and analysis and (e) reassess and reclassify events in case of new information becoming available or after analysis of previously available information.

text: GUIDANCE

text: • In the procedures defined in points 3.1.1 and 3.1.2 of the Annex to the regulation, include activities for assessing suspicious events to determine their nature and severity. These activities should include steps such as: o gathering relevant information and evidence related to the event. o analysing the potential impact on the entity’s systems, data and operations. o determining the severity of the incident based on predefined criteria. • Implement playbooks ( ) or runbooks to guide initial assessment actions for common types of incidents, for example ransomware, phishing, data or device loss, or fire. • Classify events based on their nature, severity and potential impact. Common classifications may include: o low, medium, high or critical severity; o incident types (e.g. malicious software infection or unauthorized access); o regulatory or compliance implications. • Prioritise the event according to specific criteria, as defined in the categorisation system included in the incident handling policy referred to in point 3.1.2 of the Annex to the regulation. 31 32 • By performing root cause analysis ( ), determine recurring instances ( ) of an incident.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o Consider that the root cause of an incident may be challenging to determine during the early stages of incident handling, so the assessment of the existence of recurring incidents may be delayed. • Review and correlate the logs in line with what is referred to in point 3.2 of the Annex to the regulation. • Assess past events and their classification to improve processes, procedures and thresholds.

text: EXAMPLES OF EVIDENCE

text: • Documented procedures or guidelines related to event assessment, including steps for gathering information, analysing impact and determining severity. • Existence of documented criteria or guidelines for prioritizing events based on severity and potential impact. • Existence of a process for triaging incoming alerts or reports of suspicious events. • Playbooks for common types of incidents. • Periodic reviews of assessment and classification of past events to improve processes, procedures and thresholds.

text: TIPS

text: GUIDANCE

text: • Consider deploying SIEM, EDR, XDR or similar system that will allow and facilitate the correlation and analysis of data. • Where possible, utilise automation to triage incoming alerts and prioritise them based on severity and potential impact. • Integrate security events into the central SIEM or EDR/XDR solution, where available. • Take into account the confidentiality of the data stored, especially when correlating and analysing log files, by (indicative, non-exhaustive list): o minimising data collected, meaning only collecting and analysing logs that fit the purpose – avoid retaining unnecessary personal or sensitive data; o anonymising or pseudonymising the collected data, when possible; o applying good security practices where appropriate and relevant, such as access control, encryption, regular audits and monitoring; o applying the data retention policy in alignment with GDPR requirements and regularly purging data that is no longer needed; and o considering data protection and relevant legal and compliance obligations other than the NIS2 Directive.

text: EXAMPLES OF EVIDENCE

text: • SIEM, EDR/XDR or similar system. • Tools supporting incident triage. • Measures to protect the security of information during log analysis and correlation.

text: TECHNICAL IMPLEMENTATION GUIDANCE 3.5 INCIDENT RESPONSE

text: 3.5.1. The relevant entities shall respond to incidents in accordance with documented procedures and in a timely manner.

text: GUIDANCE

text: • Establish a dedicated incident response team comprising employees with the necessary technical expertise and authority to respond effectively to incidents, where appropriate. • Define roles and responsibilities within the incident response team, such as incident coordinators, analysts and communication liaisons, where appropriate. • Take into account industry-recognised standards when developing the incident response procedures ( ). • Implement playbooks or runbooks to guide incident response actions for common types of incidents.

text: EXAMPLES OF EVIDENCE

text: • Assignment of roles within the incident response team. • Documented standards and/or good practices that are taken into account. • Playbooks or incident response plans for common types of incidents.

text: 3.5.2. The incident response procedures shall include the following stages: (a) incident containment, to prevent the consequences of the incident from spreading; (b) eradication, to prevent the incident from continuing or reappearing, (c) recovery from the incident, where necessary.

text: GUIDANCE

text: • Create incident response procedures outlining the steps referred to in point 3.5.2 of the Annex to the regulation. • Ensure that the handling of cybersecurity incidents takes into account the entity’s priorities and the impact of the incident. o Recognize and address potential conflicts between the following objectives during incident handling:  forensic activities – preserving and securing evidence for legal, compliance or investigative purposes,  incident response activities – mitigating and removing current threats to prevent further damage and  operational continuity – minimizing disruption to IT services and maintaining critical operations. o Where these objectives conflict, establish a clear decision-making process that:  prioritises based on the accepted risk tolerance levels, business impact and legal obligations,

text: TECHNICAL IMPLEMENTATION GUIDANCE

text:  involves coordination between cybersecurity, legal/compliance and operational teams and  documents the rationale for prioritisation decisions to ensure transparency and accountability. o Develop incident response playbooks that incorporate decision making and escalation paths for managing trade-offs between evidence preservation, threat containment and operational continuity. • Keep the management bodies informed.

text: EXAMPLES OF EVIDENCE

text: • Procedures for incident response, including types of incidents that could occur, objectives, roles and responsibilities. Detailed description, for each incident type, of how to manage the incident and when to escalate to management bodies (e.g. chief information security officer), etc. • Records from resolution of conflicting objectives during response to past incidents.

text: 3.5.3. The relevant entities shall establish communication plans and procedures: (a) with the Computer Security Incident Response Teams (CSIRTs) or, where applicable, the competent authorities, related to incident notification; (b) with relevant internal and external stakeholders.

text: GUIDANCE

text: • Ensure that the communication plan (Annex to the regulation, point 3.1.2) includes procedures for how to communicate the incident to the relevant authorities, the national CSIRT and internal and external stakeholders, including, where applicable, customers, direct suppliers, service providers and, if open source is used, contacts for free and open source software projects. • Include contact information for key personnel, external stakeholders and relevant authorities.

text: EXAMPLES OF EVIDENCE

text: • Procedures for how to communicate the incident to the relevant authorities and the CSIRT. • Procedures for how to communicate the incident to customers or how and when to involve a supplier (if applicable).

text: 3.5.4. The relevant entities shall log incident response activities in accordance with the procedures referred to in point 3.2.1. and record evidence.

text: GUIDANCE

text: • Log incident response information which contains (indicative, non-exhaustive list): o time of detection, containment and eradication; o when the systems recovered; o indicators of compromise; o root cause; o actions taken during each phase namely, detection, containment and eradication; o assessment of the scope and the level of impact of the incident; o communications when responding to the incident;

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o post incident lessons learnt and recommendations; and o whether the CSIRT or the competent authority was notified of the incident according to the NIS2 Directive Articles

text: and

text: EXAMPLES OF EVIDENCE

text: • Logs from incident response. • Use of a system (e.g. SIEM, EDR/XDR or ticket system).

text: 3.5.5. The relevant entities shall test at planned intervals their incident response procedures.

text: GUIDANCE

text: • Test the entity’s incident response procedures at least annually. • Test different types of incidents, for example ransomware, phishing, data breach and DoS. • Ensure that test scenarios involve employees from different departments as well as external stakeholders, for example suppliers and service providers. o Where necessary, include management bodies in the tests so that they understand their role during an incident. • Conduct post-test reviews for possible lessons learnt. • Update the incident response procedures based on the lessons learnt from the test, if applicable.

text: EXAMPLES OF EVIDENCE

text: • Documented plans or schedules for future incident response tests. • Records from tests of different types of incidents.

text: TIPS

text: GUIDANCE

text: • Issue instructions on how to respond to the most common types of incidents (ransomware, phishing, data breach, DoS, etc.) including containment, eradication and recovery steps. • Include guidelines for preserving evidence and maintaining chain of custody to support forensic analysis and legal proceedings if necessary. • Consider the use of automated solutions for incident response, for example security orchestration, automation and response technologies or similar systems.

text: EXAMPLES OF EVIDENCE

text: • Up-to-date incident response procedures based on tests conducted and/or change logs.

text: TECHNICAL IMPLEMENTATION GUIDANCE 3.6 POST-INCIDENT REVIEWS

text: 3.6.1. Where appropriate, the relevant entities shall carry out post-incident reviews after recovery from incidents. The post-incident reviews shall identify, where possible, the root cause of the incident and result in documented lessons learned to reduce the occurrence and consequences of future incidents.

text: GUIDANCE

text: • Conduct root cause analysis ( ) and identify the root cause of the incident, where possible. • Identify contributing factors and areas for improvement in incident detection, response and recovery processes. • Investigate significant incidents and write final incident reports, including actions taken and recommendations to mitigate future occurrence of this type of incident. • Document lessons learnt, accompanied by recommendations and their owners, based on logs from incident response referred to in point 3.5.4 of the Annex to the regulation. • Share any relevant findings in the post-incident review with affected stakeholders, for example suppliers, service providers, free and open source component maintainers.

text: EXAMPLES OF EVIDENCE

text: • Results of root cause analysis. • Individual reports of the handling of significant incidents. • Documented lessons learnt from incidents.

text: 3.6.2. The relevant entities shall ensure that post-incident reviews contribute to improving their approach to network and information security, to risk treatment measures and to incident handling, detection and response procedures.

text: GUIDANCE

text: • Analyse the post-incident review findings to identify gaps and weaknesses in the entity’s network and information security status. • Make sure that the identified gaps and weaknesses feed back to the risk assessment and risk treatment plan (Annex to the regulation, point 2.1). • Assess whether existing risk treatment measures were effective in preventing or mitigating the incident. • Document the findings and lessons learnt from each post-incident review comprehensively. • Consider whether information security requirements have been met throughout the handling of a cybersecurity incident or whether measures may need to be taken to restore them (e.g. resetting passwords for emergency administrative access).

text: EXAMPLES OF EVIDENCE

text: • Post-incident review reports that detail findings, lessons learnt and recommendations for improvement following security incidents. • Analysis, resolution and mitigation measures taken, communicated to all relevant personnel. • Updated risk assessment and risk treatment plan, which includes findings of the post-incident reviews.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 3.6.3. The relevant entities shall review at planned intervals if incidents led to post-incident reviews.

text: GUIDANCE

text: • Conduct an annual review or a review after significant incidents, to determine if an incident has led to a post-incident review.

text: EXAMPLES OF EVIDENCE

text: • Documented plans or schedules for future reviews.

text: TIPS

text: GUIDANCE

text: • Determine the composition of the review team, including members from relevant departments such as IT, security, legal and management bodies. • Review existing network and information security policies, topic-specific policies relevant to the incident, incident handling procedures and policy and incident response procedures in light of the lessons learnt from post-incident reviews.

text: EXAMPLES OF EVIDENCE

text: • Minutes of the post-incident review team. • Evidence of updates to network and information security or topic-specific policies and procedures based on the lessons learnt from post-incident reviews.

text: Chapter 4

text: BUSINESS CONTINUITY

text: AND

text: CRISIS MANAGEMENT

text: TECHNICAL IMPLEMENTATION GUIDANCE 4. BUSINESS CONTINUITY AND CRISIS MANAGEMENT 4.1 BUSINESS CONTINUITY AND DISASTER RECOVERY PLAN

text: 4.1.1. For the purpose of

text: Article 21(2)

text: , point (c) of

text: Directive (EU) 2022/2555

text: , the relevant entities shall lay down and maintain a business continuity and disaster recovery plan to apply in the case of incidents.

text: GUIDANCE

text: • Take into account industry-recognised standards when developing the business continuity ( ) and disaster recovery plan. • Create a list of natural disasters (e.g. hurricane, fire, flooding) and other occurrences (e.g. human error) that could affect the services together with a list of disaster recovery capabilities (e.g. backups, tests, recovery objectives, etc.).

text: EXAMPLES OF EVIDENCE

text: • Business continuity plan. • Disaster recovery plan. • Business continuity and disaster recovery plans are in line with documented standards and/or good practices. • List of natural and/or major disasters that could affect the services and a list of disaster recovery capabilities (either those available internally or provided by third parties).

text: 4.1.2. The relevant entities’ operations shall be restored according to the business continuity and disaster recovery plan. The plan shall be based on the results of the risk assessment carried out pursuant to point 2.1 and shall include, where appropriate, the following: (a) purpose, scope and audience; (b) roles and responsibilities; (c) key contacts and (internal and external) communication channels; (d) conditions for plan activation and deactivation; (e) order of recovery for operations; (f) recovery plans for specific operations, including recovery objectives; (g) required resources, including backups and redundancies; (h) restoring and resuming activities from temporary measures.

text: GUIDANCE

text: • Keep logs of activation and execution of the business continuity plan, including:

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o decisions taken; o steps followed; and o final recovery time. • Determine the order of recovery based on criteria, including (indicative, non-exhaustive list): o the asset classification level; o the importance of the service for the entity; o dependencies (services or assets that are essential for others are restored first); o recovery objectives (Annex to the regulation, point 4.1.3); o resource availability; and o regulatory requirements. • Conduct capacity planning so that necessary capacity for information processing, telecommunications and environmental support exists after business continuity plan activation. • Consider primary and alternate telecommunications service providers, section 13.1, to properly maintain disaster recovery plans (for the services provided). o For remote work, employees handling critical operations should:  have access to backup internet solutions (e.g. mobile broadband, tethering capabilities) and  participate in regular testing of failover options, including VPN access and voice communications (e.g. VoIP or cloud telephony) over backup networks. • Prepare for recovery and restoration of services after a disaster by identifying measures such as: o failover sites in other regions; o backups of data with high criticality to remote locations; and o tested restore procedures with regular validation cycles. • Make sure that third party services (e.g. hot site) will be available in case of disaster, where appropriate. • Implement advanced measures for disaster recovery capabilities, where appropriate, for example: o full redundancy; o failover mechanisms; and o alternative site.

text: EXAMPLES OF EVIDENCE

text: • Measures in place for dealing with disasters, such as failover sites in other regions and backups of data to remote locations. • Up-to-date organisational structures widely communicated. • Inventory of sectors and services essential for and/or dependent on the continuity of the network and service operation, and contingency plans for mitigating the impact related to dependent and interdependent sectors and services.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 4.1.3. The relevant entities shall carry out a business impact analysis to assess the potential impact of severe disruptions to their business operations and shall, based on the results of the business impact analysis, establish continuity requirements for the network and information systems.

text: GUIDANCE

text: • Based on the results of the BIA ( ) and risk assessment, the entity should establish appropriate recovery objectives, referred to in point 4.1.2 (f) of the Annex to the regulation (indicative, non-exhaustive list): o Recovery time objectives (RTOs) to determine the maximum amount of time allowed for the recovery of business resources and functions (e.g. information and communications technology (ICT) systems and processes, respectively) after a disaster occurs, for example maximum downtime of the entity’s website, enterprise resource planning (ERP) system or email system. o Recovery point objective (RPO) to determine how much data it is acceptable for specific ICT activities or applications to lose. Typically, they are measured in maximum time needed to recover data without causing unacceptable, according to the risk assessment, damage to the entity’s activities, for example maximum recovery time for an e-commerce website, an ERP system or an email server. o Service delivery objective (SDO) to determine the minimum level of performance that needs to be reached by business functions during the alternate processing mode. An indicative and nonexhaustive list of examples includes:  the percentage of inbound calls to be answered by a call centre within a specific timeframe;  the level of availability of ordering and payment systems of an e-commerce website within a specific timeframe;  the restoration time for accessing essential shared folders via a cloud file access system; and  the timeframe within which the full functionality of the remote work infrastructure is restored. o Maximum acceptable outage (MAO) or maximum tolerable period of disruption (MTPD) to determine the time it would take for the potential impacts of not providing a product/service or performing an activity to become unacceptable or significant, in accordance with the risk assessment. Typically they are longer than RTOs. MAOs focus on service availability while RPOs focus on data loss. An indicative and non-exhaustive list of examples:  the period of time beyond which the customer service would be severely impacted and reputation risk increases quickly;  the longest period of time that extended outage of an e-commerce website might result to major loss of sales and customer trust;  the longest period of time that shared access to project files may halt collaboration or decision-making in case that data is stored in cloud; and  the maximum acceptable outage for remote work infrastructure beyond which business functions are significantly impaired and productivity losses begin to escalate. • RTOs, RPOs and SDOs may be used to determine backup and redundancy procedures.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Document disaster recovery plan, taking into account: o the RTOs, RPOs and SDOs; and o compliance with applicable regulations and legislation.

text: EXAMPLES OF EVIDENCE

text: • Documented BIA with specific recovery objectives. • Processes, procedures and measures to ensure the required level of continuity in disruptive situations.

text: 4.1.4. The business continuity plan and disaster recovery plan shall be tested, reviewed and, where appropriate, updated at planned intervals and following significant incidents or significant changes to operations or risks. The relevant entities shall ensure that the plans incorporate lessons learnt from such tests.

text: GUIDANCE

text: • Test, review and, if necessary, update the business continuity and disaster recovery plans at least annually. • Choose and combine method(s) to test the business continuity and disaster recovery plans, such as: o alternative locations for personnel; o disaster recovery locations – hot sites; o digital twins; o simulations; o table top exercises. • Test business continuity and disaster recovery plans regularly, taking into account: o change logs; o past incidents; and o results of previous tests. • Where appropriate, test the disaster recovery plan at an alternate processing site to: o familiarize related personnel with the facility and available resources; and o evaluate the capabilities of the alternate processing site to support operations. • Test data centre infrastructure for: o availability; o auto failover; o power failover between power providers and/or power provider to backup (for example generators or batteries); and o resilience to maintain service to customers. • Define full recovery and reconstitution of the information system to a known state as part of the disaster recovery plan testing. • Update business continuity and disaster recovery plans and related measures based on: o change logs; o past incidents; o documented results of the continuity of operations test activities; and o records of individual training activities. • Review change logs and documented results from past tests on business continuity and disaster recovery plans to ensure that the plans incorporate lessons learnt from such tests. • Review and, if necessary, update roles and responsibilities.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Review dependent third parties’ disaster recovery plans to ensure that the plans meet entity’s business continuity requirements. • Communicate changes to business continuity and disaster recovery plans to related key personnel.

text: EXAMPLES OF EVIDENCE

text: • Documented plans or schedules for future tests. • Records from previous tests, reviews and possible updates. • Logs of activation and execution of business continuity and disaster recovery plans, including decisions taken, steps followed and final recovery time. • Communications, for example emails, documents and intranet announcements, concerning changes to the business continuity and disaster recovery plans. • Evidences that lessons learnt from past tests are incorporated into the plans, for example workflow changes and updated plans.

text: TIPS

text: GUIDANCE

text: • In addition to the elements referred to in point 4.1.2 of the Annex to the regulation, the business continuity plan might address: o management commitment; o coordination among organisational units; o communication plan; o compliance with laws; o metrics for measuring the successful implementation of the plan. • Protect the business continuity and disaster recovery plans from unauthorized disclosure and modification. • Ensure that business continuity and disaster recovery plans are easily accessible during a system outage. An indicative, non-exhaustive list of options to achieve this: o physical copies; o cloud storage; o external drives; o mobile access. • Distribute copies of the business continuity plan to the related key personnel. • Monitor the activation and execution of the business continuity plan registering successful and failed recovery times. • Add a reference or a description / connection with the incident handling policy, plan and procedures into the business continuity plan. • Coordinate the business continuity plan with the respective plans of external service providers to ensure that continuity requirements are satisfied • Train key personnel involved in continuity operations. • Set up procedures in regard to the appropriate communication channels with the (inter)national competent authorities, including disaster management organisations and disaster-relief teams. • Regularly train the responsible personnel in disaster recovery operations. • Implement contingency plans for systems based on scenarios.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Monitor the activation and execution of contingency plans, registering successful and failed RTOs, RPOs and SDOs. • Implement contingency plans for high criticality dependent and inter-dependent sectors and services.

text: EXAMPLES OF EVIDENCE

text: • Measures, for example encryption and access control, for protecting business continuity and disaster recovery plans from unauthorized disclosure and modification. • Up-to-date organisational structures widely communicated. • Decision process for activating contingency plans. • Contingency plans for systems, including clear steps and procedures for common threats, triggers for activation, steps and defined RTOs, RPOs and SDOs. • Logs of activation and execution of contingency plans, including decisions taken, steps followed and final recovery time.

text: 4.2 BACKUP AND REDUNDANCY MANAGEMENT

text: 4.2.1. The relevant entities shall maintain backup copies of data and provide sufficient available resources, including facilities, network and information systems and staff, to ensure an appropriate level of redundancy.

text: GUIDANCE

text: • Consider whether to invest in own redundancy or to engage third parties, for example cloud providers, to provide such redundancy, in alignment with the BIA (Annex to the regulation, point 4.1.3).

text: EXAMPLES OF EVIDENCE

text: • Backups are physically separated from the systems that generated them. • If the service is offered by a third party, SLAs.

text: 4.2.2. Based on the results of the risk assessment carried out pursuant to point 2.1 and the business continuity plan, the relevant entities shall lay down backup plans which include the following: (a) recovery times; (b) assurance that backup copies are complete and accurate, including configuration data and data stored in cloud computing service environment; (c) storing backup copies (online or offline) in a safe location or locations, which are not in the same network as the system and are at sufficient distance to escape any damage from a disaster at the main site; (d) appropriate physical and logical access controls to backup copies, in accordance with the asset classification level; (e) restoring data from backup copies; (f) retention periods based on business and regulatory requirements.

text: GUIDANCE

text: • Recovery times should not exceed the recovery objectives referred to in 4.1.2 (f) of the Annex to the regulation. • Concerning retention periods consider what is referred to in point 3.2.5 of the Annex to the regulation. • If an entity engages third parties to ensure an appropriate level of redundancy, it should be clearly decided whether it is the entity's responsibility to compile the backup plans or if the third parties have any involvement in the process.

text: EXAMPLES OF EVIDENCE

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Backup plans. • Logs from backup software that show regular backups are being performed. • Backups physically separated and with an appropriate level of protection, including encryption. • Logs or reports confirming that one copy of the backup is stored off-site, such as in a cloud storage service or a remote data centre. • Configuration settings of backup software to verify that it is set up to create copies of data and store them on different media. • Clear and concise restoration procedures that cover all relevant systems and services. • If applicable, settings of the cloud storage service to ensure it is configured to receive and store backup copies.

text: 4.2.3. The relevant entities shall perform regular integrity checks on the backup copies.

text: GUIDANCE

text: • Check the integrity of the backup copies. An indicative, non-exhaustive list of good practices is the following: o use checksums or hashing algorithms to verify that the data in your backups matches the original data (section 9.2); o implement automated scripts to run these checks regularly, reducing the risk of human error; o schedule regular tests to restore data from backups to ensure they are complete, functional and validated by business users to confirm the accuracy and usability of the restored data; o test various recovery scenarios, including full system restores and individual file recoveries, to ensure all aspects of your backup system are reliable; and o consider using cloud storage solutions for off-site backups, which often include built-in integrity checks and redundancy.

text: EXAMPLES OF EVIDENCE

text: • Logs or reports showing that checksum or hashing algorithms are used. • Settings in backup software or scripts that specify the use of checksums or hashing algorithms. • Records of regular tests in which data is restored from backups. • Evidence of tests of different recovery scenarios, including full system restores and individual file recoveries. • Logs or reports from actual incidents in which recovery procedures were implemented (Annex to the regulation, points 3.2 and 3.5). • If the service is offered by a third party, SLAs.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 4.2.4. Based on the results of the risk assessment carried out pursuant to point 2.1 and the business continuity plan, the relevant entities shall ensure sufficient availability of resources by at least partial redundancy of the following: (a) network and information systems; (b) assets, including facilities, equipment and supplies; (c) personnel with the necessary responsibility, authority and competence; (d) appropriate communication channels.

text: GUIDANCE

text: • Define minimum resources needed to ensure at least partial redundancy for each of points (a), (b), (c) and (d). These may include the following: o network and information systems: one or more of the following (indicative, non-exhaustive list):  multiple internet service providers,  load balancing,  mirrored servers,  virtualisation,  redundant array of independent disks; o assets: one or more of the following (indicative, non-exhaustive list):  shared workspaces,  backup locations,  spare equipment,  multiple suppliers for the same categories of products; o personnel: one or more of the following (indicative, non-exhaustive list):  job rotation,  backup assignments,  emergency drills; o multiple communication platforms, for example social media, messaging apps and email; and o multiple methods to power a site, either through multiple electrical providers or with a combination of electrical providers and backup mechanisms, such as generators.

text: EXAMPLES OF EVIDENCE

text: • One or more of the above mechanisms are in place.

text: 4.2.5. Where appropriate, the relevant entities shall ensure that monitoring and adjustment of resources, including facilities, systems and personnel, is duly informed by backup and redundancy requirements.

text: GUIDANCE

text: • Decisions about resource allocation and adjustments should be guided by the need for backups and redundancy. To this end, the entity might consider one or more of the following (indicative, non-exhaustive list): o prioritisation of resources based on the results of the risk analysis; o partial redundancy; o diverse backup locations; and o continuous monitoring of the resources where redundancy is necessary.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: EXAMPLES OF EVIDENCE

text: • Evidence of elements referred to in point 4.2.4 of the Annex to the regulation. • Evidence from periodic simulations and awareness raising activities to assess the readiness of personnel and the adequacy of the procedures.

text: 4.2.6. The relevant entities shall carry out regular testing of the recovery of backup copies and redundancies to ensure that, in recovery conditions, they can be relied upon and cover the copies, processes and knowledge to perform an effective recovery. The relevant entities shall document the results of the tests and, where needed, take corrective action.

text: GUIDANCE

text: • Tailor the frequency of the backup checks to the data criticality based on the risk assessment (section 2.1). As an example: o Data with high criticality might be checked on a weekly basis. o Data with moderate and low criticality might be checked on a monthly basis. o Significant changes should be checked immediately after the change. • Make sure that the issues and lessons learnt from exercises are addressed by the responsible people and that the relevant processes and systems are updated accordingly. • Involve suppliers and other third parties, such as business partners or customers in tests.

text: EXAMPLES OF EVIDENCE

text: • Reports/logs of regular testing of backup status, processes and procedures. • Test programme for backup plans, including types of contingencies, frequency, roles and responsibilities, templates and procedures for conducting tests, and templates for post-test reports. • Reports of past tests of backup and contingency plans. • Reports about tests and drills showing the execution of the plans, including evidence that recovery times were met and lessons learnt from the tests. • Issues and lessons learnt from past tests addressed by the responsible people. • Updated test plans, review comments and/or change logs. • Input from suppliers and other third parties involved about how to improve test scenarios.

text: TIPS

text: GUIDANCE

text: • Protect backup and restoration hardware and software. • Ensure that encrypted backups remain accessible by securely maintaining the associated encryption keys. Encryption keys should be stored separately from the backup data to prevent unauthorized access and ensure recoverability. • Before systems or configurations are restored, a ‘patient zero ( )’ may need to be identified so that the restoration does not restore any vulnerabilities or infections that have sometimes been cleaned up.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Consider the 3-2-1 backup rule: o keep three copies of the data (the original plus two backups), o on two different types of storage media (e.g. hard drives, cloud storage), o with one copy stored offsite. • Ensure the integrity of backups, that is, prevent any modification or deletion, such as ransomware encryption or tampering, within a defined retention period. Ways to ensure this include (indicative, nonexhaustive list): o malware and ransomware scanning of backups before backups are stored; o use of immutable backups; o offline storage of backups. • Integrate business continuity and disaster recovery plans with incident response (Annex to the regulation, point 3.5) and crisis management processes (Annex to the regulation, point 4.3). • When available cloud services: o backups will be replicated across multiple availability zones or stored in an alternate region to ensure resilience against zone-level failures; o will be configured with cross-zone replication to minimise downtime; o all backup data will be encrypted at rest using cloud-native key management systems and encrypted during transfer using TLS 1.2+; o regular backup testing will be performed to validate cross-zone recovery capabilities.

text: EXAMPLES OF EVIDENCE

text: • Measures in place to protect backup and restoration hardware and software, for example physical access controls, surveillance systems, encryption, integrity checks and failover mechanisms. • Review of the backup plan which mentions the 3-2-1 rule. • Logs from backup software that show regular backups are being performed. • Configuration settings of backup software to verify that it is set up to create three copies of data and store them on different media. • If applicable, settings of the cloud storage service ensuring it is configured to receive and store backup copies.

text: 4.3 CRISIS MANAGEMENT

text: 4.3.1. The relevant entities shall put in place a process for crisis management.

text: GUIDANCE

text: • Take into account industry-recognised standards when developing the crisis management process ( ). o Be aware that each crisis may be different and further analysis may be required on an ad hoc basis. o Consider the various aspects (e.g. technical, operational, communication and remediation) of crisis management, including processes, roles and responsibilities.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Because the escalation of an incident to crisis status depends on an entity’s risk appetite and incident handling capabilities, the entity should define criteria on when a crisis is declared ( ). This may refer to incidents that cause serious impact, beyond a certain threshold of tolerance. These criteria may include the following (indicative and non-exhaustive list): o the incident poses significant risk to critical assets or operations with high criticality, for example high-severity incidents (e.g. data breaches involving sensitive information); o the incident disrupts business operations significantly, for example prolonged downtime, widespread loss of services or significant impact on customer service; o the breadth of the incident, that is, whether it affects multiple systems, departments or geographic locations, indicating a wider threat; o the potential impact on the entity’s reputation – incidents that could lead to public scrutiny or loss of customer trust should be escalated; o the potential impact of the cybersecurity incident on the confidentiality, integrity, authenticity and availability of data; o the sophistication and motivations of the threat actors involved. Incidents linked to advanced persistent threats or organised cybercrime may require a higher-level response, beyond the capabilities of the entity; o the potential to escalate further (e.g. if vulnerabilities could be exploited again or if malware is spreading).

text: EXAMPLES OF EVIDENCE

text: • Crisis management process is in line with documented standards and/or good practices.

text: 4.3.2. The relevant entities shall ensure that the crisis management process addresses at least the following elements: (a) roles and responsibilities for personnel and, where appropriate, suppliers and service providers, specifying the allocation of roles in crisis situations, including specific steps to follow; (b) appropriate communication means between the relevant entities and relevant competent authorities; (c) application of appropriate measures to ensure the maintenance of network and information system security in crisis situations. For the purpose of point (b), the flow of information between the relevant entities and relevant competent authorities shall include both obligatory communications, such as incident reports and related timelines and non-obligatory communications.

text: GUIDANCE

text: • For crisis communication, consider (indicative, non-exhaustive list): o legal obligations for communication, such as timing of communication, in particular referring to requirements for notification; o how information will be disseminated to internal and external stakeholders (employees, customers, direct suppliers and service providers, emergency services, etc.) during a crisis; o templates for communication; o communication channels to be used for each type of stakeholder, considering that:

text: TECHNICAL IMPLEMENTATION GUIDANCE

text:  internal and external stakeholders may use different communication channels;  normal communication channels might not be safe in crisis mode;  channels used to notify and communicate with competent authorities should also be indicated; o up-to-date contact information for internal and external stakeholders.

text: EXAMPLES OF EVIDENCE

text: • Documented crisis management process. • List of members of the crisis management team, including their roles, contact information and alternatives.

text: 4.3.3. The relevant entities shall implement a process for managing and making use of information received from the CSIRTs or, where applicable, the competent authorities, concerning incidents, vulnerabilities, threats or possible mitigation measures.

text: GUIDANCE

text: • Implement a process for managing and making use of information received from the CSIRTs. Consider the following steps (indicative, non-exhaustive list): o designate a point of contact with the CSIRT; o ensure that the point of contact has sufficient knowledge concerning incidents and threat intelligence. o classify incoming information into categories such as incidents, vulnerabilities, threats and mitigation measures. o assign priority levels based on severity and potential impact on the entity, if the information is relevant or applicable o have the CSIRT contact point review the information for relevance and urgency. o validate information against internal logs, threat intelligence feeds and existing security policies. o for vulnerabilities and threats, if applicable, collaborate with relevant teams (IT, security, operations) to develop a mitigation strategy; o update or create incident response plans based on the nature of the threats or incidents reported in accordance with point 3.5 of the Annex to the regulation. o where appropriate, implement the mitigation measures and communicate with the relevant stakeholders in accordance with point 3.5 of the Annex to the regulation. o share insights and feedback on incidents and mitigations with the CSIRT on a voluntary basis.

text: EXAMPLES OF EVIDENCE

text: • Previous communications with CSIRTs or, where applicable, the competent authorities, for example emails, correspondence and meeting minutes. • Evidences that the point of contact has sufficient knowledge concerning incidents and threat intelligence.

text: 4.3.4. The relevant entities shall test, review and, where appropriate, update the crisis management plan on a regular basis or following significant incidents or significant changes to operations or risks.

text: GUIDANCE

text: • Test the crisis management process annually.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Test the crisis management process through, for example, an exercise or simulation, by (indicative, nonexhaustive list): o taking into account past crisis situations; o comparing the results of the tests to the objectives defined, for instance the recovery objectives in point 4.1.2 (f) of the Annex to the regulation (e.g. RTOs, RPOs and SDOs); and o using the results of the comparison to update and improve the crisis management procedure. • Review and update, if necessary, the crisis management process after a test or following significant incidents or significant changes to operations or risks. • Review and update the policy on the security of network and information systems and crisis management organisational measures after a test or following significant incidents or significant changes to operations or risks.

text: EXAMPLES OF EVIDENCE

text: • Documentation showing how crisis management integrates with the entity’s incident response plans (Annex to the regulation, point 3.5), particularly for ICT-related incidents. • Documents identifying any previous crises and assessing their likelihood of recurrence and potential impact on business operations. • Documentation of previous crisis management tests, including the scenarios tested, participants involved and outcomes. • After-action reports or evaluations from crisis management tests, identifying strengths, weaknesses and areas for improvement. • Records of internal or external reviews and audits of the crisis management plan, including any findings and corrective actions taken.

text: TIPS

text: GUIDANCE

text: • Management bodies should approve the crisis management process and, where appropriate, their roles and responsibilities during a crisis should be defined. • In addition to the elements referred to in point 4.3.2 of the Annex to the regulation the crisis management process might identify (indicative, non-exhaustive list): o procedures for declaring a crisis; o activation of the crisis management team; o escalation paths; o emergency procedures, which describe the actions in the event of a crisis; and o fall back procedures that describe the actions to be taken to protect essential activities or support services (e.g. alternative temporary locations for bringing the process back to normal operation, recovery or restoration).

text: EXAMPLES OF EVIDENCE

text: • Inventory of resources required for crisis management, including backup systems, alternative communication tools and emergency supplies. • Approved crisis management process. • A crisis communication plan documented and approved by the management bodies in place and communicated to all personnel. In addition to the elements referred to in point 4.3.2 of the Annex to the

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: regulation and the elements of the above guidance, the plan includes at least (indicative, non-exhaustive list): o how information will be disseminated to stakeholders during a crisis; o templates for communication; and o up-to-date contact information for internal and external stakeholders, including employees, customers, suppliers and emergency services. • Evidence that personnel are aware of the processes and who to contact in the event of a crisis. • Records from periodic simulations and awareness raising activities to assess the readiness of personnel and the adequacy of the procedures for managing a crisis.

text: Chapter 5

text: SUPPLY CHAIN SECURITY

text: TECHNICAL IMPLEMENTATION GUIDANCE 5. SUPPLY CHAIN SECURITY 5.1 SUPPLY CHAIN SECURITY POLICY

text: 5.1.1. For the purpose of

text: Article 21(2)

text: , point (d) of

text: Directive (EU) 2022/2555

text: , the relevant entities shall establish, implement and apply a supply chain security policy which governs the relations with their direct suppliers and service providers to mitigate the identified risks to the security of network and information systems. In the supply chain security policy, the relevant entities shall identify their role in the supply chain and communicate it to their direct suppliers and service providers.

text: GUIDANCE

text: • Take into account industry-recognised standards or good practices when developing the supply chain policy ( ). • The role of a supplier or service provider might be one or more of the following ( ): o ICT supplier (including software and hardware supplier), o Manufacturer, o managed service provider, o managed security service provider and o cloud computing provider. • In the case of free and open source software (FOSS), communities and projects that openly develop, maintain and distribute software may not be considered direct suppliers or service providers where no contractual relationship exists between the relevant entity and the open source project, beyond adherence to a standardised copyright licence, or where the contractual relationship is with an open source software steward (Regulation 2024/2847,

text: Article 3(14)

text: ‘provides support on a sustained basis for the development and ensures the viability of those products’).

text: EXAMPLES OF EVIDENCE

text: • Supply chain security policy in place and is in line with industry-recognised standards and/or good practices. • Evidence (e.g. email, contract or announcements) of the communication of the role of the entity to the direct suppliers and service providers, where possible.

text: 5.1.2. As part of the supply chain security policy referred to in point 5.1.1, the relevant entities shall lay down criteria to select and contract suppliers and service providers. Those criteria shall include the following: (a) the cybersecurity practices of the suppliers and service providers, including their secure development procedures;

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: (b) the ability of the suppliers and service providers to meet cybersecurity specifications set by the relevant entities; (c) the overall quality and resilience of ICT products and ICT services and the cybersecurity risk-management measures embedded in them, including the risks and classification level of the ICT products and ICT services; (d) the ability of the relevant entities to diversify sources of supply and limit vendor lock-in, where applicable.

text: GUIDANCE

text: • Consider criteria such as: o the legal jurisdiction of the supplier or service provider, for example whether the supplier is regulated under the NIS2 Directive or the Cyber Resilience Act and in which jurisdiction(s); o if available, compliance statements from the supplier in relation to the NIS2 Directive; o the corporate ownership of the supplier or service provider; o the supplier’s or service provider’s ability to ensure supply (e.g. size, reliance on other suppliers or service providers and degree of control over its own supply chain); o the cybersecurity practices of the supplier or service provider, and whether adequate prioritisation is given to cybersecurity practices, attested by:  industry standard certifications for cybersecurity;  vendor risk-management software reports or other provider assessment reports (e.g. Standardized Information Gathering, vendor security assessment or consensus assessment initiative questionnaire), if available; o notices or advice issued by national authorities on the selection of suppliers or service providers, if available; o the sensitivity of the use of the products and services acquired; o the supplier or service provider’s history in relation to cybersecurity events and breaches; o the possibility of vendor lock-in, if the supplier or service provider is selected. Parameters to consider are the use of open and interoperable standards, the use of open data formats, existing contracts with the supplier or service provider, the use of proprietary software features, etc.

text: EXAMPLES OF EVIDENCE

text: • A policy containing the elements referred to in point 5.1.2 of the Annex to the regulation.

text: 5.1.3. When establishing their supply chain security policy, relevant entities shall take into account the results of the coordinated security risk assessments of critical supply chains carried out in accordance with

text: Article 22(1) of Directive (EU) 2022/2555

text: , where applicable.

text: GUIDANCE

text: • Take into account any recommendations or guidance on supply chain security, published by the NIS Cooperation Group, established by the NIS2 Directive,

text: Article 14

text: ( ) and by the national competent authorities.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: EXAMPLES OF EVIDENCE

text: • Evidence that scenarios and the recommendations of the NIS Cooperation Group have been taken into account in the supply chain policy, relevant to the entity’s business objectives.

text: 5.1.4. Based on the supply chain security policy and taking into account the results of the risk assessment carried out in accordance with point 2.1. of this Annex, the relevant entities shall ensure that their contracts with the suppliers and service providers specify, where appropriate through service level agreements, the following, where appropriate: (a) cybersecurity requirements for the suppliers or service providers, including requirements as regards the security in acquisition of ICT services or ICT products set out in point 6.1.; (b) requirements regarding awareness, skills and training and where appropriate certifications, required from the suppliers’ or service providers’ employees; (c) requirements regarding the verification of the background of the suppliers’ and service providers’ employees; (d) an obligation on suppliers and service providers to notify, without undue delay, the relevant entities of incidents that present a risk to the security of the network and information systems of those entities; (e) the right to audit or right to receive audit reports; (f) an obligation on suppliers and service providers to handle vulnerabilities that present a risk to the security of the network and information systems of the relevant entities; (g) requirements regarding subcontracting and, where the relevant entities allow subcontracting, cybersecurity requirements for subcontractors in accordance with the cybersecurity requirements referred to in point (a); (h) obligations on the suppliers and service providers at the termination of the contract, such as retrieval and disposal of the information obtained by the suppliers and service providers in the exercise of their tasks.

text: GUIDANCE

text: • Ensure that, in all relevant new and renewed contracts, the requirements from point 5.1.4 of the Annex to the regulation are included. • When dealing with large suppliers and service providers consider one or more of the following measures (indicative, non-exhaustive list): o collective bargaining by teaming up with similar size organisations for purchasing products or services in bulk; o representation by an association of which the entity is a member of; o legal advice for reviewing and negotiating a contract; o negotiating specific clauses such as exit, pricing and SLAs ( ); o suppliers that publicly publish their security, privacy or reliability commitments; o providers with standard certifications (e.g. ISO 27001, SOC 2); o trusted platforms or marketplaces that vet suppliers (e.g. app stores, SaaS directories, partner networks); o contract templates or free legal checklists from small business associations, NGOs or government sites; o tools/services that allow easy data export, monthly payments or no lock-in; o avoiding long-term commitments or vendor lock-in without clear exit strategies; and

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o a short list of alternatives in case the supplier becomes unavailable.

text: EXAMPLES OF EVIDENCE

text: • Contracts that contain the elements referred to in point 5.1.4 of the Annex to the regulation.

text: 5.1.5. The relevant entities shall take into account the elements referred to in point 5.1.2 and 5.1.3. as part of the selection process of new suppliers and service providers, as well as part of the procurement process referred to in point 6.1.

text: GUIDANCE

text: • Perform a risk analysis before entering into any agreement with suppliers and service providers related to information security, taking into account the elements referred to in point 5.1.2 and 5.1.3, where appropriate ( ).

text: EXAMPLES OF EVIDENCE

text: • Evidence that contracts with new suppliers and service providers or the procurement guidelines take into account the elements referred to in points 5.1.2 and 5.1.3. • Comparison between selected contracts and the associated tenders to check whether the secure acquisition of ICT systems, products and service processes and particularly the elements referred to in point 6.1.2 of the Annex to the regulation, are taken into consideration. • Risk analysis results from supplier and service provider evaluations.

text: 5.1.6. The relevant entities shall review the supply chain security policy and monitor, evaluate and, where necessary, act upon changes in the cybersecurity practices of suppliers and service providers, at planned intervals and when significant changes to operations or risks or significant incidents related to the provision of ICT services or having impact on the security of the ICT products from suppliers and service providers occur.

text: GUIDANCE

text: • Review the supply chain policy at least annually. • Create and maintain a process to monitor suppliers and service providers over the life cycle.

text: EXAMPLES OF EVIDENCE

text: • Supply chain policy review plans or schedules. • Records from previous reviews. • List of security incidents related to or caused by engagement with a supplier or service provider. • Evidence that the policy was reviewed and possibly updated, after significant changes to operations or risks or significant incidents related to the provision of ICT services or having an impact on the security of the ICT products from suppliers and service providers. • Evidence from evaluations of suppliers and service providers.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 5.1.7. For the purpose of point 5.1.6., the relevant entities shall: (a) regularly monitor reports on the implementation of the service level agreements, where applicable; (b) review incidents related to ICT products and ICT services from suppliers and service providers; (c) assess the need for unscheduled reviews and document the findings in a comprehensible manner; (d) analyse the risks presented by changes related to ICT products and ICT services from suppliers and service providers and, where appropriate, take mitigating measures in a timely manner.

text: GUIDANCE

text: • Set up a regular review (e.g. as part of a regular supplier meeting) and follow up on deviations from the agreed SLAs. • Define and assign responsibilities regarding maintenance, operation and ownership of assets. • Make sure that monitoring encompasses periodic reassessment of supplier and service provider compliance, and monitor supplier and service provider release notes. • Periodically ensure that product configuration is aligned with vendor recommendations, with increasing frequency as products age. • Keep track of security incidents related to or caused by suppliers and service providers as they might trigger an unscheduled review of the suppliers and service providers. Other circumstances for such an unscheduled review include to suppliers and service providers (indicative, non-exhaustive list): o material changes in their operations; o changes in their risk exposure; o failure to meet their contractual obligations; and o emergence of new threats or vulnerabilities affecting the provided ICT products or services. • Monitoring frequency should be aligned with supply chain policy (Annex to the regulation, point 5.1.1) and the review of the secure acquisition of ICT services, systems or products processes (Annex to the regulation, point 6.1.3).

text: EXAMPLES OF EVIDENCE

text: • Records showing that service levels are monitored in accordance with established SLA). • Incident response records which confirm whether the entity takes into account incidents related to ICT services, systems or products from suppliers and service providers; • Evidence that signed contracts with third parties (e.g. contractors and suppliers) are in line with the policy on the security of network and information systems, for example contractual clauses, references to key security-relevant roles and responsibilities, and requirements for the contractor to report incidents. • Supplier and service provider exit process, meaning documentation outlining how the entity manages the exit of suppliers and service providers. This includes transitioning services, data and access rights when terminating a supplier and service provider relationship. • List of security incidents related to or caused by engagement with third parties.

text: TIPS

text: GUIDANCE

text: • In addition to the elements referred to point 5.1.4 of the Annex to the regulation, consider the following additional elements for contract clauses (indicative, non-exhaustive list): o a clear and complete description of ICT products and services;

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o service level descriptions, including uptime guarantees or target service levels, response times for service issues and updates to the service level descriptions thereof; o locations (regions or countries) where the ICT products are to be produced and ICT services are to be provided and where data is to be processed, including the storage location and the requirement for the supplier and service provider to notify the entity in advance if it envisages changing such locations; o provisions on availability, authenticity, integrity and confidentiality in relation to the protection of data, including personal data; o non-disclosure agreements; o obligations on the suppliers and service providers, such as retrieval and disposal of the information obtained by the suppliers and service providers in the exercise of their tasks, in the event of the insolvency, resolution, termination or discontinuation of the business operations of the supplier or service provider; o obligations of the supplier or service provider to provide assistance to the entity at no additional cost or at a cost that is determined ex ante, in the event of a cyber incident that presents a risk and was caused by the ICT product or the ICT service contracted; o roles and responsibilities; o contacts and reporting lines; o the obligation of the supplier or service provider to fully cooperate with the competent authorities; o termination rights and related minimum notice periods for the termination of the contractual arrangements; o notice periods and reporting obligations of the supplier or service provider to the entity, including notification of any development that might have a material impact on the supplier’s or service provider’s ability to effectively provide the ICT products or services in line with agreed service levels; o the right to audit by the entity or an appointed third party and by the competent authority and the obligation of the supplier and the service provider to fully cooperate during onsite inspections and audits performed by competent authorities and the obligation to provide details on the scope, procedures to be followed and frequency of such inspections and audits; o exit strategies, in particular the establishment of a mandatory adequate transition period, provisions on intellectual property and responsibilities of the supplier during the exit period, for example to provide relevant documentation and historical logs. • In addition to the elements referred to in point 5.1.5 of the Annex to the regulation, consider the following (indicative, non-exhaustive list): o country-specific information (e.g. threat assessment from national security services), if available; o restrictions or exclusions posed by a relevant national authority, for example equipment with high criticality for the entity or for high-risk suppliers; o information stemming from known incidents or cyber threat intelligence; and o the characteristics of each supplier, such as the quality of its security practices, the legal framework and the level of transparency. • Make sure that secure decommissioning service providers consider issues such as deactivating user and service accounts, terminating data flows and ensuring secure disposal of the entity’s data within supplier or service provider systems.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Awareness training regarding rules of engagement and behaviour should be delivered to the entity’s and the suppliers or service providers’ personnel, where appropriate, based on the level of access to the entity’s assets and information assets. • Include relevant personnel of suppliers and service providers and their relevant responsibilities, in crisis management tests, where appropriate. • Make sure that contracts with suppliers and service providers are in line with the policy on the security of network and information systems. • When implementing a supply chain security policy, consider the following elements regarding the use of free and open source software (FOSS) supply chain: o When using FOSS without purchasing a related software product or entering into a service agreement for development with the originator of the FOSS, obligations for compliance cannot be imposed beyond the adherence to the terms of the open source software licence ( ). o Consider supporting the communities developing and maintaining FOSS and invest in a mutually beneficial relationship with them. Where effective, this could involve relationships with the relevant OSS steward that ‘provid[es] support on a sustained basis for the development and ensures the viability of those products’ ( ). Such a relationship should not qualify the steward as a direct supplier or service provider, as imposing technical or methodological requirements might not be appropriate, applicable or feasible considering their role. o Consider steps to mitigate the identified risks to the security of network and information systems as it relates to free and open source software dependencies:  before integrating free and open source components, require the direct supplier or service provider to conduct a risk assessment and communicate the results to understand potential vulnerabilities and their impact on the entity’s systems; • where feasible, the risk assessment should be done in coordination with its open source project or associated OSS Steward, at the expense of the supplier or service provider using the component and in such a way that subsequent risk assessments done by third parties benefit from this work;  require suppliers or service providers to provide evidence of their engagement with the OSS community to ascertain whether adequate resources are available to support sustainable maintenance efforts and contribute such resources where appropriate, including to guarantee future availability of security patches;  ensure that free and open source components are regularly updated by the supplier or the service provider to address all known and patched security vulnerabilities;

text: TECHNICAL IMPLEMENTATION GUIDANCE

text:  require the supplier or service provider to perform regular code reviews and security testing on free and open source components to identify and address any security issues ( );  require the supplier or service provider to provide information on tools to manage software dependencies (e.g. Dependabot, Yarn, Gradle and Pip) and ensure that all components and their dependencies are secure and up to date;  require the supplier or service provider to provide clear documentation and policies for using free and open source components, including guidelines for evaluation and integration, along with evidence of efforts to ensure the sustainable maintenance of their dependencies by nurturing the open source projects they rely on, such as by referencing their public (code) contributions. o Engage with relevant open source communities to stay informed about significant updates, patches and best practices for using and updating their FOSS component.

text: EXAMPLES OF EVIDENCE

text: • Contract clauses that include, in addition to the elements referred to in point 5.1.4 of the Annex to the regulation, one or more of the above lists with additional elements. • Evidence of awareness trainings. • Records from crisis management tests (Annex to the regulation, point 4.3.4), if available or written confirmations by the supplier or provider after crisis management tests, which demonstrate the participation of relevant personnel of suppliers and service providers. • For FOSS (indicative, non-exhaustive list): o results from risk assessments of the FOSS, o dependency monitoring tools, o documentation.

text: 5.2 DIRECTORY OF SUPPLIERS AND SERVICE PROVIDERS

text: The relevant entities shall maintain and keep up to date a registry of their direct suppliers and service providers, including: (a) contact points for each direct supplier and service provider; (b) a list of ICT products, ICT services and ICT processes provided by the direct supplier or service provider to the relevant entities.

text: GUIDANCE

text: • Keep the registry up to date to ensure all information is current and accurate, that is, add, update and remove suppliers and service provider from the registry in the event of changes.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Conduct reviews of the registry, at least annually or when significant changes occur to ensure all information is current and accurate.

text: EXAMPLES OF EVIDENCE

text: • Registry of direct suppliers and service providers. • Evidence of registry updates following direct supplier and service provider changes. • Review plans or schedules.

text: TIPS

text: GUIDANCE

text: • In addition to the elements referred to in point 5.2 of the Annex to the regulation consider the start and end dates of the contract and the region of each direct supplier and service provider. • Classify direct suppliers and service providers. The classification may include one or more characteristics (indicative, non-exhaustive list): o sensitivity of assets purchased, o volume of assets purchased, o availability requirements, o applicable regulations, o inherent risk and mitigated risk. • Update and review classifications annually or when significant changes occur. Examples of categories may be: o critical – those with a significant impact on the entity’s operations; o strategic – high-value partners who contribute to information assets, for example cloud providers, data analytic providers, software developers and telecommunication providers; o routine – those with minimal impact on the entity.

text: EXAMPLES OF EVIDENCE

text: • List of relevant contracts or SLAs that are in line with the documented supply chain policy. • Evidence that the entity has categorised its direct suppliers and service providers based on criteria. • A clear description of how direct suppliers and service providers are grouped and managed based on their importance and risk level. • Evidence that the entity assesses risks associated with each direct supplier and service provider category, and that it tailors measures accordingly. For instance, ‘critical’ direct suppliers and service providers receive more attention and customised policies.

text: Chapter 6

text: SECURITY

text: IN AND

text: NETWORK INFORMATION SYSTEMS ACQUISITION, DEVELOPMENT

text: AND

text: MAINTENANCE

text: TECHNICAL IMPLEMENTATION GUIDANCE 6. SECURITY IN NETWORK AND INFORMATION SYSTEMS ACQUISITION, DEVELOPMENT AND MAINTENANCE 6.1 SECURITY IN ACQUISITION OF ICT SERVICES OR ICT PRODUCTS

text: 6.1.1. For the purpose of

text: Article 21(2)

text: , point (e) of

text: Directive (EU) 2022/2555

text: , the relevant entities shall set and implement processes to manage risks stemming from the acquisition of ICT services or ICT products for components that are critical for the relevant entities’ security of network and information systems, based on the risk assessment carried out pursuant to point 2.1, from suppliers or service providers throughout their life cycle.

text: GUIDANCE

text: • Integrate cybersecurity as a permanent component of the purchase process by dedicating a specific section to addressing it. This includes any acquisition processes for selecting FOSS ( ). • Document the process for secure acquisition of ICT services, systems or products and describe relevant procedures that support the process. • Take into account industry-recognised standards when developing the process ( ).

text: EXAMPLES OF EVIDENCE

text: • Tender templates for the acquisition of ICT services, systems or products which address cybersecurity. • Documented process which is based on relevant standards and good practices.

text: 6.1.2. For the purpose of point 6.1.1., the processes referred to in point 6.1.1. shall include: (a) security requirements to apply to the ICT services or ICT products to be acquired; (b) requirements regarding security updates throughout the entire lifetime of the ICT services or ICT products or replacement after the end of the support period; (c) information describing the hardware and software components used in the ICT services or ICT products; (d) information describing the implemented cybersecurity functions of the ICT services or ICT products and the configuration required for their secure operation; (e) assurance that the ICT services or ICT products comply with the security requirements according to point (a); (f) methods for validating that the delivered ICT services or ICT products are compliant to the stated security requirements, as well as documentation of the results of the validation.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: GUIDANCE

text: • The security requirements must include at least the means to detect, monitor and protect against unauthorized changes of software and information. • Ensure that support contracts cover the system life cycle and obsolescence management requirements, including the date until which the system must be supported and include continuous alerting. • Favour vendors that provide clear end-of-life information and that plan to provide separate critical security fixes. • Make sure that tenders request that suppliers or service providers provide tested solutions for security issues in legacy or new technologies free of charge and as soon as a relevant security issue becomes known. • Consider also the following information describing implemented cybersecurity functions such as (indicative, non-exhaustive list): o the potential risks that could arise from acquiring the specific ICT service, system or product. This might involve penetration testing to identify threats, vulnerabilities and the potential impact on the entity’s operations; o potential security tools that already need to be in place, for example a firewall, an intrusion detection system, a SIEM or a EDR/XDR; o a specific security mechanism that might need to be in place, such as a specific encryption algorithm or a particular access control mechanism (e.g. MFA); o cybersecurity standards for the ICT service, system or product that the entity needs to comply with; o where appropriate, the required assurance level of the ICT product, system or service and the existence of a relevant certificate following the European Cybersecurity Scheme for ICT products based on Common Criteria (EUCC). • Consider evaluating the security of an ICT service, system or product before acquisition ( ).

text: EXAMPLES OF EVIDENCE

text: • Past or ongoing tenders for acquiring ICT services, systems or products, that address cybersecurity by referring, as a minimum, to the elements outlined in point 6.1.2 of the Annex to the regulation. • Comparison between selected contracts and the associated tenders to check whether the supply chain policy and particularly the elements referred to in points 5.1.4 and 5.1.5 of the Annex to the regulation, are taken into consideration. • Records from security tests before acquiring an ICT system or product. • Certificates, test reports or other supporting information for the ICT products or systems from suitably accredited conformity assessment bodies.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 6.1.3. The relevant entities shall review and, where appropriate, update the processes at planned intervals and when significant incidents occur.

text: GUIDANCE

text: • Review the processes for secure acquisition of ICT services, systems or products, and the procedures based on them, at least annually. • Review logs or records of all changes made to the processes for secure acquisition of ICT services, systems or products, and the procedures based on them, including details of the changes, approvals and implementation dates. • Align the tenders and contracts with the entity’s supply chain security policy (Annex to the regulation, point 5.1). • For ICT services, systems or products that are not provided by a supplier (e.g. open source projects), entities should share relevant results from internal assessments with them.

text: EXAMPLES OF EVIDENCE

text: • Review plans or schedules for processes for secure acquisition of ICT services, systems or products, and the procedures based on them. • Minutes from reviews or possible changes made to the processes for ICT services, system or product acquisition, and the procedures based on them, including actions taken to enhance security in future acquisitions. • Documented results of possible auditing activities, indicating compliance with internal secure acquisition of ICT services, systems or products processes and external regulations. • Change management records of changes made to the processes for secure acquisition of ICT services, systems or products, and the procedures based on them, including documentation of the review and approval process. • Incident response records that confirm whether the entity takes into account significant incidents when reviewing and updating the processes and procedures for secure acquisition of ICT services, systems or products.

text: TIPS

text: GUIDANCE

text: • Apply the secure acquisition of ICT systems or product processes and relevant procedures to both software and hardware products, regardless of whether they were developed in-house or acquired. • Continuously monitor suppliers or service providers with regard to points 5.1.6 and 5.1.7 of the Annex to the regulation so that they are aligned with the supply chain security policy. • In addition to the elements referred to in point 6.1.2 of the Annex to the regulation, consider the following when formulating tenders with cybersecurity in mind (indicative, non-exhaustive list): o ensure continuous alerting, patching and mitigation proposals if vulnerabilities in the system or the product are discovered; o clarify the supplier’s or service provider’s liability in the event of cyber-attacks or incidents relevant to the service, system or product; and o consider cybersecurity during project implementation and before handover including (indicative, nonexhaustive list):  design reviews;

text: TECHNICAL IMPLEMENTATION GUIDANCE

text:  acceptance tests;  commissioning tests;  site acceptance tests; and  documentation. • Make sure that secure decommissioning service providers involve considerations such as deactivating user and service accounts, terminating data flows and ensuring the secure disposal of the entity’s data within supplier or service provider systems. • Free and open-source software is often obtained free of charge from communities and projects developing, maintaining and distributing software, as opposed to purchased from suppliers or service providers. When using such software without purchase, relevant entities cannot impose obligations for compliance beyond the adherence to the terms of the open source software license. Beyond that, it is good practice to apply the guidance of section 6.1.

text: EXAMPLES OF EVIDENCE

text: • Evidence that internal (in-house) projects consider and prioritize security when acquiring ICT services, systems or product processes. • Evidence that points 5.1.6 and 5.1.7 of the Annex to the regulation are implemented. • Tenders that contain elements in addition to those referred to in point 6.1.2 of the Annex to the regulation.

text: 6.2 SECURE DEVELOPMENT LIFE CYCLE

text: 6.2.1. Before developing a network and information system, including software, the relevant entities shall lay down rules for the secure development of network and information systems and apply them when developing network and information systems in-house or when outsourcing the development of network and information systems. The rules shall cover all development phases, including specification, design, development, implementation and testing.

text: GUIDANCE

text: • Take into account the entity’s policies and norms (if available) and industry-recognised standards when developing the rules for the secure development of network and information systems ( ).

text: EXAMPLES OF EVIDENCE

text: • Documented rules for the secure development of network and information systems which align with the entity’s policies and norms and are based on relevant standards and good practices.

text: 6.2.2. For the purpose of point 6.2.1., the relevant entities shall: (a) carry out an analysis of security requirements at the specification and design phases of any development or acquisition project undertaken by the relevant entities or on behalf of those entities; (b) apply principles for engineering secure systems and secure coding principles to any information system development activities such as promoting cybersecurity-by-design, zero-trust architectures; (c) lay down security requirements regarding development environments;

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: (d) establish and implement security testing processes in the development life cycle; (e) appropriately select, protect and manage security test data; (f) sanitise and anonymise testing data according to the risk assessment carried out pursuant to point 2.1.

text: GUIDANCE

text: • A secure software development life cycle (SSDLC) process should be implemented by all entities. However, smaller entities can use a less demanding process such as implementing secure-by-design practices and security-testing processes. • Depending on the type of requirement, the rules for the secure development of software and systems should include appropriate software testing methods (e.g. black-box, ad-hoc testing, static versus dynamic application security testing). • Test security by design at various stages of the secure development of the SSDLC prior to go-live, utilising independent tools and a self-service testing platform throughout the SSDLC. • When real production data - or derived variations of it - is used for testing, ensure that such data is properly sanitised or anonymised. An indicative, non-exhaustive list of techniques: o masking or pseudonymization on fields like names, emails, IDs; o deletion or redaction of identifiers (e.g. personal IDs, birth dates, ZIP codes); and o non-irreversible or one-way anonymisation. • When using Free and Open Source Software components, entities should take into account the voluntary nature of open source projects (see guidance of section 5.1). Where possible, entities should assist the open source projects that they depend on in adopting secure systems and secure coding principles (such as introducing SSDLC processes suited to the project’s way of working).

text: EXAMPLES OF EVIDENCE

text: • Evidence that secure development rules have been adopted (indicative, non-exhaustive list): o documentation for each phase of the life cycle, o process and workflow diagrams, o audit and testing reports, o version control, o change management logs, o code reviews, and o project management tools. • Evidence of the test results from secure development environments, including that measures for protecting test data are maintained. • Evidence of the software-testing methods chosen for a particular test scenario and an explanation of the choice. • Test results of each phase of the SSDLC maintained and up to date. • Test results maintained and, where appropriate, approved by management bodies. • Evidence that a software-testing method is chosen at each stage of the software development life cycle.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 6.2.3 For outsourced development of network and information systems, the relevant entities shall also apply the policies and procedures referred to in points 5 and 6.1.

text: GUIDANCE

text: • Align the secure development rules with the security testing policy (Annex to the regulation, point 6.5) and procedures and with the secure acquisition of ICT services, systems or product processes (Annex to the regulation, point 6.1). • Communicate the internal development rules with the relevant personnel from outsourced development. • Hold regular cross-organisational unit meetings during all phases of the development life cycle.

text: EXAMPLES OF EVIDENCE

text: • Comparison of the secure development rules with the security-testing policy and with the secure acquisition of ICT services, systems or product processes, checking whether the security requirements are set consistently in all these documents. • Evidence of communicating the internal development rules with relevant personnel from outsourced development. • Records or minutes from cross organisational unit meetings where the development of a network and information system, including software, was discussed.

text: 6.2.4 The relevant entities shall review and, where necessary, update their secure development rules at planned intervals.

text: GUIDANCE

text: • Review the rules for the secure development of network and information systems at least once every two years.

text: EXAMPLES OF EVIDENCE

text: • Documentation that outlines the schedule and frequency for reviewing secure development rules. • Documented evidence of the process for reviewing the patch development process and secure-by design software configurations. • Meeting minutes, review findings and actions taken to improve the development rules. • Version history or change log of secure development procedures showing updates made as a result of reviews. o Specific sections in the documents highlighting what changes were made and the rationale behind them. • Reports from internal and external audits that evaluate the process for reviewing secure development rules. • Documentation of change requests related to secure development rules, including those arising from review findings. • Logs or records tracking the implementation of changes to ensure they are applied throughout the development process.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: TIPS

text: GUIDANCE

text: • Consider threat modelling as part of the security requirements analysis. • Keep separate environments for development purposes, testing purposes and production. • Ensure the use of results of application assessments to regularly enhance developer training and the SSDLC process. • Defined methods and tooling for performing analysis and tracking of usage of third party libraries should be in place. • Consider integrating root cause analysis results into SSDLC process changes, if any. • In addition to the regular reviews, the entity should review and, where necessary, update its secure development rules when there are significant changes to technology, operations or risks or in the event of significant incidents.

text: EXAMPLES OF EVIDENCE

text: • Evidence of the use of threat modelling (indicative, non-exhaustive list): o documentation of the process used for example STRIDE or DREAD, o data flow diagrams, and o meeting minutes. • Evidence of separate environments for development, testing and production, for example different network segments, servers, databases, existence of accounts used for this purpose and change management records. • Relevant personnel aware of the secure development rules. • Meeting minutes, logs, reports, etc. showing that the secure development rules were reviewed and possibly changed following significant changes to technology, operations or risks or in the event of significant incidents.

text: 6.3 CONFIGURATION MANAGEMENT

text: 6.3.1. The relevant entities shall take the appropriate measures to establish, document, implement and monitor configurations, including security configurations of hardware, software, services and networks.

text: GUIDANCE

text: • Establish documented processes based on best practices and information security standards ( ). • Maintain and document detailed configuration settings for the following operating procedures (indicative, nonexhaustive list): o processing and handling of information, o backup, o scheduling requirements, including interdependencies with other systems, o handling errors or other exceptional conditions, o system restart and recovery procedures,

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o cryptographic mechanisms and settings, and o audit trail and system log information. • Consider the following security-related parameters for the configuration settings (indicative, non-exhaustive list): o registry settings, o account, file and directory permission settings, and o settings for functions, ports, protocols, services and remote connections. • Employ automated mechanisms to centrally manage, apply and verify configuration settings for software and hardware, including mobile devices and the entity’s connected vehicles. o Where appropriate, implement a configuration management database to catalogue and classify all configuration items (CIs), including their security attributes (e.g. patch level, firewall rules and encryption status) • Ensure that all network, software and system configurations adhere to established security and operational standards for functions, ports, protocols and services. • Monitor and control changes to the configuration settings in accordance with the entity’s policy on the security of network and information systems and topic-specific policies and procedures. • Identify software not authorised to run on the information systems. • Where appropriate, regularly review and update software configurations. • Where appropriate, identify software programs authorised to run on the information system. • Employ a deny-all, permit-by-exception policy to allow authorised software to run. • Set up procedures for network service usage to restrict access to necessary services or applications only. • Manage a secure baseline configuration for development and test environments separately from the operational baseline configuration, where appropriate. • Identify, document and approve any deviations from established configuration settings based on defined exceptions on operational requirements.

text: EXAMPLES OF EVIDENCE

text: • System configuration process, based on good practices and standards, in place and maintained. • System configuration tables containing configurations of hardware, software, services and networks. • Documented secure baseline configuration containing at least (indicative, non-exhaustive list): o essential capabilities of operation; o restricted use of functions; o security by default; o ports, protocols and/or services allowed. • Documented and approved exceptions to the configuration baseline containing the alternative measures in place to ensure the confidentiality, availability and integrity of the CI. • Documented secure baseline configuration for development and test environments.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 6.3.2. For the purpose of point 6.3.1., the relevant entities shall: (a) lay down and ensure security in configurations for their hardware, software, services and networks; (b) lay down and implement processes and tools to enforce the laid down secure configurations for hardware, software, services and networks, for newly installed systems as well as for systems in operation over their lifetime.

text: GUIDANCE

text: • Consider hardening guides/best practices and general cybersecurity principles (e.g. least functionality and least privilege) as a basis for deriving the defined security configurations. • Establish, document and maintain configuration settings respecting the access control policy. • Where applicable, test the configuration before implementation. • Employ security safeguards to detect and respond to unauthorised changes to defined configuration settings. • Establish a configuration management plan containing: o roles, responsibilities and configuration management processes and procedures; o a process for identifying CIs throughout the system development life cycle; and o a process for managing the configuration of the CIs throughout their life cycle. • Protect the configuration management plan from unauthorised disclosure and modification. • Implement enhanced controls, including regular vulnerability scanning, strict configuration hardening, isolation where feasible and continuous monitoring to compensate for products which lack official updates after the end of supplier support.

text: EXAMPLES OF EVIDENCE

text: • Configuration management plan. • Comparison of the configuration plan with the access control lists. • Mechanisms, for example logical and physical access controls, encryption and audit logs in place. • Documented and approved exceptions to the configuration baseline containing the alternative measures in place to ensure the confidentiality, availability and integrity of the CI.

text: 6.3.3. The relevant entities shall review and, where appropriate, update configurations at planned intervals or when significant incidents or significant changes to operations or risks occur.

text: GUIDANCE

text: • Review and, where appropriate update ( ) configurations at least monthly to ensure that patches have been applied, that the backup has been executed according to the plan and that monitoring is in place to identify and alert to fatal server/device/disk errors without delay. • Regularly produce, keep and review change logs regarding the security configuration of information systems. • Review and update the configurations after major changes (e.g. software updates) and past incidents. • Where feasible, obtain baseline configuration files for key systems and devices to compare against current configurations.

text: EXAMPLES OF EVIDENCE

text: • Up-to-date configuration management plan, review comments and/or change logs.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Documented results of the review activities. • Configuration snapshots taken before and after changes or at regular intervals to verify that reviews are conducted and documented. • Audit logs from systems and devices that track configuration changes and reviews. • Alerts from monitoring systems that notify administrators of unexpected configurations or changes or deviations from the baseline in critical systems. • Audit trails and compliance records from internal and external audits. • Minutes from team meetings where configuration reviews and changes are discussed and documented. • Records of notifications or reminders sent to relevant employees about upcoming configuration reviews. • Records from the configuration management tools to ensure they are kept up to date with accurate configuration information. • Incident response records that confirm whether the entity takes into account incidents related the configurations.

text: 6.4 CHANGE MANAGEMENT, REPAIRS AND MAINTENANCE

text: 6.4.1. The relevant entities shall apply change management procedures to control changes of network and information systems. Where applicable, the procedures shall be consistent with the relevant entities’ general policies concerning change management.

text: GUIDANCE

text: • Take into account industry-recognised and national standards when developing the change management procedures ( ). • Consider the following elements for the procedures (indicative, non-exhaustive list): o request for change, o risk assessment, o criteria for categorisation and prioritisation of changes:  associated requirements for the type and scope of the tests to be carried out and  the approvals to be obtained; o requirements for performing rollbacks; and o documentation of the changes and approval of changes. • The change management procedures may allow different workflows depending on the criticality of the system, the scope of the change and the urgency (e.g. put in place an ‘emergency intervention workflow’). • For each change, record the steps of the procedure followed. • Review and approve changes following the change management procedures, prior to implementing them. • Implement and test change management procedures to make sure that changes to networks and information systems are always done in a predefined way. • Where appropriate, establish a change advisory board (CAB) to oversee and approve changes. The CAB should evaluate change requests based on risk, impact, resource requirements and alignment with business objectives.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: EXAMPLES OF EVIDENCE

text: • Documented change management procedures for network and information systems that are based on standards or good practices. • For each relevant change, a record describing the steps and the result of the change. • A system maintenance procedure that addresses: o purpose; o scope; o roles; o responsibilities; o management commitment, if applicable; o coordination among different organisational units; and o compliance. • Logs that record the dates and outcomes of the periodic reviews of the change, repair and maintenance procedures.

text: 6.4.2. The procedures referred to in point 6.4.1. shall be applied for releases, modifications and emergency changes of any software and hardware in operation and changes to the configuration. The procedures shall ensure that those changes are documented and, based on the risk assessment carried out pursuant to point 2.1, tested and assessed in view of the potential impact before being implemented.

text: GUIDANCE

text: • Consider a mandatory integrity check before installing and deploying new software. • Ensure, where appropriate, that changes are done in an authenticated, authorised and non-repudiating manner. • Test and validate changes before they are implemented in operational systems, where applicable. Where appropriate, a security impact analysis may be performed in a separate test environment before implementation in an operational environment. • Take all necessary precautions before making changes (back up images, for instance). • Schedule, perform, document and review records of maintenance and repairs on system components in accordance with the supplier’s specifications and/or the entity’s requirements. • Ensure that changes are only allowed with approved tools and that their execution is documented. • Restrict the use of maintenance tools to authorised personnel only.

text: EXAMPLES OF EVIDENCE

text: • Logs and records of past (new) software installations. • Evidence that MFA is in place for activating change, repair and maintenance procedures, where applicable. • Test plans and results that demonstrate the implementation and effectiveness of the change, repair and maintenance procedures. • If the entity utilises change management tools, evidence that these tools enforce the use of approved resources only and mandate documentation for each change. • Access control lists (ACLs) to verify that access to the tools is in line with the access control policy.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 6.4.3. In the event that the regular change management procedures could not be followed due to an emergency, the relevant entities shall document the result of the change and the explanation for why the procedures could not be followed.

text: GUIDANCE

text: • Where appropriate, integrate the pullback scenario ( ) into the change management procedures. • Assess the risks from legacy systems and upgrade existing legacy systems to include security mitigating measures in case appropriate security cannot be achieved. • Make sure that regular change control procedures that could not be followed due to an emergency change are applied immediately after the emergency change.

text: EXAMPLES OF EVIDENCE

text: • Documentation with specific pullback plans. • Logs and records of past change requests with details of (indicative, non-exhaustive list): o the change, o reason for emergency, o approval, o reason for delay, o follow up actions and o how to revert the system to a previous stage if the change fails. • Logs and records from past legacy system upgrade that contain risk assessments and the reasoning for the change.

text: 6.4.4. The relevant entities shall review and, where appropriate, update the procedures at planned intervals and when significant incidents or significant changes to operations or risks.

text: GUIDANCE

text: • Review the change management procedures at least once every two years. • Make sure that the management procedures cover planned and unplanned changes and the development phase, when applicable. • Ensure that the process is not bypassed.

text: EXAMPLES OF EVIDENCE

text: • Review plans or schedules. • Up to date change management procedures, review comments and/or change logs. • Evidence of approval and monitoring of maintenance activities, whether performed on site or remotely and whether the equipment is serviced on site or removed to another location. • Logs of all changes made to the procedures, including details, approvals and implementation dates. • Audit trails and compliance records from internal and external audits. • Logs of significant incidents to confirm whether they include documentation of reviews and updates to the change, repair and maintenance procedures.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Reports from post-incident reviews that document any necessary adjustments to the procedures following significant incidents. • Records showing how changes and updates to the procedures were implemented and reviewed.

text: TIPS

text: GUIDANCE

text: • Perform and log: (a) changes to, (b) maintenance of and (c) repairs to network and information systems, with approved and controlled tools. • Put change management procedures in place according to licensing agreements. • Upon changes to assets, update the asset inventory (Annex to the regulation, point 12.4) and documentation. • Upon changes to risk management measures, update the risk treatment plan (Annex to the regulation, point 2.1.1). • Inform the customer of significant changes to network and information systems that affect the services offered. This information only needs to be provided if it is beneficial for customers. • Ensure availability of the required maintenance skills, resources and spare parts, including external support. • Prevent the unauthorised removal of maintenance equipment containing information related to the entity by (indicative, non-exhaustive list): o verifying that no information related to the entity is contained in the equipment; o sanitising or destroying the equipment; o retaining the equipment within the facility; or o obtaining an exemption from authorised personnel or roles explicitly authorising removal of the equipment from the facility. • Provide remote access via out-of-band (OOB) connection in the event that the standard connection does not work. • Regularly test OOB connections to ensure they function as expected during an outage. • If an incident, in the sense of Article 23 of the NIS2 Directive, involves subsequent actions that entail system changes, then notify the competent authorities of these changes in accordance with the national reporting procedure.

text: EXAMPLES OF EVIDENCE

text: • Evidence that MFA is in place for remote change, repair and maintenance procedures. • Logs and records that prove the use of approved tools. • Evidence that the procedures mention the licencing agreement. • Up-to-date asset inventory. • Up-to-date risk-treatment plan. • Documentation of a customer update on significant changes. • Evidence of previous training on change management and system maintenance. • Evidence of sanitisation procedures. • Evidence that the entity maintains a spare parts for key components of its network and information system. • Notifications to defined personnel or roles of the date and time of planned maintenance. • Network architecture diagram that proves the existence of OOB connections.

text: TECHNICAL IMPLEMENTATION GUIDANCE 6.5 SECURITY TESTING

text: 6.5.1. The relevant entities shall establish, implement and apply a policy and procedures for security testing.

text: GUIDANCE

text: • Take into account industry-recognised standards when developing the testing policy ( ). • Establish and maintain a testing programme appropriate to the entity’s size, complexity and maturity ( ).

text: EXAMPLES OF EVIDENCE

text: • Documented security testing and procedures based on relevant standards and good practices. • Guidelines and standards that the entity adheres to for conducting security tests.

text: 6.5.2. The relevant entities shall: (a) establish, based on the risk assessment carried out pursuant to point 2.1, the need, scope, frequency and type of security tests; (b) carry out security tests according to a documented test methodology, covering the components identified as relevant for secure operation in a risk analysis; (c) document the type, scope, time and results of the tests, including assessment of criticality and mitigating actions for each finding; (d) apply mitigating actions in case of critical findings.

text: GUIDANCE

text: • Make sure that network and information systems undergo continuous testing, particularly in environments utilizing continuous integration / continuous deployment practices. Regular testing should be conducted at setup, after significant upgrades or modifications and following maintenance, to maintain robust security and performance. • Consider a range of security tests (e.g. vulnerability assessments, penetration testing, code review, ethical hacking, bug bounty programmes, cyber attack simulations, red teaming, protocol conformance testing or cyber response exercises) and select the most appropriate one (or more) to test the specific procedure, service or tool over time. • Entity-wide scoped tests should be carried out at planned intervals or when significant incidents or changes occur. • Conduct internal and/or external audits throughout the entity’s networks, systems and processes in an ad-hoc manner. • Record evidence while testing. The need, scope, frequency, type and results are to be documented in a manner that is comprehensible to an expert third party. • Use criteria to assess the results of the tests similar to the criteria for performing cybersecurity risk assessments (guidance on point 2.1.2 of the Annex to the regulation). • Assess, follow up and remediate high-criticality findings with respect to the confidentiality, integrity, authenticity or availability of the service provided.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Document the assessment of criticality and mitigating actions for each finding. Ensure that risk assessment results and risk treatment plans are updated accordingly (Annex to the regulation, point 2.1). • When testing reveals an underlying security issue in a free and open source component, these findings must be shared with the relevant open source project. If a patch is developed to address the issue, the relevant code should also be shared with the relevant open source project, in a manner suitable for integration. • Where appropriate, any automated security tests written by entities for open source components that they use, should be shared with the relevant open source projects.

text: EXAMPLES OF EVIDENCE

text: • Documented security testing policy and procedures that include the elements referred to in point 5.2 (a) of the Annex to the regulation. • Documentation defining the roles and responsibilities of personnel involved in security testing. • Plans or schedules for upcoming or completed regular or ad hoc tests. • List of reports from past security tests This should cover various types of testing (e.g. vulnerability assessments, penetration testing and code reviews). • Internal or external audit reports.

text: 6.5.3. The relevant entities shall review and, where appropriate, update their security testing policies at planned intervals.

text: GUIDANCE

text: • Review the security testing policy and procedures at least once every two years.

text: EXAMPLES OF EVIDENCE

text: • Updated security-testing policy and procedures, review comments, and/or change logs. • Security-testing policy and procedures, including when tests must be carried out, test plans, test cases and test report templates.

text: TIPS

text: GUIDANCE

text: • For systems with external integrations (e.g. cloud services) beyond the organization’s control, ensure that all external application programming interface endpoints are thoroughly tested. • Determine the auditable security events that are adequate for supporting investigations of security incidents. • Implement tools for automated testing, such as code analysis tools or vulnerability scanners. • Ensure the policy is approved by, communicated to and acknowledged by relevant personnel and third parties. • Ensure that the development and testing environment(s) is/are separate from the production environment. • Review the security-testing policy and procedures when significant incidents or major changes to the network and information system occur.

text: EXAMPLES OF EVIDENCE

text: • In addition to the elements referred to in point 6.5.2 (c) of the Annex to the regulation, documented policy that includes at least (indicative, non-exhaustive list): o approved parties (internal or third); o confidentiality levels for assessment; and

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o test results and the objectives of security assessments and tests. • Relevant staff aware of the security-testing procedures and tools. • Documented audit requirements. • A list of tools used for security testing, including their purpose and how they are maintained and updated. • Valid licences for commercial testing tools or subscriptions to security services. • Review showing that the security tools are in use and configured to perform the actions intended. • Records showing updates to the security policy and procedures based on lessons learnt and new threats.

text: 6.6 SECURITY PATCH MANAGEMENT

text: 6.6.1. The relevant entities shall specify and apply procedures, coherent with the change management procedures referred to in point 6.4.1. as well as with vulnerability management, risk management and other relevant management procedures, for ensuring that: (a) security patches are applied within a reasonable time after they become available; (b) security patches are tested before being applied in production systems; (c) security patches come from trusted sources and are checked for integrity; (d) additional measures are implemented and residual risks are accepted in cases where a patch is not available or not applied pursuant to point 6.6.2.

text: GUIDANCE

text: • Take into account well known standards when developing the security patch management procedures ( ). • Actions may vary, depending on the network and information system (e.g. mandatory patching for all exposed systems or internet-connected devices such as firewalls or routers, and limited patching only in specific circumstances, for instance in isolated or legacy systems where regular patching may not be feasible or available). • Establish a process, in combination with the asset inventory, for being informed when a new security patch is published and schedule patch roll-outs accordingly. • Patching should be a standard activity in normal maintenance and outage planning of services. Nonetheless, some failures may require immediate patching depending on their criticality. • Prioritise and apply patches based on risk. Evaluate the severity of the vulnerability, exposure of the affected system and likelihood of exploitation. • Deploy vulnerability management technologies to identify unpatched and misconfigured software. • Define your relevant security information sources considering your assets and continuously monitor them for patch announcements, patch and non-patch remediation, and general threats. • Verify the patch sources through (indicative, non-exhaustive list): o digital certificates to verify the vendor; o digital signatures of the patches o change logs provided by the vendor; and o feedback from the community concerning the reliability of the vendor. • Consider a strategy for applying patches after approval or testing following the change management procedure (indicative, non exhaustive list):

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o Blue/green allows the patches to be applied first in an isolated environment identical to the production environment, and then in the production environment. This ensures zero downtime and an immediate rollback option. o Rolling ( ) deployment allows gradual updates of parts of the production environment, one set of servers or instances at a time, rather than deploying a patch all at once. It is ideal for large and distributed environments. o Feature toggles allow new features or patches to be deployed to production but keep them disabled until they are ready to be used. They are suitable for control over new features or patches when they are turned on, making it easy to test and release. o Shadow deployment allows new code or patches to be deployed directly to production but it shadows live traffic by mirroring user requests to both the current and new systems to observe how the new version behaves without affecting the user experience. It is ideal for testing new features in production without affecting users. o Hotfix deployments are used for critical patches that need to be applied immediately to address severe issues. • Where appropriate and to reduce risks related to significant updates in important dependencies, consider performing a trial using release candidates ( ) of these components, to get an early indication of incompatibilities or breaking changes, so they may be remedied. If any of these components are open source software, offer feedback about any issues found during this trial.

text: EXAMPLES OF EVIDENCE

text: • Detailed procedures and guidelines for how patches are identified, evaluated, tested, deployed and verified. • Logs or records showing the history of patch deployments across various systems. These may include (indicative, non-exhaustive list): o timestamps; o responsible personnel; and o affected systems. • Evidence that the asset inventory (Annex to the regulation, point 12.4) is updated after a new security patch is announced, if possible accompanied by the time plan for applying it. • Evidence of testing patches before deployment in a controlled environment. This should include results of testing and any issues encountered and resolved. • Documentation of test plans and results for patches before deployment to production environments. • Documentation of change requests for deploying patches, including approvals and impact assessments. • Detailed audit trails showing the steps taken from patch identification to deployment. • Checks for the latest patches. • Approved documented actions for applying patches. • Records of changes logged, reviewed and approved. • Evidence of vendor verification mechanisms for example digital certificates and digital signatures. • Reports from internal and external audits evaluating the effectiveness of the patch management processes.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 6.6.2. By way of derogation from point 6.6.1.(a), the relevant entities may choose not to apply security patches when the disadvantages of applying the security patches outweigh the cybersecurity benefits. The relevant entities shall duly document and substantiate the reasons for any such decision.

text: GUIDANCE

text: • Make an effort, proportionate to the entity’s size and importance, to ensure that security patches do not introduce additional vulnerabilities or instabilities. Examples of information supporting such a decision may include (indicative, non-exhaustive list): o vendor documentation on the patch:  what specific vulnerabilities or bugs are addressed,  whether the patch fixes a security issue, improves performance, adds features or resolves stability concerns,  system requirements or any specific configurations required or changes to system settings,  installation instructions on How to apply the patch and whether it requires a restart or additional configuration; o severity rating - patches that address critical vulnerabilities are more likely to apply; and o security blogs, forums and mailing lists for any known issues or incompatibilities introduced by the patch. • If patching is not feasible, consider alternative measures such as strict configuration hardening, intrusion detection systems, regular vulnerability scanning, network segmentation or isolation where feasible, access control and monitoring.

text: EXAMPLES OF EVIDENCE

text: • Evidence of patch prioritisation for example emphasis is placed on patches assessed as critical. • Evidence that residual risks resulting from non-patching are listed and mitigated. • Incident reports related to unpatched vulnerabilities to check the effectiveness of the mitigation measures during the entity’s response. • Logs of changes made to systems, including patches applied, rollback procedures and any issues encountered. • Documented decisions no to patch accompanied by relevant alternative measures. • Up-to-date risk-treatment plan.

text: TIPS

text: GUIDANCE

text: • Patch management procedures should indicate scope, roles and responsibilities. • Perform operating system and application updates on enterprise assets through automated patch management. • Use appropriate patch management tools to fulfil the elements referred to in point 6.6.1 of the Annex to the regulation. • Since patches can sometimes cause issues, it is recommended to back up the system before applying them. • Have a rollback plan to ensure that the system reverts to a safe previous state if patching does not work or fixing the problem is not feasible.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Remove unsupported hardware and software from the network in a reasonable and accepted time in line with the entity’s risk assessment. • Include patch and update requirements in the supply chain policy (Annex to the regulation, point 5.1) and in the contracts, bid evaluation and selection criteria for new ICT services, systems or products (section 6.1), considering the system life span among other aspects.

text: EXAMPLES OF EVIDENCE

text: • Documentation of regular meetings where patch management processes are reviewed. This should include agendas, attendance records, actions taken to improve the process and minutes from the meetings. • Checks of the latest patches for evidence of who performed each step and when and for documentation outlining the roles and responsibilities of staff involved in the patch management process. • Patch management tools. • Configuration and logs from these tools demonstrating regular use. • Rollback plan. • Contract, bid and documented evaluation and selection criteria for new systems which consider the patch management requirements and the system life span.

text: 6.7 NETWORK SECURITY

text: 6.7.1. The relevant entities shall take the appropriate measures to protect their network and information systems from cyber threats.

text: GUIDANCE

text: • Take into account well-known standards when implementing measures for network security ( ).

text: EXAMPLES OF EVIDENCE

text: • Documented network security measures that are based on relevant standards and good practices.

text: 6.7.2. For the purpose of point 6.7.1., the relevant entities shall: (a) document the architecture of the network in a comprehensible and up to date manner; (b) determine and apply controls to protect the relevant entities’ internal network domains from unauthorised access; (c) configure controls to prevent accesses and network communication not required for the operation of the relevant entities; (d) determine and apply controls for remote access to network and information systems, including access by service providers; (e) not use systems used for administration of the security policy implementation for other purposes; (f) explicitly forbid or deactivate unneeded connections and services; (g) where appropriate, exclusively allow access to the relevant entities’ network and information systems by devices authorised by those entities;

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: (h) allow connections of service providers only after an authorisation request and for a set time period, such as the duration of a maintenance operation; (i) establish communication between distinct systems only through trusted channels that are isolated using logical, cryptographic or physical separation from other communication channels and provide assured identification of their end points and protection of the channel data from modification or disclosure; (j) adopt an implementation plan for the full transition towards latest generation network layer communication protocols in a secure, appropriate and gradual way and establish measures to accelerate such transition; (k) adopt an implementation plan for the deployment of internationally agreed and interoperable modern e-mail communications standards to secure e-mail communications to mitigate vulnerabilities linked to e-mail-related threats and establish measures to accelerate such deployment; (l) apply best practices for the security of the DNS and for Internet routing security and routing hygiene of traffic originating from and destined to the network.

text: GUIDANCE

text: • Implement secure-by-design principles by integrating security at every layer of network design including the physical, data link, network, transport and application layers. • Implement secure configurations for wireless networks. • Where appropriate, consider zero-trust ( ) network access. • Identify the technical measures for the transition to the latest network layer communication protocols (e.g. transition to Internet Protocol version 6). • Define roles, responsibilities and timelines for the transition to latest-generation network layer communication protocols. • Approve, log and perform remote maintenance of network and information systems in a manner that prevents unauthorised access. • Consider the following for email communications (indicative, non-exhaustive list): o standards such as Start transport layer security (STARTTLS), DNS-based authentication of named entities (DANE), domain-based message authentication, reporting and& conformance (DMARC), DomainKeys identified mail (DKIM) and sender policy framework ( ), o internal spam/scam/virus filtering and o URL rewriting, URL scanning and URL detonation in a sandbox. • Consider DNS security good practices (indicative, non-exhaustive list): o deploying DNS security extensions (DNS SEC) ( ),

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o deploying protective DNS, wherever technically feasible, to provide additional network-wide security capabilities, o encrypting DNS traffic, both internal and external, wherever feasible, o deploying dedicated DNS servers to reduce attack surface and o following all technical guidance on ensuring that DNS deployments and the DNS protocol are as secure and resilient as possible. • Consider Border Gateway Protocol (BGP) ( ) for internet routing.

text: EXAMPLES OF EVIDENCE

text: • Up-to-date network diagrams, including OOB connections. • Firewall(s) configured in accordance with the network traffic rules of the entity’s policies. • Configuration files and rulesets for firewalls and routers, showing how traffic is filtered and managed. • Secure configurations for wireless networks for example use of WPA3 (encryption), 802.1X with EAP (authentication), firmware updates. • Configuration files for switches, including virtual local access network (VLAN) settings and ACLs. • Documentation of ACLs implemented on network devices to control traffic flow. • Documented correct usage of mobile devices, including the entity’s connected vehicles that can store data locally on the vehicle and/or share data externally by means of telematics and other remote accesses (e.g. teleworking and OOB connections). • Evidence of controls over privileged accounts, including logs and policies. • A list of all devices used (network components), if any, that cannot receive security patches and are not up to date. • Access logs to confirm that only authorised personnel make changes and conduct reviews of the network security rules. • Transition to the latest generation plan for implementing network layer communication protocols.

text: 6.7.3. The relevant entities shall review and, where appropriate, update these measures at planned intervals and when significant incidents or significant changes to operations or risks occur.

text: GUIDANCE

text: • Although the frequency of reviews of network security measures depends on the entity’s risk assessment as a general rule the entity might (indicative, non-exhaustive list): o continuously monitor the networks for real time threats; o perform scans for new vulnerabilities weekly; o review and possibly update the rules of the firewall and other tools monthly; and o thoroughly assess the entire network annually. • Review logs or records of all changes made to the network security rules, including details of the changes, approvals and implementation dates. • Ensure that these reviews are conducted regularly and documented comprehensively.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: EXAMPLES OF EVIDENCE

text: • Plans or schedules for upcoming or completed, regular or ad hoc reviews. • List of reports from past reviews. This should cover various types of reviews. • Logs from firewalls, routers and other network devices showing access attempts, configuration changes and other relevant activities. • Reports from SIEM and EDR/XDR systems showing aggregated and analysed security events. • Virtual private network (VPN) and remote access logs showing remote access, including OOB connections, access attempts, successful connections and any anomalies. • Evidence of network access control (NAC) or other similar and/or alternative solutions, in place, including logs and configuration settings. • Logs or records showing the dates and results of regular reviews of the network security rules. • Logs or records of all changes made to the network security rules. • Logs or records of firewall and ACL reviews. • Documentation showing regular reviews of user and administrative access to network devices. • Audit logs from network security devices (e.g. firewalls, intrusion detection/prevention systems (IDS/IPS)) to ensure that changes and reviews are logged. • Backup files of network device configurations to ensure that changes and reviews are reflected in the backups. • Logs of network security incidents to see if they include documentation of rule set reviews following significant incidents. • Post incident review reports to see if they document reviews and any necessary adjustments to the network security rules.

text: TIPS

text: GUIDANCE

text: • Communicate to personnel the correct usage of mobile devices, including the entity’s connected vehicles and other remote accesses. • Where appropriate, apply solutions capable of collecting, analysing and detecting all anomalies, exfiltrations, intrusions and the most sophisticated threats.

text: EXAMPLES OF EVIDENCE

text: • The correct usage of mobile devices and other remote accesses (e.g. teleworking and VPN) has been communicated to personnel. • Existence of IDS/IPS.

text: TECHNICAL IMPLEMENTATION GUIDANCE 6.8 NETWORK SEGMENTATION

text: 6.8.1. The relevant entities shall segment systems into networks or zones in accordance with the results of the risk assessment referred to in point 2.1. They shall segment their systems and networks from third parties’ systems and networks.

text: GUIDANCE

text: • Take into account well known standards when segmenting networks ( ). • Integrate the segmentation derived from the risk assessment into the network diagram.

text: EXAMPLES OF EVIDENCE

text: • Documented network segmentation rules based on relevant standards and good practices.

text: 6.8.2. For that purpose, the relevant entities shall: (a) consider the functional, logical and physical relationship, including location, between trustworthy systems and services; (b) grant access to a network or zone based on an assessment of its security requirements; (c) keep systems that are critical to the relevant entities operation or to safety in secured zones; (d) deploy a demilitarised zone within their communication networks to ensure secure communication originating from or destined to their networks; (e) restrict access and communications between and within zones to those necessary for the operation of the relevant entities or for safety; (f) separate the dedicated network for administration of network and information systems from the relevant entities’ operational network; (g) segregate network administration channels from other network traffic; (h) separate the production systems for the relevant entities’ services from systems used in development and testing, including backups.

text: GUIDANCE

text: • Make sure that the segments are in line with the results of the risk assessment (Annex to the regulation, point 2.1). • Apply a graduated set of measures in different logical network domains to further segregate the network security environments, including: o publicly accessible systems; o internal networks; o OOB connections; and o assets with high criticality.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Implement subnetworks for publicly accessible system components that are physically and/or logically separate from internal organisational networks. • Determine the degree of physical separation of system components from physically distinct components: o in separate racks in the same room, o in separate rooms for the components with high criticality and o more significant geographical separation of the components with high criticality. • Implement separate network addresses (that is,, different subnets) to connect to systems in different security domains. • Monitor and control communications at the external boundary of the system as well as at key internal boundaries within the system, including segmentation violations. • Where appropriate, isolate information security tools, mechanisms and support components from other internal information system components, where appropriate ( ), by implementing physically separate subnetworks with managed interfaces to other components of the system. • Route all networked, privileged accesses through a dedicated, managed interface for the purposes of access control and auditing. • Implement a managed interface for each external telecommunication service.

text: EXAMPLES OF EVIDENCE

text: • Risk assessments that justify the segmentation decisions. • Interviews with IT and security staff to understand the rationale behind network segmentation. • Up-to-date network diagrams showing segmentation into different networks or zones (e.g. DMZ ( ), internal networks and guest networks). • Verification that the diagrams align with business functions and risk profiles. • Documented criteria for creating and maintaining different network zones. • VLAN configurations on network switches and routers. • VLANs corresponding to different security zones and business functions. • Measures (e.g. IDS/IPS and monitoring systems) tailored to each network zone. • Configurations of network devices (e.g. routers, switches and firewalls) for appropriate segmentation settings. • Configuration settings that match documented segmentation rules and diagrams. • ACLs that consider segregation of duties. • Firewall configurations.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 6.8.3. The relevant entities shall review and, where appropriate, update network segmentation at planned intervals and when significant incidents or significant changes to operations or risks.

text: GUIDANCE

text: • Review and, if necessary, update the process for network segmentation rules at least annually.

text: EXAMPLES OF EVIDENCE

text: • Reports from recent penetration tests and/or vulnerability scans. • Plans or schedules for reviewing network segmentation rules. • Logs or records confirming that the reviews have been conducted in accordance with the schedule. • Change management documentation for network segmentation changes, in line with risk-assessment results and business needs. • Incident response documentation to verify that network segmentation rules are reviewed following significant security incidents. • Post-incident analysis reports that include assessments of segmentation rule effectiveness and any necessary adjustments. • Internal or external audit logs and reports that cover network segmentation rule reviews. • Reviews performed periodically and in response to network changes or incidents. • Minutes from security or IT operations meetings where network segmentation rules are discussed. • Penetration tests and vulnerability assessments that include evaluations of network segmentation. • Tests conducted periodically and after major changes or incidents and findings leading to rule reviews.

text: TIPS

text: GUIDANCE

text: • Limit the data traffic between the different segments to the operationally required extent by means of data flow control for example a firewall. • Connect to external networks or information systems only through managed interfaces consisting of boundary protection devices arranged in accordance with the entity’s security architecture such as: o gateways; o routers; o firewalls; o network-based malicious code analysis; o virtualisation systems; and o encrypted tunnels. • Prevent discovery of specific system components composing a managed interface. • Monitor exceptions.

text: EXAMPLES OF EVIDENCE

text: • Network isolation and implementation of segmented network security zones that limit the impact of a malicious software incident. • Logging and monitoring active for each zone. • Alerts for segmentation rule violations. • Reviews triggered by alerts to segmentation violations.

text: TECHNICAL IMPLEMENTATION GUIDANCE 6.9 PROTECTION AGAINST MALICIOUS AND UNAUTHORISED SOFTWARE

text: 6.9.1. The relevant entities shall protect their network and information systems against malicious and unauthorised software. 6.9.2. For that purpose, the relevant entities shall in particular implement measures that detect or prevent the use of malicious or unauthorised software. The relevant entities shall, where appropriate, ensure that their network and information systems are equipped with detection and response software, which is updated regularly in accordance with the risk assessment carried out pursuant to point 2.1 and the contractual agreements with the providers.

text: GUIDANCE

text: • Employ mechanisms for detecting and protecting against malicious and unauthorised software at system entry and exit points and at workstations, servers and mobile computing devices on the network to detect and eradicate malicious code transported by electronic mail, electronic mail attachments, web accesses or removable media or inserted through the exploitation of system vulnerabilities. • Configure malicious code protection mechanisms to: o be active all the time; o perform periodic scans of the system regularly and real-time scans of files from external sources as the files are downloaded, opened or executed; o generate notifications when suspected malicious and unauthorised software is detected; o disinfect and quarantine infected files; and o restore system settings and ensure that critical settings cannot be disabled or restricted. • Apply application whitelisting and monitor unauthorised activities and system behaviour, where appropriate. • Make sure that the malicious and unauthorised protection mechanisms are centrally managed, where appropriate. • Make sure that there are mechanisms that prevent users from circumventing malicious and unauthorised software protection capabilities. • Make sure that spam protection mechanisms are employed at system entry points such as workstations, servers or mobile computing devices on the network. • Update malicious code protection mechanisms (including signature definitions) whenever new releases are available in accordance with configuration rules and the entity’s patch management procedures. • Address issues related to false positives during malicious code detection and eradication and the resulting potential impact on system availability. • Align rules for monitoring and logging malicious and unauthorised detection and repair software with the entity’s monitoring and logging tools and procedures (Annex to the regulation, point 3.2) and with the entity’s access control (Annex to the regulation, point 11.1) and asset-handling policy.

text: EXAMPLES OF EVIDENCE

text: • Endpoint protection systems (EPS), such as endpoint protection platform (EPP) and endpoint detection and response (EDR), across the network. • Malware detection system present and up to date. • Tools for monitoring unauthorised software is in place and up to date. • Firewall configurations, IDS/IPS and secure web gateways containing malicious and unauthorised software protection measures. • Use of whitelisting solutions, which restrict the execution of non-approved software and code.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Rules and configurations related to application whitelisting up to date. • Documented description of centrally managed tools. • Records of recent updates of mechanisms for detecting and protecting against malicious/unauthorised software showing that they are regularly patched and updated to protect against known vulnerabilities. • Records of periodic scans. • Monitoring and logging of network and information systems, at intervals to identify malicious code and unauthorized code execution. • Logs of blocked or detected threats. • Logs recorded and maintained covering: o user activities; o exceptions; and o information security incidents. • Documented spam protection mechanism. • Risk assessment to determine the level of logs monitoring required.

text: TIPS

text: GUIDANCE

text: • Consider that the use of malicious and unauthorised detection and repair software alone is not usually adequate or may not be available, so it should be complemented by additional measures such as (indicative, non-exhaustive list): o implementing rules and measures that prevent or detect the use of unauthorised software; o implementing measures that prevent or detect the use of known or suspected malicious websites; o reducing vulnerabilities that can be exploited by malicious software; o controlling the running of applications on user workstations or user end devices (including smartphones or tablets); o employing web application filters to reduce exposure to malicious content. • Consider email filters as essential tools for detecting and blocking malicious and unauthorised software. Different types of filter are (indicative, non-exhaustive list): o content filter; o blocklist filter; o antivirus filter; o phishing filters; and o machine learning filters.

text: EXAMPLES OF EVIDENCE

text: • Documented alternative countermeasures such as: o securing all physical and logical data interfaces; o network isolation and implementation of segmented network security zones that limit the impact of a malicious software incident; o comprehensive system-hardening measures to minimise the risk of malicious software incidents. o logs confirming that administrative privileges are controlled and monitored. • Logs from email filters.

text: TECHNICAL IMPLEMENTATION GUIDANCE 6.10 VULNERABILITY HANDLING AND DISCLOSURE

text: 6.10.1. The relevant entities shall obtain information about technical vulnerabilities in their network and information systems, evaluate their exposure to such vulnerabilities and take appropriate measures to manage the vulnerabilities.

text: GUIDANCE

text: • Adopt a framework for assessing the severity of vulnerabilities based on models (e.g. CVSS, exploit prediction scoring system (EPSS) or SANS vulnerability assessment framework) and supplemented by environmental and threat metrics as appropriate.

text: EXAMPLES OF EVIDENCE

text: • Documentation of a risk-assessment framework used to evaluate the severity, impact and probability of exploitation of identified vulnerabilities (e.g. CVSS scores).

text: 6.10.2. For the purpose of point 6.10.1., the relevant entities shall: (a) monitor information about vulnerabilities through appropriate channels, such as announcements of CSIRTs, competent authorities or information provided by suppliers or service providers; (b) perform, where appropriate, vulnerability scans and record evidence of the results of the scans, at planned intervals; (c) address, without undue delay, vulnerabilities identified by the relevant entities as critical to their operations; (d) ensure that their vulnerability handling is compatible with their change management, security patch management, risk management and incident management procedures; (e) lay down a procedure for disclosing vulnerabilities in accordance with the applicable national coordinated vulnerability disclosure policy.

text: GUIDANCE

text: • As a minimum, address vulnerabilities assigned to higher classifications (e.g. ‘critical’ and ‘high’ in the CVSS) or equivalent (e.g. as defined by the national CSIRT) without undue delay. Where possible, accepting the risk of such vulnerabilities and not addressing them is not advisable. • Share information obtained from technical vulnerability scans with designated personnel throughout the entity and with authorities to help eliminate similar vulnerabilities in other information systems. • Disclose as yet unknown vulnerabilities to designated CSIRTs in accordance with national coordinated vulnerability disclosure (CVD) policies, where applicable. • Identify a single point of contact and channels for communication with suppliers and service providers about issues related to network and information security.

text: EXAMPLES OF EVIDENCE

text: • Logs of a vulnerability assessed as critical to check if it was addressed. • Licences or subscriptions for vulnerability-scanning tools. • Configuration files of the vulnerability-scanning tools to ensure they are set up to scan the entire relevant infrastructure and are updated with the latest vulnerability definitions. • Logs from vulnerability management tools showing scan schedules, results and follow-up actions. • Documented technical vulnerability scan reports. • SIEM and EDR/XDR logs for records of detected vulnerabilities and related alerts from monitoring channels. • Reports from third-party security assessments or penetration tests. • For vulnerabilities assessed as critical, evidence that findings from these assessments have been addressed. • Records of any vulnerabilities disclosed, in accordance with the national CVD policy.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Interview with the single point of contact and channels for communication with suppliers and service providers about information-security-related issues.

text: 6.10.3. When justified by the potential impact of the vulnerability, the relevant entities shall create and implement a plan to mitigate the vulnerability. In other cases, the relevant entities shall document and substantiate the reason why the vulnerability does not require remediation.

text: GUIDANCE

text: • Ensure comprehensive documentation of identified vulnerabilities, the associated risk assessments and any mitigation plans developed. • Define and establish the roles and responsibilities associated with vulnerability management. • Mitigation plans should include clear timelines, assigned responsibilities and follow-up procedures. • All mitigation plans, along with the rationale for non-remediation decisions, should be reviewed and validated by the management body responsible for risk oversight

text: EXAMPLES OF EVIDENCE

text: • Records showing timelines and responsible employees for each remediation effort and verification of fixes. • Records or logs of past vulnerability mitigation plans or schedules. • Records of any vulnerability that was not addressed and the justification for not addressing it.

text: 6.10.4. The relevant entities shall review and, where appropriate, update at planned intervals the channels they use for monitoring vulnerability information.

text: GUIDANCE

text: • Review the information from the technical-vulnerability-monitoring channels at least biannually. • Consider inventorying sources likely to report technical vulnerabilities in the identified components and distribute updates (software publisher websites, CERT website and ENISA website) ( ).

text: EXAMPLES OF EVIDENCE

text: • List of monitoring channels for technical vulnerabilities, including suppliers and service providers’ single points of contact. • Records of past reviews and plans for future reviews of technical vulnerability channels. • Subscriptions to relevant vulnerability notification services, mailing lists and alert systems (e.g. CERT, vendor advisories and security forums). • Logs that document periodic reviews of the monitoring channels to verify that they are up to date and effective. • Records of alerts or notifications received from monitoring channels about new vulnerabilities, including how these alerts were handled and any subsequent actions taken. • Logs that record the monitoring activities for vulnerability information, including dates and sources monitored (e.g. security advisories, vendor bulletins, threat intelligence feeds).

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: TIPS

text: GUIDANCE

text: • Create and maintain procedures for identifying, assessing, prioritising and remediating vulnerabilities. • Make sure that suppliers and service providers report vulnerabilities in their systems or products or services that present a risk to the security of the network and information systems of the entity. • Perform vulnerability scans and record evidence of the results of the scans, when significant incidents or significant changes to operations or risks occur. • Where possible, consider authenticated vulnerability or an alternative method to perform in depth scans. • Review and, where appropriate, update the channels for monitoring vulnerability information when significant incidents or significant changes to operations or risks occur.

text: EXAMPLES OF EVIDENCE

text: • Documented procedures for identifying, assessing, prioritising and remediating vulnerabilities. • Contracts with suppliers and service providers that require technical vulnerability reporting, handling and disclosure. • Vulnerability-related communications or reports from suppliers and service providers. • Records of ad-hoc scans performed in response to significant incidents or changes to the infrastructure, including the dates and reasons for these scans. • Change management logs to verify that vulnerability scans are conducted following significant incidents or changes to the infrastructure or to the threat landscape. • Records of internal audits or reviews of the vulnerability management procedures. • Findings and corrective actions taken from these audits.

text: Chapter 7

text: POLICIES

text: AND TO

text: PROCEDURES

text: THE

text: ASSESS

text: OF

text: EFFECTIVENESS CYBERSECURITY RISK-MANAGEMENT MEASURES

text: TECHNICAL IMPLEMENTATION GUIDANCE 7. POLICIES AND PROCEDURES TO ASSESS THE EFFECTIVENESS OF CYBERSECURITY RISK- MANAGEMENT MEASURES

text: 7.1. For the purpose of

text: Article 21(2)

text: , point (f) of

text: Directive (EU) 2022/2555

text: , the relevant entities shall establish, implement and apply a policy and procedures to assess whether the cybersecurity risk-management measures taken by the relevant entity are effectively implemented and maintained.

text: GUIDANCE

text: • Take into account industry-recognised standards when developing the policy and procedures for assessing the efficient implementation of the measures ( ). • Implement a policy for assessing the effectiveness of implementation of measures that is proportionate to the risk posture of the entity in line with the risk assessment.

text: EXAMPLES OF EVIDENCE

text: • Documented policy and procedures for effectiveness assessments based on good practices and standards ( ).

text: 7.2. The policy and procedures referred to in point 7.1. shall take into account results of the risk assessment pursuant to point 2.1. and past significant incidents. The relevant entities shall determine: (a) what cybersecurity risk-management measures are to be monitored and measured, including processes and controls; (b) the methods for monitoring, measurement, analysis and evaluation, as applicable, to ensure valid results; (c) when the monitoring and measuring is to be performed; (d) who is responsible for monitoring and measuring the effectiveness of the cybersecurity risk-management measures; (e) when the results from monitoring and measurement are to be analysed and evaluated; (f) who has to analyse and evaluate these results.

text: GUIDANCE

text: • When selecting measures for assessing effectiveness of implementation take into account the cost of their implementation. • Consider one or more of the following indicative methods for assessing the effectiveness of implementation of a measure, according to the risk-treatment plan (section 2.1):

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o self-assessment, o benchmarking against a measure’s checklist or a standard, o vulnerability assessment, o penetration testing (e.g. internal, external, red/blue team), o secure code review, o audit (e.g. internal, external, compliance) and o performance monitoring. • The assessment service can be provided by an external entity or by specially authorised employees of the entity. o In the case of external entities, confidentiality and non-disclosure terms should be included in the contract. o Internal employees should be suitably trained, based on the skills required for the objective of their role and the entity should consider their objectivity and impartiality, where possible. The entity should pay particular attention to the elements of point 2.3. of the Annex to the regulation concerning the impartiality of the employees. For instance, employees should not come from the department or division whose systems are being inspected and should not have been involved in developing the code or in installing or operating the system being audited for this purpose. • Define key performance indicators (KPIs) to measure the effectiveness of measures including, one or more, notable examples such as (indicative, non-exhaustive list) ( ): o the cost of implementation and maintenance, for example capital expenditure (CAPEX) / operational expenditure (OPEX); o the number of employees who have attended cybersecurity trainings ( ); o the number of vulnerabilities detected; o time to remediation; o the number of incidents; o the number of incidents related to a change; o incident response times; and o number of non-compliances (consider the elements in point 2.2 of the Annex to the regulation concerning compliance monitoring). • If possible, use the same KPIs for each assessment and utilize standardized templates and checklists to ensure consistency and thoroughness. • Although the frequency of monitoring and measurement of measures, addressed in point 7.2.1 (a) of the Annex to the regulation, depends on the entity's risk assessment, the entity may follow this indicative, nonexhaustive guideline: o continuously monitor and measure the effectiveness of mitigating measures designed to address real-time threats (e.g. firewalls, IDS/IPS); o monitor and measure the effectiveness of security measures related to the threat landscape biannually (e.g. vulnerability management and incident response plans); o assess the overall effectiveness of all measures annually; o assess the effectiveness of measures related to a specific incident following that incident; and

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o assess the effectiveness of measures related to a specific system or one of its components following significant changes to this system or this component.

text: EXAMPLES OF EVIDENCE

text: • Evidence that management has received reporting on the effective implementation of the measures. • Evidence that monitoring and measurement results are reported to the management bodies (Annex to the regulation, point 2.3.3 concerning compliance monitoring). • Documented objectives and KPIs for the implementation of the measures. • Documented analysis and evaluation of the results from previous evaluations. • Logs or records from previous effectiveness assessments. • Plans or schedules for future effectiveness assessments. • Documented roles and responsibilities.

text: 7.3. The relevant entities shall review and, where appropriate, update the policy and procedures at planned intervals and when significant incidents or significant changes to operations or risks.

text: GUIDANCE

text: • Review policy and procedures for the assessment of the effectiveness of the measures at least every two years, taking into account: o changes to the information systems; o changes to the environment of operation; and o trends related to threats and vulnerabilities (take into account root cause analysis) ( ). • Update the policy and procedures based on findings from security tests (Annex to the regulation, point 6.5.2 (c)) and the independent review of the policy on the security of the network and information systems (Annex to the regulation, point 2.3.3), if applicable. • Take into account the results of the assessment and consider them when identifying and prioritising appropriate risk-treatment options and measures (Annex to the regulation, point 2.1.3).

text: EXAMPLES OF EVIDENCE

text: • Logs or records from previous policy reviews. • Plans or schedules for future effectiveness assessment reviews. • Risk-treatment plan that takes into account the results of the effectiveness assessments. • Minutes from meetings where security-testing results are discussed and the effectiveness of other policies is reviewed and improvements to them are discussed based on these results. • Records showing updates to other policies and procedures with a view to assessing their effectiveness.

text: Chapter 8

text: BASIC CYBER HYGIENE PRACTICES

text: AND

text: SECURITY TRAINING

text: TECHNICAL IMPLEMENTATION GUIDANCE 8. BASIC CYBER HYGIENE PRACTICES AND SECURITY TRAINING 8.1 AWARENESS RAISING AND BASIC CYBER HYGIENE PRACTICES

text: 8.1.1. For the purpose of

text: Article 21(2)

text: , point (g) of

text: Directive (EU) 2022/2555

text: , the relevant entities shall ensure that their employees are aware of risks, are informed of the importance of cybersecurity and apply cyber hygiene practices.

text: GUIDANCE

text: • Implement cybersecurity awareness programmes: o use various formats, such as workshops, webinars and e-learning modules; o use multiple communication channels (emails, newsletters and intranet) to keep employees informed about cybersecurity updates, risks and cyber hygiene practices for users.

text: EXAMPLES OF EVIDENCE

text: • Awareness raising programme, for example a comprehensive outline of the programme, detailing its objectives, content, frequency, syllabus and schedule.

text: 8.1.2. For the purpose of point 8.1.1., the relevant entities shall offer to all employees, including members of management bodies, as well as to direct suppliers and service providers where appropriate in accordance with point 5.1.4, an awareness raising programme, which shall: (a) be scheduled over time, so that the activities are repeated and cover new employees; (b) be established in line with the network and information security policy, topic-specific policies and relevant procedures on network and information security; (c) cover cybersecurity risk-management measures in place, contact points and resources for additional information and advice on cybersecurity matters, as well as cyber hygiene practices for users.

text: GUIDANCE

text: • Include cyber hygiene practices ( ) for relevant users (indicative, non-exhaustive list): o clear desk and screen policy, o use of relevant strong authentication means and methods, multi factor passwords etc, o event reporting, o safe email use and web browsing, o protection from phishing and social engineering, o secure use of mobile devices, o secure use of the entity’s connected-vehicles, o secure connection practices,

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o backup practices, o zero-trust concept, o software updates, o secure device configuration, o network segmentation, o secure teleworking practices. • Include the following in the programme (indicative, non-exhaustive list). o Train personnel on the policy on the security of network and information systems. o Train personnel to recognize social engineering attacks, such as phishing, pre-texting and tailgating. o Train personnel to be aware of causes of unintentional data exposure. Example topics include the erroneous delivery of sensitive data, losing a portable end-user device, providing unauthorized access to an entity’s connected-vehicle and the data stored on it and publishing data to unintended audiences. o Train personnel on the dangers of connecting to and transmitting data via insecure networks for the entity’s activities. If the entity has remote workers, training should include guidance to ensure that all users securely configure their home network infrastructure. o Train personnel in understanding malicious and unauthorised software, on the importance of malicious software detection and on the risks and consequences of using unauthorised software. • Offer employees contact points and resources for additional advice. • To implement the awareness raising programme, consult available sources, such as those from national or international cybersecurity organisations, ENISA’s AR-in-a-Box ( ) and the Cybersecurity Skills Academy ( ).

text: EXAMPLES OF EVIDENCE

text: • Awareness raising programme, that is, a comprehensive outline of the programme, detailing its objectives, content, frequency, syllabus and schedule. • Copies of the awareness-raising materials distributed to employees, including handouts, emails, presentations and online modules. • Logs, sign-in sheet, certificates of completion or acknowledgements given to employees upon completing the programme, showing which employees have taken part in the awareness-raising programme.

text: 8.1.3. The awareness raising programme shall, where appropriate, be tested in terms of effectiveness. The awareness raising programme shall be updated and offered at planned intervals taking into account changes in cyber hygiene practices, and the current threat landscape and risks posed to the relevant entities.

text: GUIDANCE

text: • Offer cybersecurity awareness raising programmes periodically.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Test the effectiveness of the awareness raising programme for example by using quizzes or real scenarios. • Consider common KPIs (Annex to the regulation, point 7.2) to measure the effectiveness of the awareness-raising programme. • Review and update the awareness-raising programme at least annually.

text: EXAMPLES OF EVIDENCE

text: • Logs, sign-in sheets, certificates of completion or acknowledgements given to employees upon completing the programme showing which employees have taken part in the awareness-raising programme. • Results from any quizzes or assessments conducted to measure the employees’ understanding of the topics covered. • Employee feedback forms on the awareness raising programme, which can provide insight into the effectiveness of the programme and areas for improvement. • Reviewed and updated records showing that the programme is reviewed regularly and updated as necessary.

text: 8.2 SECURITY TRAINING

text: 8.2.1. The relevant entities shall identify employees, whose roles require security relevant skill sets and expertise and ensure that they receive regular training on network and information system security.

text: GUIDANCE

text: • Assess which roles within the entity require security-relevant skills and expertise. • Offer training that focuses on the specific security skills required by the identified roles. • Consider globally recognized qualifications and certifications, and the ECSF ( ).

text: EXAMPLES OF EVIDENCE

text: • A comprehensive outline of the training programme, detailing the objectives for different roles and how to reach them, content and frequency of the training.

text: 8.2.2. The relevant entities shall establish, implement and apply a training program in line with the network and information security policy, topic-specific policies and other relevant procedures on network and information security which lays down the training needs for certain roles and positions based on criteria.

text: GUIDANCE

text: • Provide role-specific network and information security training ( ). • Consider various training methods, such as online courses, workshops, hands-on labs and simulations. • Consider various types of training, such as courses, certifications or attending security conferences or webinars, and the maintenance of certifications.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Examples of training may include secure system administration courses for IT professionals, Open Worldwide Application Security Project® awareness and prevention training for web application developers and advanced social engineering awareness training for high-profile roles.

text: EXAMPLES OF EVIDENCE

text: • A comprehensive outline of the training programme, detailing the objectives for different roles and how to reach them, content and frequency of the training. • Assessment of effect and feedback from trainings.

text: 8.2.3. The training referred to in point 8.2.1. shall be relevant to the job function of the employee and its effectiveness shall be assessed. Training shall take into consideration security measures in place and cover the following: (a) instructions regarding the secure configuration and operation of the network and information systems, including mobile devices; (b) briefing on known cyber threats; (c) training of the behaviour when security-relevant events occur.

text: GUIDANCE

text: • Topics to include in the programme may include the following (indicative, non-exhaustive list). o Train personnel in authentication best practices, such as MFA, password creation and credential management. o Train personnel in how to identify and properly store, transfer, archive and destroy sensitive data. o Train personnel to recognise a potential incident, such as unusual email attachments, unexpected system behaviour and suspicious network traffic. o Train personnel in how to report events promptly and accurately, including the use of designated communication channels. o Train personnel to understand how to verify and report out-of-date software or any failures in automated processes and tools. Part of this training should include notifying IT personnel of any failures in automated processes and tools. o Train relevant personnel in crisis management and business continuity procedures. Incorporate simulated events ( ) into crisis management training to facilitate an effective response by personnel in crisis situations. o Train relevant personnel (e.g. system administrators and software developers) in the secure configuration and operation of the network and information systems. Provide regular updates on the latest cyber threats. • Test the security knowledge of employees to make sure that it is sufficient and up to date.

text: EXAMPLES OF EVIDENCE

text: • Comprehensive outline of the training programme, detailing the objectives of different roles and how to reach them, and the content and frequency of the training. • Results from any quizzes or assessments conducted to measure the employees’ understanding of the topics covered.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 8.2.4. The relevant entities shall apply training to staff members who transfer to new positions or roles which require security relevant skill sets and expertise.

text: GUIDANCE

text: • Examine whether the new position or role of an employee requires role-specific network and information security training.

text: EXAMPLES OF EVIDENCE

text: • Logs, sign-in sheets, certificates of completion or acknowledgements given to employees upon completing the training, showing that employees who transferred to new positions or roles attended training sessions relevant to the new position or role. • Evidence of maintenance of certifications obtained.

text: 8.2.5. The program shall be updated and run periodically taking into account applicable policies and rules, assigned roles, responsibilities, as well as known cyber threats and technological developments.

text: GUIDANCE

text: • Provide cybersecurity training periodically. • Review and update the training programme at least annually.

text: EXAMPLES OF EVIDENCE

text: • Logs, sign-in sheets, certificates of completion or acknowledgements given to employees upon completing the training, showing which employees attended the training sessions. • Information materials distributed to employees, including handouts, presentations and online modules. • Updates showing that the training programme is reviewed and updated regularly to keep up with the latest cybersecurity threats and best practices. • Employee feedback forms on the training sessions, which can provide insight into the effectiveness of the training and areas for improvement.

text: TIP

text: GUIDANCE

text: • Encourage participation in threat-intelligence-sharing communities to stay informed about emerging threats.

text: Chapter 9

text: CRYPTOGRAPHY

text: TECHNICAL IMPLEMENTATION GUIDANCE 9. CRYPTOGRAPHY

text: 9.1. For the purpose of

text: Article 21(2)

text: , point (h) of

text: Directive (EU) 2022/2555

text: , the relevant entities shall establish, implement and apply a policy and procedures related to cryptography, with a view to ensuring adequate and effective use of cryptography to protect the confidentiality, authenticity and integrity of data in line with the relevant entities’ asset classification and the results of the risk assessment carried out pursuant to point 2.1.

text: GUIDANCE

text: • Ensure that the comprehensive policy and procedures related to cryptography are in line with relevant regulations and state-of-the-art standards ( ).

text: EXAMPLES OF EVIDENCE

text: • Documented policy on cryptography and procedures related to cryptography.

text: 9.2. The policy and procedures referred to in point 9.1 shall establish: (a) in accordance with the relevant entities’ classification of assets, the type, strength and quality of the cryptographic measures required to protect the relevant entities’ assets, including data at rest and data in transit; (b) based on point (a), the protocols or families of protocols to be adopted, as well as cryptographic algorithms, cipher strength, cryptographic solutions and usage practices to be approved and required for use in the relevant entities, following, where appropriate, a cryptographic agility approach; (c) the relevant entities’ approach to key management, including, where appropriate, methods for the following: (i) generating different keys for cryptographic systems and applications; (ii) issuing and obtaining public key certificates; (iii) distributing keys to intended entities, including how to activate keys when received; (iv) storing keys, including how authorised users obtain access to keys; (v) changing or updating keys, including rules on when and how to change keys; (vi) dealing with compromised keys; (vii) revoking keys including how to withdraw or deactivate keys; (viii) recovering lost or corrupted keys; (ix) backing up or archiving keys; (x) destroying keys; (xi) logging and auditing of key management-related activities; (xii) setting activation and deactivation dates for keys ensuring that the keys can only be used for the specified period of time according to the organization's rules on key management.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: GUIDANCE

text: • Ensure that the policy and procedures cover cryptographic mechanisms, such as digital signatures ( ) and hashes ( ), to: o protect the confidentiality and integrity of data in transit and at rest; o detect unauthorized changes to data at rest marked as critical; and o ensure secure disposal of the data after its lawful use. • Set up a mechanism (either manual or automated) for the selection, establishment and management (including updating) of cryptographic keys. • Apply encryption in sensitive information transfer (e.g. key generation and key management). • Consider the encryption of electronic media that contain confidential/sensitive information. • Ensure the confidentiality and integrity of the data with cryptographic mechanisms, when, for example (indicative, non-exhaustive list): o sharing information; o scanning network traffic; o using secure online (e.g. client-side cloud encryption) and offline storage; and o removing sensitive data from storage media. • Maintain availability of information in the event of the loss of cryptographic keys, for example by escrowing encryption keys. • Produce, control and distribute symmetric and asymmetric cryptographic keys using key management technology and processes. • Consider automated cryptographic key management mechanisms to: o generate keys for different cryptographic systems and different applications; o generate and obtaining public key certificates; o distribute keys to intended users; and o deal with compromised keys. • Keep logs of cryptographic key management activities to ensure accountability, traceability and support for incident response and audit activities. As a minimum, logging should include key generation or renewal, key transmission and key destruction or revocation. • Where applicable, key retrieval, archiving and storage activities should also be logged, particularly in environments where manual handling or high-assurance key protection is required. • Ensure the protection of cryptographic keys against modification and loss. • Ensure the protection of secret and private keys against unauthorized use and disclosure. • Ensure the authenticity of public keys. • Physically protect equipment used to generate, store and archive keys. • Limit the use of ad hoc cryptographic processes. • Consider, where appropriate, a cryptographic agility approach ( ). Key features of this approach are: o flexibility in algorithm selection;

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o modular design of the architecture whereby cryptographic components can be changed or updated independently without affecting the entire system; o regular updates and patching; o compliance with the legislative frameworks and governance of the use of cryptography within the entity’s networks and information systems; o future-proofing by considering quantum cryptographic algorithms. • Consider evaluating the chosen encryption methods to verify that they meet industry standards for secure methods ( ).

text: EXAMPLES OF EVIDENCE

text: • Documented policy on cryptography in line with relevant regulations and state-of-the-art standards. • Documented guidelines for encryption. 88 89 • Acceptable encryption algorithms, key lengths, protocols ( ) or family of protocols ( ) in line with the state of the art. • Safeguards to protect the secrecy of secret (private) key(s) in place. • Evidence of the existence of cryptographic mechanisms that support ensuring the confidentiality and integrity of the data at rest and in transit. • Evidence of the existence of a mechanism (either manual or automated) for the establishment and management of cryptographic keys. • Evidence of encryption implementation on various systems (e.g. databases, files, communications). • Access control mechanisms for cryptographic keys and encrypted data. • Verification that access is restricted to authorized personnel and that actions related to cryptographic keys are logged and monitored. • Assessments of cryptographic measures for protecting data privacy. • Evidence of secure key generation. • Internal or external audit reports focusing on cryptographic measures. • Evidence that the entity follows cryptographic best practices, including documentation of how new best practices are identified and incorporated.

text: 9.3. The relevant entities shall review and, where appropriate, update their policy and procedures at planned intervals, taking into account the state of the art in cryptography.

text: GUIDANCE

text: • Ensure the cryptography policy aligns with relevant industry standards and with advancements in the field. • Review the cryptography policy and procedures at least annually. • Maintain a procedure that specifies how reviews of the cryptography policy and procedures are conducted, including responsible personnel and review intervals.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Ensure that changes to the cryptographic measures are tested before being applied. • Ensure that changes to the cryptographic measures are communicated to employees.

text: EXAMPLES OF EVIDENCE

text: • Logs of changes made to the cryptography policy and procedures • Test plans and results that demonstrate the implementation and effectiveness of updated cryptographic measures. • Records of notifications or reminders sent to relevant personnel about upcoming reviews of the cryptography policy and procedures. • Communication records informing personnel about updates to the cryptography policy following advancements in the field or significant changes. • Evidence that the entity remains up to date with the latest developments in cryptography (e.g. member of cryptographic bodies or consortia (e.g. Internet Engineering Task Force and cryptographic research groups) and subscriptions to cryptographic journals/feeds, mailing lists or news feeds).

text: TIPS

text: GUIDANCE

text: • Train employees and make them aware of the use of cryptographic measures in the entity. • Make sure network and information systems automatically encrypt and secure all portable and removable media. • Where appropriate, consider implementing a key management system to ensure the secure handling of cryptographic keys.

text: EXAMPLES OF EVIDENCE

text: • Records of training programmes related to cryptography for employees. • Employees aware of the confidentiality and integrity of data, communications and procedures and what they imply for their work. • Employees handling sensitive information aware of and understanding the cryptography policies and procedures. • Key management system in place.

text: Chapter 10

text: HUMAN RESOURCES SECURITY

text: TECHNICAL IMPLEMENTATION GUIDANCE 10. HUMAN RESOURCES SECURITY 10.1 HUMAN RESOURCES SECURITY

text: 10.1.1. For the purpose of

text: Article 21(2)

text: , point (i) of

text: Directive (EU) 2022/2555

text: , the relevant entities shall ensure that their employees and direct suppliers and service providers, wherever applicable, understand and commit to their security responsibilities, as appropriate for the offered services and the job and in line with the relevant entities’ policy on the security of network and information systems.

text: GUIDANCE

text: • Define clear security roles and responsibilities for employees, aligned with the entity’s security policies and each employee’s functional role. Define relevant security responsibilities for direct suppliers and service providers, within the scope of contractual obligations, ensuring they are appropriate to the nature of the services provided and aligned with the entity’s overall security requirements. • Establish onboarding and continuous education programmes that include both security awareness and role-specific cybersecurity training tailored to different risk exposures. • Implement periodic assessments to evaluate understanding of security responsibilities, supported by mandatory refresher training as needed. • Ensure that security responsibilities are formally documented and integrated into job descriptions, contractual agreements and performance review processes. Incorporate relevant security responsibilities into contractual agreements or service-level agreements (SLA), for direct suppliers and service providers with clear language regarding expectations and compliance requirements. • Promote a culture of accountability by requiring formal acknowledgement of security obligations and by linking compliance to incentives and disciplinary measures, where appropriate. • Develop and maintain a centralized repository of training records, acknowledgements, certifications and contractual clauses to demonstrate compliance and facilitate audits. • Require suppliers and service providers to designate responsible contacts for cybersecurity and encourage or mandate participation in relevant security briefings or training programmes provided by the entity.

text: EXAMPLES OF EVIDENCE

text: • List of employees whose roles require specific security skills and their assignment to roles. • Documented evidence of regular training sessions on security of network and information systems for employees, direct suppliers and service providers, wherever applicable. This includes attendance records, training materials and feedback forms. • Signed acknowledgements from employees, direct suppliers and service providers, wherever applicable, confirming they have read, understood and agreed to comply with the policy. • Reports from internal or external audits assessing the understanding and implementation of security responsibilities among employees, direct suppliers and service providers, wherever applicable. • Inclusion of security responsibilities, where relevant, in employee performance reviews and evaluations.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Contracts with direct suppliers and service providers that include clauses on security responsibilities and compliance with the entity’s policies or written justifications by the direct supplier or service provider in cases where these clauses do not exist in the contract. • Certifications or attestations of cybersecurity skills from nationally recognized or accredited bodies confirming that a person fulfils specific requirements regarding cybersecurity knowledge and skills.

text: 10.1.2. The requirement referred to in point 10.1.1. shall include the following: (a) mechanisms to ensure that all employees, direct suppliers and service providers, wherever applicable, understand and follow the standard cyber hygiene practices that the entities apply pursuant to point 8.1.; (b) mechanisms to ensure that all users with administrative or privileged access are aware of and act in accordance with their roles, responsibilities and authorities; (c) mechanisms to ensure that members of management bodies understand and act in accordance with their role, responsibilities and authorities regarding network and information system security; (d) mechanisms for hiring personnel qualified for the respective roles, such as reference checks, vetting procedures, validation of certifications or written tests.

text: GUIDANCE

text: • Implement regular awareness raising on cyber hygiene practices for users, tailored to different roles and responsibilities (Annex to the regulation, point 8.1). Wherever applicable, require employees of direct suppliers and service providers, to follow similar awareness raising on cyber hygiene via contractual clauses. • Communicate clear and concise cyber hygiene practices for users to all employees, suppliers and service providers. Require acknowledgement of receipt and understanding (Annex to the regulation, point 8.1). • Consider specialised training for users with administrative or privileged access, focusing on their specific responsibilities (Annex to the regulation, point 8.2). • Establish performance metrics related to security responsibilities and include them in management evaluations. • Hold regular briefings for members of management bodies on the importance of network and information system security, their specific responsibilities and the potential impact of incidents (section 8.2). • Conduct thorough reference checks, where appropriate, to verify the candidate’s previous experience and performance in similar roles. • Consider vetting procedures, including background checks (section 10.2), to ensure the candidate’s suitability for the role. • Validate any relevant certifications claimed by the candidate, to ensure they are current and legitimate. • Use written tests or practical assessments to evaluate the candidate’s knowledge and skills related to network and information system security. • Use interview panels, where appropriate, that also include security experts, to assess the candidate’s technical and behavioural competencies.

text: EXAMPLES OF EVIDENCE

text: • Training and awareness raising material such as videos, slides, emails, newsletters, posters and intranet announcements.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Documented records showing that all users with administrative or privileged access were properly informed and are aware of and are following their network and information security roles, responsibilities and authorities. • Contractual agreements, the policy on the security of network and information systems, terms and conditions, code of conduct and other documentation confirming that all users have understood and are following the standard cyber hygiene practices for users (signed employment contracts and any proof of employees having been informed of their responsibilities relating to network and information security). • Records of security training sessions provided to employees, including attendance logs and training schedules. • Evidence, for example attendance certificates where relevant, that suppliers and service providers receive security training relevant to their roles. • Mechanisms for hiring qualified personnel (e.g. reference check, validation of certifications and written tests) in place. • Use of relevant cybersecurity frameworks and standards along with widely recognised quality management and capability maturity models and standards.

text: 10.1.3. The relevant entities shall review the assignment of personnel to specific roles as referred to in point 1.2., as well as their commitment of human resources in that regard, at planned intervals and at least annually. They shall update the assignment where necessary.

text: GUIDANCE

text: • Set up a formal schedule for reviewing personnel assignments and resource commitments. This should occur at least annually.

text: EXAMPLES OF EVIDENCE

text: • Up-to-date list of employees and their assignment to roles. • Records of the review process, including the criteria used, the findings and any changes made.

text: 10.2 VERIFICATION OF BACKGROUND

text: 10.2.1. The relevant entities shall ensure to the extent feasible verification of the background of their employees and where applicable of direct suppliers and service providers in accordance with point 5.1.4, if necessary for their role, responsibilities and authorisations.

text: GUIDANCE

text: • Identify which roles, responsibilities and authorities require verification of background, based on the criteria in point 10.2.2 (a) of the Annex to the regulation. • Perform background verification on employees and, where applicable, direct suppliers and service providers in accordance with point 5.1.4 (c) of the Annex to the regulation.

text: EXAMPLES OF EVIDENCE

text: • Documented background verification process. • Results of background verification on employees and, where applicable, direct suppliers and service providers in accordance with point 5.1.4 (c).

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 10.2.2. For the purpose of point 10.2.1., the relevant entities shall: (a) put in place criteria, which set out which roles, responsibilities and authorities shall only be exercised by persons whose background has been verified; (b) ensure that verification referred to in point 10.2.1 is performed on these persons before they start exercising these roles, responsibilities and authorities, which shall take into consideration the applicable laws, regulations and ethics in proportion to the business requirements, the asset classification as referred to in point 12.1. and the network and information systems to be accessed and the perceived risks.

text: GUIDANCE

text: • Where applicable, define criteria for roles, responsibilities and authorities that will be exercised only by persons who have undergone background verification. An indicative, non-exhaustive list is the following: o executives and senior management, o roles with access to sensitive information, o roles with financial responsibilities, o roles involving procurement and vendor management, o roles that grant access to physical assets or are responsible for physical security. • Define criteria and limitations for background verification (e.g. who is eligible to screen people, and how, when and why verification reviews are carried out). • For background verification, consider checking the criminal records of the person concerned with regard to offences that would be relevant to a specific position. • Ensure that checks of criminal records align with legal and regulatory requirements (e.g. national (labour) laws and the GDPR). • Collect and handle information on job candidates, taking into consideration any applicable laws, regulations and ethics, including the protection of personal data. This may include collecting professional references. • Consider screening requirements in the contractual agreements between the entity and the direct suppliers and service providers in cases of personnel contracted with an external supplier. • Periodically repeat verification to confirm the ongoing suitability of personnel, depending on the criticality of a person’s role, responsibilities and authorities. • Entities should be permitted to rely on background checks of contractors employed by a third-party talent agency with which the entity covered has contracts for performing services.

text: EXAMPLES OF EVIDENCE

text: • Records of an analysis conducted to determine which roles, responsibilities and authorities require background verification. • Guidance for employees about when/how to perform background verification. • Records of completed verifications of professional references for employees or, where applicable, for direct suppliers and service providers. • Signed consent forms from employees or job candidates, confirming their agreement to undergo background verification. • Documentation of follow-up actions taken in response to any issues or discrepancies identified during background verification. • Agreements with third-parties that perform background verification services, if used, to ensure they comply with legal and policy requirements.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 10.2.3. The relevant entities shall review and, where appropriate, update the policy at planned intervals and update it where necessary.

text: GUIDANCE

text: • Where necessary, review and update background verification procedure at least annually.

text: EXAMPLES OF EVIDENCE

text: • Records of background verification for roles requiring ongoing clearance. • Review comments or change logs of the procedure.

text: 10.3 TERMINATION OR CHANGE OF EMPLOYMENT PROCEDURES

text: 10.3.1. The relevant entities shall ensure that network and information system security responsibilities and duties that remain valid after termination or change of employment of their employees are contractually defined and enforced.

text: GUIDANCE

text: • Include specific clauses in employment contracts that outline the ongoing security responsibilities and duties of employees after their employment ends or their role changes.

text: EXAMPLES OF EVIDENCE

text: • Documents, such as terms and conditions of employment, contracts or agreements, outlining responsibilities and duties still valid after termination of employment or contract.

text: 10.3.2. For the purpose of point 10.3.1., the relevant entities shall include in the individual’s terms and conditions of employment, contract or agreement the responsibilities and duties that are still valid after termination of employment or contract, such as confidentiality clauses.

text: GUIDANCE

text: • Ensure these clauses cover the protection of confidential information, return of company property and restrictions on accessing the entity’s network and information systems. • Revoke access to network and information systems in a timely manner upon termination or role change. • Identify and document all assets to be returned upon termination or change of employment. • After a change of employment, brief and inform personnel on the procedures in place.

text: EXAMPLES OF EVIDENCE

text: • Records confirming the timely return of the entity’s assets. • Records confirming the timely revocation of access rights. • Copies of written notifications to the employee about the termination of or change in employment status.

text: TIPS

text: GUIDANCE

text: • Identify and transfer to another individual network and information security roles and responsibilities held by any individual who leaves the organisation. • Where deemed reasonably necessary, conduct thorough exit interviews to remind departing employees of their ongoing security responsibilities.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Collect company property and revoke access to systems. • Monitor for any unauthorized access attempts by former employees. Use security tools to detect and respond to suspicious activities. Maintain logs of access attempts and investigate any anomalies. • Regularly review and update policies related to post-employment security responsibilities to ensure they remain effective and aligned with current legal and regulatory requirements. Keep a record of changes and ensure that it is up to date. • Take into account changes or past incidents when reviewing the process • Involve legal and human resources (HR) departments in the review process to ensure comprehensive coverage.

text: EXAMPLES OF EVIDENCE

text: • Records of all contractual agreements, non-disclosure agreements, exit interviews and access revocations, and any legal action taken. • Documentation showing that the process is reviewed regularly and updated as necessary. • Evidence that the employee’s access to the entity’s systems and facilities has been revoked or altered in accordance with a process. • Documentation of the process for personnel changes, including responsibilities for managing changes, description of rights of access and possession of assets for each role, and procedures for briefing and training personnel in new roles (e.g. standardised checklists used during the termination process to ensure all necessary steps are taken).

text: 10.4 DISCIPLINARY PROCESS

text: 10.4.1. The relevant entities shall establish, communicate and maintain a disciplinary process for handling violations of network and information system security policies. The process shall take into consideration relevant legal, statutory, contractual and business requirements.

text: GUIDANCE

text: • Make sure that the process holds employees accountable for violations of the network and information system security policies. • Involve human resources in implementing the disciplinary process, ensuring it aligns with legal and regulatory requirements (e.g. national labour laws and the GDPR). • Communicate and raise awareness of the process among employees. • Protect the identity of individuals subject to disciplinary action, where possible, in line with applicable requirements.

text: EXAMPLES OF EVIDENCE

text: • Disciplinary process documentation outlining the types of violations that may be subject to disciplinary actions, and what steps to take when a violation occurs. • Evidence that the policy has been communicated to all employees, which could include email records, meeting minutes or training session materials. • Records of any violations of the network and information system security policies that have occurred and the corresponding disciplinary actions taken, demonstrating adherence to the disciplinary process. Examples of such records may include interviews with employees, witness statements, e-mails, paperwork, digital records, system logs and phone records.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 10.4.2. The relevant entities shall review and, where appropriate, update the disciplinary process at planned intervals and when necessary due to legal changes or significant changes to operations or risks.

text: GUIDANCE

text: • Regularly review and update the disciplinary process at planned intervals and promptly when legal changes or significant operational or risk changes occur.

text: EXAMPLES OF EVIDENCE

text: • Records of reviews and updates showing that the disciplinary process is reviewed regularly and updated as necessary.

text: TIPS

text: GUIDANCE

text: • Include the disciplinary process for handling violations of network and information system security policies in the entity’s overall disciplinary process, if available. • Recognize that deliberate violations of the policy on the security of network and information systems may require immediate actions. • Do not initiate the disciplinary process without verifying that a violation of network and information system security policies has occurred. • Consider the following factors for the process: o the nature (who, what, when, how) and gravity of the violation and its consequences; o whether the offence was intentional (malicious) or unintentional (accidental); o whether this is a first or repeated offence; o whether or not the employee who committed the violation was properly trained. • Use the process as a deterrent to prevent employees from violating the network and information system security policies. • Reward individuals who demonstrate excellent behaviour regarding network and information security as a means of promoting and encouraging good behaviour.

text: EXAMPLES OF EVIDENCE

text: • Disciplinary process documentation outlining the types of violations that may be subject to disciplinary actions, and what steps to take when a violation occurs.

text: Chapter 11

text: ACCESS CONTROL

text: TECHNICAL IMPLEMENTATION GUIDANCE 11. ACCESS CONTROL 11.1 ACCESS CONTROL POLICY

text: 11.1.1. For the purpose of

text: Article 21(2)

text: , point (i) of

text: Directive (EU) 2022/2555

text: , the relevant entities shall establish, document and implement logical and physical access control policies for the access to their network and information systems, based on business requirements as well as network and information system security requirements.

text: GUIDANCE

text: • Implement and maintain logical and physical access restrictions to network and information system based on access-control policies that take into account industry good practices. • Ensure that these policies are documented, communicated to all relevant stakeholders and include clear guidelines on the appropriate use of access privileges.

text: EXAMPLES OF EVIDENCE

text: • Access control policy document or documents outlining the access control requirements, procedures and responsibilities.

text: 11.1.2. The policies referred to in point 11.1.1. shall: (a) address access by persons, including staff, visitors and external entities such as suppliers and service providers; (b) address access by network and information system processes; (c) ensure that access is only granted to users that have been adequately authenticated.

text: GUIDANCE

text: • Implement access control rules by defining and mapping appropriate access rights and restrictions to human users or network and information system processes (e.g. a machine, device or a service). To simplify access control management, assign specific roles to groups. o Access control rules can be implemented in different granularities, ranging from covering whole networks or systems to specific data fields and can also consider properties, such as user location or the type of network connection that is used for access. o Use business requirements and risk assessment results to define which access control rules are applied and which granularity is required. • Take into account the following when defining and implementing access control rules: o consistency between access rights and asset classification; o consistency between access rights and physical perimeter security needs and requirements; o consideration of all types of available connections in distributed environments so entities are only provided with access to associated assets, including networks and network services, that they are authorized to use; o consideration of how elements or factors relevant to dynamic access control can be reflected. • Develop documented procedures and defined responsibilities to support the access control rules.

text: EXAMPLES OF EVIDENCE

text: • Access control policy document outlining the access control requirements, procedures and responsibilities.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • User access records showing the list of users and their corresponding levels of access to various network and information systems. • Authentication protocols, meaning documentation of the authentication methods in place, such as MFA. • Authorization mechanisms with details on how permissions are granted, reviewed and revoked, ensuring that access rights are in line with users’ roles, responsibilities and authorities. • Access logs that record user access activities, which can be used to track and audit user behaviour within the system in the event of suspected misconduct. • Access rights review records showing alignment with asset classifications. • Records of access control assessments that align access rights with physical security requirements. • Network diagrams showing access control measures for different connection types and network access control policies. • Logs showing dynamic access control decisions based on user behaviour or environment factors

text: 11.1.3. The relevant entities shall review and, where appropriate, update the policies at planned intervals and when significant incidents or significant changes to operations or risks occur.

text: GUIDANCE

text: • Review the policies at least annually.

text: EXAMPLES OF EVIDENCE

text: • Past incident reports with records of any security incidents related to access control, including unauthorized access attempts and the responses to such events. • Change management records of any changes made to access rights, showing adherence to the policy during modifications. • Records of reviews and updates showing that the policies are reviewed regularly and updated as necessary. • Reports from internal or external audits that assess the effectiveness of and compliance with the access control policy.

text: TIPS

text: GUIDANCE

text: • Consider the two overarching principles most frequently used in the context of access control: o need-to-know: an entity is only granted access to the information that it requires to perform its tasks and in line with the asset classification levels of point 12.1 of the Annex to the regulation (different tasks or roles mean different need-to-know information and hence different access profiles); o need-to-use: an entity is only assigned access to information technology infrastructure where a clear need is present. • Consider the following when specifying access control rules: o establishing rules based on the premise of least privilege (‘everything is generally forbidden unless expressly permitted’) rather than the weaker rule (‘everything is generally permitted unless expressly forbidden’);

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o changes in user permissions that are initiated automatically by the network and information system and those initiated by a system administrator; o when to define and regularly review the approval. • Consider ways to implement access control, such as mandatory access control (MAC), discretionary access control (DAC), role-based access control (RBAC) and attribute-based access control (ABAC) depending on the business needs of the organisation. • Take into account the fact that access control rules can also contain dynamic elements (e.g. a function that evaluates past accesses or specific environmental values).

text: EXAMPLES OF EVIDENCE

text: • Access control policy document outlining the access control requirements, procedures and responsibilities. • Access reviews showing adherence to need-to-know and need-to-use principles. • Change management records of any changes made to access rights, showing adherence to the policy during modifications. • Access control system configurations showing the adoption of MAC, DAC, RBAC or ABAC depending on business needs.

text: 11.2 MANAGEMENT OF ACCESS RIGHTS

text: 11.2.1. The relevant entities shall provide, modify, remove and document access rights to network and information systems in accordance with the access control policy referred to in point 11.1. 11.2.2. The relevant entities shall: (a) assign and revoke access rights based on the principles of need-to-know, least privilege and separation of duties; (b) ensure that access rights are modified accordingly upon termination or change of employment; (c) ensure that access to network and information systems is authorised by the relevant persons; (d) ensure that access rights appropriately address third-party access, such as visitors, suppliers and service providers, in particular by limiting access rights in scope and in duration; (e) maintain a register of access rights granted; (f) apply logging to the management of access rights.

text: GUIDANCE

text: • Ensure each user only has access to information necessary for their role (‘need-to-know’). • Restrict user permissions to the minimum necessary for their duties (‘least privilege’). Regularly review and adjust access rights as needed. • Determine which duties and areas of responsibility need to be segregated. Establish and follow a process for requesting and approving access, preferably automated. The process should: o cover granting access rights to assets upon the new hire or role change of a user; o obtain authorization from the owner of the asset, separate approval for access rights by management bodies can also be appropriate; o ensure that access rights are activated (e.g. by service providers) only after authorization procedures are successfully completed; o consider the business requirements and the entity’s access control policy; o consider segregation of duties, including segregating the roles of approval and implementation of the access rights and separation of conflicting roles;

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o verify that the level of access granted is in accordance with the access control policy and is consistent with other information security requirements such as segregation of duties; o consider giving temporary access rights for a time and revoking them at the expiry date, in particular for temporary personnel or temporary access required by personnel. • Establish and follow a process, preferably automated, for revoking access to assets. The process should: o timely disable accounts upon the termination, rights revocation or role change of a user, as needed; disabling accounts, instead of deleting accounts, may be necessary to preserve audit trails; o modify the access rights of users who have changed roles or jobs; o remove or adjust access rights, which can be done by removing, revoking or replacing keys, authentication information, identification cards or subscriptions. o where feasible, enable different components or services to share information (signals) about access revocation in a timely manner. • Limit third-party access based on need and duration. Use temporary access accounts with expiry dates and regularly review third-party access rights. • Ensure third parties acknowledge their access responsibilities and obligations. • Where appropriate ( ), keep a detailed and up-to-date central record (register or database) of all granted access rights, including user names, roles, permissions and dates of access changes. • Establish and maintain an inventory of the authentication and authorization systems, including those hosted on-site or with a remote service provider. • Implement logging for all access rights management activities. Logs should include details of who granted or modified access, when and what changes were made. • Minimise the use of generic and shared accounts and ensure users can always be identified for their actions within ICT systems.

text: EXAMPLES OF EVIDENCE

text: • Clear definitions of user roles and their corresponding access rights. • A central record (register or database) detailing all granted access rights, including user names, roles, access levels and dates of access changes. • Approved access request forms supporting entries in the access rights register. Granting, withdrawals and changes of access should be appropriately documented and visible in the register and consistent with the process for granting and withdrawing access rights (Annex to the regulation, point 11.2.2). It is also important that archived backups are properly secured to prevent unauthorised access. It should be remembered that in the case of these copies, excessive permissions should be limited and controlled. • Periodic access reviews meaning evidence of regular reviews of user access rights to ensure they remain appropriate over time. • System logs showing all access rights management activities (creation, modification and deletion). • Audit trail logs demonstrating access rights management, including timestamps, user IDs and actions performed. • Records of incidents related to access rights management, including unauthorized access attempts and corrective actions.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Evidence of systems enforcing access controls, such as identity and access management (IAM) solutions. • Reports from internal or external compliance audits verifying alignment with the access control policy. • Results of physical inspections of access control systems and their use, if applicable.

text: 11.2.3. The relevant entities shall review access rights at planned intervals and shall modify them based on organisational changes. The relevant entities shall document the results of the review including the necessary changes of access rights.

text: GUIDANCE

text: • Regularly review physical and logical access rights, taking into account: o users’ access rights after termination or change of employment; o authorisations for privileged access rights. • Review and update the inventory of the authentication and authorization systems regularly. • Perform access control reviews of assets to verify that all privileges are authorised on a recurring schedule at least annually.

text: EXAMPLES OF EVIDENCE

text: • A central record (register or database) detailing all granted access rights, including user names, roles, access levels and dates of access changes. • Approved access request forms supporting entries in the access rights register. • Periodic access reviews meaning evidence of regular reviews of user access rights to ensure they remain appropriate over time. • System logs showing all access rights management activities (creation, modification and deletion). • Audit trail logs demonstrating access rights management, including timestamps, user IDs and actions performed. • Records of incidents related to access rights management, including unauthorized access attempts and corrective actions. • Reports from internal or external compliance audits verifying alignment with the access control policy. • Physical inspection results of access control systems and their use, if applicable. • Records of reviews and updates showing that access rights are reviewed regularly and updated as necessary.

text: TIPS

text: GUIDANCE

text: • Centralize access control for all assets through a directory service or single sign on (SSO) provider, where supported. • Implement a segregation of duties matrix and ensure that it is updated dynamically by automating how changes are handled in response to role assignments or task changes (e.g. integration with access control, IAM or enterprise resource planning (ERP) systems).

text: EXAMPLES OF EVIDENCE

text: • Evidence of a centralized directory service or SSO provider to manage access control, supported by documentation, logs, audit reports and records. • Segregation of duties matrix.

text: TECHNICAL IMPLEMENTATION GUIDANCE 11.3 PRIVILEGED ACCOUNTS AND SYSTEM ADMINISTRATION ACCOUNTS

text: 11.3.1. The relevant entities shall maintain policies for management of privileged accounts and system administration accounts as part of the access control policy referred to in point 11.1.

text: GUIDANCE

text: • Allocate privileged access rights to users as needed and, on an event-by-event basis in line with the access control policy referred to in point 11.1 of the Annex to the regulation (that is, only to individuals with the necessary authority to carry out activities that require privileged access and based on the minimum requirement for their functional roles). • Identify users who need privileged access ( ) to a network and information system (e.g. operating systems, database management systems and applications). This should include any privileged physical access to, e.g. cryptographic codes, keys or devices and in line with point 13.3 of the Annex to the regulation. • Where appropriate, maintain an authorization process and a record of all allocated privileged access rights, consistent with the process for granting and revoking access rights (Annex to the regulation, point 11.2.2).

text: EXAMPLES OF EVIDENCE

text: • Clear policy on privileged account usage and access rules for privileged accounts. • List of users with privileged access and what systems they can access. • Documented approval records for granting privileged access. • Logs or records of access reviews and revocations. • Role-based access matrix showing who needs what access.

text: 11.3.2. The policies referred to in point 11.3.1. shall: (a) establish strong identification, authentication such as multi-factor authentication and authorisation procedures for privileged accounts and system administration accounts; (b) set up specific accounts to be used for system administration operations exclusively, such as installation, configuration, management or maintenance; (c) individualise and restrict system administration privileges to the highest extent possible, (d) provide that system administration accounts are only used to connect to system administration systems.

text: GUIDANCE

text: • Introduce higher authentication requirements for privileged access rights, such as re-authentication or authentication step-up before using privileged access rights. • Define and implement expiry requirements for privileged access rights, where appropriate. • In the absence of a system that allows all uses to be attributed to an individual with certainty, establish specific rules to avoid the use of generic administration user IDs (e.g. ‘root’) and manage and protect the authentication information of such identities. • Grant temporary privileged access only for the time necessary to implement approved changes or activities (e.g. for maintenance activities), rather than permanently granting privileged access rights.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o Consider the frequency of system administration operations: daily tasks (e.g. backups and email routing) versus weekly or monthly tasks (e.g. reviewing memory and disk space). • Log all privileged access for audit purposes; • Assign separate identities with privileged access rights to individual users, rather than sharing or linking identities. Group identities for easier management if needed. • Use identities with privileged access rights exclusively for administrative tasks, not for day-to-day general tasks such as checking email or accessing the web. Where feasible ( ), separate privileged identities should be assigned for administrative tasks. • Ensure users are aware of their privileged access rights or when they are in privileged access mode, for example using specific user identities, user interface settings or equipment.

text: EXAMPLES OF EVIDENCE

text: • Measures for privileged access control and monitoring for privileged accounts, including granting and revoking privileged access rights. • Access assignment records showing how access rights are initially granted, based on job roles and responsibilities. • Clear definitions of user roles and the corresponding access rights associated with each role. • Audit trail and monitoring logs that capture the use of access rights, including any unauthorized access attempts and actions taken in response.

text: 11.3.3. The relevant entities shall review access rights of privileged accounts and system administration accounts at planned intervals and be modified based on organisational changes and shall document the results of the review, including the necessary changes of access rights.

text: GUIDANCE

text: • Verify whether the duties, roles, responsibilities and competences of system administrators still qualify them for working with privileged access rights.

text: EXAMPLES OF EVIDENCE

text: • Records of reviews and updates showing that access rights are reviewed regularly and updated as necessary. • Periodic access reviews meaning evidence of regular reviews of user access rights to ensure they remain appropriate over time. • Change management logs of changes to access rights, reflecting any alterations due to role changes or termination of employment. • Compliance audits with reports from internal or external audits verifying that the management of access rights aligns with the policy and regulatory requirements.

text: TECHNICAL IMPLEMENTATION GUIDANCE 11.4 ADMINISTRATION SYSTEMS

text: 11.4.1. The relevant entities shall restrict and control the use of system administration systems in accordance with the access control policy referred to in point 11.1.

text: GUIDANCE

text: • Access to system administration systems must be strictly controlled in line with the access control policy. Only authorized personnel should be granted such access and all activity must be logged and regularly reviewed. • Measures should be in place to detect unauthorized access and ensure accountability through audit trails and periodic security assessments. • Access logs from system administration systems should be integrated into the entity's centralized log management or SIEM solution. Automated alerts must be configured to detect and notify of any suspicious or unauthorized access attempts, ensuring a timely response and ongoing compliance with security policies. • The retention period for logs must be clearly defined based on business needs, legal requirements and network and information security objectives. • Logs should capture relevant events necessary for security monitoring, incident detection and forensic analysis, such as access attempts, administrative actions and system changes.

text: EXAMPLES OF EVIDENCE

text: • Regularly maintained logs that track access to system administration systems ( ). • Audit reports from internal or external security audits that assess compliance with the policy.

text: 11.4.2. For that purpose, the relevant entities shall: (a) only use system administration systems for system administration purposes and not for any other operations; (b) separate logically such systems from application software not used for system administrative purposes, (c) protect access to system administration systems through authentication and encryption.

text: GUIDANCE

text: • Implement strict access controls to ensure that administrative systems are used exclusively for their intended purpose. For instance, only allow authorised personnel with specific roles (e.g. system administrators and IT staff) access to system administration systems. • Physically or logically isolate administrative systems from other application servers, for example use network segmentation to create separate zones for system administration systems and other systems, such as application servers. If applicable, physically inspect server racks to ensure separation. • Require strong authentication mechanisms such as MFA for accessing system administration systems. • Encrypt communication channels (e.g. secure shell protocol, hypertext transfer protocol secure) to protect data in transit to and from system administration systems. • Encrypt sensitive configuration files and credentials stored on system administration systems.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Ensure that application protocols are securely implemented. In addition, verify that any SSO or federation protocols are correctly implemented and conform to their specifications.

text: EXAMPLES OF EVIDENCE

text: • Regularly maintained logs that track access to system administration systems. • Network segmentation documentation indicating how system administration systems are logically or physically separated from other systems. • Documented authentication methods used to secure access to administration systems. • Information on encryption protocols applied to protect data transmitted to and from system administration systems.

text: TIPS

text: GUIDANCE

text: • Consider using a centralized privileged access management (PAM) solution. • Consider using a cloud access security broker (CASB) to enhance the visibility of, control over and the security of cloud service usage. • Regularly audit system logs to monitor usage patterns and identify any unauthorised activities. • Train personnel in the proper use of system administration systems.

text: EXAMPLES OF EVIDENCE

text: • Regularly maintained logs that track access to administration systems. • Incident response records of any incidents related to system administration system misuse or unauthorized access. • User training records meaning evidence that personnel have been trained in the proper use of system administration systems, for example training materials, attendance records or completion certificates.

text: 11.5 IDENTIFICATION

text: 11.5.1. The relevant entities shall manage the full life cycle of identities of network and information systems and their users.

text: GUIDANCE

text: • Establish and maintain an inventory of all identities managed in the entity. o The inventory should include both user and privileged or system administrator identities. The inventory should contain, as a minimum, the person’s name, username, start/stop dates and the level of privileges for each identity. o The inventory should also include all service identities and have these identity records as a minimum including department owner, review date, purpose and the level of privileges for each service identity.

text: EXAMPLES OF EVIDENCE

text: • Documented policy or procedure related to identity management, if available. • Reports from internal or external audits verifying that the management of identities aligns with the policy and regulatory requirements.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: 11.5.2. For that purpose, the relevant entities shall: (a) set up unique identities for network and information systems and their users; (b) link the identity of users to a single person; (c) ensure oversight of identities of network and information systems; (d) apply logging to the management of identities.

text: GUIDANCE

text: • Consider that providing or revoking access to assets is usually a multi-step procedure: o confirming the business requirements for an identity to be established; o verifying the identity of an entity before allocating them a logical identity; o establishing an identity; o configuring and activating the identity, which also includes configuration and initial setup of related authentication services; and o providing or revoking the identity’s specific access rights, based on appropriate authorization or entitlement decisions (section 11.2). • Make sure that identities assigned to network and information systems (non-human users) are subject to appropriately segregated approval and independent ongoing oversight. • Apply logging to the management of identities in cooperation with human resource security (section 10.1) where possible.

text: EXAMPLES OF EVIDENCE

text: • Identity records, for example user profiles with unique identifiers (e.g. usernames and employee IDs) and evidence of linking these identities to specific individuals (e.g. HR records). • Logs of reviews or approvals for identities for network and information systems and their users. • Logs or reports related to identity management. • Evidence of the systems in place that enforce access control, such as IAM solutions.

text: 11.5.3. The relevant entities shall only permit identities assigned to multiple persons, such as shared identities, where they are necessary for business or operational reasons and are subject to an explicit approval process and documentation. The relevant entities shall take identities assigned to multiple persons into account in the cybersecurity risk management framework referred to in point 2.1.

text: GUIDANCE

text: • Shared identities should be avoided unless strictly necessary for business or operational reasons ( ). In such cases, their use must be formally justified, explicitly approved and properly documented. Examples of technical, procedural and governance controls to enhance their protection include (indicative, nonexhaustive list): o MFA enforcement; o Least privilege concept enforcement; o Time-bound or just-in-time access;

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o Checking out the shared credentials through a tool which logs who accessed the identity and when. If check-out is not possible, consider using privileged session recording or proxy-based access auditing; o Session attribution techniques to link shared identity use back to individual users; o Logging; o Credential vaulting with auto-rotation; o Prohibition of storing shared credentials in personal files, emails or messaging platforms; o Network segmentation so that shared account use is limited to isolated network segments or virtual environments; and o Mandatory training on acceptable use and accountability. • These identities should be clearly recorded in the cybersecurity risk management framework, with appropriate controls in place to mitigate associated risks, including enhanced monitoring and accountability measures.

text: EXAMPLES OF EVIDENCE

text: • Approval records for exceptions.

text: 11.5.4. The relevant entities shall regularly review the identities for network and information systems and their users and, if no longer needed, deactivate them without delay.

text: GUIDANCE

text: • Verify that all active identities are reviewed. This can be done on a recurring schedule, as a minimum quarterly, or more frequently. However, for micro-sized entities, this can be done annually. • Disable or remove, in a timely fashion, identities that they are no longer required, for example delete or disable any dormant identities after a predefined period of days of inactivity, where supported.

text: EXAMPLES OF EVIDENCE

text: • Records of reviews and updates showing that identities are reviewed regularly and updated as necessary. • Records of changes to identities, reflecting any alterations due to role changes or termination of employment or inactivity.

text: TIPS

text: GUIDANCE

text: • Centralize identity management through a directory or identity service. • Where appropriate, define different levels of identification required based on role, use or need.

text: EXAMPLES OF EVIDENCE

text: • Evidence of the systems in place, such as IAM solutions.

text: TECHNICAL IMPLEMENTATION GUIDANCE 11.6 AUTHENTICATION

text: 11.6.1. The relevant entities shall implement secure authentication procedures and technologies based on access restrictions and the policy on access control.

text: GUIDANCE

text: • Authentication technologies are methods used to verify the identity of users, devices or systems before granting access to resources. Here are some common authentication technologies (indicative, non-exhaustive list): o password-based authentication, o passkeys, o two-factor authentication, o MFA ( ), o biometric authentication, o token-based authentication, such as a one-time passcode (OTP), o smart cards, o Fast Identity Online 2 security keys, o certificate-based authentication, o SSO, o OpenID Connect.

text: EXAMPLES OF EVIDENCE

text: • Access control policy documents outlining secure authentication procedures and technologies. • Logs from authentication systems showing successful and failed authentication attempts, which demonstrate secure implementation. • Evidence of the systems in place that enforce access controls, such as IAM solutions. • Internal or external audit reports verifying the implementation of secure authentication procedures aligned with the access control policy. • Documentation that shows the use of secure authentication and authorization protocols and demonstrates that these have been tested to confirm that they are implemented in a secure fashion.

text: 11.6.2. For that purpose, the relevant entities shall: (a) ensure the strength of authentication is appropriate to the classification of the asset to be accessed; (b) control the allocation to users and management of secret authentication information by a process that ensures the confidentiality of the information, including advising personnel on appropriate handling of authentication information; (c) require the change of authentication credentials initially, at predefined intervals and upon suspicion that the credentials were compromised; (d) require the reset of authentication credentials and the blocking of users after a predefined number of unsuccessful log-in attempts; (e) terminate inactive sessions after a predefined period of inactivity; and (f) require separate credentials to access privileged access or administrative accounts.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: GUIDANCE

text: • Use unique authentication credentials for all the entity’s assets. Best-practice implementation includes, as a minimum, an 8-character password for accounts using MFA and a 14-character password for accounts not using MFA. • Consider that the allocation and management process for authentication information should ensure that: o passwords or PINs generated automatically during enrolment processes as temporary secret authentication information are non-guessable and unique for each user; and that users are required to change them after the first use; o procedures are established to verify the identity of a user prior to providing new, replacement or temporary authentication information; o authentication information, including temporary authentication information, is transmitted to users in a secure manner (e.g. via an authenticated and protected channel), and the use of unprotected (clear text) electronic mail messages is avoided; o users acknowledge receipt of authentication information; o default authentication information as predefined or provided by suppliers is changed immediately following installation of systems or software; o records of significant events concerning allocation and management of authentication information are kept and their confidentiality granted, and that the record keeping method is approved (e.g. using an approved password vault tool). • When passwords are used as authentication information, the password management system should: o allow users to select and change their own passwords and include a confirmation procedure to address input errors; o enforce strong passwords ( ); o force users to change their passwords at first login, if relevant; o enforce password changes as necessary, for example after a security incident or upon termination or change of employment when a user has known passwords for identities that remain active (e.g. shared identities); o prevent the use of commonly used passwords, and compromised combinations of usernames and password from hacked systems; o not display passwords on the screen when they are being entered; and o store and transmit passwords in protected form. • The use of phishing-resistant MFA is recommended. Below is a list of currently available solutions ordered from strongest to weakest. o ‘Strong’:  phishing-resistant: - no shared secrets, not vulnerable to attacker-in-the-middle; - protected cryptographic private key that can be securely registered to: o a domain, in accordance with Fast Identity Online (FIDO) and W3C WebAuthn standards;

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o a trust provider, following public key infrastructure and International Telecommunication Union X.509 standards. o ‘Medium’ MFA, for example:  push notification, number matching or application based. o ‘Last resort’ MFA, for example:  text message or email OTP. • Perform password encryption and hashing in accordance with approved cryptographic techniques for passwords (section 9.2). • Generate an alert when a potential attempted or successful breach of login controls is detected.

text: EXAMPLES OF EVIDENCE

text: • Logs or reports related to authentication. • Compliance audits from internal or external audits verifying that the management of identities aligns with the policy and regulatory requirements. • Documentation showing that the identities are reviewed regularly and updated as necessary. • Records of changes to identities, reflecting any alterations due to role changes or termination of employment.

text: 11.6.3. The relevant entities shall to the extent feasible use state-of-the-art authentication methods, in accordance with the associated assessed risk and the classification of the asset to be accessed and unique authentication information.

text: GUIDANCE

text: • Adjust authentication methods based on the associated assessed risk. For example, require additional authentication for high-risk transactions or access to assets of higher criticality. • Use more stringent authentication methods for assets of higher criticality. • Ensure each user has unique credentials. Avoid shared accounts and implement strict policies for credential management.

text: EXAMPLES OF EVIDENCE

text: • Access control policy documents outlining secure authentication procedures and technologies.

text: 11.6.4. The relevant entities shall regularly review the authentication procedures and technologies at planned intervals.

text: GUIDANCE

text: • Conduct periodic audits of authentication procedures and technologies to ensure they remain up to date, where appropriate and effective against emerging threats. • Stay up to date on advancements in authentication technology and integrate new methods as they become available.

text: EXAMPLES OF EVIDENCE

text: • Internal or external audit reports detailing the results of periodic audits of authentication procedures and technologies. • Logs showing the implementation of new authentication technologies and methods as they become available

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: TIPS

text: GUIDANCE

text: • Advise any user with access to or using authentication information to comply with the following. o Secret authentication information, such as passwords, is kept confidential. Personal secret authentication information is not to be shared with anyone. Secret authentication information used in the context of identities linked to multiple users or linked to non-personal entities is solely shared with authorised persons. o Affected or compromised authentication information is changed immediately upon notification of or any other indication of a compromise. o When passwords are used as authentication information, strong passwords according to best practice recommendations are selected. For example, passwords are not based on anything somebody else can easily guess or obtain using person-related information (e.g. names, telephone numbers and dates of birth); passwords are not based on dictionary words or combinations thereof; use easy to remember passphrases and try to include alphanumerical and special characters; passwords should have a minimum length. o The same credentials are not used across different network and information systems. o The obligation to follow these rules is also included in the terms and conditions of employment.

text: EXAMPLES OF EVIDENCE

text: • Documentation of training sessions for employees on secure authentication practices and technologies. • Records of awareness programmes or communications to employees about the importance of secure authentication.

text: 11.7 MULTI-FACTOR AUTHENTICATION

text: 11.7.1. The relevant entities shall ensure that users are authenticated by multiple authentication factors or continuous authentication mechanisms for accessing the entities’ network and information systems, where appropriate, in accordance with the classification of the asset to be accessed.

text: GUIDANCE

text: • Select appropriate MFA ( ) methods and continuous authentication mechanisms based on the entity’s security needs and depending on the classification of the asset. It is also good practice to consider user convenience when selecting and implementing a solution: o test-message-based OTP: simple but less secure due to risks such as SIM swapping; o authenticator apps: generate time-based OTPs; o push notifications: send an approval request to a user’s device; o hardware tokens: for example physical devices generating OTPs, smart cards; o passkeys; o Fast Identity Online 2 security keys; o biometrics: fingerprints, facial recognition, etc.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Consider continuous authentication ( ) for avoiding specific threats such as session hijacking, credential theft and insider threats.

text: EXAMPLES OF EVIDENCE

text: • Logs showing MFA being used to access network and information systems. • Configuration of authentication solutions implementing MFA. • Access control policy outlining how different MFA methods are assigned, including whether phishing-resistant MFA is used.

text: 11.7.2. The relevant entities shall ensure that the strength of authentication is appropriate for the classification of the asset to be accessed.

text: GUIDANCE

text: • Determine which network and information systems require the use of MFA protection based on the classification of the asset to be accessed. Wherever possible, use phishing-resistant MFA. • Analyse user roles and the level of access required by each role to determine appropriate MFA methods. • Consider MFA, in particular when accessing systems from a remote location, accessing system administration systems, access to sensitive information, etc. • Enforce MFA on internet-facing systems, such as email, remote desktop and VPNs ( ). • Define when and how MFA is required (e.g. every login, once per session or for high-risk actions).

text: EXAMPLES OF EVIDENCE

text: • Documentation detailing the classification of assets and the associated requirement for MFA protection. • Risk assessment results justifying the need for MFA on certain network and information systems. • List of user roles, associated access rights and the analysis conducted to determine appropriate MFA methods. • Configuration files and logs showing MFA enabled on specific network and information systems. • Settings from authentication systems reflecting the defined MFA requirements. • Logs from authentication systems showing enforcement of these MFA requirements.

text: TIPS

text: GUIDANCE

text: • Integrate MFA with SSO solutions for seamless access. Wherever possible, use phishing-resistant MFA. • Implement secure fallback methods for users who lose access to their MFA methods. • Educate users about the importance of MFA and how to use it. • Regularly monitor MFA logs for suspicious activity. • Keep the MFA system and associated devices updated.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Combine MFA with other techniques to require additional factors under specific circumstances, based on predefined rules and patterns, such as access from an unusual location, from an unusual device or at an unusual time. • Evaluate and choose an MFA provider that fits the entity’s requirements: o ease of integration: ensure the MFA solution integrates well with the existing systems; o user experience: aim for a balance between security and user convenience; o scalability: choose a solution that can grow with the entity; o support and reliability: ensure the provider offers robust support and high reliability. • Pilot test the MFA solution with a small group of users. • Ensure that MFA implementation meets legal requirements (e.g. the GDPR).

text: EXAMPLES OF EVIDENCE

text: • Manuals, configuration files or screenshots demonstrating the successful integration of MFA with an SSO provider. • Records of training sessions, attendance lists and training materials provided to users about the importance and usage of MFA. • Regularly generated reports from MFA systems showing log monitoring activities and any suspicious activities detected. • Configuration files showing the implementation of additional authentication factors based on predefined rules.

text: Chapter 12

text: ASSET MANAGEMENT

text: TECHNICAL IMPLEMENTATION GUIDANCE 12. ASSET MANAGEMENT 12.1 ASSET CLASSIFICATION

text: 12.1.1. For the purpose of

text: Article 21(2)

text: , point (i) of

text: Directive (EU) 2022/2555

text: , the relevant entities shall lay down classification levels of all assets, including information, in scope of their network and information systems for the level of protection required.

text: GUIDANCE

text: • Create and document classification levels for the assets, including conventions for classification.

text: EXAMPLES OF EVIDENCE

text: • Documented classification levels for the assets.

text: 12.1.2. For the purpose of point 12.1.1., the relevant entities shall: (a) lay down a system of classification levels for assets; (b) associate all assets with a classification level, based on confidentiality, integrity, authenticity and availability requirements, to indicate the protection required according to their sensitivity, criticality, risk and business value; (c) align the availability requirements of the assets with the delivery and recovery objectives set out in their business continuity and disaster recovery plans.

text: GUIDANCE

text: • Ensure that classifications and associated protective measures for assets consider business needs, including: o sharing or restricting information; o protecting the integrity and authenticity of information; o ensuring availability ( ); and o complying with legal requirements concerning the confidentiality, integrity or availability of the information. • Define and communicate a classification for sensitive information, such as (indicative example): o public - freely accessible to all, even externally; o internal - accessible only to members of the entity; o confidential - accessible only to those whose duties require access. • Use classifications derived from national law, international agreements or internationally accepted strategies for sharing information, such as the traffic light protocol. • Align the classification with the access control policy (section 11.1). • Classify assets in accordance with the identified classification levels. • Classify assets other than information in accordance with the classification of the information they store, process, handle or protect.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: EXAMPLES OF EVIDENCE

text: • The latest, updated record of the entity’s assets and their classification based on the identified classification levels.

text: 12.1.3. The relevant entities shall conduct periodic reviews of the classification levels of assets and update them, where appropriate.

text: GUIDANCE

text: • Define criteria for reviewing the classification over time. • Review the classification at least annually, taking into account: o regulatory changes; and o changes in the value, sensitivity and criticality of the assets throughout their life cycle.

text: EXAMPLES OF EVIDENCE

text: • Documentation showing the schedule for reviews. • Records of the most recent review and logs detailing changes made during the last review, including reclassifications and the addition/removal of assets.

text: TIPS

text: GUIDANCE

text: • Ensure that owners of the assets are responsible for their classification. • Communicate to personnel the classification of assets and associated protection requirements.

text: EXAMPLES OF EVIDENCE

text: • Personnel knowing classification levels and protection requirements for each level.

text: 12.2 HANDLING OF ASSETS

text: 12.2.1. The relevant entities shall establish, implement and apply a policy for the proper handling of assets, including information, in accordance with their network and information security policy and shall communicate the policy on proper handling of assets to anyone who uses or handles assets.

text: GUIDANCE

text: • Ensure that employees, direct suppliers, service providers and any other third parties who use or handle the entity’s assets ( ) are aware of the policy. • Consider mobile devices, such as smartphones and tablets, and determine a strategy for mobile device management, including Bring-Your-Own-Device (BYOD) ( ).

text: EXAMPLES OF EVIDENCE

text: • Policy on the proper handling of assets.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • User manuals or instructions provided to employees, direct suppliers, service providers and any other third parties who use or handles the entity’s assets. • Documentation showing that employees have completed training sessions on the asset handling policy. • Forms or electronic records that employees, direct suppliers, service providers and third parties have signed to acknowledge they have read and understood the policy.

text: 12.2.2. The policy shall: (a) cover the entire life cycle of the assets, including acquisition, use, storage, transportation and disposal; (b) provide instructions on the safe use, safe storage, safe transport and the irretrievable deletion and destruction of the assets; (c) provide that the transfer shall take place in a secure manner, in accordance with the type of asset or information to be transferred.

text: GUIDANCE

text: • Identify, document and implement a policy for handling assets ( ) throughout their life cycle (acquisition, use, storage, transportation and disposal). • Ensure that the policy includes at least safe storage, safe transport; and irretrievable deletion and destruction. For example: o create user manuals and training materials on the correct and secure use of assets; o establish guidelines for secure storage, taking into account backup management (section 4.2); o define protocols for secure transfer, including consider secure migration processes, when transferring data to a cloud service; o outline methods for data wiping and physical destruction, ensuring complete and irretrievable deletion. • Ensure that the policy covers the proper usage of all in-scope assets, both on-premises and off-premises (e.g. mobile devices, data in the cloud, transient data ( ) or sensitive information). • Ensure that assets may be transferred to external premises only after approval by authorized management bodies, in accordance with the policy. • Link the asset handling policy with the asset classification by providing handling details for each classification level.

text: EXAMPLES OF EVIDENCE

text: • Documented policy for handling assets. • User access lists, access request forms and approval records. • Incident reports related to asset handling (e.g. loss, theft or damage).

text: 12.2.3. The relevant entities shall review and, where appropriate, update the policy at planned intervals and when significant incidents or significant changes to operations or risks occur.

text: GUIDANCE

text: • Review and update the policy for asset handling at least annually.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: EXAMPLES OF EVIDENCE

text: • Up-to date policy for asset handling • Records of reviews or history of changes.

text: 12.3 REMOVABLE MEDIA POLICY

text: 12.3.1. The relevant entities shall establish, implement and apply a policy on the management of removable storage media and communicate it to their employees and third parties who handle removable storage media at the relevant entities’ premises or other locations where the removable media is connected to the relevant entities’ network and information systems.

text: GUIDANCE

text: • Define, document and implement a policy on the management of removable media ( ). • Communicate the policy to employees and third parties who handle removable storage media to ensure that they are aware of the policy.

text: EXAMPLES OF EVIDENCE

text: • Documented policy on the management of removable media, including at least the items in point 12.3.2 of the Annex to the regulation. • User manuals or instructions provided to employees and third parties concerning the correct usage of the removable media. • Documentation showing that employees and third parties have completed training sessions on the policy or forms or electronic records that employees and third parties have signed to acknowledge they have read and understood the policy. • Evidence of ongoing awareness campaigns, such as posters, emails or intranet posts, reminding employees about the risks and policies associated with removable media.

text: 12.3.2. The policy shall: (a) provide for a technical prohibition of the connection of removable media unless there is an organisational reason for their use; (b) provide for disabling self-execution from such media and scanning the media for malicious code before they are used on the relevant entities’ systems; (c) provide measures for controlling and protecting portable storage devices containing data while in transit and in storage; (d) where appropriate, provide measures for the use of cryptographic techniques to protect data on removable storage media.

text: GUIDANCE

text: • Align the policy with the asset classification (section 12.1) and include at least the following: o definitions and scope of removable media, o authorization requirements, o usage guidelines,

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: o measures for control and protection of removable media while in storage and in transit;, o techniques to protect information on removable storage media and o incident response procedures for lost or compromised media. • Configure network and information systems to disable the autorun feature for all removable media, to prevent the automatic execution of potentially malicious software. • If connection of removable media is not prohibited for an organisational (business) reason, removable media should be scanned for malicious code, where appropriate, with up-to-date software against malicious code before being connected to the entity’s network and information systems and/or in real time. • Encrypt sensitive data stored on removable media using strong cryptographic algorithms to protect against unauthorized access • Use encryption to protect data stored on portable storage devices, ensuring that unauthorized users cannot access the data if the device is lost or stolen. • Implement physical security measures, where appropriate, such as secure storage locations and tracking logs for portable storage devices.

text: EXAMPLES OF EVIDENCE

text: • Configuration settings of endpoint protection software, if any. • Audit logs that track the use of removable media, including insertion, removal and data transfer activities. • Reports of incidents involving removable media, if any.

text: 12.3.3. The relevant entities shall review and, where appropriate, update the policy at planned intervals and when significant incidents or significant changes to operations or risks occur.

text: GUIDANCE

text: • Regularly monitor and audit the use of removable media to ensure compliance with the policy.

text: EXAMPLES OF EVIDENCE

text: • Up-to date removable media policy. • Records of reviews or history of changes.

text: 12.4 ASSET INVENTORY

text: 12.4.1. The relevant entities shall develop and maintain a complete, accurate, up-to-date and consistent inventory of their assets. They shall record changes to the entries in the inventory in a traceable manner.

text: GUIDANCE

text: • Ensure that all assets, including hardware, software, data and services, are listed in the inventory. • Regularly verify the accuracy of the inventory entries. • Update the inventory promptly to reflect any changes, such as new assets, decommissioned assets or changes in asset status (section 6.4) • Use standardised naming conventions and categorization methods to maintain consistency across the inventory. • Make sure that inventory entries contain the data in the guidance below (sampling). • Implement validation rules within the inventory to ensure data entered is complete and consistent.

text: EXAMPLES OF EVIDENCE

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Documentation for the inventory of assets • Up to date inventory of assets • Records of reviews or history of changes. • Records of key metrics tracked, such as the number of assets, types of assets, compliance with inventory policies and the timeliness of updates.

text: 12.4.2. The granularity of the inventory of the assets shall be at a level appropriate for the needs of the relevant entities. The inventory shall include the following: (a) the list of operations and services and their description, (b) the list of network and information systems and other associated assets supporting the relevant entities’ operations and services.

text: GUIDANCE

text: • Consider adding one or more of the following to the inventory (indicative, non-exhaustive list): o asset unique ID, o asset type, for example software including virtual machines (version), hardware (operating system / firmware), services, supporting utilities, facilities, heating, ventilation and air conditioning (HVAC) systems, personnel and physical records, o asset owner and contact information, o operational unit responsible for the asset, either internal department name or external provider name ( ), o asset description, o asset location, o date of asset’s last update/patch, o asset classification consistent with the risk assessment, o type of information and its classification processed in the basset, o asset end of life, where applicable, o relation to other assets and o logging requirements.

text: EXAMPLES OF EVIDENCE

text: • Configuration of the asset inventory tool, if any.

text: 12.4.3. The relevant entities shall regularly review and update the inventory and their assets and document the history of changes.

text: GUIDANCE

text: • Conduct regular reviews to verify the accuracy and completeness of the inventory. • Maintain history of changes.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: EXAMPLES OF EVIDENCE

text: • Up-to-date inventory of assets including history of changes. • Regular reports generated on inventory status, changes and audit findings.

text: TIPS

text: GUIDANCE

text: • Use tools that support the comprehensive tracking and management of assets. • Ideally, consider the use of tools for automated discovery and asset tracking to continuously discover, categorize, and monitor both on-premises and cloud assets, ensuring comprehensive, up-to-date visibility and security. Alternatively, consider manual update procedures. • Configure the chosen tool to capture the defined attributes and categories, ensuring it supports relevant functionalities such as tagging, searching and reporting. • Set up automated alerts for missing or incomplete data, discrepancies and anomalies detected in the inventory.

text: EXAMPLES OF EVIDENCE

text: • Configuration settings of the asset management tool.

text: 12.5 DEPOSIT, RETURN OR DELETION OF ASSETS UPON TERMINATION OF EMPLOYMENT

text: The relevant entities shall establish, implement and apply procedures which ensure that their assets which are under custody of personnel are deposited, returned or deleted upon termination of employment and shall document the deposit, return and deletion of those assets. Where the deposit, return or deletion of assets is not possible, the relevant entities shall ensure that the assets can no longer access the relevant entities’ network and information systems in accordance with point 12.2.2.

text: GUIDANCE

text: • Define procedures to ensure that assets are deposited, returned or irrevocably deleted on termination of employment or contractual relationships. • Make sure that the procedures clearly identify all assets to be returned, according to the asset inventory (Annex to the regulation, point 12.4.1), which can include (indicative, non-exhaustive list): o user endpoint devices, e.g. computers, tablets and phones etc and/or portable storage devices, including vehicles, that can store data locally on the vehicle and/or share data externally by means of telematics. Identify where the user process, transfer or store entity data to determine the scope of user endpoint devices; o specialised equipment; o authentication hardware (e.g. access cards, mechanical keys, physical tokens and smart cards); o physical copies of information.

text: EXAMPLES OF EVIDENCE

text: • Documented procedures for the timely return of assets upon termination of employment. • Logs or records indicating that data on returned assets was deleted according to the procedures.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Completed exit checklist forms that include asset return and data deletion steps, signed by the departing employee and relevant supervisors.

text: TIPS

text: GUIDANCE

text: • In cases where employees (and other third parties) use their own personal equipment, follow procedures to ensure that all relevant information is traced and transferred to the entity and securely deleted from the equipment. • Keep a record of the implementation of the policy (list of employees who have left or contractors whose contracts have ended and list of the assets they returned, including return date). • Make sure that relevant terms are part of the employment or service contract. • Communicate the procedures to employees during the induction process and during the exit process. • Check that there is an employee exit interview process and the return of the assets is linked with it. • Where the deposit, return or deletion of assets is not possible (indicative, non-exhaustive list): o ensure that any credentials associated with the assets are revoked or disabled; o isolate the assets by placing them in a separate network segment; o use access control lists to restrict access to and from the isolated assets; o ensure that only authorised personnel can interact with these assets; o configure firewalls to block any traffic to and from the isolated assets; o physically or logically disable the network interfaces of the assets; o continuously monitor the isolated assets and log any access attempts.

text: EXAMPLES OF EVIDENCE

text: • Personnel aware of the procedures. • Communication materials, such as emails or intranet posts, that remind employees of their obligations upon termination. • Statements confirming that data was irrevocably deleted, especially for external employees or contractors. • Documentation of the termination process, including coordination between HR and IT departments. • Sample checks of lists of employees/contractors and the assets they were assigned and those they returned.

text: Chapter 13

text: ENVIRONMENTAL

text: AND

text: PHYSICAL SECURITY

text: TECHNICAL IMPLEMENTATION GUIDANCE 13. ENVIRONMENTAL AND PHYSICAL SECURITY 13.1 SUPPORTING UTILITIES

text: 13.1.1. For the purpose of

text: Article 21(2)

text: (c) of

text: Directive (EU) 2022/2555

text: , the relevant entities shall prevent loss, damage or compromise of network and information systems or interruption to their operations due to the failure and disruption of supporting utilities.

text: GUIDANCE

text: • Consider supporting utilities, where relevant ( ), that ensure the continuous operation of network and information systems, such as (indicative, non-exhaustive list): o power supply – electricity to keep systems running; o water for cooling and other operational needs; o gas for heating or backup power generation; o HVAC to maintain optimal operating conditions; o telecommunications – internet and network connectivity. • Include the potential failure and disruption of supporting utilities in the risk assessment.

text: EXAMPLES OF EVIDENCE

text: • List of supporting utilities and associated risk assessment results. • Measures to protect against the failure and disruption of supporting utilities.

text: 13.1.2. For that purpose, the relevant entities shall, where appropriate: (a) protect facilities from power failures and other disruptions caused by failures in supporting utilities such as electricity, telecommunications, water supply, gas, sewage, ventilation and air conditioning; (b) consider the use of redundancy in utilities services; (c) protect utility services for electricity and telecommunications, which transport data or supply network and information systems, against interception and damage; (d) monitor the utility services referred to in point (c) and report to the competent internal or external personnel events outside the minimum and maximum control thresholds referred to in point 13.2.2(b) affecting the utility services; (e) conclude contracts for the emergency supply with corresponding services, such as for the fuel for emergency power supply; (f) ensure continuous effectiveness, monitor, maintain and test the supply of the network and information systems necessary for the operation of the service offered, in particular the electricity, temperature and humidity control, telecommunications and Internet connection.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: GUIDANCE

text: • Consider the availability of supporting utilities in the business continuity plan (section 4.1). • Consider the availability of supporting utilities, when implementing backup management (section 4.2). • Consider implementing measures for the protection of supporting utilities, such as (indicative, nonexhaustive list): o active/passive cooling; o automatic restart after power interruption; o battery backup power; o diesel generators; o backup fuel; o uninterruptable power supply, hot standby power generators; o sufficient fuel delivery SLA; o delivery companies; o redundant cooling; o spare parts for components of network and information systems; and o power backup systems.

text: EXAMPLES OF EVIDENCE

text: • Description of different types of supporting utilities. • Measures to protect against the failure and disruption of supporting utilities.

text: 13.1.3. The relevant entities shall test, review and, where appropriate, update the protection measures on a regular basis or following significant incidents or significant changes to operations or risks.

text: GUIDANCE

text: • Conduct routine tests of protection measures. • Set up periodic reviews to evaluate the effectiveness of current protection measures.

text: EXAMPLES OF EVIDENCE

text: • Updated measures to protect against the failure and disruption of supporting utilities, review comments and/or change logs. • Evidence that the measures that protect supporting utilities against failures and disruptions are deployed and regularly tested.

text: TIPS

text: GUIDANCE

text: • Include a simulated total power failure in the verification of the testing procedure for power generators. • Make employees aware of dependencies on supporting utilities. • Train staff in how to respond effectively to failures and disruptions of supporting utilities. • Set up monitoring systems to detect utility failures or disruptions.

text: EXAMPLES OF EVIDENCE

text: • Records of internal communications, emails or newsletters highlighting the importance of supporting utilities and their impact on operations.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Logs demonstrating detection and recording of any utility failures or disruptions.

text: 13.2 PROTECTION AGAINST PHYSICAL AND ENVIRONMENTAL THREATS

text: 13.2.1. For the purpose of

text: Article 21(2)

text: (e) of

text: Directive (EU) 2022/2555

text: , the relevant entities shall prevent or reduce the consequences of events originating from physical and environmental threats, such as natural disasters and other intentional or unintentional threats, based on the results of the risk assessment carried out pursuant to point 2.1.

text: GUIDANCE

text: • Consider risks associated with current and forecasted physical and environmental threats to the network and information systems, where relevant ( ). o Include in the assessment the (physical) locations of the entity’s facilities. • Based on the results of the risk assessment determine the assets that need to be protected from physical and environmental threats.

text: EXAMPLES OF EVIDENCE

text: • Risk assessment report that includes: o identification and evaluation of physical locations, such as data centres, offices and server rooms, o analysis of potential physical and environmental threats and o mapping of critical assets to physical locations.

text: 13.2.2. For that purpose, the relevant entities shall, where appropriate: (a) design and implement protection measures against physical and environmental threats; (b) determine minimum and maximum control thresholds for physical and environmental threats; (c) monitor environmental parameters and report to the competent internal or external personnel events outside the minimum and maximum control thresholds referred to in point (b).

text: GUIDANCE

text: • Implement measures against physical and environmental threats. Parameters to consider are (indicative, non-exhaustive list): o purpose and scope; o network and information systems in scope; o description of facilities; o roles and responsibilities; o management commitment; o coordination among organisational units; o compliance with national and EU law, including personal data protection.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Consider potential physical and environmental threats relevant to the context, location and operational environment. The following list offers examples (indicative and non-exhaustive) to support risk-based planning: o fire, flood or natural events (e.g. earthquakes, storms), o public disturbances or unauthorized access, theft or vandalism, o hazardous material incidents (e.g. chemical spills), o long-term environmental changes (e.g. climate trends, air quality). • Consider measures against physical and environmental threats such as (indicative, non-exhaustive list): o physical access control measures (e.g. IDs, badges, logs; visitor management system and physical barriers); o surveillance systems (e.g. CCTV, entry points, exits, locking mechanisms and security personnel); o climate control (e.g. temperature and humidity controls and HVAC systems); o fire prevention and response measures (e.g. fire alarms, smoke detectors, sprinkler systems and fire extinguishers); • Consider enhanced (maximum) measures to be activated during heightened threat levels or specific scenarios. Examples of such measures include (indicative, non-exhaustive list): o Increased security personnel, advanced biometric access controls and lockdown procedures. o Enhanced monitoring systems, redundant power supplies and advanced environmental sensors.

text: EXAMPLES OF EVIDENCE

text: • Detailed documentation showing the design and implementation of measures against physical and environmental threats. • Reports outlining the defined minimum and maximum control thresholds for various threats. • Logs from environmental monitoring systems showing continuous tracking of parameters, such as temperature, humidity and security breaches. • Records of incidents where parameters fell outside the defined thresholds, including the actions taken and notifications sent to relevant personnel.

text: 13.2.3. The relevant entities shall test, review and, where appropriate, update the protection measures against physical and environmental threats on a regular basis or following significant incidents or significant changes to operations or risks.

text: GUIDANCE

text: • Schedule and perform regular tests, such as quarterly fire drills and annual assessments of physical security measures. o Conduct both announced and unannounced tests

text: EXAMPLES OF EVIDENCE

text: • Detailed reports of the tests conducted, including objectives, procedures, results and any issues identified. • Minutes from review meetings detailing discussions, findings and decisions regarding protection measures.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: TIPS

text: GUIDANCE

text: • Consider creating a topic-specific policy for protection against physical and environmental threats. • Deploy periodic simulations and awareness raising activities to assess the readiness of personnel and the adequacy of the procedures • Consider implementing physically secure storage facilities for high-criticality assets of.

text: EXAMPLES OF EVIDENCE

text: • Documented physical and environmental security policy, including a description of facilities and network and information systems in scope. • Results of periodic simulations and awareness raising activities.

text: 13.3 PERIMETER AND PHYSICAL ACCESS CONTROL

text: 13.3.1. For the purpose of

text: Article 21(2)

text: (i) of

text: Directive (EU) 2022/2555

text: , the relevant entities shall prevent and monitor unauthorised physical access, damage and interference to their network and information systems.

text: GUIDANCE

text: • Implement perimeter physical access control, where relevant ( ), taking into account the measures for protection against physical and environmental threats (section 13.2). • Ensure that physical access control is integrated with logical and network access control, in line with human resources security procedures (section 10.1) to support the detection of irregular activities and enhance overall organisational security.

text: EXAMPLES OF EVIDENCE

text: • Documented policy for physical security measures, including a description of facilities and network and information systems in scope.

text: 13.3.2. For that purpose, the relevant entities shall: (a) on the basis of the risk assessment carried out pursuant to point 2.1, lay down and use security perimeters to protect areas where network and information systems and other associated assets are located; (b) protect the areas referred to in point (a) by appropriate entry controls and access points; (c) design and implement physical security for offices, rooms and facilities, (d) continuously monitor their premises for unauthorised physical access.

text: GUIDANCE

text: • In the risk assessment, consider risks associated with unauthorised physical access to, damage to and interference with network and information systems.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: • Based on the results of the risk assessment, determine high-criticality assets and the impact of their being compromised. This will help in identifying the perimeter for such assets. • Prevent unauthorised physical access to facilities and set up adequate measures. o Physical access control measures designed to protect the entity as a whole will also protect individual assets. o Consider introducing further specific access control measures for specific assets or facilities. • Consider physical security measures (indicative, non-exhaustive list): o physical access controls such as key cards, biometric scanners, locks and security personnel to restrict access to high-criticality areas, o electronic control of entry, with an audit trail, o segmentation of spaces or creation of zones according to authorization levels and their contents, o CCTV cameras and monitoring systems to continuously observe sensitive areas, o fencing, barriers and security patrols for securing physical perimeters, o guards and/or alarms to monitor every physical access point to the facility where the information system resides, 24 hours per day, seven days per week. • Develop and enforce procedures for granting, reviewing and revoking physical access rights (section 11.2). o Identify a designated official within the entity to review and approve the list of personnel with authorized physical access. o Maintain a list of personnel with authorized access to facilities, and their authorization levels.

text: EXAMPLES OF EVIDENCE

text: • Risk assessment results • Existence of physical security measures • Procedures for granting, reviewing and revoking physical access rights in accordance with point 11.2 in the Annex to the regulation.

text: 13.3.3. The relevant entities shall test, review and, where appropriate, update the physical access control measures on a regular basis or following significant incidents or significant changes to operations or risks.

text: GUIDANCE

text: • Review physical access lists. • Employ intrusion tests that include, where applicable, unannounced attempts to bypass or circumvent measures associated with physical access points to the facility. • At the physical boundary of the facility or network and information system, perform security checks for unauthorised exfiltration of information or removal of information system components.

text: EXAMPLES OF EVIDENCE

text: • Periodic simulations and awareness-raising activities to assess the readiness of personnel and the adequacy of the procedures for physical access control. • Schedule and results of tests and security checks. • Up-to-date list of personnel with authorised physical access to facilities.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: TIPS

text: GUIDANCE

text: • Enforce authorisation for physical access to network and information systems in addition to the physical access controls for the facility. • Remove individuals from the facility access list when their access is no longer required. • Document procedures for emergencies. • Log and monitor personnel physical access (entry and exit) through an entry control system. • Authenticate visitors before authorizing access to the facility. Escort visitors in accordance with security policies and procedures. Maintain records of visitors’ access to the facility. • Employ automated mechanisms to facilitate the maintenance and review of visitor access records. • Make sure that employees are aware of the existence of a secure area on a need-to-know basis. • Define and communicate to personnel an intruder response process or emergency procedures. • Communicate physical access control measures to employees. • Separate facilities managed by the entity from those managed by third parties. • Employ automated mechanisms to recognize types of intrusions and initiate defined response actions. • Employ video surveillance of operational areas and retain video recordings for a defined period, in accordance with the GDPR. • Keep physical access records as dictated by applicable regulations or based on an entity-defined period in accordance with the entity’s policy. Keep and store physical access records in case of an audit or investigation. • Take heed of risk-assessment results before doing anything with damaged devices containing sensitive data.

text: EXAMPLES OF EVIDENCE

text: • Perimeter incident response procedures in place. • Personnel clearly displaying their ID.

text: ANNEX I NATIONAL FRAMEWORKS

text: TECHNICAL IMPLEMENTATION GUIDANCE ANNEX I NATIONAL FRAMEWORKS

text: Belgium

text: Belgium has completed the incorporation of the NIS2 Directive into national legislation. In that legislation, a special role is reserved for the CyberFundamentals framework (CyFun®, www.cyfun.eu).

text: Finland

text: Traficom (the Finnish Transport and Communications Agency) has issued a national recommendation on cybersecurity risk-management measures for supervisory authorities. The Cybermeter/Kybermittari is a maturity model developed by the National Cyber Security Centre (NCSC-FI) and based on the Cybersecurity Capability Maturity Model and the NIST cybersecurity framework. They are the two instrumental documents for the national regulatory framework. The recommended cybersecurity risk-management measures are mapped to the Cybermeter/Kybermittari’s objectives and practices that enable organisations to self-assess their cybersecurity capabilities and optimise their security investments. Voluntarily sharing quantitative self-assessment data to NCSC-FI enables the creation of benchmarking data and improves situational awareness of NCSC-FI.

text: Germany

text: In Germany, there is an advisory on what requirements should be seen as state of the art. The document is available at https://www.bsi.bund.de/dok/408936. For information on BSI standards and certification, see https://www.bsi.bund.de/dok/it-grundschutz-en.

text: Greece

text: Greece has incorporated the NIS2 Directive into national legislation with Law 5160/2024. Furthermore, regarding cybersecurity measures, the Greek national framework consists of the following: • ministerial decision 1689/2025 ‘National framework of cybersecurity requirements for essential and important entities’; • the Cybersecurity Handbook, available at https://cyber.gov.gr/wp-content/uploads/2025/04/Cybersecurity- Handbook-English-version-1.pdf; • the self-assessment tool, available at https://cyber.gov.gr/wp-content/uploads/2025/03/Cybersecurity- Self-Assessment-Tool-English-version-1.zip. The Cybersecurity Handbook and the self-assessment tool are based on globally accepted international standards and guidelines (Center for Internet Security Controls, ISO 27002, NIST 800-53, Open Worldwide Application Security Project, etc.) and will be dynamically modified to follow changes in standards, the current threat landscape and the legal and regulatory framework.

text: Spain

text: Royal Decree 311/2022, of 3 May 2022, regulates the national security framework, which is a legal regulation that is mandatory for all entities in the Spanish public sector to comply with and is mandatory to apply to the information systems used by private companies to provide services to the abovementioned public entities. The full text of the framework is available at https://ens.ccn.cni.es/es/docman/documentos-publicos/39-boe-a-2022- 7191-national-security-framework-ens/file.

text: ANNEX II GLOSSARY

text: TECHNICAL IMPLEMENTATION GUIDANCE ANNEX II GLOSSARY

text: Asset: anything that is of value to the entity, including information. Overall, the assets of a network and information system are personnel, processes, information, software and hardware. Crisis: an abnormal or extraordinary event or situation that threatens an organisation or community and requires a strategic, adaptive and timely response to preserve its viability and integrity ( ). Critical: one of the classification levels assigned to the entity’s assets following an assessment of their criticality, including the asset classification (Annex to the regulation, point 12.1). Cyber hygiene practices ( ): • Cyber hygiene practices for essential and important entities are a common baseline set of network and information security practices, which are already covered by the technical and methodological requirements of the cybersecurity risk-management measures outlined in the Annex to the regulation. Therefore, no additional guidance on cyber hygiene practices for essential and important entities is deemed necessary. • Cyber hygiene practices relating to users are a set of routine, proactive practices and behaviours that the entity’s users follow to maintain the network and information security of the entity’s systems. These practices are explicitly mentioned in the guidance of section 8.1. Direct suppliers and service providers: any entity providing ICT products, ICT systems or ICT services that an essential or important entity relies on. When this guidance refers to direct suppliers and service providers, it includes their personnel. Entity: one of the relevant entities in the scope of Commission Implementing

text: Regulation (EU) 2024/2690

text: . In other standards or good practice guides, the term ‘organisation’, ‘enterprise’ or ‘business’ may be used. Event: in reference to an information security event, an identified occurrence indicating a possible information security breach or failure of controls ( ). Facilities: the physical location housing the entity’s network and information systems. Incident handling: any actions and procedures aiming to prevent, detect, analyse and contain, or to respond to and recover from, an incident (NIS2 Directive

text: Article 6(8)

text: ). Incident: an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible through, network and information systems (NIS2 Directive

text: Article 6(6)

text: ). Information: data in context. In the text, we primarily use ‘information’, unless we refer specifically to data (‘data breach’ etc.). Management bodies: the highest-level leadership within essential and important entities as in the context of Article 20 of the NIS2 Directive. Measure: a cybersecurity risk-management measure as referred to in the NIS2 Directive. The word is used similarly to ‘control’, which denotes a measure that modifies risk ( ). In addition, the terms ‘measure’ and ‘protection measure’ are used interchangeably.

text: TECHNICAL IMPLEMENTATION GUIDANCE

text: Personnel: persons doing work under the entity’s direction ( ). The concept of personnel includes the entity’s members, such as the governing body, management bodies, employees, temporary staff, contractors and volunteers. In this document it is used interchangeably with the term ‘employees’. Policy: intentions and direction of an organisation, as formally expressed by its management bodies. Privileged access: the necessary permissions granted to specific users of the network and the information system of the entity, in order for them to perform tasks that regular users cannot. Procedure: a specified way to carry out an activity or a process ( ). The entity can document its needs for more detailed information in a way that is efficient for it beyond the policy. These are mainly procedures and processes. Process: an activity that transforms input into output. Rule: accepted principle or instruction that states the entity’s expectations of what is required to be done and what is allowed or not allowed. Rules can be formally expressed in topic-specific policies and in other types of documents ( ). Significant incident: an incident that meets the criteria of

text: Article 3 of the regulation

text: . Suspicious event: an event that appears unusual or a previously unknown situation that might be a potential security threat. To make clearer the difference between an event and a suspicious event, consider an example where a legitimate user fails to log in once due to a typing error. This is an event. However, a situation where a user fails to log in after five attempts might be considered a suspicious event. Topic-specific policy: a policy on a specific subject or topic, as formally expressed by the management bodies relevant to the topic. User: all legal and natural persons that have access to the entity’s network and information systems (

text: recital 10

text: of

text: the regulation

text: -N -EN -012 -25 -01 TP

text: ABOUT ENISA

text: The European Union Agency for Cybersecurity, ENISA, is the Union’s agency dedicated to achieving a high common level of cybersecurity across Europe. Established in 2004 and strengthened by the EU Cybersecurity Act, the European Union Agency for Cybersecurity contributes to EU cyber policy, enhances the trustworthiness of ICT products, services and processes with cybersecurity certification schemes, cooperates with Member States and EU bodies and helps Europe prepare for the cyber challenges of tomorrow. Through knowledge sharing, capacity building and awareness raising, the Agency works together with its key stakeholders to strengthen trust in the connected economy, to boost resilience of the Union’s infrastructure and, ultimately, to keep Europe’s society and citizens digitally secure. More information about ENISA and its work can be found here: www.enisa.europa.eu.

text: ISBN 978-92-9204-704-7 doi: 10.2824/2702548