IMPLEMENTING

GUIDANCE
On Commission Implementing Regulation (EU) 2024/2690 of
17.10.2024 laying down rules for the application of Directive (EU)
2022/2555 as regards technical and methodological requirements
of cybersecurity risk-management measures

with regard to DNS service providers, TLD name registries, cloud computing service providers,
data centre service providers, content delivery network providers, managed service providers,
managed security service providers, providers of online market places, of online search engines
and of social networking services platforms, and trust service providers

DRAFT FOR PUBLIC CONSULTATION

OCTOBER 2024
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1 ABOUT ENISA

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

10 CONTACT
11 For contacting the authors, please use ENISA-NIS-Directive@[Link]
12 For media enquiries about this paper, please use press@[Link].

13 AUTHORS
14 Konstantinos Moulinos, Marianthi Theocharidou, ENISA

15 ACKNOWLEDGEMENTS
16 This implementation guidance was developed by ENISA, in collaboration with the European Commission and the NIS
17 Cooperation Group. ENISA would like to thank for their efforts the NIS Cooperation Group work streams on
18 cybersecurity risk and vulnerability management, on digital service providers and on digital infrastructures, as well as
19 the ENISA European Competent Authorities for Trust Services (ECATS) Expert Group and the European Competent
20 Authorities for Secure Electronic Communications (ECASEC).

21 LEGAL NOTICE
22 This publication represents the views and interpretations of ENISA, unless stated otherwise. It does not endorse a
23 regulatory obligation of ENISA or of ENISA bodies pursuant to the Regulation (EU) No 2019/881.
24 ENISA has the right to alter, update or remove the publication or any of its contents. It is intended for information
25 purposes only and it must be accessible free of charge. All references to it or its use as a whole or partially must
26 contain ENISA as its source.
27 Third-party sources are quoted as appropriate. ENISA is not responsible or liable for the content of the external
28 sources including external websites referenced in this publication.
29 Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information
30 contained in this publication.
31 ENISA maintains its intellectual property rights in relation to this publication.
32
33 COPYRIGHT NOTICE
34 © European Union Agency for Cybersecurity (ENISA), 2024

35 This publication is licenced under CC-BY 4.0 “Unless otherwise noted, the reuse of this document is authorised under
36 the Creative Commons Attribution 4.0 International (CC BY 4.0) licence
37 ([Link] This means that reuse is allowed, provided that appropriate credit is
38 given and any changes are indicated”.

39 For any use or reproduction of photos or other material that is not under the ENISA copyright, permission must be
40 sought directly from the copyright holders.
41
42 ISBN SHOULD BE PLACED HERE, DOI SHOULD BE PLACED HERE (IF APPLICABLE)

1
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

43

44 EXECUTIVE SUMMARY 5

45 INTRODUCTION 6
46 BACKGROUND 6

47 STRUCTURE 6

48 TOPIC SPECIFIC POLICIES 8

49 1. POLICY ON THE SECURITY OF NETWORK AND INFORMATION 9

50 1.1 POLICY ON THE SECURITY OF NETWORK AND INFORMATION SYSTEMS 9

51 1.2 ROLES, RESPONSIBILITIES AND AUTHORITIES 12

52 2. RISK MANAGEMENT POLICY 16

53 2.1 RISK MANAGEMENT FRAMEWORK 16

54 2.2 COMPLIANCE MONITORING 21

55 2.3 INDEPENDENT REVIEW OF INFORMATION AND NETWORK SECURITY 23

56 3. INCIDENT HANDLING 26
57 3.1 INCIDENT HANDLING POLICY 26

58 3.2 MONITORING AND LOGGING 29

59 3.3 EVENT REPORTING 34

60 3.4 EVENT ASSESSMENT AND CLASSIFICATION 36

61 3.5 INCIDENT RESPONSE 38

62 3.6 POST-INCIDENT REVIEWS 41

63 4. BUSINESS CONTINUITY AND CRISIS MANAGEMENT 44

64 4.1 BUSINESS CONTINUITY AND DISASTER RECOVERY PLAN 44

65 4.2 BACKUP MANAGEMENT 48

66 4.3 CRISIS MANAGEMENT 52

67 5. SUPPLY CHAIN SECURITY 57

68 5.1 SUPPLY CHAIN SECURITY POLICY 57

2
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

69 5.2 DIRECTORY OF SUPPLIERS AND SERVICE PROVIDERS 63

70 6. SECURITY IN NETWORK AND INFORMATION SYSTEMS

71 ACQUISITION, DEVELOPMENT AND MAINTENANCE 65
72 6.1 SECURITY IN ACQUISITION OF ICT SERVICES, ICT SYSTEMS OR ICT PRODUCTS 65

73 6.2 SECURE DEVELOPMENT LIFE CYCLE 68

74 6.3 CONFIGURATION MANAGEMENT 71

75 6.4 CHANGE MANAGEMENT, REPAIRS AND MAINTENANCE 74

76 6.5 SECURITY TESTING 78

77 6.6 SECURITY PATCH MANAGEMENT 81

78 6.7 NETWORK SECURITY 83

79 6.8 NETWORK SEGMENTATION 87

80 6.9 PROTECTION AGAINST MALICIOUS AND UNAUTHORISED SOFTWARE 90

81 6.10 VULNERABILITY HANDLING AND DISCLOSURE 92

82 7. POLICIES AND PROCEDURES TO ASSESS THE EFFECTIVENESS OF

83 CYBERSECURITY RISK-MANAGEMENT MEASURES 96

84 8. BASIC CYBER HYGIENE PRACTICES AND SECURITY TRAINING 99

85 8.1 AWARENESS RAISING AND BASIC CYBER HYGIENE PRACTICES 99

86 8.2 SECURITY TRAINING 101

87 9. CRYPTOGRAPHY 104

88 [Link] RESOURCES SECURITY 108

89 10.1 HUMAN RESOURCES SECURITY 108

90 10.2 VERIFICATION OF BACKGROUND 110

91 10.3 TERMINATION OR CHANGE OF EMPLOYMENT PROCEDURES 112

92 10.4 DISCIPLINARY PROCESS 114

93 [Link] CONTROL 116

94 11.1 ACCESS CONTROL POLICY 116

95 11.2 MANAGEMENT OF ACCESS RIGHTS 119

96 11.3 PRIVILEGED ACCOUNTS AND SYSTEM ADMINISTRATION ACCOUNTS 121

3
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

97 11.4 ADMINISTRATION SYSTEMS 124

98 11.5 IDENTIFICATION 125

99 11.6 AUTHENTICATION 127

100 11.7 MULTI-FACTOR AUTHENTICATION 131

101 [Link] MANAGEMENT 133

102 12.1 ASSET CLASSIFICATION 133

103 12.2 HANDLING OF ASSETS 135

104 12.3 REMOVABLE MEDIA POLICY 136

105 12.4 ASSET INVENTORY 138

106 12.5 DEPOSIT, RETURN OR DELETION OF ASSETS UPON TERMINATION OF EMPLOYMENT 141

107 [Link] AND PHYSICAL SECURITY 143

108 13.1 SUPPORTING UTILITIES 143

109 13.2 PROTECTION AGAINST PHYSICAL AND ENVIRONMENTAL THREATS 145

110 13.3 PERIMETER AND PHYSICAL ACCESS CONTROL 148

111 ANNEX I NATIONAL FRAMEWORKS 151

112 ANNEX II GLOSSARY 152

4
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

113 EXECUTIVE SUMMARY

114
115 Commission Implementing Regulation (EU) 2024/2690 of 17 October 20241, with regard to DNS service providers, TLD
116 name registries, cloud computing service providers, data centre service providers, content delivery network providers,
117 managed service providers, managed security service providers, providers of online market places, of online search
118 engines and of social networking services platforms, and trust service providers (the relevant entities) lays down the
119 technical and the methodological requirements of the measures referred to in Article 21(2) of Directive (EU) 2022/2555.
120 The technical and methodological requirements are set out in Article 2 and in the Annex of the implementing regulation.
121
122 This document offers guidance to support relevant entities to implement these technical and methodological
123 requirements. For these requirements, the document contains:

124 • guidance, i.e., indicative and actionable advice on parameters to consider when implementing a requirement or further
125 explanation to concepts found in the legal text;
126 • examples of evidences, i.e. the types of evidence that a requirement is in place;
127 • extra general tips for additional consideration by the entity, where available; and
128 • mapping correlating each requirement to European and international standards and national frameworks.
129
130 This guidance was prepared by ENISA, in collaboration with the European Commission and the NIS Cooperation Group.
131 This is a living document because it maps the technical and methodological requirements, referred to in Article 2 and
132 the Annex of the implementing regulation, to international standards as well as to national cybersecurity management
133 frameworks which are both constantly subject to change. Therefore, a review process should be initiated at regular
134 intervals by ENISA in collaboration with the European Commission and the NIS Cooperation Group.
135

DISCLAIMER

The document is not legally binding and it is only of advisory character. It does not intend to replace the
frameworks, guidance or other mechanisms provided by Member States’ national law.

It should be clarified that the Member States retain the freedom to determine their approach to supervision of the
requirements under this implementing regulation. Therefore, the ENISA document isn’t 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). However, the ENISA document can help the national competent
authorities develop their approach to the supervision of the requirements.

Furthermore, entities in scope should check under whose jurisdiction they fall, and follow any guidance produced
by national competent authorities (see Recital (7) of the Implementing regulation).

136

137

1
Available at: [Link]

5
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

138 INTRODUCTION

139 BACKGROUND
140 On 18 October 2024, the European Commission published the Commission Implementing Regulation 2024/2690 of 17
141 October 2024, hereafter the Regulation, pursuant to Articles 21(5), first subparagraph and 23(11), second
142 subparagraph of Directive (EU) 2022/2555 (hereafter NIS2 Directive). Article 2 of this regulation specifies that for the
143 essential and important entities, in scope of the Regulation (hereafter ‘relevant entities’), the technical and
144 methodological requirements of cybersecurity risk management measures referred to in Article 21(2), points (a) to (j),
145 of the NIS2 Directive are set out in the Annex to the Regulation.

146 According to Recital (7), ENISA can support relevant entities by providing guidance on the implementation of the
147 technical and methodological requirements referred to the Annex of the Regulation. This implementation guidance
148 was developed by ENISA and the work stream on cybersecurity risk and vulnerability management of the NIS
149 Cooperation Group (NIS CG), in collaboration with the NIS Cooperation Group work streams on digital service
150 providers and on digital infrastructures, as well as with the ENISA European Competent Authorities for Trust Services
151 (ECATS) Expert Group and the European Competent Authorities for Secure Electronic Communications (ECASEC). It
152 is the result of consultations which took place from June to mid-October 2024.

153 The document provides non-binding guidance for relevant entities to the Regulation, on the technical and the
154 methodological requirements of the cybersecurity risk-management measures.

155 Beyond the relevant entities to the Regulation, this guidance may provide indications on the technical and the
156 methodological requirements of the cybersecurity risk-management measures of NIS 2 Directive, which may be
157 considered useful by other public or private actors in improving their cybersecurity.

158 STRUCTURE
159 The Annex of the Regulation consists of 13 Titles with a varying number of technical and methodological
160 requirements. Each technical and methodological requirement is highlighted in blue and is included in this document
161 for readability. This is mandatory and must be implemented in its entirety by the relevant entities.

162 Each technical and methodological requirement is followed by three elements: guidance, examples of evidences and
163 tips2. This part of the document is not legally binding and has only a recommendation character3.

164 1. The Guidance section contains indicative and actionable advice on parameters to consider when
165 implementing a technical and methodological requirement or further explanation to concepts found in the
166 legal text.
167 2. Examples of evidences are indicative types of evidence that a technical and methodological requirement is
168 in place.
169 3. In some technical and methodological requirements, extra general tips are also offered for additional
170 consideration by the entity.

171 The guidance, examples of evidence, and tips are non-exhaustive. Their partial or complete implementation does not
172 assume compliance or conformity with the requirements of the Regulation. Entities may choose alternative methods to
173 fulfil a requirement or use different evidence to demonstrate compliance. Moreover, a single piece of evidence may

2
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.

6
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

174 support various requirements; for example, an organizational chart can demonstrate both ‘roles and responsibilities’
175 and ‘segregation of duties.’ Consequently, evidence may appear multiple times within the text.

176 Finally, a mapping table correlates each requirement with European and international standards or frameworks
177 (ISO/IEC 27001:2022, ISO/IEC 27002:20224, NIST Cybersecurity Framework 2.0, ETSI EN 319 401 V2.2.1 (2018-04),
178 CEN/TS 18026:2024), and with national frameworks5. It should be noted that the mapping was done only to horizontal
179 standards and for specific topics, there are detailed standards or technical specifications referenced, where available,
180 in footnotes. Annex I of this document provides details for each national framework submitted to ENISA during the
181 consultation phases while in annex II some terms are explained. The document does not aim at establishing a new
182 standard nor to duplicate existing ones (e.g., ISO, IEC, CEN). The guidance is written in a technology-neutral and
183 standards-neutral way.

184

185 Figure 1: Technical and methodological measure structure

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

192 Entities subject to the Regulation can use national frameworks, guidance, or other mechanisms equivalent to the
193 requirements of the Regulation to demonstrate their compliance to national competent authorities. Depending on the
194 national framework, assessment by relevant accredited conformity assessment bodies or by independent auditors
195 authorised by the national competent authorities, against the national frameworks, guidelines or other mechanisms
196 equivalent to technical and methodological requirements for cybersecurity risk management measures, could serve as
197 demonstration of compliance with the requirements set out by the implementing act. In order to keep the current
198 guidance up to date, Member States can inform ENISA of those equivalent national frameworks, guidance or other
199 mechanisms, if available.

4
The information security controls listed in Table A.1 of the annex A of this standard, are directly derived from and aligned with those listed in ISO/IEC
27002:2022, Clauses 5 to 8 and 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.

7
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

200 TOPIC SPECIFIC POLICIES

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

205 In addition to this overarching corporate policy the following topic-specific, documented policies7 are required:

206 1. Incident handling policy (Annex to the Regulation, point 3.1.1).

207 2. Supply security chain policy (Annex to the Regulation, point 5.1.1).
208 3. Security testing policy (Annex to the Regulation, point 6.5.1).
209 4. Policy to assess the effectiveness of cybersecurity risk-management measures (Annex to the Regulation,
210 point 7.1.1).
211 5. Policy related to cryptography (Annex to the Regulation, point 9.1.1).
212 6. Access control policy (Annex to the Regulation, point 11.1.1).
213 7. Policies for the management of privileged accounts and system administration accounts (Annex to the
214 Regulation, point 11.3)
215 8. Handling of information and assets policy (Annex to the Regulation, point 12.2.1).
216 9. Removable media policy (Annex to the Regulation, point 12.3.1).

6
Article 21(2), point (a) of the NIS2 Directive.
7
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”.

8
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

217 1. POLICY ON THE SECURITY OF

218 NETWORK AND INFORMATION

219 1.1 POLICY ON THE SECURITY OF NETWORK AND INFORMATION SYSTEMS

220 1.1.1. For the purpose of Article 21(2), point (a) of Directive (EU) 2022/2555, the policy on the security of network and
221 information systems shall:
222 (a) set out the relevant entities’ approach to managing the security of their network and information systems;
223 (b) be appropriate to and complementary with the relevant entities’ business strategy and objectives;
224 (c) set out network and information security objectives;
225 (d) include a commitment to continual improvement of the security of network and information systems;
226 (e) include a commitment to provide the appropriate resources needed for its implementation, including the necessary
227 staff, financial resources, processes, tools and technologies;
228 (f) be communicated to and acknowledged by relevant employees and relevant interested external parties;
229 (g) lay down roles and responsibilities pursuant to point 1.2.;
230 (h) list the documentation to be kept and the duration of retention of the documentation;
231 (i) list the topic-specific policies;
232 (j) lay down indicators and measures to monitor its implementation and the current status of relevant entities’ maturity
233 level of network and information security;
234 (k) indicate the date of the formal approval by the management bodies of the relevant entities (the ‘management bodies’).

235 GUIDANCE

236 • Set a policy on the security of network and information systems for systems, assets, and/or procedures,
237 which are considered in scope of the policy.
238 • Make sure that personnel, as well as all third parties8 (e.g. contractors, suppliers) acknowledge the policy
239 on the security of network and information systems, typically through a signed document or digital
240 acknowledgement, where applicable, and what it implies for their work.

241 EXAMPLES OF EVIDENCES

242 • Documented policy on the security of network and information systems which contains the elements
243 required by points 1.1.1 (a) to 1.1.1 (k) from the Annex to the Regulation.
244 • The policy on the security of network and information systems as well topic specific policies are approved
245 by top management.
246 • The date of the formal approval by the management bodies of the relevant entities is indicated in the policy
247 on the security of network and information systems.
248 • Personnel are aware of the policy on the security of network and information systems and what it implies
249 for their work.
250 • Signed acknowledgement forms from contractor personnel confirming they have read and understood the
251 security policies.
252 • Interview with top management to verify their involvement with information security management.

8
Depending on the occasion third parties might mean the suppliers, service providers, the shareholders, the authorities, the customers, visitors,
external interest groups and forums.

9
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

253 • Evidence that top management understand their role, responsibilities and authorities regarding network
254 and information security. This can include but is not limited to:
255 o Allocation of resources for policy implementation;
256 o Requests to personnel to apply network and information security in accordance with the
257 established policies and procedures; and
258 o Any initiatives that indicate that management promotes improvement in the area of network and
259 information security.
260
261 1.1.2. The network and information system security policy shall be reviewed and, where appropriate, updated by
262 management bodies at least annually and when significant incidents or significant changes to operations or risks occur.
263 The result of the reviews shall be documented.

264 GUIDANCE

265 • Review the policy on the security of network and information systems at least annually, taking into account
266 (indicative, non-exhaustive list):
267 o relevant changes in legislation, best practices;
268 o feedback from interested parties;
269 o results of independent reviews;
270 o recommendations provided by relevant authorities;
271 o violations;
272 o exceptions; and
273 o incidents, even those affecting other similar entities in the sector
274 • Update the policy on the security of network and information systems as well topic specific policies
275 accordingly to new findings that could affect the entity’s approach to managing information security
276 including:
277 o changes to the information systems;
278 o changes to the environment of operation;
279 o problems identified during plan implementation;
280 o status of preventive and corrective actions;
281 o trends related to threats and vulnerabilities;
282 o exceptions
283 o policy violations; and known reported security incidents.
284 • Obtain management approval for the revised policy and the policy exceptions.

285 EXAMPLES OF EVIDENCES

286 • Review comments or change logs for the policy on the security of network and information systems as
287 well topic specific policies.
288 • Logs of policy exceptions, approved by the relevant roles. Examples of such exceptions, amongst others,
289 include the situations mentioned in article 2(2) second paragraph as well as those under recital 5 of the
290 Regulation. Other examples (indicative, non-exhaustive list):
291 o software updates: if a system relies on an older version of software that is incompatible with the
292 latest update, an exception might be granted to delay the update until a compatible solution is
293 found;

10
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

294 o access control: If a particular user or system cannot support multi-factor authentication (MFA)
295 due to technical limitations, an exception might be granted while alternative measures are
296 implemented; and
297 o encryption: if a legacy system does not support encryption, an exception might be granted until
298 the system is replaced.
299 • Documentation of review process of the requirements listed in point 1.1.1 of the Annex to the Regulation,
300 Up to date policy on the security of network and information systems as well topic specific policies.
301 • Evidence that any updates to the policy on the security of network and information systems as well topic
302 specific policies, as well as any policy exceptions are approved by management, and record is kept.

303 TIPS

304 GUIDANCE

305 • Analyse the policy on the security of network and information systems for compliance with:
306 o legislative, regulatory, and contractual requirements;
307 o training and awareness requirements; and
308 o business continuity requirements.
309 • Define procedures to facilitate the implementation of the policy on the security of network and information
310 systems and associated measures.
311 • Maintain a record of the management review.
312 • Examine documentation of post-incident reviews for significant incidents that include participation and
313 input from top management.
314 • Ensure that the policy is:
315 o protected in terms of confidentiality, integrity and availability;
316 o managed properly so the information is complete, correct, understandable, easily identifiable and
317 retrievable.

318 EXAMPLES OF EVIDENCES

319 • Documented policy on the security of network and information systems, including networks and services
320 in scope, assets supporting them, and the security objectives, including applicable laws and regulations,
321 accessible to personnel.
322 • Documented topic specific policies, including applicable laws and regulations, accessible to relevant
323 personnel.
324 • Training material on the policy on the security of network and information systems.
325 • Evidence of cybersecurity training of management, for instance:
326 o training records;
327 o workshop and seminar attendance; and
328 o continuous learning materials.
329 • Internal communication logs, ad hoc reports or communication policy or records showing regular briefings
330 or updates provided to top management regarding cybersecurity matters or during significant incidents.
331
332

11
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

333 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 5.2, A.5.1, A.5.36, A.5.4, 9.3 BE-CyFun®2023 BASIC: [Link]-1.1
IMPORTANT: [Link]-1.2, [Link]-5.1,
[Link]-6.1, [Link]-2.1, [Link]-4.1
ESSENTIAL: [Link]-3.3, [Link]-4.3
NIST CSF v2.0 [Link]-02, [Link]-01, FI-Kybermittari WORKFORCE-3, PROGRAM-1,
[Link]-02, [Link]-03, PROGRAM-2, Management activities,
[Link]-03, [Link]-02, CRITICAL-2, ARCHITECTURE-1,
[Link]-01, [Link]-02, [Link]-
03, [Link]-04
ETSI EN 319 401 REQ 6.1-02, REQ 6.1-06, EL – Ministerial Cybersecurity handbook: Part A: 2,
REQ 6.1-07, REQ 6.1-08, decision Part B: 1.1, 1.5, 2.1, 3.1, 4.1, 5.1, 6.1,
REQ 6.3 1027/2019 7.1, 8.1, 9.1, 10.1, 11.1, 12.1, 13.1,
Article 2 - 14.1, 15.1, 16.1, 17.1, 18.1
paragraph 2, Self assessment tool: 1.7, 1.8, 1.9,
Article 3 1.10, 1.11, 1.12, 1.13, 2.1, 2.2, 3.1,
4.1, 5.1, 6.1, 7.1, 8.1, 9.1, 10.1, 11.1,
12.1, 13.1, 14.1, 15.1, 16.1, 17.1,
18.1, 19.1
CEN/TS 18026:2024 ISP-01, ISP-02, OPS-01, ES- Royal Decree Article 5, Article 6, Article 10, Article
OPS-02, OPS-03 311/2022 12, Annex II: 3.1 Security policy

334

335 1.2 ROLES, RESPONSIBILITIES AND AUTHORITIES

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

339 GUIDANCE

340 • Write job descriptions in way that they clearly outline rights and responsibilities.
341 • Assign security roles and responsibilities to personnel and include these roles in the organisational chart.
342 • Describe and assign corresponding responsibilities regarding the following roles (or comparable
343 equivalents): Chief Information Officer (CIO), Chief Information Security Officer (CISO) and IT security
344 incident handling officer.
345 • Use guidance of major frameworks and international standards suitable for the size and business needs
346 of the entity, including the European Cybersecurity Skills Framework (ECSF)9.
347 • Formally appoint security personnel in security roles.

348 EXAMPLES OF EVIDENCES

349 • Job descriptions.

350 • List of security roles (CISO, DPO, business continuity manager, etc.), who occupies them and contact
351 information.
352 • Formal appointment of the key security roles and responsibilities.
353 • List of appointments (CISO, DPO, etc.), and description of responsibilities and tasks for security roles
354 (CISO, DPO, etc.)

9
[Link]

12
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

355

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

359 GUIDANCE

360 • Make general personnel aware of the security roles in the entity and when each role should be contacted.
361 • Make third parties aware that they should comply with the entity’s network and information security policy.
362 Consider third parties, which refer to external entities or organisations not directly involved in the
363 operations of the entity in scope but that may still affect its network and information security. Examples
364 include suppliers, contractors, service providers, and other external partners.

365 EXAMPLES OF EVIDENCES

366 • Awareness/dissemination material for personnel explaining security roles and when/how they should be
367 contacted.
368 • Service level agreements (SLAs) with third parties. These documents should explicitly state that third
369 parties must adhere to the entity’s network and information security policy, topic-specific policies and
370 procedures.
371 • Formal acknowledgement letters or emails from third-parties confirming that they have received and
372 understand the entity’s network and information security policy, topic-specific policies and procedures.
373

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

376 GUIDANCE

377 • Appoint a dedicated person (e.g., Chief Information Security Officer or Information Security Manager)
378 responsible for overseeing security matters.
379 • Make sure that this person has the authority and expertise to communicate effectively with management.

380 EXAMPLES OF EVIDENCES

381 • Up-to-date documentation of the structure of security role assignments and responsibilities.
382 • Interview with the individual to assess communication skills and authority.
383 • Feedback from management and other stakeholders about the individual’s effectiveness in
384 communication.
385 • Minutes from meetings with the management.
386

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

389 GUIDANCE

390 • In bigger entities, it’s often practical to have dedicated information security roles (like a Chief Information
391 Security Officer or security analysts) who focus solely on protecting the entity’s data and systems.
392 • In smaller entities with limited resources, information security responsibilities might be distributed among
393 existing roles. For instance, IT staff might take on security duties alongside their regular tasks.

13
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

394 EXAMPLES OF EVIDENCES

395 • Verify the presence of dedicated security roles in larger entities.

396 • Check if security responsibilities are assigned to existing roles in smaller entities.
397

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

399 GUIDANCE

400 • Segregate conflicting duties and areas of responsibility in order to reduce opportunities for unauthorized
401 or unintentional modification or misuse of the entity’s asset. Examples of such segregations are
402 (indicative, non-exhaustive list):
403 o (Chief) Information Security Officer from IT administrator;
404 o (Cyber security) System architect from system (security) tester;
405 o Identity manager from system administrator;
406 o Reviewer (auditor) from the personnel or the line of authority of the area under review (see point
407 2.3.2 of the Annex to the Regulation); and
408 o Incident responder from legal compliance team.

409 EXAMPLES OF EVIDENCES

410 • Up-to-date documentation of the structure of security role assignments and responsibilities.
411

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

414 GUIDANCE

415 • Regularly review and revise the structure of security roles and responsibilities, based on changes and/or
416 past incidents.

417 EXAMPLES OF EVIDENCES

418 • Documentation of review process, taking into account changes and past incidents.
419

420 TIPS

421 GUIDANCE

422 • Make sure the security roles are reachable in case of incidents.
423 • Examine the crisis management process (see section 4.3.1) or incident response procedures (see
424 section 3.5.1) to see if they outline specific roles for top management, as appropriate.
425 • Make sure that each role has its deputy or that measures ensuring the continuity in case of role
426 representative´s absence are in place.
427 • Establish a clear reporting line from the designated security officer to senior management.
428 • Ensure that security reporting is integrated into the entity’s overall risk management framework.

429 EXAMPLES OF EVIDENCES

430 • Documented incident response procedures (see section 3.5) include clear procedures for contacting
431 security roles during an incident.
432 • Logs and records of past incidents to check if the security roles were contacted promptly and effectively.
433 • Crisis management process and incident response records to check the involvement of the
434 management.

14
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

435 • Up-to-date organisational chart to check if it clearly shows the reporting structure, including the
436 designated security officer and their direct line to senior management.
437
438

439 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 5.3, A.5.2, A.5.3, A.5.4 BE-CyFun®2023 BASIC: [Link]-1.1
IMPORTANT: [Link]-6.1, [Link]-2.1,
[Link]-4.1, [Link]-5.1, [Link]-1.1
NIST CSF v2.0 [Link]-02, [Link]-02, [Link]- FI- Kybermittari PROGRAM-1, PROGRAM-2, CRITICAL-2,
02, [Link]-01, [Link]-02, [Link]- WORKFORCE-2 WORKFORCE-3
03, [Link]-04
ETSI EN 319 401 REQ 7.2.6, REQ 7.2.7, REQ EL – Ministerial Cybersecurity handbook: Part A: 2, Part
7.2.10, REQ 7.2.11, REQ decision B: 1.1, 2.1, 3.1, 4.1, 5.1, 6.1, 7.1, 8.1,
7.2.12, REQ 7.2.13, REQ 1027/2019 Article 9.1, 10.1, 11.1, 12.1, 13.1, 14.1, 15.1,
7.2.14 2 - paragraph 2, 16.1, 17.1, 18.1
Article 3 Self assessment tool: 1.1, 1.2, 1.3, 1.4,
1.5

CEN/TS 18026:2024 ISP-02, OIS-02 ES-Royal Decree Article 11, Article 13

311/2022

440

15
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

441 2. RISK MANAGEMENT POLICY

442 2.1 RISK MANAGEMENT FRAMEWORK

443 2.1.1. For the purpose of Article 21(2), point (a) of Directive (EU) 2022/2555, the relevant entities shall establish and
444 maintain an appropriate risk management framework to identify and address the risks posed to the security of network
445 and information systems. The relevant entities shall perform and document risk assessments and, based on the results,
446 establish, implement and monitor a risk treatment plan. Risk assessment results and residual risks 10 shall be accepted
447 by management bodies or, where applicable, by persons who are accountable and have the authority to manage risks,
448 provided that the relevant entities ensure adequate reporting to the management bodies.

449 GUIDANCE

450 • The entity can use its current risk management framework or adopt a new one 11. A risk management
451 framework is the structured approach used by an entity to identify, assess, manage, and mitigate its cyber
452 security risks and it might be documented or not.
453 • Create a risk treatment plan which associates the identified risks with assets and the measures mitigating
454 the associated risks. The plan should at least include:
455 o the risk identified;
456 o the assets associated with the risk;
457 o the objective associated with the risk;
458 o the measures associated with the objective which are mitigating the risk;
459 o procedure for assessing the effectiveness of implementation of the measure(s);
460 o detailed implementation timelines;
461 o responsible roles; and
462 o implementation costs for the measures.
463 • Communicate residual risks which might affect the offered services to the customers.
464 • Consider residual risks from third parties e.g. data breaches, unaddressed vulnerabilities, regulatory non-
465 compliance from the third party side, over reliance on a single third party etc.
466 • Ensure residual risks are accepted by management or, where applicable, persons who are accountable
467 and have the authority to manage risks, in line with the acceptable residual risk levels of the entity.
468 • Make sure that management or, where applicable, persons who are accountable and have the authority
469 to manage risks, approves the risk assessment results and risk treatment plan.

470 EXAMPLES OF EVIDENCES

471 • Documented risk management framework, if available.

472 • Documented results from previous risk assessments.
473 • Documented risk treatment plan which takes into account, at least, the elements (g) to (h) referred to in
474 point 2.1.2 of the Annex to the Regulation.

10
The remaining risk after management has implemented a risk response (ISACA).
11
For example, the 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 [Link] last access 29 September
2024.

16
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

475 • Record of management or, where applicable, by persons who are accountable and have the authority to
476 manage risks, approval of risk assessment results.
477 • Record of management or, where applicable, by persons who are accountable and have the authority to
478 manage risks, approval of residual risks.
479 2.1.2. For the purpose of point 2.1.1., the relevant entities shall establish procedures for identification, analysis,
480 assessment and treatment of risks (‘cybersecurity risk management process’). The cybersecurity risk management
481 process shall be an integral part of the relevant entities’ overall risk management process, where applicable. As part of
482 the cybersecurity risk management process, the relevant entities shall:
483 (a) follow a risk management methodology;
484 (b) establish the risk tolerance level in accordance with the risk appetite of the relevant entities;
485 (c) establish and maintain relevant risk criteria;
486 (d) in line with an all-hazards approach, identify and document the risks posed to the security of network and information
487 systems, in particular in relation to third parties and risks that could lead to disruptions in the availability, integrity,
488 authenticity and confidentiality of the network and information systems, including the identification of single point of
489 failures;
490 (e) analyse the risks posed to the security of network and information systems, including threat, likelihood, impact, and
491 risk level, taking into account cyber threat intelligence and vulnerabilities;
492 (f) evaluate the identified risks based on the risk criteria;
493 (g) identify and prioritise appropriate risk treatment options and measures;
494 (h) continuously monitor the implementation of the risk treatment measures;
495 (i) identify who is responsible for implementing the risk treatment measures and when they should be implemented;
496 (j) document the chosen risk treatment measures in a risk treatment plan and the reasons justifying the acceptance of
497 residual risks in a comprehensible manner.

498 GUIDANCE

499 • Select a risk management methodology11.

500 • Define the risk tolerance level, which refers to the level of risk that an entity is willing to accept in pursuit
501 of its long term objectives. Examples may include (indicative, non-exhaustive list):
502 o acceptable downtime for systems that their criticality is high (e.g., up to 2 hours of downtime per
503 month).
504 o tolerance for data loss (e.g., loss of data with low criticality within a 24-hour window).
505 o maximum financial loss that can be absorbed without jeopardizing operations (e.g., up to 100,000
506 Euros in recovery costs).
507 o willingness to invest a certain percentage of revenue in measures (e.g., 5% of annual revenue).
508 o adherence to regulatory obligations with specific penalties or fines influencing risk acceptance.
509 o acceptable level of customer dissatisfaction or negative media exposure from a data breach (e.g.,
510 tolerating one major incident every few years).
511 o acceptance of certain vulnerabilities based on risk mitigation measures in place (e.g., outdated
512 software as long as it's monitored and patched regularly).
513 o time frame for responding to and recovering from incidents (e.g., a maximum of 48 hours for
514 containment).
515 o acceptance of minor incidents as part of normal operations while prioritizing major threats.

17
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

516 • Define risk criteria, i.e. how the entity evaluates the significance of the risks that it identifies and makes
517 decisions concerning risks. These may include risk acceptance criteria or criteria for performing cyber
518 security risk assessments12.
519 o Risk acceptance criteria may include (indicative, non-exhaustive list):
520 ▪ accepting risks categorized as low severity, such as minor data leaks that don't expose
521 sensitive information risk assessed as having a low likelihood of occurrence (e.g.,
522 certain rare types of cyberattacks).
523 ▪ accepting risks if the cost of mitigation exceeds the potential impact (e.g., not upgrading
524 legacy systems if the upgrade cost is significantly higher than potential losses).
525 ▪ accepting specific compliance risks if there is a plan in place to address them within a
526 defined timeframe (e.g., temporarily accepting minor non-compliance with a
527 commitment to remediate within six months).
528 ▪ allowing certain risks in low criticality systems or departments that do not affect core
529 business operations (e.g., accepting a risk in a test environment).
530 ▪ accepting certain vulnerabilities for a defined period while planning for remediation (e.g.,
531 accepting the risk of outdated software for three months until a full upgrade can be
532 completed).
533 ▪ accepting risks where the expected incident impact falls below a predetermined financial
534 threshold (e.g., losses under 50,000 Euros accepted without further action).
535 ▪ accepting risks after informing stakeholders and receiving their agreement, particularly
536 if they understand the trade-offs involved.
537 ▪ accepting residual risks where existing measures reduce the likelihood or impact to an
538 acceptable level (e.g., using encryption for sensitive data but accepting risks of loss due
539 to user error).
540 o Criteria for performing cyber security risk assessments refer to consequences, likelihood or level
541 of risk. These may refer to (indicative, non-exhaustive list):
542 ▪ Importance of assets
543 ▪ Severity of threats
544 ▪ Vulnerability of network and information systems
545 ▪ Impact analysis
546 ▪ Frequency of cyber incidents
547 ▪ Existing measurers
548 ▪ Stakeholders concerns or requirements
549 • Make a list of the main risks for the security of network and information systems, taking into account main
550 threats to the assets in scope.
551 • Make sure that each risk is associated with at least one:
552 o of the risk treatment option or a combination of them, in line with the results of the risk assessment
553 and be in accordance with the entity’s policy on the security of network and information systems
554 (recital 11 of the Regulation); and
555 o specific risk treatment measure.

12
More information on risk criteria can be found on ISO/IEC 27005:2022, par. 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.

18
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

556 • Develop risk treatment plans to address the elements points (i) and (j) referred to in point 2.1.2 of the
557 Annex to the Regulation.
558 • Assign responsibilities to appropriate individuals or teams for executing these risk treatment plans.

559 EXAMPLES OF EVIDENCES

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

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

575 GUIDANCE

576 • Make sure that the personnel takes into account the elements referred to in point 2.1.3 of the Annex to the
577 Regulation.

578 EXAMPLES OF EVIDENCES

579 • Guidance for personnel on assessing risks which takes into account the elements referred to in point 2.1.3
580 of the Annex to the Regulation.
581

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

585 GUIDANCE

586 • Review risk assessment results and risk treatment at least annually taking into account:
587 o results of audits and previous reviews,
588 o status of implementation of the measures described in the risk treatment plan;
589 o changes to the information systems;
590 o changes to the environment of operation;
591 o post-incident review findings (3.6); and
592 o trends related to threats and vulnerabilities.

593 EXAMPLES OF EVIDENCES

594 • Documentation of review process, taking into account the points mentioned in the middle column.
595 • Review comments or change logs for risk assessment and risk treatment plan.

19
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

596

597 TIPS

598 GUIDANCE

599 • Ensure that key personnel uses the risk management methodology and tools.
600 • Mitigate residual risks, where possible.
601 • Overall the entity has four risk treatment options associated with each risk. Each option should be
602 accompanied by specific risk treatment measure (indicative, non-exhaustive list of examples):
603 o Risk Avoidance: As a measure to treat this risk the entity might choose to eliminate activities or
604 conditions that expose the entity to this risk. For example, discontinuing the use of a vulnerable
605 software application.
606 o Risk Mitigation: As a measure to treat this risk the entity might choose to implement measures to
607 reduce the likelihood or impact of such a risk. This can include installing firewalls, using
608 encryption, and conducting regular security training for employees.
609 o Risk Transfer: As a measure to treat this risk the entity might choose to shift the risk to another
610 party, typically through insurance or outsourcing certain functions to a third-party provider. For
611 instance, purchasing cyber insurance to cover potential data breach costs.
612 o Risk Acceptance: As a measure to treat this risk the entity might choose to acknowledge the risk
613 and decide to accept it without taking any specific action, often because the cost of mitigation is
614 higher than the potential impact. This approach is usually accompanied by a contingency plan to
615 manage the risk if it materializes.
616 • Make sure that the risk from vulnerabilities assigned to the highest classification (e.g. ”critical” in CVSS)
617 or equivalent is not accepted, if possible (6.10)
618 • Concerning the risk treatment plans, the entity might additionally take account:
619 o findings of the review;
620 o implementation steps; and
621 o resources needed.
622 • Manage any exceptions in the risk treatment plans’ implementation.

623 EXAMPLES OF EVIDENCES

624 • Documented action plans developed in response to review findings.

625 • Key personnel knows the main risks .
626 • Documented risk treatment plan implementation exceptions
627
628
629

20
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

630 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 6.1, 6.1.2, 6.1.3, 6.2, 8.2, BE-CyFun®2023 BASIC: [Link]-4.1, [Link]-5.1
8.3, A5.7, Α.5.19, Α.5.20, IMPORTANT: [Link]-4.1, [Link]-4.2,
Α.5.21 [Link]-5.2, [Link]-6.1, [Link]-1.1,
[Link]-2.1, [Link]-3.1, [Link]-2.1,
[Link]-3.1, [Link]-7.1, [Link]-6.2,
[Link]-1.1
ESSENTIAL: [Link]-5.3, [Link]-1.1,
[Link]-1.5, [Link]-4.1
NIST CSF v2.0 [Link]-01, [Link]-02, [Link]- FI-Kybermittari CRITICAL-2, RISK-1, RISK-2, RISK-3,
03, [Link]-04, [Link]-05, RISK-4, RISK-5, THIRD-PARTIES-2,
[Link]-06, [Link]-03, WORKFORCE-3, WORKFORCE-4
[Link]-01, [Link]-06,
[Link]-03, [Link]-01, [Link]-
02, [Link]-03, [Link]-04
ETSI EN 319 401 REQ 5, Clause 6.3 EL – Ministerial Cybersecurity Handbook: Part A: 2
decision
1027/2019
Article 4 -
Self assessment tool: 1.15, 1.16, 1.17,
paragraphs 3, 4
1.18, 1.19

CEN/TS 18026:2024 OIS-01, RM-01, RM-02, RM- ES-Royal Decree Article 7, Article 14
03 311/2022
631

632 2.2 COMPLIANCE MONITORING

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

636 GUIDANCE

637 • Develop a standardized report format for reporting to the management bodies. Consider the following
638 elements (indicative, non-exhaustive list):
639 o key metrics;
640 o compliance status;
641 o identified risks, and
642 o recommended actions.
643 • Reports are generated and presented to management bodies at least annually.

644 EXAMPLES OF EVIDENCES

645 • Recent compliance review reports.

646

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

650 GUIDANCE

651 • Review Set up procedures for compliance monitoring, including (indicative, non-exhaustive list):

21
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

652 o objectives and high-level approach of compliance monitoring;

653 o relevant security policies that are subject to compliance monitoring;
654 o frequency of compliance reviews;
655 o who should carry out compliance reviews (in- or external); and
656 o templates for compliance review reports.
657 • Analyse and evaluate the results of the compliance review.

658 EXAMPLES OF EVIDENCES

659 • Documented procedures for monitoring compliance.

660 • Documented analysis and evaluation of the results, including the current state of the entity’s management
661 of risks.
662 • Detailed compliance monitoring plans, including long-term, high-level objectives and planning.
663

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

666 GUIDANCE

667 • Compliance monitoring should take place at least yearly, taking into account:
668 o significant incidents, if any;
669 o changes to the environment of operation
670 o changes to the threat landscape and cyber security legal and regulatory requirements; and
671 o changes to the policy on the security of network and information systems and/or topic specific
672 policies.

673 EXAMPLES OF EVIDENCES

674 • Any corrective actions resulting from the assessments and tests, including the changes to the measures
675 made by the entity once effectiveness of measures has been assessed in line with Annex to the
676 Regulation, point 7.1.1
677
678 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 9.2, A.5.31, A.5.35, A.5.36 BE-CyFun®2023 BASIC: [Link]-1.1
IMPORTANT: [Link]-1.2, [Link]-3.2,
[Link]-4.1, [Link]-3.3, [Link]-9.1,
[Link]-3.1, [Link]-5.1, [Link]-1.2,
[Link]-2.1, [Link]-1.1
ESSENTIAL: [Link]-4.2, [Link]-3.4,
[Link]-7.2, [Link]-9.2, [Link]-5.2
NIST CSF v2.0 [Link]-02, [Link]-01, [Link]- FI-Kybermittari PROGRAM-1, PROGRAM-2
02, [Link]-03, [Link]-04
ETSI EN 319 401 Clause 7.13 EL – Ministerial Cybersecurity Handbook: Part A: 2
decision
1027/2019 Self assessment tool: 1.11, 1.12, 1.19,
Article 4 - 1.20
paragraphs 1, 6

22
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

CEN/TS 18026:2024 CO-01, DOC-03, INQ-01, ES-Royal Decree Article 28, Article 31, Article 32,
INQ-02, INQ-03 311/2022 ANNEX III - Security audit13
679

680 2.3 INDEPENDENT REVIEW OF INFORMATION AND NETWORK SECURITY

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

683 GUIDANCE

684 • Make sure that the independent review is conducted by an entity with the appropriate competences
685 (indicative, non-exhaustive list):
686 o cybersecurity technical knowledge e,g. cybersecurity frameworks (ISO/IEC 27001, NIST etc);
687 o the industry knowledge;
688 o risk assessment skills;
689 o compliance and regulatory knowledge e.g. the NIS2, GDPR, DORA etc; and
690 o good understanding of good practices in auditing.

691 EXAMPLES OF EVIDENCES

692 • Evidences on the competences of the independent reviewers e.g. certifications like CISA, CISSP, CISM,
693 working experience, academic qualifications, etc.
694

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

700 GUIDANCE

701 • Set up a process for independent review of information and network security, including (indicative and
702 non-exhaustive list):
703 o scope and purpose of the independent reviews (e.g., compliance, risk assessment, policy
704 adherence);
705 o methodology of the reviews (e.g. standardised checklist, standard based, ad hoc);
706 o review committee’s role;
707 o frequency of the independent reviews;
708 o who should carry out independent reviews (in- or external, independence is important); and
709 o templates for independent review reports.
710 • Maintain independence in line with point 2.3.2 of the Annex to the Regulation;
711 • If the size of the entity makes the separation of line of authority challenging, consider alternative measures
712 (indicative and non-exhaustive list):
713 o review personnel rotation;
714 o setting up a review committee with members from different departments;
715 o external third-party review service provider.

13
As a development of the National Security Framework (ENS), two Resolutions have been published by the Secretary of State for Civil Service which
regulate the ENS Compliance and the ENS Security Audit process. They an be found at: [Link]
(ENS security Audit) and [Link] (ENS Compliance)

23
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

716 EXAMPLES OF EVIDENCES

717 • Documented process for independent review of information and network security.
718 • Conflict of interest declarations.
719 • Contracts with external third-party review service providers.
720 • Detailed independent review plans.
721

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

725 GUIDANCE

726 • Analyse and evaluate the results of the independent review.

727 • Report results to management bodies.
728 • Develop a standardized report format for reporting to the management bodies. Consider the following
729 elements (indicative, non-exhaustive list):
730 o executive summary, including the scope and the key findings;
731 o methodology;
732 o detailed findings, including gaps identified and non-compliance issues;
733 o recommendations; and
734 o conclusions.
735 • Reports are generated and presented to management bodies at least annually.
736 • Take corrective actions or justify, accept and document residual risks.

737 EXAMPLES OF EVIDENCES

738 • Documented analysis and evaluation of the results, including any residual risks.
739 • Minutes from review committee’s gathering from past reviews.
740 • Any corrective actions resulting from the assessments and tests, including the changes to the measures
741 made by the entity once effectiveness of measures has been assessed in line with the Annex to
742 Regulation, point 7.1.1
743 • Documentation of any corrective actions.
744 • Most recent results of compliance monitoring and auditing.
745

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

748 GUIDANCE

749 • Make sure that independent review is conducted in the defined frequency.
750 • Independent reviews should take place at least yearly, taking into account:
751 o significant incidents, if any;
752 o changes to the environment of operation
753 o changes to the threat landscape and cyber security legal and regulatory requirements; and
754 o changes to the policy on the security of network and information systems and/or topic specific
755 policies.

24
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

756 EXAMPLES OF EVIDENCES

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

764 TIPS

765 GUIDANCE

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

768 EXAMPLES OF EVIDENCES

769 • Documented procedures approved by management.

770 • Approval of the residual risks by top management.
771

772 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 9.2, 10.1, A.5.35, A.8.34 BE-CyFun®2023 ESSENTIAL: [Link]-4.2, [Link]-7.2,
[Link]-5.2, [Link]-2.2
NIST CSF v2.0 [Link]-02, [Link]-01 FI-Kybermittari PROGRAM-2
ETSI EN 319 401 Clause 7.13 EL Cybersecurity Handbook: -

Self assessment tool: 15.2

CEN/TS 18026:2024 CO-01, CO-02, CO-03, CO- ES-Royal Decree National Security Framework
04 311/2022 Compliance, sections V (National
Security Framework Compliance) and
VI (Requirements of the certifier
bodies)

25
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

773 3. INCIDENT HANDLING

774 3.1 INCIDENT HANDLING POLICY

775 3.1.1. For the purpose of Article 21(2), point (b) of Directive (EU) 2022/2555, the relevant entities shall establish and
776 implement an incident handling policy laying down the roles, responsibilities, and procedures for detecting, analysing,
777 containing or responding to, recovering from, documenting and reporting of incidents in a timely manner.

778 GUIDANCE

779 • Define clear objectives for the incident handling policy.

780 • Ensure the policy complies with relevant laws, regulations, and industry standards 14.

781 EXAMPLES OF EVIDENCES

782 • Documented incident handling policy which contains, at least, the elements referred to in point 3.1.2 of the
783 Annex to the Regulation.
784 • Documented standards and/or good practices which are taken into consideration for this policy.
785

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

794 GUIDANCE

795 • Align the incident handling policy with the business continuity and disaster recovery plan (4.1) by
796 (indicative, non-exhaustive list):
797 o ensuring that they aim to minimise disruptions, protect assets, and ensure a swift return to normal
798 operations;
799 o describing workflows which trigger business continuity (4.1 or 4.2 or 4.3) during an incident; and
800 o developing scenarios that test the interaction between these processes.
801 • Set up a categorisation system for incidents, which refers to the scheme that the entity uses to identify the
802 consequences and the priority of an incident, together with the criteria to categorise events as incidents 15.
803 An indicative, non-exhaustive list of criteria might include one or more of the following:
804 o impact on business operations;
805 o data sensitivity in accordance with the GDPR;
806 o legal and regulatory impact;

14
Additionally to the frameworks in the mapping table, consider “Computer Security Incident Handling Guide” from NIST, available at
[Link] last accessed 12.10.2024.
15
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 categorization of incidents, please also consult the ENISA guidelines related to Article 23(9) summary reporting for NIS2 or information provided by
the national CSIRTs.

26
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

807 o scope and scale meaning the evaluation of how widespread the event is;
808 o type of the attack;
809 o malicious software/vulnerability exploitation;
810 o criticality of the systems affected;
811 o incident containment urgency;
812 o potential of data exfiltration or corruption e.g. in case of ransomware;
813 o likelihood of recovery; and
814 o impact on human lives and safety
815 • Ensure that the incident handling policy refers to different types of incidents like (indicative, non-exhaustive
816 list):
817 o system failures and loss of service availability;
818 o malicious code;
819 o denial of service;
820 o errors;
821 o breaches of confidentiality and integrity; and
822 o misuse of network and information systems.
823 • Communicate the incident to relevant stakeholders and personnel according to a communication plan.
824 The communication plan should consider the event reporting mechanism (3.3) and may include (indicative,
825 non-exhaustive list) the following:
826 o purpose and scope of the plan;
827 o roles and responsibilities for communication tasks;
828 o list of internal and external stakeholders to be informed;
829 o conditions and procedures for escalation of incidents;
830 o channels to be used for communication (e.g., email, intranet, phone calls, social media, press
831 releases);
832 o methods for stakeholders to provide feedback or ask questions; and
833 o guidelines for when to communicate and the frequency of updates, as well as pre-drafted
834 message templates for various scenarios and the core messages to be communicated
835 • Additional to the elements referred to in point 3.1.2 of the Annex to the Regulation, describe in the incident
836 handling policy how it interacts with the business continuity and disaster recovery plan.

837 EXAMPLES OF EVIDENCES

838 • Cross references between incident handling policy, business continuity and disaster recovery plan.
839 • Records of testing and drills that involve both incident handling and business continuity/disaster recovery.
840 • Interviews with key personnel involved in incident response, business continuity, and disaster recovery.
841 • An incident categorisation system.
842 • Evidence that the incident handling policy is in place and communicated to employees.
843 • A communication plan for incident handling is in place.
844 • Procedures on how to communicate the incident to relevant authorities and the CSIRT are in place.
845 • Procedures on how to communicate the incident to customers or how and when to involve a supplier (if
846 applicable).
847

848

27
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

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

851 GUIDANCE

852 • Consider one or more of the following in order to test the entity’s incident handling policy (indicative, non-
853 exhaustive list):
854 o tabletop exercise;
855 o simulation of an incident, preferably based on a selected attack scenario based on identified risks
856 and the current threat landscape;
857 o red team/blue team exercise;
858 o log analysis exercise; and
859 o past incident walkthrough.
860 • Test roles, responsibilities and procedures laid down in the policy at least semi-annual.
861 • Review and update roles, responsibilities and procedures laid down in the policy at least yearly, taking
862 into account, additionally to the elements referred to in point 3.1.3 of the Annex to the Regulation,
863 o results from the policy tests;
864 o changes to the threat landscape and cyber security legal and regulatory requirements; and
865 o changes to the policy on the security of network and information systems and/or topic specific
866 policies.

867 EXAMPLES OF EVIDENCES

868 • Periodic simulations and awareness raising activities to assess the readiness of personnel and the
869 adequacy of the procedures.
870 • Incident handling policy testing plans or schedules.
871 • Incident handling policy review plans or schedules.
872

873 TIPS

874 GUIDANCE

875 • Identify and consider all internal and external resources required in case of an incident and ensure their
876 availability at any time.
877 o make sure that personnel are properly trained to handle and manage incidents.
878 o identify and consider all external stakeholders (e.g. operators, technology suppliers) necessary
879 for incident handling.
880 • Changes in the policy should be communicated to the relevant personnel.
881 • Ensure a clear overview of the various incident reporting obligations that the entity must fulfill under
882 different reporting regimes.

883 EXAMPLES OF EVIDENCES

884 • Detailed procedures on the incident handling policy have been communicated to personnel as appropriate.
885 • A list of reporting obligations and deadlines, which may cover both legal and contractual obligations.
886
887
888

28
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

889 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.5 .24 BE-CyFun®2023 BASIC: [Link]-1.1
IMPORTANT: [Link]-6.1, [Link]-9.1,
[Link]-1.1, [Link]-1.1, [Link]-1.1
NIST CSF v2.0 [Link]-08, [Link]-01, FI-Kybermittari RESPONSE-1, RESPONSE-2,
[Link]-05, [Link]-01, [Link]- RESPONSE-3, RESPONSE-5, CRITICAL-
02, [Link]-01, [Link]-04 3
ETSI EN 319 401 REQ-7.9-06 EL – Ministerial Cybersecurity Handbook: Part B: 17.1
decision
1027/2019 - Self-assessment tool: 18.1
Article 4 -
paragraph 18
CEN/TS 18026:2024 ISP-02, IM-01, IM-07 ES-Royal Decree Article 25, Article 33, Article 34,
311/2022 Annex II: 4.3.7, 4.3.9, 4.7.2
890

891 3.2 MONITORING AND LOGGING

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

895 GUIDANCE

896 • Identify one or more objectives of the monitoring the activities on entity’s network and information systems,
897 (indicative, non-exhaustive list):
898 o threat detection;
899 o compliance assurance;
900 o incident response support;
901 o performance optimisation;
902 o anomaly detection;
903 o data loss prevention; and
904 o network health monitoring.
905 • Procedures should describe (indicative, non-exhaustive list):
906 o objectives;
907 o data for collection;
908 o analysis of data algorithms; and
909 o notification, to the relevant personnel, mechanisms.
910 • Select tools which serve the objectives of monitoring according to specific criteria (indicative, non-
911 exhaustive list):
912 o ease of use;
913 o integration with the existing network and information system;
914 o minimisation of manual intervention;
915 o capability of collecting data from various sources e.g. networks, systems, applications;
916 o security features offered e.g. encryption, access control; and
917 o costs and licencing.

918 EXAMPLES OF EVIDENCES

919 • Procedures are in place.

29
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

920 • Tools are in place.

921 • Configuration settings of the logging function serve the identified objectives.
922 • Configuration settings of the logging function are in line with documented standards and/or good practices.
923 • Safeguards to protect the confidentiality, integrity and availability of logs are in place
924

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

928 GUIDANCE

929 • To minimise false positives and false negatives, to the extent feasible, consider one or more of the
930 following (indicative, non-exhaustive list):
931 o analytics and machine learning algorithms;
932 o continuous update of the automated monitoring tools to adapt to new threats and changes in the
933 environment; and
934 o fine-tune the parameters and thresholds based on the latest data and feedback.

935 EXAMPLES OF EVIDENCES

936 • Acceptable, in line with the state of the art, log monitoring, collection, storage and analysis tools.
937 • SIEM systems are used to analyse data and identify deviations from established baselines.
938 • Mechanisms which aim at minimising false positives and false negatives are in place.
939

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

956 GUIDANCE

957 • With regard to critical configuration, consider the settings and parameters that are vital for the proper
958 functioning, security, and performance of entity’s network and information system. These configurations
959 are vital because any changes or misconfigurations might have significant impact, including system
960 outages, security vulnerabilities, or reduced performance of entity’s network and information system.

30
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

961 EXAMPLES OF EVIDENCES

962 • Log files contain the elements referred to in point 3.2.3 of the Annex to the Regulation.
963

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

968 GUIDANCE

969 • Make sure that the implemented procedures are able to detect network-based attacks based on
970 anomalous inbound and outbound ingress or egress traffic patterns and/or denial of service (DoS) attacks
971 in a timely manner.
972 • Make sure that alarm thresholds, where appropriate, have been set in alignment with the results of the
973 risk assessment carried out pursuant to point 2.1, covering at least the situations in point 3.2.3 of the
974 Annex to the Regulation. An indicative, non-exhaustive list of examples with thresholds follows:
975 o Relevant outbound and inbound network traffic: Traffic volume spikes exceeding 50% of normal
976 traffic in a 10-minute period on a specific port;
977 o Access to systems and applications: 3 or more account lockouts within 15 minutes;
978 o Privileged access: 2 or more instances of privilege escalation (e.g., normal user to admin) within
979 24 hours;
980 o Antivirus: three or more malicious software detections on different devices within 30 minutes.
981 o Use of system resources: three or more installations of unauthorised software within 30 minutes.

982 EXAMPLES OF EVIDENCES

983 • Regular reports which summarize log data and highlight any anomalies detected.
984 • Alarm thresholds are set.
985 • Records from past alarm triggers when thresholds were exceeded.
986 • Existing workflows which trigger event reporting (3.3).
987

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

990 GUIDANCE

991 • Make sure that the log retention period is defined according to business needs, the risk assessment
992 results, good practices and legal requirements/obligations.
993 • The backup logs’ maintenance period shouldn’t be shorter than the review period of the logs, referred to
994 in point 3.2.4 of the Annex to the Regulation.
995 • The retention period should be in line with what is referred to in point 4.2.2 (f) of the Annex to the
996 Regulation.
997 • Delete data when retention period ends.
998 • Consider mechanisms to protect logs from unauthorised access or changes (indicative, non-exhaustive
999 list):
1000 o encryption;
1001 o access control;

31
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1002 o hashing; and

1003 o logging of all access and changes to log files.
1004 • The access control should be in line with what is referred to in point 4.2.2 (d) of the Annex to the
1005 Regulation.

1006 EXAMPLES OF EVIDENCES

1007 • A retention period is set.

1008 • The retention period is in line with what is referred to in point 4.2.2 (f) of the Annex to the Regulation and
1009 is shorter than the review period of the logs, referred to in point 3.2.4 of the Annex to the Regulation.
1010 • Centralised log management is in place.
1011 • Logs do not contain data of which retention periods has expired.
1012 • Access control mechanisms are in place.
1013 • Access control is in line with what is referred to in point 4.2.2 (d) of the Annex to the Regulation.
1014

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

1019 GUIDANCE

1020 • Consider the following for the time synchronisation:

1021 o utilize Network Time Protocol (NTP) servers or Precision Time Protocol (PTP) for accurate and
1022 reliable time synchronization16,
1023 o use authenticated NTP to prevent malicious entities from tampering with your time
1024 synchronization;
1025 o configure a central time server within the entity. This server should synchronize with an external
1026 reliable time source and then distribute the time to all other systems within the network; and
1027 o use multiple time sources to avoid a single point of failure.
1028 • Assets being logged should be marked as such in the asset inventory, in line with what is referred to in
1029 point 12.4 of the Annex to the Regulation.
1030 • Ensure redundant log storage (e.g. cloud, multiple servers, multiple storage locations) to prevent data loss
1031 in line with what is referred to in point 4.2 of the Annex to the Regulation.
1032 • Deploy separate tools to monitor the health and availability of entity’s primary monitoring and logging
1033 systems.

1034 EXAMPLES OF EVIDENCES

1035 • Mechanisms for logs’ time synchronisation are in place.

1036 • Mechanisms for logs’ redundant storage are in place.
1037 • Logs from the activity of the tools which monitor the health and availability of entity’s primary monitoring
1038 and logging systems
1039

1040

16
For public NTP servers see [Link]

32
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

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

1043 GUIDANCE

1044 • Determine the frequency of reviews based on the risk assessment results related to the criticality of the
1045 assets, ensuring that reviews are conducted at least annually. assets.

1046 EXAMPLES OF EVIDENCES

1047 • Review plans or schedules.

1048

1049 TIPS

1050 GUIDANCE

1051 • Document monitoring and logging procedures.

1052 • Assess the frequency of monitoring activities to ensure they are sufficient to support risk-based security
1053 decisions for adequately protecting the entity’s network and information systems.
1054 • Make sure that personal data which are included in the logs is not processed unnecessarily. When
1055 required, additional level of protection is deployed after performing a data protection impact assessment.
1056 • Determine the log baselines in line with the needs and the capabilities of the business capabilities
1057 (indicative, non-exhaustive list):
1058 o structured or semi structured, if possible, instead of unstructured format;
1059 o consistent data format in line with the selected tools and well-known standards e.g. JASON and
1060 XML;
1061 o log level in line with the classification level of the asset being logged. The entity should assign a
1062 higher level of log level e.g. ERROR, FATAL to highly classified assets while the lower log levels
1063 e.g. INFO, DEBUG should be used for assets with lower classification; and
1064 o the standard for the timestamps e.g. ISO-8601
1065 • For each log entry should contain necessary metadata such as (indicative, no exhaustive list):
1066 o log level;
1067 o timestamp;
1068 o source identifier e.g. the application or the device relevant to the entry; and
1069 o a unique identifier for the entry.

1070 EXAMPLES OF EVIDENCES

1071 • Documented procedures.

1072 • Log baselines are in place.
1073 • Each entry contains necessary metadata.
1074
1075
1076

33
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1077 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.5.28, A.8.15, A.8.16, BE-CyFun®2023 BASIC: [Link]-1.1, [Link]-3.1
A.8.17 IMPORTANT: [Link]-2.2, [Link]-4.5,
[Link]-5.1, [Link]-7.1, [Link]-1.3,
[Link]-3.2, [Link]-1.2, [Link]-6.1,
[Link]-7.1
ESSENTIAL: [Link]-3.2, [Link]-1.3,
[Link]-1.1, [Link]-3.3, [Link]-1.3,
[Link]-2.2
NIST CSF v2.0 [Link]-06, [Link]-07, [Link]- FI-Kybermittari SITUATION-1, SITUATION-2,
01, [Link]-02, [Link]-03, SITUATION-3, ASSET-4
[Link]-04
ETSI EN 319 401 REQ-7.9-01, REQ-7.9-02, EL – Ministerial Cybersecurity Handbook: Part B: 8.1,
REQ-7.9-03, REQ-7.9-04, decision 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.8, 8.9,
REQ-7.9-09, REQ-7.9-12 1027/2019 - 8.10
Article 4 - Self-assessment tool: 9.1, 9.2, 9.3,
paragraph 17 9.4, 9.5, 9.6, 9.7, 9.8, 9.9, 9.10, 9.11
CEN/TS 18026:2024 OPS-10, OPS-11, OPS-12, ES-Royal Decree Article 10, Article 21, Annex II: 4.7.1,
OPS-13, OPS-14, OPS-15, 311/2022 4.7.3
OPS-16, OPS-23, CS-01, IM-
07, PSS-01
1078

1079 3.3 EVENT REPORTING

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

1082 GUIDANCE

1083 • Define what constitutes a suspicious event based on criteria (indicative, non-exhaustive list):
1084 o the confidentiality or the integrity or the availability (CIA) of the network or the information system
1085 has been affected;
1086 o persistence meaning if the event is ongoing or not;
1087 o impact e.g. the number of assets (potentially) affected, the financial impact for the entity etc; and
1088 o compliance violation of a regulation or the entity’s policies.
1089 • Develop clear and concise guidelines for what information should be included in a report. Align this
1090 information with the information that might be submitted to the CSIRT or, where applicable to the
1091 competent authority, in case that the event is notified in accordance with the NIS2 articles 23 or 30. As a
1092 good practice the following should be reported as a minimum (indicative, non-exhaustive list):
1093 o date and time of the event.
1094 o description of the event.
1095 o any relevant screenshots, logs, or other evidence.
1096 o contact information for follow-up if necessary.
1097 • Provide multiple channels for reporting, such as email, a web form, a dedicated phone line, or a mobile
1098 app. Ensure these channels are easily accessible and intuitive to use.

1099 EXAMPLES OF EVIDENCES

1100 • Documented mechanism that outlines the process for reporting security events.

34
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1101 • Examples or templates of reporting.17

1102 • Personnel is aware of the mechanism and who to contact in case they notice something or suspicious.
1103 • Existence of multiple reporting channels such as email addresses, web forms, phone numbers, or
1104 dedicated reporting portals.
1105

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

1108 GUIDANCE

1109 • Make available to personnel, entity’s suppliers and customers, appropriate means and time thresholds for
1110 reporting.
1111 • Consider anonymous reporting to encourage individuals to report security events without fear of reprisal.
1112 • Take into account legal obligations for time thresholds to report an incident to competent authorities (and
1113 CSIRTs) in line with NIS2 articles 23 and 30.
1114 • Regularly remind stakeholders of the reporting mechanism through email newsletters, posters, and other
1115 communication channels.
1116 • Conduct regular exercises or simulations to test the effectiveness of the reporting mechanism.

1117 EXAMPLES OF EVIDENCES

1118 • Evidence of past communications and event reporting.

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

1130 TIPS

1131 GUIDANCE

1132 • Maintain a record of all reported events.

1133 • Ensure compliance with other relevant regulations and laws regarding data privacy, confidentiality, and
1134 incident reporting.
1135 • Ask for legal advice, if necessary, to understand any legal implications of the reporting mechanism.
1136 • Evaluate past communications and reporting about events.
1137 • Review and update the reporting mechanism and the communication plans (3.1.2), based on changes or
1138 past events.

1139 EXAMPLES OF EVIDENCES

17
Seek coherence with the reporting templates required by the national CSIRT or where applicable the competent authority.

35
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1140 • Record of events and per event, impact, cause, actions taken and lessons learnt.
1141 • Summaries of previous reviews, if any.
1142
1143
1144 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks
ISO 27001:2022 A.6.8 BE-CyFun®2023 BASIC: [Link]-1.1, [Link]-3.1
IMPORTANT: [Link]-1.2, [Link]-3.2,
[Link]-5.1, [Link]-2.1, [Link]-1.1,
[Link]-5.1
ESSENTIAL: [Link]-1.1, [Link]-3.3,
[Link]-1.3, [Link]-2.2
NIST CSF v2.0 [Link]-01, [Link]-02 FI-Kybermittari RESPONSE-1, WORKFORCE-2
ETSI EN 319 401 REQ-7.9-06, REQ-7.9-07, EL – Ministerial Cybersecurity Handbook: Part B:
REQ-7.9-08 decision 17.2, 17.7
1027/2019 - Self-assessment tool: 18.3
Article 4 -
paragraph 18
CEN/TS 18026:2024 IM-03, IM-04 ES-Royal Decree Article 32, Article 33, Annex II: 4.3.7
311/2022
1145

1146 3.4 EVENT ASSESSMENT AND CLASSIFICATION

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

1149 GUIDANCE

1150 • Use criteria to assess whether a suspicious event is an incident or not (section 3.1.1 of this guideline
1151 provides an indicative, non-exhaustive list of such criteria).
1152 • Determine the nature and severity of the event based on a categorisation system referred to in point 3.1.2
1153 (a) of the Annex to the Regulation.

1154 EXAMPLES OF EVIDENCES

1155 • Defined criteria are in place.

1156 • An incident categorisation system.
1157

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

1166 GUIDANCE

1167 • Document procedures for assessing suspicious events to determine their nature and severity. These
1168 procedures should include steps such as:

36
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1169 o Gathering relevant information and evidence related to the event.

1170 o Analysing the potential impact on the entity’s systems, data, and operations.
1171 Determining the severity of the incident based on predefined criteria.

1172 • Implement playbooks or runbooks to guide initial assessment and response actions for common types of
1173 incidents e.g. ransomware, phishing, data or device loss, fire.
1174 • Classify events based on their nature, severity, and potential impact. Common classifications may include:
1175 o low, medium, or high severity.
1176 o incident types (e.g., malicious software infection, unauthorized access).
1177 o regulatory or compliance implications.
1178 • Prioritise the event according to specific criteria, as defined in the categorisation system included in the
1179 incident handling policy referred to in point 3.1.2 of the Annex to the Regulation.
1180 • Determine recurring instances of an incident by performing root cause analysis 18.
1181 o Consider that the root cause of an incident may challenging to determine at early stages of
1182 incident handling, so the assessment of the existence of recurring incidents may be delayed.
1183 • Review and correlate the logs in line with what is referred to in point 3.2 of the Annex to the Regulation.
1184 • Assess past events and their classification to in order to improve processes, procedures and thresholds.

1185 EXAMPLES OF EVIDENCES

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

1195 TIPS

1196 GUIDANCE

1197 • Consider deploying a Security Information and Event Management tool (SIEM), or similar systems that
1198 will allow and facilitate the correlation and analysis of data.
1199 • Utilize automation where possible to triage incoming alerts and prioritize them based on severity and
1200 potential impact.
1201 • Take into account the confidentiality of the data stored, especially when correlating and analysing log files
1202 by (indicative, non-exhaustive list):
1203 o minimising data collected meaning that only collect and analyse logs that fit the purpose. Avoid
1204 retaining unnecessary personal or sensitive data;
1205 o anonymising or pseudonymising , when possible, the collected data;

18
More information on root cause analysis can be found at:
FIRST Computer Security Incident Response Team (CSIRT) Services Framework, Version 2.1, 6.2.4 Function: Information security incident root cause
analysis, available at [Link]
Management

37
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1206 o apply good security practices when applicable and relevant such as access control, encryption,
1207 regular audits and monitoring;
1208 o apply the data retention policy in alignment with the GDPR requirements and regularly purge
1209 data that is no longer needed; and
1210 o considering the data protection and other than NIS2 relevant legal and compliance obligations.

1211 EXAMPLES OF EVIDENCES

1212 • A SIEM or a similar system.

1213 • Tools supporting incident triage.
1214 • Measures to protect the security of information during log analysis and correlation.
1215 • Communications with the national Data Protection Authority (DPA) concerning the data protection of the
1216 logs.
1217
1218
1219 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 A.5.25 BE-CyFun®2023 BASIC: [Link]-1.1
IMPORTANT: [Link]-9.1, [Link]-1.2,
[Link]-3.2, [Link]-5.1, [Link]-3.1,
[Link]-2.1
ESSENTIAL: [Link]-1.4, [Link]-2.2,
[Link]-3.3, [Link]-4.1, [Link]-1.3,
[Link]-4.1, [Link]-2.2, [Link]-3.2
NISTCSF v2.0 [Link]-04, [Link]-02, FI-Kybermittari RESPONSE-1, RESPONSE-2
[Link]-03, [Link]-04,
[Link]-01, [Link]-02, [Link]-
03, [Link]-04
ETSI EN 319 401 REQ-7.9-07, REQ-7.9-12 EL – Ministerial Cybersecurity Handbook: Part B: 17.2
decision
1027/2019 - Self-assessment tool: 18.2, 18.3
Article 4 -
paragraph 18
CEN/TS 18026:2024 IM-02 ES-Royal Decree Article 32, Article 33, Annex II: 4.3.7
311/2022
1220

1221 3.5 INCIDENT RESPONSE

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

1224 GUIDANCE

1225 • Establish a dedicated incident response team comprising employees with the necessary technical
1226 expertise and authority to respond effectively to incidents.
1227 • Define roles and responsibilities within the incident response team, including incident coordinators,
1228 analysts, and communication liaisons.
1229 • Take into account well known standards when developing the incident response procedures 19.

19
Additionally to those mentioned in the mapping table at the end of this section, consider also the following:
a) ISO/IEC 27035-1:2023, Information technology — Information security incident management, Part 1: Principles and process.
1
Please use footnotes for providing additional or explanatory information and/or relevant links. References should be listed
in a dedicated section. Use only the function References/Insert Footnote

38
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1230 EXAMPLES OF EVIDENCES

1231 • Assignments of roles within the incident response team.

1232 • Documented standards and/or good practices which are taken into account.
1233

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

1238 GUIDANCE

1239 • Create detailed incident response procedures outlining the steps referred to in point 3.5.2 of the Annex to
1240 the Regulation.
1241 • Ensure that the handling of cybersecurity incidents takes into account the entity’s priorities and the impact
1242 of the incident.
1243 o Conflicting objectives between:
1244 ▪ 1) forensic activities to secure evidence,
1245 ▪ 2) incident response activities to remove existing threats, and
1246 ▪ 3) objectives of operational IT operations to minimise the impact of the incident,
1247 are considered and presented to the management bodies for a decision on how to proceed.

1248 EXAMPLES OF EVIDENCES

1249 • Procedures for incident response, including, types of incidents that could occur, objectives, roles and
1250 responsibilities, detailed description, per incident type, how to manage the incident, when to escalate to
1251 management bodies (CISO e.g.), etc.
1252 • Records from conflicting objectives resolution during past incidents response.
1253

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

1258 GUIDANCE

1259 • Ensure that the communication plan (3.1.2) includes procedures on how to communicate the incident to
1260 relevant authorities and the national CSIRT as well as with the internal and external stakeholders.
1261 • Include contact information for key personnel, external stakeholders, and relevant authorities.

1262 EXAMPLES OF EVIDENCES

1263 • Procedures on how to communicate the incident to relevant authorities and the CSIRT are in place.
1264 • Procedures on how to communicate the incident to customers or how and when to involve a supplier (if
1265 applicable).
1266

b) ISO/IEC 27035-2:2023, Information technology — Information security incident management, Part 2: Guidelines to plan and prepare for
incident response.
c) NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide, available at [Link]

39
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

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

1269 GUIDANCE

1270 • Log incident response information which at minimum contains (indicative, non-exhaustive list):
1271 o time of detection, containment and eradication;
1272 o when the systems recovered;
1273 o indicators of compromise (IoCs);
1274 o root cause;
1275 o actions taken during each phase namely, detection, containment and eradication;
1276 o impact assessment;
1277 o communications when responding to the incident;
1278 o post incident lessons learnt and recommendations; and
1279 o whether the incident was notified to the CSIRT or the competent authority according to NIS2
1280 articles 23 and 30;

1281 EXAMPLES OF EVIDENCES

1282 • Logs from incident response

1283

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

1285 GUIDANCE

1286 • Test entity’s incident response procedures at least annually.

1287 • Test different types of incidents e.g. ransomware, phishing, data breach, DoS, etc.
1288 • Ensure that test scenarios involve employees from different departments as well as external stakeholders
1289 e.g. suppliers and service providers.
1290 • Include management bodies in the tests so that they understand their role during an incident.
1291 • Conduct post-test reviews for possible lessons learnt.
1292 • Update the incident response procedures based on the lessons learnt from the test, if applicable.

1293 EXAMPLES OF EVIDENCES

1294 • Documented plans or schedules for future incident response tests.

1295 • Records from tests of different types of incidents.
1296

1297 TIPS

1298 GUIDANCE

1299 • Instructions on how to respond to the most common types of incidents (e.g. ransomware, phishing, data
1300 breach, DoS, etc.) including containment, eradication, and recovery steps.
1301 • Include guidelines for preserving evidence and maintaining chain of custody to support forensic analysis
1302 and legal proceedings if necessary.
1303 • Consider the use of automated solutions for incident response, e.g. SOAR technologies or similar systems.

1304 EXAMPLES OF EVIDENCES

1305 • Up to date incident response procedures based on test conducted and/or change logs.

40
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1306

1307 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.5.26 BE-CyFun®2023 BASIC: [Link]-1.1
IMPORTANT: [Link]-9.1
ESSENTIAL: [Link]-9.2, [Link]-2.2
NIST CSF v2.0 [Link]-01, [Link]-02, FI-Kybermittari RESPONSE-2, RESPONSE-3
[Link]-03, [Link]-04,
[Link]-02, [Link]-03, [Link]-
04, [Link]-02, [Link]-03,
[Link]-03, [Link]-01, [Link]-
02, [Link]-03, [Link]-04.
ETSI EN 319 401 REQ-7.9-05, REQ-7.9-09, EL – Ministerial Cybersecurity Handbook: Part B:
REQ-7.9-12 decision 17.2, 17.3, 17.4, 17.5, 17.6, 17.9,
1027/2019 - 17.10
Article 4 - Self-assessment tool: 18.2, 18.3,
paragraph 18 18.4, 18.5, 18.6, 18.7, 18.8
CEN/TS 18026:2024 OIS-03, IM-01, IM-05, IM- ES-Royal Decree Article 32, Article 33, Annex II: 4.3.7
07, INQ-02, INQ-03 311/2022
1308

1309

1310 3.6 POST-INCIDENT REVIEWS

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

1314 GUIDANCE

1315 • Define a process for conducting post-incident reviews after security incidents.
1316 • Identify root causes, contributing factors, and areas for improvement in incident detection, response, and
1317 recovery processes.
1318 • Investigate significant incidents and write final incident reports, including actions taken and
1319 recommendations to mitigate future occurrence of this type of incident.
1320 • Document lessons learnt based on logs from incident response referred to in point 3.5.4 of the Annex to
1321 the Regulation.

1322 EXAMPLES OF EVIDENCES

1323 • Conduct root cause analysis18 and identify the root cause of the incident.
1324 • Individual reports of the handling of significant incidents.
1325 • Documented lessons learnt from incidents.
1326

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

1329 GUIDANCE

1330 • Analyse the post-incident review findings to identify gaps and weaknesses in the entity’s network and
1331 information security status.

41
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1332 • Make sure that the identified gaps and weaknesses feed back to the risk assessment and the risk
1333 treatment plan (2.1).
1334 • Assess whether existing risk treatment measures were effective in preventing or mitigating the incident.
1335 • Document the findings and lessons learnt from each post-incident review comprehensively.
1336 • Consider whether information security requirements have been met throughout the handling of a cyber
1337 security incident or whether measures may need to be taken to restore them (e.g. resetting passwords for
1338 administrative emergency access).

1339 EXAMPLES OF EVIDENCES

1340 • Post-incident review reports that detail findings, lessons learnt, and recommendations for improvement
1341 following security incidents.
1342 • Analysis, resolving and mitigation measures taken are communicated to all relevant personnel.
1343

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

1345 GUIDANCE

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

1348 EXAMPLES OF EVIDENCES

1349 • Documented plans or schedules for future reviews.

1350

1351 TIPS

1352 GUIDANCE

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

1358 EXAMPLES OF EVIDENCES

1359 • Minutes from the composition of the post-incident review team.

1360 • Evidence of updates to network and information security or topic specific policies, and procedures based
1361 on the lessons learnt from post-incident reviews.
1362
1363

42
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1364 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.5.27 BE-CyFun®2023 BASIC: [Link]-1.1
IMPORTANT: PR.P-7.1, [Link]-1.2,
[Link]-2.1, [Link]-1.1, [Link]-3.2,
[Link]-1.1
NIST CSF v2.0 [Link]-01, [Link]-04, [Link]- FI-Kybermittari RESPONSE-3, RESPONSE-5
08
ETSI EN 319 401 - EL – Ministerial Cybersecurity Handbook: Part B: 17.8
decision
1027/2019 - Self-assessment tool: 18.2, 18.3
Article 4 -
paragraph 8
CEN/TS 18026:2024 IM-06 ES-Royal Decree Article 32, Article 33, Annex II: 4.3.7
311/2022

43
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1365 4. BUSINESS CONTINUITY AND

1366 CRISIS MANAGEMENT

1367 4.1 BUSINESS CONTINUITY AND DISASTER RECOVERY PLAN

1368 4.1.1. For the purpose of Article 21(2), point (c) of Directive (EU) 2022/2555, the relevant entities shall lay down and
1369 maintain a business continuity and disaster recovery plan to apply in the case of incidents.

1370 GUIDANCE

1371 • Take into account well known standards when developing the business continuity and the disaster
1372 recovery plan.
1373 • Create a list of natural and/or major disasters that could affect the services together with a list of disaster
1374 recovery capabilities e.g. backups, tests, recovery objectives etc.

1375 EXAMPLES OF EVIDENCES

1376 • Business continuity plan.

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

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

1393 GUIDANCE

1394 • Keep logs of activation and execution of business continuity plan, including:
1395 o decisions taken;
1396 o steps followed; and
1397 o final recovery time.
1398 • Determine the order of recovery based on criteria (indicative, non-exhaustive list):
1399 o the asset classification level;
1400 o the importance of the service for the entity;
1401 o dependencies (services or assets that which are essential for others are restored first);

44
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1402 o recovery objectives (point 4.1.3 of the Annex to the Regulation);

1403 o resource availability; and
1404 o regulatory requirements.
1405 • Conduct capacity planning so that necessary capacity for information processing, telecommunications,
1406 and environmental support exists after business continuity plan activation.
1407 • Require primary and alternate telecommunications service providers, according to what is referred to in
1408 point 13.1 of the annex of the Annex to the Regulation, in order to maintain properly disaster recovery
1409 plans (for the services provided).
1410 • Prepare for recovery and restoration of services after a disaster identifying measures like:
1411 o failover sites in other regions; and
1412 o backups of data with high criticality to remote locations.
1413 • Make sure that third party services will be available in case of disaster (e.g. hot site).
1414 • Implement advanced measures for disaster recovery capabilities like:
1415 o full redundancy;
1416 o failover mechanisms; and
1417 o alternative site.

1418 EXAMPLES OF EVIDENCES

1419 • Measures are in place for dealing with disasters, such as failover sites in other regions, backups of data
1420 to remote locations, et cetera.
1421 • Up-to-date organisational structures widely communicated.
1422 • Map of sectors and services essential for and/or dependent on the continuity of the network and service
1423 operation and contingency plans for mitigating the impact related to dependent and interdependent sectors
1424 and services.
1425

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

1429 GUIDANCE

1430 • Based on the results of the business impact analysis (BIA) 20 and risk assessment, the entity should
1431 establish appropriate recovery objectives, referred to in point 4.1.2 (f) of the Annex to the Regulation
1432 (indicative, non-exhaustive list):
1433 o Recovery time objectives (RTOs) to determine the maximum amount of time allowed for the
1434 recovery of business resources and functions (such as ICT systems and processes, respectively)
1435 after a disaster occurs.
1436 o Recovery point objectives (RPOs) to determine how much data can be lost by specific ICT
1437 activities or applications as a result of an outage.
1438 o Service delivery objectives (SDOs) to determine the minimum level of performance that needs to
1439 be reached by business functions during the alternate processing mode.
1440 • RTOs, RPOs and SDOs may be used to determine backup and redundancy procedures.
1441 • Document disaster recovery plan, taking into account:

20
Consider the following standards: ISO/TS 22317:2021 and NIST Special Publication 800-34

45
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1442 o the RTOs, RPOs and SDOs; and

1443 o compliance with applicable regulations and legislation.

1444 EXAMPLES OF EVIDENCES

1445 • Documented BIA with specific recovery objectives.

1446 • Processes, procedures and measures to ensure the required level of continuity in disruptive situations.
1447

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

1451 GUIDANCE

1452 • Test, review and, if necessary, update the business continuity and disaster recovery plans at least
1453 annually.
1454 • Test business continuity and disaster recovery plans regularly, taking into account:
1455 o change logs;
1456 o past incidents; and
1457 o results of previous tests.
1458 • Test disaster recovery plan at the alternate processing site to:
1459 o familiarize related personnel with the facility and available resources; and
1460 o evaluate the capabilities of the alternate processing site to support operations.
1461 • Test data centre infrastructure for:
1462 o availability;
1463 o auto failover; and
1464 o resiliency to maintain service to customers.
1465 • Define a full recovery and reconstitution of the information system to a known state as part of the disaster
1466 recovery plan testing.
1467 • Update business continuity and disaster recovery plans and related measures based on:
1468 o change logs;
1469 o past incidents;
1470 o documented results of the continuity of operations test activities; and
1471 o records of individual training activities.
1472 • Review change logs and documented results from past tests on business continuity and disaster recovery
1473 plans, on order to ensure that the plans incorporate lessons learnt from such tests.
1474 • Review and, if necessary, update roles and responsibilities.
1475 • Review of dependent third parties’ disaster recovery plans in order to ensure that the plans meet entity’s
1476 business continuity requirements.
1477 • Communicate business continuity and disaster recovery plans’ changes to related key personnel.

1478 EXAMPLES OF EVIDENCES

1479 • Documented plans or schedules for future tests.

1480 • Records from previous tests, reviews and possible updates.
1481 • Logs of activation and execution of business continuity and disaster recovery plans, including decisions
1482 taken, steps followed, final recovery time.

46
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1483 • Communications e.g. emails, documents, intranet announcements etc concerning the changes of the
1484 business continuity and disaster recovery plans.
1485 • Evidences e.g worklow changes, updated plans etc that lessons learnt from past tests are incorporated
1486 into the plans.
1487

1488

1489 TIPS

1490 GUIDANCE

1491 • In addition to the elements referred to in point 4.1.2 of the Annex to the Regulation, the business continuity
1492 plan might address:
1493 o management commitment;
1494 o coordination among organisational units;
1495 o compliance with laws;
1496 o metrics for measuring the successful implementation of the plan.
1497 • Protect the business continuity and disaster recovery plans from unauthorized disclosure and modification.
1498 • Ensure that business continuity and disaster recovery plans are easily accessible during a system outage.
1499 An indicative, non-exhaustive list of options to achieve this:
1500 o Physical copies.
1501 o Cloud storage.
1502 o External drives.
1503 o Mobile access.
1504 • Distribute copies of the business continuity plan to the related key personnel.
1505 • Monitor the activation and execution of business continuity plan registering successful and failed recovery
1506 times.
1507 • Coordinate business continuity planning activities with incident handling activities.
1508 • Coordinate business continuity plan with the respective plans of external service providers to ensure that
1509 continuity requirements are satisfied
1510 • Train key personnel involved in continuity operations.
1511 • Periodically conduct awareness training regarding the continuity of operations for the personnel.
1512 • Set up procedures in regards to the appropriate communication channels with the (inter)national
1513 competent authorities containing disaster management organisations and disaster-relief teams.
1514 • Train regularly the responsible personnel in disaster recovery operations.
1515 • Implement contingency plans for systems based on scenarios.
1516 • Monitor activation and execution of contingency plans, registering successful and failed RTOs, RPOs and
1517 SDOs.
1518 • Implement contingency plans for highly criticality dependent and inter-dependent sectors and services.

1519 EXAMPLES OF EVIDENCES

1520 • Measures e.g. encryption, access control etc for protecting business continuity and disaster recovery plans
1521 from unauthorized disclosure and modification.
1522 • Up-to-date organisational structures widely communicated.
1523 • Decision process for activating contingency plans.

47
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1524 • Contingency plans for systems, including clear steps and procedures for common threats, triggers for
1525 activation, steps and defined RTOs, RPOs and SDOs.
1526 • Logs of activation and execution of contingency plans, including decisions taken, steps followed, final
1527 recovery time.
1528

1529 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A5.29, A. 5.3021 BE-CyFun®2023 BASIC: [Link]-5.1, [Link]-4.1
IMPORTANT: [Link]-5.1, [Link]-9.1
ESSENTIAL: [Link]-5.2, [Link]-4.4,
[Link]-4.5, [Link]-9.2, [Link]-1.2
NIST [Link]-02, [Link]-03, [Link]- FI-Kybermittari RESPONSE-4, RESPONSE-5, CRITICAL-
04, [Link]-04, [Link]-08, 3
[Link]-01, [Link]-02
ETSI EN 319 401 Clause 7.11 EL – Ministerial Cybersecurity Handbook: Part B:
decision 18.1, 18.2
1027/2019 -
Self-assessment tool: 19.1, 19.2, 19.3
Article 4 -
paragraph 19, 20
CEN/TS 18026:2024 BC-01, BC-02, BC-03, BC-04 ES-Royal Decree Article 26, Article 27, Annex II: 4.6.1,
311/2022 4.6.2, 4.6.3
1530

1531 4.2 BACKUP MANAGEMENT

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

1534 GUIDANCE

1535 • Consider whether to invest in own redundancy or to engage third parties, e.g. cloud providers, to provide
1536 such redundancy.

1537 EXAMPLES OF EVIDENCES

1538 • Backups are physically separated.

1539 • In case that the service is offered by a third party, service level agreements (SLAs).
1540

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

21
Further information on business continuity management can be found in ISO 22313: 2020 and ISO 22301:2019. Information on business impact
analysis (BIA) can be found in ISO/TS 22317:2021 and in NIST IR 8286D: Using Business Impact Analysis to Inform Risk Prioritization and Response

48
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1551 GUIDANCE

1552 • Recovery times should not exceed the recovery objectives referred to in 4.1.2 (f) of the Annex to the
1553 Regulation.
1554 • Concerning retention periods consider what is referred to in point 3.2.5 of the Annex to the Regulation.

1555 EXAMPLES OF EVIDENCES

1556 • Backup plans.

1557 • Logs from backup software that show regular backups are being performed.
1558 • Backups are physically separated and are offered an appropriate level of protection, including encryption.
1559 • Logs or reports confirming that one copy of the backup is stored offsite, such as in a cloud storage service
1560 or a remote data center.
1561 • Configuration settings of backup software to verify that it is set up to create copies of data and store them
1562 on different media.
1563 • Clear and concise restoration procedures that cover all relevant systems and services.
1564 • If applicable, settings of cloud storage service to ensure they are configured to receive and store backup
1565 copies
1566

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

1568 GUIDANCE

1569 • Check the integrity of the backup copies. An indicative, non-exhaustive list of good practices is the
1570 following:
1571 o use checksums or hashing algorithms to verify that the data in your backups matches the original
1572 data;
1573 o implement automated scripts to run these checks regularly, reducing the risk of human error;
1574 o schedule regular tests to restore data from backups to ensure they are complete and functional;
1575 o test various recovery scenarios, including full system restores and individual file recoveries, to
1576 ensure all aspects of your backup system are reliable; and
1577 o consider using cloud storage solutions for off-site backups, which often include built-in integrity
1578 checks and redundancy.

1579 EXAMPLES OF EVIDENCES

1580 • Logs or reports showing that checksum or hashing algorithms are used.
1581 • Settings in backup software or scripts that specify the use of checksums or hashing algorithms.
1582 • Records of regular tests where data is restored from backups.
1583 • Evidence of tests for different recovery scenarios, including full system restores and individual file
1584 recoveries.
1585 • Logs or reports from actual incidents where recovery procedures were implemented (3.2 and 3.5).
1586 • In case that the service is offered by a third party, service level agreements (SLAs).
1587

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

49
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1593 (d) appropriate communication channels.

1594 GUIDANCE

1595 • Network and information systems, one or more of the following (indicative, non-exhaustive list):
1596 o multiple internet service providers;
1597 o load balancing;
1598 o mirrored servers;
1599 o virtualisation; and
1600 o Redundant Array of Independent Disks (RAID).
1601 • Assets, one or more of the following (indicative, non-exhaustive list):
1602 o shared workspaces;
1603 o backup locations;
1604 o spare equipment; and
1605 o multiple suppliers for the same categories of products;
1606 • Personnel, one or more of the following (indicative, non-exhaustive list):
1607 o job rotation;
1608 o backup assignments; and
1609 o emergency drills;
1610 • Multiple communication platforms e.g social media, messaging apps, email etc;

1611 EXAMPLES OF EVIDENCES

1612 • Oner or more of the above mechanisms are in place.

1613

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

1616 GUIDANCE

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

1624 EXAMPLES OF EVIDENCES

1625 • Evidence that elements referred to in point 4.2.4 of the Annex to the Regulation.
1626 • Evidence from periodic simulations and awareness raising activities to assess the readiness of personnel
1627 and the adequacy of the procedures.
1628

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

50
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1633 GUIDANCE

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

1642 EXAMPLES OF EVIDENCES

1643 • Regular testing of backup status, processes and procedures.

1644 • Test program for backup plans, including types of contingencies, frequency, roles and responsibilities,
1645 templates and procedures for conducting tests, templates for post-test reports.
1646 • Reports of past tests of backup and contingency plans.
1647 • Reports about tests and drills showing the execution of the plans, including lessons learnt from the tests.
1648 • Issues and lessons learnt from past tests have been addressed by the responsible people.
1649 • Updated test plans, review comments, and/or change logs.
1650 • Input from suppliers and other third parties involved about how to improve test scenarios.
1651

1652 TIPS

1653 GUIDANCE

1654 • Protect backup and restoration hardware and software.

1655 • Before systems or configurations are restored, a “patient zero22” may need to be identified so that the
1656 restoration does not restore any vulnerabilities or infections that have sometimes been cleaned up.
1657 • Consider the 3-2-1 backup rule:
1658 o keep three copies of the data (the original plus two backups),
1659 o on two different types of storage media (e.g., hard drives, cloud storage),
1660 o with one copy stored offsite.

1661 EXAMPLES OF EVIDENCES

1662 • Measures are in place to protect backup and restoration hardware and software e.g. physical access
1663 controls, surveillance systems, encryption, integrity checks, failover mechanisms etc.
1664 • Review of the backup plan which mentions the 3-2-1 rule.
1665 • Logs from backup software that show regular backups are being performed.
1666 • Configuration settings of backup software to verify that it is set up to create three copies of data and store
1667 them on different media.
1668 • If applicable, settings of cloud storage service to ensure they are configured to receive and store backup
1669 copies.
1670
1671
1672

22
This term is usually used to identify the first system affected by an attack.

51
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1673 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.8.13, A.8.14 BE-CyFun®2023 BASIC: [Link]-4.1, [Link]-1.1
IMPORTANT: [Link]-4.2, [Link]-3.3,
[Link]-5.1, [Link]-6.1, [Link]-4.3
ESSENTIAL: [Link]-5.2, [Link]-8.1,
[Link]-4.4, [Link]-4.5
NIST CSF v2.0 [Link]-11, [Link]-01, [Link]- FI-Kybermittari RESPONSE-4, ASSET-1, ASSET-2,
02, [Link]-03 CRITICAL-2, ARCHITECTURE-1,
ARCHITECTURE-5
ETSI EN 319 401 - EL – Ministerial Cybersecurity Handbook: Part B:
decision 16.1, 16.2, 16.3, 16.4, 16.5, 16.6, 16.7
1027/2019 - Self-assessment tool: 17.1, 17.2,
Article 4 - 17.3, 17.4, 17.5, 17.6, 17.7, 17.8
paragraph 12
CEN/TS 18026:2024 OPS-06, OPS-07, OPS-08, ES-Royal Decree Annex II: 5.7.6
OPS-09 311/2022
1674

1675 4.3 CRISIS MANAGEMENT

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

1677 GUIDANCE

1678 • Take into account well known standards when developing the crisis management process23.
1679 • Due to the fact that the escalation of an incident to crisis status depends on an entity’s risk appetite and
1680 incident handling capabilities, the entity should define criteria on when a crisis is declared24. This may
1681 refer to incidents that cause serious impact, beyond a certain threshold of tolerance. These criteria may
1682 include (indicate and non-exhaustive list):
1683 o the incident poses significant risk to critical assets or operations with high criticality, e.g. high-
1684 severity incidents (e.g., data breaches involving sensitive information)
1685 o the incident disrupts business operations significantly, e.g. prolonged downtime, widespread loss
1686 of services, or significant impact on customer service.
1687 o the breadth of the incident—whether it affects multiple systems, departments, or geographic
1688 locations, indicating a wider threat.
1689 o the potential impact on the entity’s reputation. Incidents that could lead to public scrutiny or loss
1690 of customer trust should be escalated.
1691 o the sophistication and motivations of the threat actors involved. Incidents linked to advanced
1692 persistent threats (APTs) or organised cybercrime may require higher-level response, beyond
1693 the capabilities of the entity.
1694 o the potential to escalate further (e.g., if vulnerabilities could be exploited again or if malware is
1695 spreading).

1696 EXAMPLES OF EVIDENCES

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

23
Additionally to the frameworks in the mapping table, consider:
a) ISO 22361:2022, Security and resilience — Crisis management — Guidelines.
b) ENISA Best Practices for Cyber Crisis Management, available at: [Link]
management/@@download/fullReport
c) NIST Special Publication 800-61 Revision 2.
24
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’.

52
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1698

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

1708 GUIDANCE

1709 • The communication element might describe (indicative, non-exhaustive list):

1710 o how information will be disseminated to stakeholders during a crisis;
1711 o templates for communication; and
1712 o up-to-date contact information for internal and external stakeholders, including employees,
1713 customers, suppliers and emergency services.

1714 EXAMPLES OF EVIDENCES

1715 • Documented crisis management process.

1716 • List of members of the crisis management team, including their roles, contact information, and alternates.
1717

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

1721 GUIDANCE

1722 • Implement a process for managing and making use of information received from the CSIRTs. Consider
1723 the following steps (indicative, non-exhaustive list):
1724 o Designate a point of contact with the CSIRT.
1725 o Ensure that the point of contact has sufficient knowledge concerning incidents and threat
1726 intelligence.
1727 o Classify incoming information into categories such as incidents, vulnerabilities, threats, and
1728 mitigation measures.
1729 o Assign priority levels based on severity and potential impact on the entity.
1730 o Have the CSIRT contact point review the information for relevance and urgency.
1731 o Validate information against internal logs, threat intelligence feeds, and existing security policies.
1732 o For vulnerabilities and threats, if relevant, collaborate with relevant teams (IT, Security,
1733 Operations) to develop a mitigation strategy.
1734 o Update or create incident response plans based on the nature of the threats or incidents reported
1735 in accordance with point 3.5 of the Annex to the Regulation.
1736 o Implement the mitigation measures and communicate with the relevant stakeholders in
1737 accordance with point 3.5 of the Annex to the Regulation.

53
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1738 o Share insights and feedback on incidents and mitigations with the CSIRT to contribute to the
1739 broader cybersecurity community.

1740 EXAMPLES OF EVIDENCES

1741 • Evidences from previous communications e.g. emails, correspondence, meeting minutes etc with CSIRTs
1742 or, where applicable, the competent authorities.
1743

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

1746 GUIDANCE

1747 • Test the crisis management process depending on the scope of the test:
1748 o Full scale-biannually;
1749 o Stress tests and crisis management process components-annually.
1750 • Test the crisis management process (indicative, non-exhaustive list) by.
1751 o taking into account past crisis situations;
1752 o comparing the results of the tests to the objectives defined, for instance the recovery objectives
1753 under point 4.1.2 (f) of the Annex to the Regulation (e.g. RTOs, RPOs and SDOs); and
1754 o using the results of the comparison in order to update and improve the crisis management
1755 procedure.
1756 • Review and update, if necessary, the crisis management process after a test or following significant
1757 incidents or significant changes to operations or risks.
1758 • Review and update the policy on the security of network and information systems and crisis management
1759 organisational measures after a test or following significant incidents or significant changes to operations
1760 or risks.

1761 EXAMPLES OF EVIDENCES

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

1773 TIPS

1774 GUIDANCE

1775 • The management should have approved the crisis management process.
1776 • In addition to the elements referred to in point 4.3.2 of the Annex to the Regulation the crisis management
1777 process might identify (indicative, non-exhaustive list):

54
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1778 o procedures for declaring a crisis;

1779 o activation of the crisis management team;
1780 o escalation paths;
1781 o emergency procedures, which describe the actions in case of a crisis; and
1782 o fall back procedures which describe the actions to be taken to protect essential activities or
1783 support services (e.g. alternative temporary locations for bringing process back to normal
1784 operation, recovery or restore).
1785 • Train personnel regularly in the crisis management. Incorporate simulated events 25 into crisis
1786 management training to facilitate effective response by personnel in crisis situations.

1787 EXAMPLES OF EVIDENCES

1788 • Inventory of resources required for crisis management, including backup systems, alternative
1789 communication tools, and emergency supplies.
1790 • Approved crisis management process.
1791 • Documented and approved by the management bodies crisis communication plan is in place and
1792 communicated to all personnel. The plan, additionally to the elements referred to in point 4.3.2 of the
1793 Annex to the Regulation and the elements of the above guidance, includes at least (indicative, non-
1794 exhaustive list):
1795 o communication plans outlining how information will be disseminated to stakeholders during a
1796 crisis;
1797 o templates for communication; and
1798 o up-to-date contact information for internal and external stakeholders, including employees,
1799 customers, suppliers and emergency services.
1800 • Evidence that personnel is aware of the processes and who to contact in case of crisis.
1801 • Records from periodic simulations and awareness raising activities to assess the readiness of personnel
1802 and the adequacy of the procedures to manage a crisis.
1803 • Records showing that crisis management team members and relevant staff have received training on the
1804 crisis management process.
1805
1806
1807

25
In its lightest form, the exercise can mean simulating the continuity and recovery procedures through discussion (so-called tabletop exercise).

55
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1808 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.5.26, A.5.29, A.5.30 BE-CyFun®2023 BASIC: [Link]-3.1
IMPORTANT: [Link]-8.1, [Link]-4.1,
[Link]-3.2
ESSENTIAL: [Link]-4.4, [Link]-9.2,
[Link]-2.1, [Link]-2.2
NIST CSF v2.0 [Link]-02, [Link]-03. [Link]- FI-Kybermittari RESPONSE-3, THREAT-2, CRITICAL-1,
03, [Link]-01, [Link]-03, CRITICAL-3
[Link]-02, [Link]-03, [Link]-
04, [Link]-06, [Link]-07,
[Link]-08
ETSI EN 319 401 Clause 7.11, ref. to clause EL – Ministerial Cybersecurity Handbook: Part B:
17 of ISO/IEC 27002:2013 decision 17.2, 17.10, 18.1, 18.2, 18.8
1027/2019 - Self-assessment tool: 18.2, 18.3,
Article 4 - 19.2, 19.3, 19.8
paragraph 18, 19,
20
CEN/TS 18026:2024 BC-03, OIS-03 ES-Royal Decree Article 26, Article 27, Annex II: 4.6.1,
311/2022 4.6.2, 4.6.3, 5.7.6

1809

56
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1810 5. SUPPLY CHAIN SECURITY

1811 5.1 SUPPLY CHAIN SECURITY POLICY

1812 5.1.1. For the purpose of Article 21(2), point (d) of Directive (EU) 2022/2555, the relevant entities shall establish,
1813 implement and apply a supply chain security policy which governs the relations with their direct suppliers and service
1814 providers in order to mitigate the identified risks to the security of network and information systems. In the supply chain
1815 security policy, the relevant entities shall identify their role in the supply chain and communicate it to their direct suppliers
1816 and service providers.

1817 GUIDANCE

1818 • Take into account well known standards or good practices when developing the supply chain policy 26.
1819 • The role of the entity might be one or more from the following27:
1820 o ICT supplier;
1821 o manufacturer;
1822 o software supplier;
1823 o hardware supplier;
1824 o Managed Service Provider (MSP);
1825 o Managed Security Service Provider (MSSP); and
1826 o user.

1827 EXAMPLES OF EVIDENCES

1828 • Supply chain policy.

1829 • Supply chain policy is in line with documented standards and/or good practices.
1830 • Evidence e.g. email, contract, announcements etc from the communication of the role of the entity to the
1831 direct suppliers and service providers.
1832

1833 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
1834 select and contract suppliers and service providers. Those criteria shall include the following:
1835 (a) the cybersecurity practices of the suppliers and service providers, including their secure development procedures;
1836 (b) he ability of the suppliers and service providers to meet cybersecurity specifications set by the relevant entities;
1837 (c) the overall quality and resilience of ICT products and ICT services and the cybersecurity risk-management measures
1838 embedded in them, including the risks and classification level of the ICT products and ICT services;
1839 (d) the ability of the relevant entities to diversify sources of supply and limit vendor lock-in, where applicable.

1840 EXAMPLES OF EVIDENCES

1841 • The policy contains the elements referred to in point 5.1.2 of the Annex to the Regulation.

26
Additionally to those mentioned in the mapping table at the end of this section, consider also the following:
a) ISO/IEC 27036-1:2021, Cybersecurity — Supplier relationships Part 1: Overview and concepts.
b) ISO/IEC 27036-2:2022, Cybersecurity — Supplier relationships Part 2: Requirements.
c) NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations,
[Link]
d) ENISA Good Practices for Supply Chain Cybersecurity, [Link]
cybersecurity.
27
The list aligns with the draft EU ICT Supply chain Toolbox from the NIS Cooperation Group work stream on supply chain, as of October 2024.

57
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1842

1843 5.1.3. When establishing their supply chain security policy, relevant entities shall take into account the results of the
1844 coordinated security risk assessments of critical supply chains carried out in accordance with Article 22(1) of Directive
1845 (EU) 2022/2555, where applicable.

1846
1847 GUIDANCE

1848 • Follow the activities of the Network and Information Systems (NIS) Cooperation Group, established by
1849 NIS2 article 14, on supply chain.28

1850 EXAMPLES OF EVIDENCES

1851 • Evidence that, relevant to the entity’s business objectives, scenarios as well as recommendations of the
1852 NIS Cooperation Group are integrated into the supply chain policy.
1853

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

1871 GUIDANCE

1872 • For small entities with limited bargaining power when dealing with large suppliers and service providers
1873 consider one or more of the following measures (indicative, non-exhaustive list):
1874 o collective bargaining or purchasing of products or services;
1875 o representation from an association that the entity is a member of;
1876 o legal advice for review and negotiating a contract; and
1877 o negotiating specific clauses such as the exit, pricing and service level agreements.
1878 • Make sure that suppliers and service providers report vulnerabilities of their systems or products or
1879 services that present a risk to the security of the network and information systems of the entity.

1880 EXAMPLES OF EVIDENCES

28
[Link]

58
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1881 • Contracts which contain the elements referred to in point 5.1.4 of the Annex to the Regulation.
1882 • Comparison between selected contracts and the associated tenders in order to check whether the secure
1883 acquisition of ICT systems, products and service processes, and particularly the elements referred to in
1884 point 6.1.2 of the Annex to the Regulation, are taken into consideration.
1885 • Evidences from supplier and service providers vulnerability related communications or reports
1886

1887 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
1888 selection process of new suppliers and service providers, as well as part of the procurement process referred to in point
1889 6.1.

1890 GUIDANCE

1891 • Perform risk analysis before entering any agreement with suppliers and service providers taking into
1892 account the elements referred to in point 5.1.2 and 5.1.3.

1893 EXAMPLES OF EVIDENCES

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

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

1905 GUIDANCE

1906 • Review the supply chain policy at least annually.

1907 • Create and maintain a process to monitor suppliers and service providers over the life cycle.

1908 EXAMPLES OF EVIDENCES

1909 • Supply chain policy review plans or schedules.

1910 • Records from previous reviews.
1911 • List of security incidents related to or caused by engagement with a supplier or service provider.
1912 • Evidence that the policy was reviewed, and possibly updated, after significant changes to operations or
1913 risks or significant incidents related to the provision of ICT services or having impact on the security of the
1914 ICT products from suppliers and service providers.
1915 • Evidence from evaluations of suppliers and service providers.
1916

1917 5.1.7. For the purpose of point 5.1.6., the relevant entities shall:
1918 (a) regularly monitor reports on the implementation of the service level agreements, where applicable;
1919 (b) review incidents related to ICT products and ICT services from suppliers and service providers;
1920 (c) assess the need for unscheduled reviews and document the findings in a comprehensible manner;

59
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1921 (d) analyse the risks presented by changes related to ICT products and ICT services from suppliers and service
1922 providers and, where appropriate, take mitigating measures in a timely manner.

1923 GUIDANCE

1924 • Define responsibilities regarding the maintenance, operation and ownership of assets.
1925 • Make sure that monitoring encompasses periodic reassessment of supplier and service provider
1926 compliance, monitoring supplier and service provider release notes, and conducting dark web monitoring.
1927 • Keep track of security incidents related to or caused by third parties.

1928 EXAMPLES OF EVIDENCES

1929 • Records showing that service levels are monitored in accordance with established Service Level
1930 Agreements (SLAs).
1931 • Incident Response records which confirm whether the entity takes into account incidents related to ICT
1932 services, systems or products from suppliers and service providers;
1933 • Evidence that the signed contracts with third parties (e.g. contractors, suppliers) are in line with the policy
1934 on the security of network and information systems e.g. check the contractual clauses, references to key
1935 security relevant roles and responsibilities, requirements for the contractor to report incidents etc.
1936 • Supplier and service provider exit process meaning documentation outlining how the entity manages the
1937 exit of suppliers and service providers. This includes transitioning services, data, and access rights when
1938 terminating a supplier and service provider relationship.
1939 • List of security incidents related to or caused by engagement with third parties.
1940

1941 TIPS

1942 GUIDANCE

1943 • In addition to the elements referred to in point 5.1.2 of the Annex to the Regulation, consider the following
1944 criteria for the use of Open Source Software supply chain (OSS)29:
1945 o risk assessment: before integrating open source libraries, require the supplier or service provider
1946 to conduct a thorough risk assessment and communicate the results to the entity in order to
1947 understand potential vulnerabilities and their impact on entity’s systems;
1948 o community collaboration: require suppliers or service providers to provide evidence of their
1949 engagement with the OSS community for peer reviews and to stay informed about the latest
1950 security threats and best practices.
1951 o updates: ensure that all open source libraries are regularly updated to the latest versions by the
1952 supplier or the service provider;
1953 o licensing: consider the license type (permissive/BSD, copyleft) and their features 30;
1954 o code reviews: require the supplier or service provider to perform regular code reviews and
1955 security testing on open source libraries to identify and address any security issues;
1956 o software dependencies: require from the supplier or the service provider to provide information
1957 on tools to manage dependencies (e.g. Dependabot, Yarn, Gradle, Pip) and ensure that all
1958 libraries and their dependencies are secure and up-to-date;

29
ENISA Secure software engineering initiatives, [Link]
initiatives/@@download/fullReport, accessed 15 October 2024.
30
Permissive license brings minimal restrictions while copyleft require that any further version of the software is distributed under the same license
regime.

60
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

1959 o zero trust: request the supplier or provider to adopt the zero trust model 43 by verifying and
1960 authenticating all access requests; and
1961 o documentation: request the supplier or provider clear documentation and policies for using open
1962 source libraries, including guidelines for evaluating, integrating, and maintaining these libraries.
1963 • Consider additional elements for the contract clauses (indicative, non-exhaustive list):
1964 o clear and complete description of ICT products and ICT services;
1965 o service level descriptions, including uptime guarantees or target service levels, response times
1966 for service issues, updates to the service level descriptions thereof;
1967 o locations (regions or countries), where the ICT products are to be produced and ICT services are
1968 to be provided and where data is to be processed, including the storage location, and the
1969 requirement for the supplier and service provider to notify the entity in advance if it envisages
1970 changing such locations;
1971 o provisions on availability, authenticity, integrity and confidentiality in relation to the protection of
1972 data, including personal data;
1973 o non-disclosure agreements;
1974 o obligations on the suppliers and service providers, such as retrieval and disposal of the
1975 information obtained by the suppliers and service providers in the exercise of their tasks, in the
1976 event of the insolvency, resolution, termination or discontinuation of the business operations of
1977 the supplier or service provider;
1978 o obligations of the supplier or service provider to provide assistance to the entity at no additional
1979 cost, or at a cost that is determined ex-ante, in the case of a cyber incident which present a risk
1980 of the ICT product or ICT service contracted;
1981 o roles and responsibilities;
1982 o contacts and reporting lines;
1983 o the obligation of the supplier or service provider to fully cooperate with the competent authorities;
1984 o termination rights and related minimum notice periods for the termination of the contractual
1985 arrangements;
1986 o notice periods and reporting obligations of the supplier or service provider to the entity, including
1987 notification of any development that might have a material impact on the supplier’s or service
1988 provider’s ability to effectively provide the ICT products or ICT services in line with agreed service
1989 levels;
1990 o the right to audit by the entity, or an appointed third party, and by the competent authority, and
1991 the obligation of the supplier and the service provider to fully cooperate during onsite inspections
1992 and audits performed by competent authorities, and the obligation to provide details on the scope,
1993 procedures to be followed and frequency of such inspections and audits;
1994 o exit strategies, in particular the establishment of a mandatory adequate transition period, and
1995 provisions on intellectual property.
1996 • Engage with the open source community to stay informed about updates, patches, and best practices for
1997 open source software;
1998 • In addition to the elements referred to in point 5.1.5 the entity might consider the following (indicative, non-
1999 exhaustive list):
2000 o country-specific information (e.g. threat assessment from national security services etc.), if
2001 available;

61
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2002 o restrictions or exclusions posed by a relevant national authority, e.g. in equipment with high
2003 criticality for the entity or for high-risk suppliers;
2004 o information stemming from known incidents or cyber threat intelligence; and
2005 o the characteristics of each supplier, such as the quality of its security practices, the legal
2006 framework, the level of transparency and more.
2007 • Make sure that secure decommissioning service providers involve considerations such as deactivating
2008 user and service accounts, terminating data flows, and ensuring the secure disposal of entity’s data within
2009 supplier or service provider systems.
2010 • Awareness training should be delivered to the entity’s as well as suppliers or service providers’ personnel
2011 regarding rules of engagement and behaviour based on the level of access to the entity’s assets and
2012 information assets
2013 • Include relevant personnel of suppliers and service providers, and their relevant responsibilities, in crisis
2014 management tests.
2015 • Make sure that contracts with third parties (e.g. contractors, suppliers) are in line with the policy on the
2016 security of network and information systems.

2017 EXAMPLES OF EVIDENCES

2018 • For OSS (indicative, non-exhaustive list)

2019 o results from risk assessments of the OSS;
2020 o dependencies’ monitoring tools; and
2021 o documentation.
2022 • Contract clauses which include, in addition to the elements referred to in point 5.1.4 of the Annex to the
2023 Regulation, one or more of the above list with additional elements.
2024 • Evidence from awareness trainings.
2025 • Records from crisis management tests (4.3) which demonstrate the participation of relevant personnel of
2026 suppliers and service providers.
2027

2028 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.5.19, A.5.20, A.5.21, BE-CyFun®2023 IMPORTANT: [Link]-1.1, [Link]-1.2,
A.8.30 [Link]-2.1, [Link]-3.1
ESSENTIAL: [Link]-1.1, [Link]-1.2,
[Link]-4.3
NIST CSF v2.0 [Link]-03, [Link]-05, FI-Kybermittari THIRD-PARTIES-1, THIRD-PARTIES-2,
[Link]-01, [Link]-04, [Link]- CRITICAL-1, CRITICAL-2, CRITICAL-3,
06, [Link]-05, [Link]-07, WORKFORCE-1, WORKFORCE-3
[Link]-09, [Link]-10, [Link]-
10, [Link]-01, [Link]-02,
[Link]-03, [Link]-04
ETSI EN 319 401 Clauses 7.1, 7.7, ref. to EL – Ministerial Cybersecurity Handbook: Part B: 13.1
clause 15 of ISO/IEC decision
27002:2013 1027/2019 - Self-assessment tool: -
Article 4 -
paragraph 5
CEN/TS 18026:2024 ISP-02, DEV-08, PM-01, PM- ES-Royal Decree Article 2, Article 19, Article 23, Annex
02, PM-04, PM-05 311/2022 II: 4.4.3, 4.4.4, 4.5
2029

62
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2030 5.2 DIRECTORY OF SUPPLIERS AND SERVICE PROVIDERS

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

2036 GUIDANCE

2037 • Conduct reviews of the registry, at least biannually, to ensure all information is current and accurate.

2038 EXAMPLES OF EVIDENCES

2039 • Evidence of registry updates following direct supplier and service provider changes.
2040 • Review plans or schedules.
2041

2042 TIPS

2043 GUIDANCE

2044 • In addition to the elements referred to in point 5.2 of the Annex to the Regulation consider the start and
2045 the end date of the contract as well as the region of each direct supplier and service provider.
2046 • Classify direct suppliers and service providers. Classification may include one or more characteristics
2047 (indicative, non-exhaustive list):
2048 o sensitivity of assets purchased;
2049 o volume of assets purchased;
2050 o availability requirements;
2051 o applicable regulations;
2052 o inherent risk, and mitigated risk.
2053 • Update and review classifications annually, or when significant changes occur. Examples of categories
2054 may be:
2055 o Critical: those with a significant impact on the entity’s operations.
2056 o Strategic: High-value partners who contribute to information assets e.g cloud providers, data
2057 analytic providers, software developers, telecommunication providers etc.
2058 o Routine: Those with minimal impact on the entity.

2059 EXAMPLES OF EVIDENCES

2060 • List of relevant contracts or service level agreements which are in line with the documented supply chain
2061 policy.
2062 • Evidence that the entity has categorized its direct suppliers and service providers based on criteria.
2063 • A clear description of how direct suppliers and service providers are grouped and managed based on their
2064 importance and risk level.
2065 • Evidence that the entity assesses risks associated with each direct supplier and service provider category
2066 and tailors measures accordingly. For instance, “Critical” direct suppliers and service providers receive
2067 more attention and customised policies.
2068

63
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2069 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.5.22 BE-CyFun®2023 BASIC: [Link]-4.1, [Link]-5.1
IMPORTANT: [Link]-4.1, [Link]-5.2,
[Link]-6.1, [Link]-1.1, [Link]-2.1,
[Link]-3.1, [Link]-2.1, [Link]-3.1, [Link]-
4.1, [Link]-7.1, [Link]-6.1, [Link]-6.2
ESSENTIAL: [Link]-5.3, [Link]-1.1,
[Link]-2.2, [Link]-3.2, [Link]-3.3, [Link]-
4.2
NIST CSF v2.0 [Link]-05, [Link]-04, [Link]- FI-Kybermittari THIRD-PARTIES-1, CRITICAL-1
01, [Link]-02, [Link]-03,
[Link]-04
ETSI EN 319 401 - EL – Ministerial Cybersecurity Handbook: Part B:
decision 13.2, 13.3, 13.4, 13.5, 13.6, 13.7
1027/2019 - Self-assessment tool: 14.2, 14.3,
Article 4 - 14.4, 14.5, 14.6, 14.7
paragraph 5
CEN/TS 18026:2024 DEV-02, PM-03 ES-Royal Decree -
311/2022

2070

64
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2071 6. SECURITY IN NETWORK AND

2072 INFORMATION SYSTEMS
2073 ACQUISITION, DEVELOPMENT AND
2074 MAINTENANCE

2075 6.1 SECURITY IN ACQUISITION OF ICT SERVICES, ICT SYSTEMS OR ICT PRODUCTS
2076 6.1.1. For the purpose of Article 21(2), point (e) of Directive (EU) 2022/2555, the relevant entities shall set and implement
2077 processes to manage risks stemming from the acquisition of ICT services or ICT products for components that are
2078 critical for the relevant entities’ security of network and information systems, based on the risk assessment carried out
2079 pursuant to point 2.1, from suppliers or service providers throughout their life cycle.

2080 GUIDANCE

2081 • Make cybersecurity fixed part of the purchase process addressing cybersecurity in a separate section.
2082 • Document the secure acquisition of ICT services, systems or products process and describe relevant
2083 procedures which support the process.
2084 • Take into account well known standards when developing the process31.

2085 EXAMPLES OF EVIDENCES

2086 • Tender templates for the acquisition of ICT services, systems or products which address cyber security.
2087 • Documented process which is based on relevant standards and good practices.
2088

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

2099 GUIDANCE

2100 • The security requirements have to include at least means to detect, monitor and protect against
2101 unauthorized changes of software and information.

31
Additionally to those mentioned in the mapping table at the end of this section, consider also the following:
a) [Link]
services
b) Irish National Cybersecurity Center, Guidelines on Cyber Security Specifications (ICT Procurement for Public Service Bodies),
[Link] last accessed 14 October 2024.

65
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2102 • Ensure that support contracts cover the system life cycle and obsolescence management requirements,
2103 including the date until which the system must be supported and continuous alerting.
2104 • Make sure that tenders request from suppliers or service providers to provide tested solutions for security
2105 issues in legacy or new technologies free of charge and as soon as a relevant security issue becomes
2106 known.
2107 • Consider also the following information describing implemented cybersecurity functions such as
2108 (indicative, non-exhaustive list):
2109 o the potential risks that could arise from acquiring the specific ICT service, system or product. This
2110 might involve a penetration testing to identify threats, vulnerabilities, and the potential impact on
2111 the entity’s operations;
2112 o potential security tools that need to be already in place e.g. a firewall, an intrusion detection
2113 system or a SIEM;
2114 o specific security mechanism which might be needed to be in place like specific encryption
2115 algorithm or a particular access control mechanism (e.g. MFA); and
2116 o cyber security standards that the entity needs to comply with in order for the ICT service system
2117 or product.
2118 • Evaluate the security of systems or products before acquisition.
2119 • Consider criteria for Open Source Software (5.1.2).

2120 EXAMPLES OF EVIDENCES

2121 • Past or on-going tenders for acquiring ICT services, systems or products, address cyber security by
2122 referring, as minimum, to the elements outlined in point 6.1.2 of the Annex to the Regulation.
2123 • Comparison between selected contracts and the associated tenders in order to check whether the supply
2124 chain policy, and particularly the elements referred to in points 5.1.4 and 5.1.5 of the Annex to the
2125 Regulation, are taken into consideration.
2126 • Records from security tests before acquiring an ICT system or product.
2127

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

2130 GUIDANCE

2131 • Review the secure acquisition of ICT services, systems or products processes and the derived procedures
2132 at least annually.
2133 • Review logs or records of all changes made to the secure acquisition of ICT services, systems, or products
2134 processes and the derived procedures, including details of the changes, approvals, and implementation
2135 dates.
2136 • Align the tenders and contracts with the entity’s supply chain security policy (5.1).

2137 EXAMPLES OF EVIDENCES

2138 • Review plans or schedules for the secure acquisition of ICT services, systems or products processes and
2139 the derived procedures.
2140 • Minutes from reviews or possible changes made to the ICT services, system or product acquisition
2141 processes and the derived procedures, including actions taken to enhance security in future acquisitions.

66
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2142 • Documented results of possible auditing activities, indicating compliance with internal secure acquisition
2143 of ICT services, systems or products processes and external regulations.
2144 • Change management records of changes made to the secure acquisition of ICT services, systems or
2145 products processes and the derived procedures, including documentation of the review and approval
2146 process.
2147 • Incident Response records which confirm whether the entity takes into account significant incidents when
2148 reviewing and updating the secure acquisition of ICT services, systems or products process and
2149 procedures.
2150

2151 TIPS

2152 GUIDANCE

2153 • Apply the secure acquisition of ICT systems or products processes and relevant procedures to both
2154 software and hardware products, regardless of whether they were developed in-house or acquired.
2155 • Continuously monitor suppliers or service providers in accordance with the entity’s supply chain security
2156 policy and particularly points 5.1.6 and 5.1.7 of the Annex to the Regulation.
2157 • Additional to the elements referred to in point 6.1.2 of the Annex to the Regulation, consider the following
2158 when formulating tenders with cybersecurity in mind (indicative, non-exhaustive list):
2159 o ensure continuous alerting, patching and mitigation proposals if vulnerabilities of the system or the
2160 product are discovered;
2161 o clarify supplier’s or service provider’s liability in the event of cyber-attacks or incidents relevant to the
2162 service, system or product; and
2163 o consider cybersecurity during project implementation and before handover including (indicative, non-
2164 exhaustive list):
2165 ▪ design reviews,
2166 ▪ acceptance tests,
2167 ▪ commissioning tests,
2168 ▪ site acceptance tests; and
2169 ▪ and documentation.
2170 • Make sure that secure decommissioning service providers involve considerations such as deactivating
2171 user and service accounts, terminating data flows, and ensuring the secure disposal of entity’s data within
2172 supplier or service provider systems.

2173 EXAMPLES OF EVIDENCES

2174 • In house projects which take into account the secure acquisition of ICT services, systems or products
2175 processes.
2176 • Evidences that points 5.1.6 and 5.1.7 of the Annex to the Regulation are implemented (5.1).
2177 • Tenders with additional to the elements referred to in point 6.1.2 of the Annex to the Regulation.
2178
2179

67
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2180 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.5.21, A.5.23 BE-CyFun®2023 BASIC: [Link]-4.1
IMPORTANT: [Link]-1.1, [Link]-4.2,
[Link]-3.1, [Link]-4.1, [Link]-2.1,
[Link]-6.2
ESSENTIAL: [Link]-2.2, [Link]-3.2,
[Link]-4.2, [Link]-3.3
NIST CSF v2.0 [Link]-02, [Link]-06, [Link]- FI-Kybermittari THIRD-PARTIES-1, THIRD-PARTIES-2,
09, [Link]-10, [Link]-01, ARCHITECTURE-4
[Link]-02, [Link]-03, [Link]-
04
ETSI EN 319 401 REQ-7.7-01 EL – Ministerial Cybersecurity Handbook: Part B:
decision 13.1, 13.2, 13.4, 13.5
1027/2019 - Self-assessment tool: 14.1, 14.2,
Article 4 - 14.4, 14.5
paragraph 10
CEN/TS 18026:2024 OIS-04, AM-03, DEV-02, ES-Royal Decree Article 19, Annex II: 4.1.3, 4.1.5,
DEV-07, PM-01 311/2022 4.4.1, 4.4.2

2181

2182 6.2 SECURE DEVELOPMENT LIFE CYCLE

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

2187 GUIDANCE

2188 • Take into account well known standards when developing the rules for the secure development of network
2189 and information systems.

2190 EXAMPLES OF EVIDENCES

2191 • Documented rules for the secure development of network and information systems which are based on
2192 relevant standards and good practices.
2193

2194 6.2.2. For the purpose of point 6.2.1., the relevant entities shall:
2195 (a) carry out an analysis of security requirements at the specification and design phases of any development or
2196 acquisition project undertaken by the relevant entities or on behalf of those entities;
2197 (b) apply principles for engineering secure systems and secure coding principles to any information system development
2198 activities such as promoting cybersecurity-by-design, zero-trust architectures;
2199 (c) lay down security requirements regarding development environments;
2200 (d) establish and implement security testing processes in the development life cycle;
2201 (e) appropriately select, protect and manage security test data;
2202 (f) sanitise and anonymise testing data according to the risk assessment carried out pursuant to point 2.1.

2203 GUIDANCE

68
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2204 • A secure software and development life cycle (SDLC) process should be implemented by all entities,
2205 however smaller entities can do with a less demanding process such as implementing secure by design
2206 practices and security testing processes.
2207 • Depending on the type of requirement, the rules for the secure development of software and systems
2208 should include appropriate software testing methods (e.g. black-box, ad-hoc testing).
2209 • Test security by design at various stages of the secure development of SDLC prior to Go-live utilising
2210 independent tools and a self-service testing platform throughout SDLC.

2211 EXAMPLES OF EVIDENCES

2212 • Evidence that secure development rules have been adopted (indicative, non-exhaustive list):
2213 o documentation for each phase of the life cycle;
2214 o process and Workflow diagrams;
2215 o audit and testing reports;
2216 o version control;
2217 o change management logs;
2218 o code reviews; and
2219 o project management tools.
2220 • Evidence of the test results to secure development environments, including measures for protecting test
2221 data are maintained.
2222 • Evidence of the software testing methods chosen for a particular test scenario and explanation of this.
2223 • Test results of each phase of the SDLC are maintained and are up to date.
2224 • Test results are maintained and approved by management bodies.
2225 • Evidence that a software testing method is chosen at each stage of the software development lifecycle.
2226

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

2229 GUIDANCE

2230 • Align the secure development rules with the security testing policy (point 6.5 of the Annex to the
2231 Regulation) and procedures as well as with the secure acquisition of ICT services, systems or products
2232 process (point 6.1 of the Annex to the Regulation).
2233 • Hold regular cross organisation unit meetings during all phases of the development life cycle.

2234 EXAMPLES OF EVIDENCES

2235 • Compare the secure development rules with the security testing policy as well as with the secure
2236 acquisition of ICT services, systems or products process and check whether the security requirements are
2237 set consistently in all these documents.
2238 • Records or minutes from cross organisational units where the development of a network and information
2239 system, including software, was discussed.
2240

2241

69
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

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

2244 GUIDANCE

2245 • Review the rules for the secure development of network and information systems at least annually.

2246 EXAMPLES OF EVIDENCES

2247 • Documentation that outlines the schedule and the frequency for reviewing secure development rules.
2248 • Documented evidence of the review process of the patch development process, security training for
2249 software developments and secure by design software configurations.
2250 • Meeting minutes, review findings, and actions taken to improve the development rules.
2251 • Version history or change log of secure development procedures showing updates made as a result of
2252 reviews.
2253 o Specific sections in the documents highlighting what changes were made and the rationale behind
2254 them.
2255 • Reports from internal and external audits that evaluate the review process of secure development rules.
2256 • Documentation of change requests related to secure development rules, including those initiated from
2257 review findings.
2258 • Logs or records tracking the implementation of changes to ensure they are applied throughout the
2259 development process.
2260

2261 TIPS

2262 GUIDANCE

2263 • Consider threat modelling as part of the security requirements analysis.

2264 • Keep separated environments for development purposes, testing purposes and production.
2265 • Ensure the use of results of application assessments in order to regularly enhance developer training and
2266 the SDLC process.
2267 • In addition to the regular reviews, the entity should review and, where necessary, update its secure
2268 development rules when significant changes to technology or operations or risks or significant incidents.

2269 EXAMPLES OF EVIDENCES

2270 • Evidence from the use of threat modelling (indicative, non-exhaustive list):
2271 o documentation of the process used e.g. STRIDE or DREAD;
2272 o data flow diagrams; and
2273 o meeting minutes.
2274 • Evidence of separated environments for development, testing and production e.g different network
2275 segments, servers, databases, existence of accounts used for this purpose, change management records
2276 etc.
2277 • Relevant personnel are aware of the secure development rules.
2278 • Evidence e.g. meeting minutes, logs, reports etc which show that the secure development rules were
2279 reviewed, an possibly changed, following significant changes to technology or operations or risks or
2280 significant incidents.
2281

70
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2282 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.8.25, A.8.31 BE-CyFun®2023 IMPORTANT: [Link]-1.2, [Link]-2.1
ESSENTIAL: [Link]-7.1, [Link]-2.2
NIST CSF v2.0 [Link]-08, [Link]-06, [Link]- FI-Kybermittari ARCHITECTURE-4, THIRD-PARTIES-2
01, [Link]-02, [Link]-03,
[Link]-04
ETSI EN 319 401 REQ-7.7-01, REQ-7.7-02, EL – Ministerial Cybersecurity Handbook: Part B: 9.1,
REQ-7.8-10 decision 9.2, 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9,
1027/2019 - 9.10, 9.11, 9.12, 9.13, 9.14, 9.15, 9.16
Article 4 - Self-assessment tool: 10.1, 10.2,
paragraph 10 10.3, 10.4, 10.5, 10.6, 10.7, 10.8,
10.9, 10.10, 10.11, 10.12
CEN/TS 18026:2024 OIS-04, CCM-04, CCM-06, ES-Royal Decree Annex II: 5.6.1, 5.6.2, 5.7.1
DEV-01, DEV-03, DEV-04, 311/2022
DEV-05, DEV-06
2283

2284 6.3 CONFIGURATION MANAGEMENT

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

2287 GUIDANCE

2288 • Establish documented processes based on best practices and information security standards32.
2289 • Maintain operating procedures with details on (indicative, non-exhaustive list):
2290 o computer start-up and close-down procedures;
2291 o processing and handling of information;
2292 o backup;
2293 o scheduling requirements, including interdependencies with other systems;
2294 o handling errors or other exceptional conditions;
2295 o system restart and recovery procedures;
2296 o cryptographic mechanisms and settings, and
2297 o audit-trail and system log information.
2298 • Consider the following security-related parameters for the configuration settings (indicative, non-exhaustive
2299 list):
2300 o registry settings;
2301 o account, file, directory permission settings; and
2302 o settings for functions, ports, protocols, services, and remote connections.
2303 • Employ automated mechanisms to centrally manage, apply, and verify configuration settings for software and
2304 hardware.
2305 • Ensure compliance with requirements for functions, ports, protocols, and services.
2306 • Monitor and control changes to the configuration settings in accordance with entity’s policy on the security of
2307 network and information systems as well as topic specific policies and procedures.
2308 • Identify software not authorised to execute on the information systems.

32
Additionally to those mentioned in the mapping table at the end of this section, consider also the following:
a) ISO/IEC 20000 is the international standard for IT service management. It consists of 17 parts.
b) ITIL (Information Technology Infrastructure Library).
c) IEEE 828, Configuration Management in Systems and Software Engineering.

71
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2309 • Review and update the list of unauthorised software regularly.

2310 • Review and update regularly the list of authorised software.
2311 • Identify software programs authorised to execute on the information system.
2312 • Employ a deny-all, permit-by-exception policy to allow the execution of authorised software.
2313 • Set up procedures for the network service usage to restrict access only to necessary services or applications.
2314 • A secure baseline configuration for development and test environments is managed separately from the
2315 operational baseline configuration.
2316 • Identify, document, and approve any deviations from established configuration settings based on defined
2317 exceptions on operational requirements.

2318 EXAMPLES OF EVIDENCES

2319 • System configuration process, based on good practices and standards, in place and maintained.
2320 • System configuration tables containing configurations of hardware, software, services and networks.
2321 • Documented secure baseline configuration containing at least (indicative, non-exhaustive list):
2322 o essential capabilities of operation;
2323 o restricted use of functions;
2324 o security by default;
2325 o ports, protocols and/or services allowed.
2326 • Documented configuration management plan for asset management, including roles and responsibilities, the
2327 assets and configurations that are subject to the plan, the objectives of asset management.
2328 • Documented and approved exceptions to the configuration baseline containing the alternative measures in
2329 place to ensure the confidentiality, availability and integrity of the configuration item.
2330 • Documented secure baseline configuration for development and test environments.
2331

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

2336 GUIDANCE

2337 • Consider state-of-the-art hardening guides/best practices and general cyber security principles (e.g., least
2338 functionality, least privilege) as a basis to derive the defined security configurations.
2339 • Protect the configuration management plan from unauthorised disclosure and modification.
2340 • Establish, document and maintain configuration settings respecting the access control policy.
2341 • Where applicable, test the configuration before implementation.
2342 • Employ security safeguards to detect and respond to unauthorised changes to defined configuration settings.
2343 • Establish configuration management plan containing:
2344 o roles, responsibilities, and configuration management processes and procedures;
2345 o a process for identifying configuration items throughout the system development life cycle; and
2346 o a process for managing the configuration of the configuration items.

2347 EXAMPLES OF EVIDENCES

2348 • Configuration plan.

2349 • Compare the configuration plan with the access control lists.

72
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2350 • Mechanisms e.g. logical and physical access controls, encryption and audit logs are in place.
2351 • Documented and approved exceptions to the configuration baseline containing the alternative measures in
2352 place to ensure the confidentiality, availability and integrity of the configuration item.
2353

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

2356 GUIDANCE

2357 • Review, where appropriate update, configurations at least monthly to ensure that patches have been applied,
2358 the systems run the latest versions of software, the backup has been executed according to the plan and that
2359 there are no fatal server/device/disk errors.
2360 • Produce, keep and review regularly change logs regarding security configuration of information systems;
2361 • Review and update the configurations after major changes (e.g software updates) and past incidents.
2362 • Obtain baseline configuration files for key systems and devices to compare against current configurations.

2363 EXAMPLES OF EVIDENCES

2364 • Up to date configuration management plan, review comments and/or change logs.
2365 • Documented results of the review activities.
2366 • Configuration snapshots taken before and after changes or at regular intervals to verify that reviews are
2367 conducted and documented.
2368 • Audit logs from systems and devices that track configuration changes and reviews.
2369 • Alerts from monitoring systems that notify administrators of configuration changes or deviations from the
2370 baseline.
2371 • Audit trails and compliance records from internal and external audits.
2372 • Minutes from team meetings where configuration reviews and changes are discussed and documented.
2373 • Records of notifications or reminders sent to relevant employees about upcoming configuration reviews.
2374 • Records from the configuration management tools to ensure they are kept up-to-date with accurate
2375 configuration information.
2376 • Incident Response records which confirm whether the entity takes into account incidents related the
2377 configurations.
2378

73
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2379 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.8.9 BE-CyFun®2023 BASIC: [Link]-4.1
IMPORTANT: [Link]-3.2, [Link]-1.1
ESSENTIAL: [Link]-3.2, [Link]-1.1,
[Link]-1.2, [Link]-2.2, [Link]-7.2
NIST CSF v2.0 [Link]-01, [Link]-01, [Link]- FI-Kybermittari ASSET-3, ASSET-4, ARCHITECTURE-3,
02, [Link]-03, [Link]-04 ARCHITECTURE-4
ETSI EN 319 401 REQ-6.3-09, REQ-7.7-03 EL – Ministerial Cybersecurity Handbook: Part B: 2.1,
decision 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9,
1027/2019 - 2.10, 2.12, 2.15
Article 4 - Self-assessment tool: 3.1, 3.2, 3.3,
paragraph 2, 10 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, 3.12,
3.13
CEN/TS 18026:2024 OPS-21, PSS-03, PSS-04 ES-Royal Decree Article 10, Article 20, Article 21,
311/2022 Article 30, Annex II: 4.3.2, 4.3.3
2380

2381

2382 6.4 CHANGE MANAGEMENT, REPAIRS AND MAINTENANCE

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

2386 GUIDANCE

2387 • Take into account well known standards when developing the change management procedures.33
2388 • Consider the following elements for the procedures (indicative, non-exhaustive list):
2389 o request for change;
2390 o risk assessment;
2391 o criteria for categorisation and prioritisation of changes
2392 ▪ associated requirements for the type and scope of the tests to be carried out; and
2393 ▪ the approvals to be obtained;
2394 o requirements for performing roll-backs; and
2395 o documentation of the changes and approval of changes.
2396 • The change management procedures may allow different workflows depending on the criticality of the system,
2397 scope of the change and urgency (for instance, put in place an “emergency intervention workflow”).
2398 • Record for each change the steps of the followed procedure.
2399 • Review and approve changes following the change management procedures, prior to implementing them.
2400 • Implement and test change management procedures, to make sure that changes of networks and information
2401 systems are always done following a predefined way.

2402 EXAMPLES OF EVIDENCES

2403 • Documented change management procedures for network and information systems which are based on
2404 standards or good practices.
2405 • For each change, a report is available describing the steps and the result of the change.

33
Additionally to those mentioned in the mapping table at the end of this section, consider also the following:
a) ISO 21500:2021, Project, programme and portfolio management — Context and concepts
b) ISO 21502:2020, Project, programme and portfolio management — Guidance on project management

74
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2406 • A system maintenance procedure that addresses:

2407 o purpose;
2408 o scope;
2409 o roles;
2410 o responsibilities;
2411 o management commitment;
2412 o coordination among different organisational units; and
2413 o compliance.
2414 • Logs that record the dates and outcomes of the periodic reviews of the change, repair, and maintenance
2415 procedures.
2416

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

2421 GUIDANCE

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

2432 EXAMPLES OF EVIDENCES

2433 • Logs and records of past (new) software installations.

2434 • Evidence that multifactor authentication (MFA) is in place for activating change, repair, and maintenance
2435 procedures.
2436 • Test plans and results that demonstrate the implementation and effectiveness of the change, repair, and
2437 maintenance procedures.
2438 • If the entity utilises change management tools, evidence that these tools enforce the use of only approved
2439 resources and mandate documentation for each change.
2440 • ACLs to verify that access to the tools is in line with the access control policy.
2441

2442

75
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

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

2446 GUIDANCE

2447 • Integrate the pullback scenario34 into the change management procedures.
2448 • Assess the risks from legacy systems and upgrade existing legacy systems to include security mitigating
2449 measures in case an appropriate security cannot be achieved.
2450 • Make sure that regular change control procedures which could not be followed due to an emergency change,
2451 have to be applied immediately after the emergency change.

2452 EXAMPLES OF EVIDENCES

2453 • Documentation with specific pullback plans.

2454 • Logs and records of past change requests with details on (indicative, non-exhaustive list):
2455 o details of the change;
2456 o reason for emergency;
2457 o approval;
2458 o reason for delay;
2459 o follow up actions; and
2460 o how to revert the system to a previous stage if the change fails.
2461 • Logs and records from past legacy systems’ upgrade which contain risk assessment and reasoning for the
2462 change.
2463

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

2466 GUIDANCE

2467 • Review the change management procedures at least annually.

2468 • Make sure that the management procedures cover planned and unplanned changes and the development
2469 phase, when applicable.

2470 EXAMPLES OF EVIDENCES

2471 • Review plans or schedules.

2472 • Up to date change management procedures, review comments and/or change logs.
2473 • Evidence of approval and monitoring of maintenance activities, whether performed on site or remotely and
2474 whether the equipment is serviced on site or removed to another location.
2475 • Logs of all changes made to the procedures, including details, approvals, and implementation dates.
2476 • Audit trails and compliance records from internal and external audits.
2477 • Logs of significant incidents to confirm whether they include documentation of reviews and updates to the
2478 change, repair, and maintenance procedures.
2479 • Reports from post-incident reviews that document any necessary adjustments to the procedures following
2480 significant incidents.
2481 • Records showing how changes and updates to the procedures were implemented and reviewed.

34
Also known as 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 that the change does not work as expected.

76
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2482

2483 TIPS

2484 GUIDANCE

2485 • Perform and log changes, maintenance and repairs of network and information systems, with approved and
2486 controlled tools.
2487 • Put change management procedures in place according to licensing agreements.
2488 • Upon changes update of the asset inventory (point 12.4 of the Annex to the Regulation) and documentation.
2489 • Inform the customer of significant changes to network and information systems which affect the offered
2490 services.
2491 • Ensure availability of required maintenance skills, resources and spare parts, including external support.
2492 • Prevent the unauthorised removal of maintenance equipment containing information related to the entity by
2493 (indicative, non-exhaustive list):
2494 o verifying that there is no information related to the entity contained on the equipment;
2495 o sanitising or destroying the equipment;
2496 o retaining the equipment within the facility; or
2497 o obtaining an exemption from authorised personnel or roles explicitly authorising removal of the
2498 equipment from the facility.
2499 • Provide remote access via out of band connection (OOB) in case that the standard connection does not work.
2500 • Regularly test OOB connections to ensure they function as expected during an outage.
2501 • If an incident, in accordance with Article 23 of the NIS2 Directive, involves post actions, which entail system
2502 changes, then notify the competent authorities for these changes in accordance with ENISA guideline on
2503 incident reporting or national reporting procedure.

2504 EXAMPLES OF EVIDENCES

2505 • Evidence that multifactor authentication is in place for remote change, repair, and maintenance procedures.
2506 • Logs and records which prove the use of approved tools.
2507 • Evidence that the procedures mention the licencing agreement.
2508 • Documentation of a customer update on significant changes.
2509 • Evidence for previous trainings on change management and system maintenance.
2510 • Evidence of sanitisation procedure.
2511 • Evidence that the entity maintains a spare parts for key components of its network and information system.
2512 • Notifications to defined personnel or roles of the date and time of planned maintenance.
2513 • Network architecture diagram which proves the existence of OOB connections.
2514
2515
2516

77
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2517 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 6.3, 8.1, A.7.13, A.8.32 BE-CyFun®2023 BASIC: [Link]-1.1, [Link]-2.1; [Link]-
1.1
IMPORTANT: [Link]-1.2, [Link]-2.2,
[Link]-4.1, [Link]-1.2, [Link]-6.1,
[Link]-1.2, [Link]-1.3, [Link]-3.1,
[Link]-2.1
ESSENTIAL: [Link]-3.3, [Link]-4.2,
[Link]-2.2, [Link]-3.2, [Link]-7.2
NIST CSF v2.0 [Link]-07, [Link]-01, [Link]- FI-Kybermittari ASSET-4
02, [Link]-03, [Link]-04
ETSI EN 319 401 REQ-7.7-03, REQ-7.7-04 EL – Ministerial Cybersecurity Handbook: Part B: 2.12
decision
1027/2019 - Self-assessment tool: -
Article 4 -
paragraph 15
CEN/TS 18026:2024 ISP-03, CCM-01, CCM-02, ES-Royal Decree Annex II: 4.3.5
CCM-03, CCM-04, CCM-05, 311/2022
CCM-06
2518

2519

2520 6.5 SECURITY TESTING

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

2522 GUIDANCE

2523 • Take into account well known standards when developing the testing policy32.
2524 • Establish and maintain a testing program appropriate to entity’s size, complexity, and maturity 35.

2525 EXAMPLES OF EVIDENCES

2526 • Documented security testing and procedures which are based on relevant standards and good practices.
2527 • Guidelines and standards that the entity adheres to for conducting security tests.
2528

2529 6.5.2. The relevant entities shall:

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

2537

2538

35
Cyber fundamentals, [Link]-1, Centre for Cyber Security Belgium, accessible at:
[Link]

78
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2539 GUIDANCE

2540 • Make sure that network and information systems are tested at set up, after infrastructure or application
2541 upgrades or modifications that the entity determines are significant, or after maintenance.
2542 • Consider a range of security tests, e.g. vulnerability assessments, penetration testing, code review, ethical-
2543 hacking, cyber-attack simulations or cyber response exercises etc.
2544 • Entity wide tests should be carried out at planned intervals or when significant incidents or changes occur.
2545 • Conduct internal and/or external audits throughout the entity’s networks, systems and processes in an ad-hoc
2546 manner.
2547 • Record evidence while testing. The need, scope, frequency, type and results are documented in a manner that
2548 is comprehensible to an expert third party.
2549 • Use criteria to assess the results of the tests similar to the criteria for performing cyber security risk
2550 assessments (section 2.1, and in particular in point 2.1.2 of this document).
2551 • Assess, follow up and remediate findings at least in the case of medium to very high criticality with respect to
2552 the confidentiality, integrity, authenticity or availability of the service provided.
2553 • The assessment of criticality and mitigating actions for each finding are documented.

2554 EXAMPLES OF EVIDENCES

2555 • Documented security testing policy and procedures which include the elements referred to in point 6.5.2 (a) of
2556 the Annex to the Regulation.
2557 • Documentation defining the roles and responsibilities of personnel involved in security testing.
2558 • Plans or schedules for upcoming or completed, regular or ad hoc tests.
2559 • List of reports from past security tests This should cover various types of testing (e.g., vulnerability
2560 assessments, penetration testing, code reviews).
2561 • Internal or external audit reports.
2562

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

2565 GUIDANCE

2566 • Review the security testing policy and procedures at least annually.

2567 EXAMPLES OF EVIDENCES

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

79
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2572

2573 TIPS

2574 GUIDANCE

2575 • Determine the auditable security events that are adequate to support investigations of security incidents.
2576 • Implement tools for automated testing, such as code analysis tools or vulnerability scanners.
2577 • Ensure the policy is approved, communicated to and acknowledged by relevant personnel and third parties.
2578 • Ensure that the development and testing environment(s) are separate from the production environment.
2579 • Review the security testing policy and procedures when significant incidents or major changes to the network
2580 and information system occur.

2581 EXAMPLES OF EVIDENCES

2582 • Additionally to the elements referred to in point 6.5.2 (c) of the Annex to the Regulation documented policy
2583 which at least include (indicative, non-exhaustive list):
2584 o approved parties (internal or third);
2585 o confidentiality levels for assessment; and
2586 o test results and the objectives security assessments and tests.
2587 • Relevant staff is aware of the security testing procedures and tools.
2588 • Audit requirements are approved by the management bodies.
2589 • A list of tools used for security testing, including their purpose and how they are maintained and updated.
2590 • Valid licenses for commercial testing tools or subscriptions to security services.
2591 • Records showing updates to the security policy and procedures based on lessons learnt and new threats.
2592

2593
2594 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 A.8.29, A.8.33, A.8.34 BE-CyFun®2023 IMPORTANT: [Link]-5.1, [Link]-4.1,
[Link]-3.1, PR.P-4.2, [Link]-7.3, [Link]-
1.3, [Link]-1.1, [Link]-1.2, [Link]-1.1
ESSENTIAL: [Link]-1.3, [Link]-3.2,
[Link]-4.2, [Link]-7.1, [Link]-2.2, [Link]-
3.2, [Link]-5.2
NIST CSF v2.0 [Link]-01, [Link]-01, [Link]- FI-Kybermittari THREAT-1, THIRD-PARTIES-2
02, [Link]-03, [Link]-04
ETSI EN 319 401 REQ-7.8-10, REQ-7.8-14, EL – Ministerial Cybersecurity Handbook: Part B:
14A, REQ-7.8-15 decision 14.4, 14.5, 9.13, 9.14
1027/2019 - Self-assessment tool: 15.6, 15.7,
Article 4 - 15.8, 15.9, 10.10, 10.11
paragraph 14
CEN/TS 18026:2024 ISP-02, OPS-19, DEV-01, ES-Royal Decree Annex II: 4.5
DEV-04, DEV-06 311/2022
2595

2596

80
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2597 6.6 SECURITY PATCH MANAGEMENT

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

2606 GUIDANCE

2607 • Take into account well known standards when developing the security patch management procedures.32,36
2608 • Actions may vary, depending on the system (e.g. mandatory patching for exposed systems (e.g. internet-
2609 connected devices like firewalls and routers) and limited patching for isolated or legacy systems).
2610 • Establish a process, in combination with the asset inventory, to be informed when a new security patch is
2611 published and schedule patch roll-outs accordingly.
2612 • Patching should be a standard activity in normal maintenance and outage planning of services. Nonetheless,
2613 some failures may require immediate patching depending on their criticality.
2614 • Deploy vulnerability management technologies to identify unpatched and misconfigured software.
2615 • Define your relevant security information sources considering your assets and continuously monitor them for
2616 patches announcements, patch and non-patch remediation, and general threats.
2617 • Verify the patch sources through (indicative, non-exhaustive list):
2618 o digital certificates to verify the vendor;
2619 o digital signatures of the patches
2620 o change logs provided by the vendor; and
2621 o feedback from the community concerning the reliability of the vendor.
2622 • Apply patches after approval or testing on an isolated environment, following the change management
2623 procedure.

2624 EXAMPLES OF EVIDENCES

2625 • Detailed procedures and guidelines for how patches are identified, evaluated, tested, deployed, and verified.
2626 • Logs or records showing the history of patch deployments across various systems. These may include
2627 (indicative, non-exhaustive list):
2628 o timestamps;
2629 o responsible personnel; and
2630 o affected systems.
2631 • Evidence that the asset inventory (12.4) is updated after a new security patch is announced accompanied by
2632 the time plan to apply it.
2633 • Evidence of testing patches before deployment in a controlled environment. This should include results of
2634 testing and any issues encountered and resolved.
2635 • Documentation of test plans and results for patches before deployment to production environments.
2636 • Documentation of change requests for deploying patches, including approvals and impact assessments.

36
Additionally to those mentioned in the mapping table at the end of this section, consider also NIST SP 800-40 Rev. 4, Guide to Enterprise Patch
Management Planning: Preventive Maintenance for Technology, [Link] last accessed 15 October 2024.

81
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2637 • Detailed audit trails showing the steps taken from patch identification to deployment.
2638 • Checks for latest patches.
2639 • Approved documented actions applying patches.
2640 • Records of changes logged, reviewed, and approved.
2641 • Evidence for vendor verification mechanisms e.g digital certificates, digital signatures etc.
2642 • Reports from internal and external audits evaluating the effectiveness of the patch management processes.
2643

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

2647 GUIDANCE

2648 • Take effort, proportionate to entity’s size and importance, to ensure that security patches don’t introduce
2649 additional vulnerabilities or instabilities.
2650 • If patching is not feasible, consider compensating measures like hardening, intrusion detection systems,
2651 network segmentation, access control and monitoring.

2652 EXAMPLES OF EVIDENCES

2653 • Evidence from patch prioritisation e.g emphasis is given on patches assessed as critical.
2654 • Evidence that residual risks resulting from non patching are listed and mitigated.
2655 • Incident reports related to unpatched vulnerabilities in order to check the effectiveness of the mitigation
2656 measures during entity’s response.
2657 • Logs of changes made to systems, including patches applied, rollback procedures, and any issues
2658 encountered.
2659 • Documented decisions for non patching accompanied by relevant compensating measures.
2660

2661 TIPS

2662 GUIDANCE

2663 • Inform customers in advance in case of planned inaccessibility to the service.

2664 • Patch management procedures indicating scope, roles & responsibilities.
2665 • Perform operating system and application updates on enterprise assets through automated patch
2666 management.
2667 • Use appropriate patch management tools to fulfil the elements referred to in point 6.6.1 of the Annex to the
2668 Regulation.
2669 • Since patches can sometimes cause issues, it is recommended to back up the system before applying them.
2670 • Have a rollback plan, in case that patching does not work, to ensure that the system reverts to a safe previous
2671 state.
2672 • Remove unsupported hardware and software from the network in a reasonable and accepted timeline in line
2673 with the entity’s risk assessment.
2674 • Include patch and update requirements in the supply chain policy (5.1) as well as in the contracts, bid evaluation
2675 and selection criteria for new ICT services, systems or products (secure acquisition of ICT services, systems
2676 or products, 6.1), also considering the system life span.

82
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2677 EXAMPLES OF EVIDENCES

2678 • Evidence of communications e.g. sms, emails, announcement, posts at media etc. with the customers related
2679 to inaccessibility of the service.
2680 • Documentation of regular meetings where patch management processes are reviewed. This should include
2681 agendas, attendance records, actions taken to improve the process and minutes from the meetings.
2682 • Checks for latest patches for evidence of who performed each step and when as well as for documentation
2683 outlining the roles and responsibilities of staff involved in the patch management process.
2684 • Patch Management Tools.
2685 • Configuration and logs from these tools demonstrating regular use.
2686 • Rollback plan.
2687 • Contract, bid, documented evaluation and selection criteria for new systems which consider the patch
2688 management requirements as well as the system life span.
2689

2690 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.8.31, A.8.32 BE-CyFun®2023 BASIC: [Link]-1.1
IMPORTANT: [Link]-1.2, [Link]-1.1
ESSENTIAL: [Link]-3.2, [Link]-1.7
NIST CSF v2.0 [Link]-02, [Link]-09, [Link]- FI-Kybermittari ASSET-4, THREAT-1
01, [Link]-02, [Link]-03,
[Link]-04
ETSI EN 319 401 REQ-7.7-09 EL – Ministerial Cybersecurity Handbook: Part B: 2.8
decision
1027/2019 - Self-assessment tool: 3.5, 3.6, 15.4
Article 4 -
paragraph 10
CEN/TS 18026:2024 CCM-03, CCM-04, CCM-05, ES-Royal Decree Annex II: 4.3.2
OPS-18 311/2022
2691

2692

2693 6.7 NETWORK SECURITY

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

2696 GUIDANCE

2697 • Take into account well known standards when developing the supply chain policy 37.

2698 EXAMPLES OF EVIDENCES

2699 • Documented network security measures which are based on relevant standards and good practices.
2700

2701

37
Additionally to those mentioned in the mapping table at the end of this section, consider also the following:
a) NIST Special Publication NIST SP 800-215, Guide to a Secure Enterprise Network Landscape, [Link]
accessed 15 October 2024.
b) ISO/IEC 27033 series of standards on network security.

83
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2702 6.7.2. For the purpose of point 6.7.1., the relevant entities shall:
2703 (a) document the architecture of the network in a comprehensible and up to date manner;
2704 (b) determine and apply controls to protect the relevant entities’ internal network domains from unauthorised access;
2705 (c) configure controls to prevent accesses and network communication not required for the operation of the relevant
2706 entities;
2707 (d) determine and apply controls for remote access to network and information systems, including access by service
2708 providers;
2709 (e) not use systems used for administration of the security policy implementation for other purposes;
2710 (f) explicitly forbid or deactivate unneeded connections and services;
2711 (g) where appropriate, exclusively allow access to the relevant entities’ network and information systems by devices
2712 authorised by those entities;
2713 (h) allow connections of service providers only after an authorisation request and for a set time period, such as the
2714 duration of a maintenance operation;
2715 (i) establish communication between distinct systems only through trusted channels that are isolated using logical,
2716 cryptographic or physical separation from other communication channels and provide assured identification of their end
2717 points and protection of the channel data from modification or disclosure;
2718 (j) adopt an implementation plan for the full transition towards latest generation network layer communication protocols
2719 in a secure, appropriate and gradual way and establish measures to accelerate such transition;
2720 (k) adopt an implementation plan for the deployment of internationally agreed and interoperable modern e-mail
2721 communications standards to secure e-mail communications to mitigate vulnerabilities linked to e-mail-related threats
2722 and establish measures to accelerate such deployment;
2723 (l) apply best practices for the security of the DNS, and for Internet routing security and routing hygiene of traffic
2724 originating from and destined to the network.

2725 GUIDANCE

2726 • Define roles and responsibilities as well as timelines for the transition towards latest generation network
2727 layer communication protocols.
2728 • Approve, log, and perform remote maintenance of network and information systems in a manner that
2729 prevents unauthorised access.
2730 • Consider the following for email communications (indicative, non-exhaustive list):
2731 o standards such as STARTTLS, DANE, DMARC, DKIM and SPF38
2732 o internal spam/scam/virus filtering; and
2733 o URL rewriting.
2734 • Consider DNS SEC39 for DNS.
2735 • Consider BGP40 for internet routing.

2736 EXAMPLES OF EVIDENCES

2737 • Up-to-date network diagrams, including the Out-Of-Band (OOB) connections.

2738 • Firewall(s).
2739 • Configuration files and rulesets for firewalls and routers, showing how traffic is filtered and managed.

38
[Link]
a)
39
a) Secure Domain Name System (DNS) Deployment Guide [Link] accessed 15
October 2024.
b) DNSSEC HOWTO, a tutorial in disguise Olaf Kolkman, [Link] accessed 15 October 2024.
40
ENISA, 7 Steps to shore up the Border Gateway Protocol (BGP), [Link] accessed 15
October 2024.

84
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2740 • Configuration files for switches, including Virtual Local Access Network (VLAN) settings and access control
2741 lists (ACLs).
2742 • Documentation of ACLs implemented on network devices to control traffic flow.
2743 • Documented correct usage of mobile devices and other remote-accesses (e.g. teleworking, OOB
2744 connections).
2745 • Evidence of controls over privileged accounts, including logs and policies.
2746 • Access logs to confirm that only authorised personnel are making changes and conducting reviews of the
2747 network security rules.
2748 • Transition towards latest generation network layer communication protocols implementation plan.
2749

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

2752 GUIDANCE

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

2762 EXAMPLES OF EVIDENCES

2763 • Plans or schedules for upcoming or completed, regular or ad hoc reviews.

2764 • List of reports from past reviews. This should cover various types of reviews.
2765 • Logs from firewalls, routers, and other network devices showing access attempts, configuration changes,
2766 and other relevant activities.
2767 • Reports from Security Information and Event Management (SIEM) systems showing aggregated and
2768 analysed security events.
2769 • VPN and Remote Access Logs showing remote, including OOB connections, access attempts, successful
2770 connections, and any anomalies.
2771 • Evidence of Network Access Control (NAC) in place, including logs and configuration settings.
2772 • Logs or records showing the dates and results of regular reviews of the network security rules.
2773 • Logs or records of all changes made to the network security rules.
2774 • Logs or records of firewall and access control list (ACL) reviews.
2775 • Documentation showing regular reviews of user and administrative access to network devices.
2776 • Audit logs from network security devices (e.g., firewalls, IDS/IPS 41) to ensure that changes and reviews
2777 are logged.
2778 • Backup files of network device configurations to ensure that changes and reviews are reflected in the
2779 backups.

41
Intrusion detection/prevention systems

85
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2780 • Logs of network security incidents to see if they include documentation of rule set reviews following
2781 significant incidents.
2782 • Post-Incident review reports to see if they document reviews and any necessary adjustments to the
2783 network security rules.
2784

2785 TIPS

2786 GUIDANCE

2787 • Communicate to personnel the correct usage of mobile devices and other remote-accesses.

2788 EXAMPLES OF EVIDENCES

2789 • The correct usage of mobile devices and other remote-accesses (e.g. teleworking, VPN) has been
2790 communicated to the personnel.
2791

2792 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.8.16, A.8.20 BE-CyFun®2023 BASIC: [Link]-1.1, [Link]-2.1, [Link]-
3.1, [Link]-3.2, [Link]-5.1, [Link]-5.2,
[Link]-1.1, [Link]-3.1
IMPORTANT: [Link]-2.2, [Link]-3.3,
[Link]-5.3, [Link]-5.4, [Link]-1.2,
[Link]-1.2, [Link]-3.2
ESSENTIAL: [Link]-1.2, [Link]-2.4,
[Link]-5.5, [Link]-1.3
NIST CSF v2.0 [Link]-01, [Link]-01, [Link]- FI-Kybermittari ACCESS-1, ACCESS-2, ARCHITECTURE-
05, [Link]-01, [Link]-02, 1, ARCHITECTURE-2
[Link]-03, [Link]-04
ETSI EN 319 401 REQ-7.8 EL – Ministerial Cybersecurity Handbook: Part B: 6.1,
decision 6.2, 6.3, 6.8, 6.9, 6.10, 6.11, 6.12,
1027/2019 - 6.13, 6.14, 6.15, 6.16, 6.17, 6.18,
Article 4 - 6.19, 6.20, 6.21, 6.22, 6.23
paragraph 13, 17 Self-assessment tool: 7.1, 7.2, 7.3,
7.8, 7.9, 7.11, 7.12, 7.13, 7.14, 7.16,
7.17, 7.18, 7.19, 7.20, 7.21
CEN/TS 18026:2024 PS-04, CS-01, CS-02, CS-03, ES-Royal Decree Article 9, Annex II: 5.4.1, 5.4.2, 5.4.3
CS-06, CS-07, CS-08, PSS-02 311/2022
2793

2794

86
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2795 6.8 NETWORK SEGMENTATION

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

2799 GUIDANCE

2800 • Take into account well known standards when segmenting networks42, 43.

2801 EXAMPLES OF EVIDENCES

2802 • Documented network segmentation rules which are based on relevant standards and good practices.
2803

2804 6.8.2. For that purpose, the relevant entities shall:

2805 (a) consider the functional, logical and physical relationship, including location, between trustworthy systems and
2806 services;
2807 (b) grant access to a network or zone based on an assessment of its security requirements;
2808 (c) keep systems that are critical to the relevant entities operation or to safety in secured zones;
2809 (d) deploy a demilitarised zone within their communication networks to ensure secure communication originating from
2810 or destined to their networks;
2811 (e) restrict access and communications between and within zones to those necessary for the operation of the relevant
2812 entities or for safety;
2813 (f) separate the dedicated network for administration of network and information systems from the relevant entities’
2814 operational network;
2815 (g) segregate network administration channels from other network traffic;

2816 (h) separate the production systems for the relevant entities’ services from systems used in development and testing,
2817 including backups.

2818 GUIDANCE44, 45

2819 • Make sure that the segments are in line with the results of the risk assessment (2.1).
2820 • Apply a graduated set of measures in different logical network domains to further segregate the network
2821 security environments, including:
2822 o publicly accessible systems;
2823 o internal networks;
2824 o OOB connections; and
2825 o assets with high criticality.
2826 • Implement subnetworks for publicly accessible system components that are physically and/or logically
2827 separated from internal organisational networks.
2828 • Determine the degree of physical separation of system components from physically distinct components:
2829 o in separate racks in the same room;

42
Additionally to those mentioned in the mapping table at the end of this section, consider also the following:
b) NIST Special Publication NIST SP 800-215, Guide to a Secure Enterprise Network Landscape, [Link]
accessed 15 October 2024.
c) ISO/IEC 27033 series of standards on network security.
43
Zero trust model proposed by NIST and it assumes that no part of the network is trusted (NIST Special Publication
NIST SP 800-215).
44
Different organisations use different terminology for the term ‘operational network’ e.g. enterprise network, corporate network, IT network, OT
network, administration network. However, the fundamental concept remains focused on the interconnectedness and functionality of components
working together toward common objectives set by the management of the entity.
45
The network for administration of a network and information systems, often referred to as network administration, involves managing, monitoring,
and maintaining an entity’s network infrastructure to ensure its optimal performance and security

87
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2830 o in separate rooms for the components with high criticality; and
2831 o to more significant geographical separation of the components with high criticality.
2832 • Implement separate network addresses (i.e., different subnets) to connect to systems in different security
2833 domains.
2834 • Monitor and control communications at the external boundary of the system and at key internal boundaries
2835 within the system.
2836 • Isolate information security tools, mechanisms, and support components from other internal information
2837 system components by implementing physically separate subnetworks with managed interfaces to other
2838 components of the system.
2839 • Route all networked, privileged accesses through a dedicated, managed interface for purposes of access
2840 control and auditing.
2841 • Implement a managed interface for each external telecommunication service.

2842 EXAMPLES OF EVIDENCES

2843 • Risk assessments that justify the segmentation decisions.

2844 • Interviews with IT and security staff to understand the rationale behind network segmentation.
2845 • Up-to-date network diagrams showing segmentation into different networks or zones (e.g., DMZ 46, internal
2846 networks, guest networks).
2847 • Verify that the diagrams align with business functions and risk profiles.
2848 • Documented criteria for creating and maintaining different network zones.
2849 • Virtual Local Access Network (VLAN) configurations on network switches and routers.
2850 • VLANs correspond to different security zones and business functions.
2851 • Measures (e.g., IDS/IPS41, monitoring systems) tailored to each network zone.
2852 • Configurations of network devices (e.g., routers, switches, firewalls) for proper segmentation settings.
2853 • Configuration settings match documented segmentation rules and diagrams.
2854 • Segregation of duties control matrix.
2855 • Access Control Lists (ACLs) and firewall configurations
2856

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

2859 GUIDANCE

2860 • Review and, if necessary, update the process for network segmentation rules at least biannually.

2861 EXAMPLES OF EVIDENCES

2862 • Reports from recent penetration tests and vulnerability scans.

2863 • Network segmentation rules’ review plans or schedules.
2864 • Logs or records confirming that the reviews have been conducted according to the schedule.
2865 • Change management documentation for network segmentation changes, in line with risk assessment
2866 results and business needs.

46
A perimeter network, also known as a demilitarized 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.

88
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2867 • Incident response documentation to verify that network segmentation rules are reviewed following
2868 significant security incidents.
2869 • Post-incident analysis reports that include assessments of segmentation rule effectiveness and any
2870 necessary adjustments.
2871 • Internal or external audit logs and reports that cover network segmentation rule reviews.
2872 • Reviews are performed periodically and in response to network changes or incidents.
2873 • Minutes from security or IT operations meetings where network segmentation rules are discussed.
2874 • Penetration tests and vulnerability assessments that include evaluations of network segmentation.
2875 • Tests are conducted periodically and after major changes or incidents, and their findings lead to rule
2876 reviews.
2877

2878 TIPS

2879 GUIDANCE

2880 • Limit the data traffic between the different segments to the operationally required extent by means of data
2881 flow control, e.g. firewall.
2882 • Connect to external networks or information systems only through managed interfaces consisting of
2883 boundary protection devices arranged in accordance with the entity’s security architecture like:
2884 o gateways;
2885 o routers;
2886 o firewalls;
2887 o guards;
2888 o network-based malicious code analysis;
2889 o virtualization systems; and
2890 o encrypted tunnels.
2891 • Prevent discovery of specific system components composing a managed interface.
2892 • Exceptions are monitored

2893 EXAMPLES OF EVIDENCES

2894 • Network isolation and implementation of segmented network security zones that limit the impact of a
2895 malicious software incident.
2896 • Logging and monitoring are active for each zone.
2897 • Alerts for segmentation rule violations.
2898 • Reviews triggered by alerts of segmentation violations.
2899
2900

89
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2901 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.8.22 BE-CyFun®2023 BASIC: [Link]-3.1, [Link]-5.2
IMPORTANT: [Link]-5.3, [Link]-5.4,
[Link]-4.3
ESSENTIAL: [Link]-5.2, [Link]-7.1,
[Link]-3.2, [Link]-4.5
NIST CSF v2.0 [Link]-01, [Link]-01, [Link]- FI-Kybermittari ARCHITECTURE-1, ARCHITECTURE-2
02, [Link]-03, [Link]-04
ETSI EN 319 401 REQ-7.8-02 EL – Ministerial Cybersecurity Handbook: Part B: 6.4,
decision 6.5, 6.6, 6.7, 6.15
1027/2019 - Self-assessment tool: 7.4, 7.5, 7.6,
Article 4 - 7.7, 7.15
paragraph 13
CEN/TS 18026:2024 IAM-09, CS-02, CS-04, CS-05 ES-Royal Decree Annex II: 5.4.4
311/2022
2902

2903

2904 6.9 PROTECTION AGAINST MALICIOUS AND UNAUTHORISED SOFTWARE

2905 6.9.1. The relevant entities shall protect their network and information systems against malicious and unauthorised
2906 software.

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

2911 GUIDANCE

2912 • Employ malicious and unauthorised software detection and protection mechanisms at system entry and
2913 exit points and at workstations, servers and mobile computing devices on the network to detect and
2914 eradicate malicious code transported by electronic mail, electronic mail attachments, web accesses,
2915 removable media, or inserted through the exploitation of system vulnerabilities.
2916 • Configure malicious code protection mechanisms to perform periodic scans of the system regularly and
2917 real-time scans of files from external sources as the files are downloaded, opened, or executed.
2918 • Disinfect and quarantine infected files.
2919 • Apply application whitelisting and monitor unauthorised activities and system behaviour.
2920 • Make sure that the malicious and unauthorised protection mechanisms are centrally managed.
2921 • Make sure that there are mechanisms which prevent users from circumventing malicious and unauthorised
2922 software protection capabilities.
2923 • Make sure that spam protection mechanisms are employed at system entry points such as workstations,
2924 servers, or mobile computing devices on the network.
2925 • Update malicious code protection mechanisms (including signature definitions) whenever new releases
2926 are available in accordance with configuration rules as well as patch management procedures of the entity.
2927 • Address issues related to false positives during malicious code detection and eradication and the resulting
2928 potential impact on the availability of the system.

90
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2929 • Align malicious and unauthorised detection and repair software monitoring and logging rules with entity’s
2930 monitoring and logging tools and procedures (3.2) as well as with entity’s access control (11.1) and asset
2931 handling policy.

2932 EXAMPLES OF EVIDENCES

2933 • Endpoint protection systems (EPS) across the network.

2934 • Malware detection systems are present, and up to date.
2935 • Tools for monitoring unauthorised software is in place and up to date.
2936 • Firewall configurations, intrusion detection/prevention systems (IDS/IPS), and secure web gateways
2937 contain malicious and unauthorised software protection measures.
2938 • Use of whitelisting solutions, which restrict the execution of non-approved software and code.
2939 • Rules and configurations related to application whitelisting are up to date.
2940 • Documented description of centrally management tools.
2941 • Records of recent updates malicious and unauthorised detection and repair software which show that they
2942 are regularly patched and updated to protect against known vulnerabilities.
2943 • Records of periodical scans.
2944 • Monitoring and logging of network and information systems, at discrete intervals to identify malicious code
2945 and unauthorized code execution.
2946 • Logs for blocked or detected threats.
2947 • Record and maintain logs including:
2948 o user activities;
2949 o exceptions; and
2950 o information security incidents.
2951 • Documented spam protection mechanism.
2952 • Determine the level of logs monitoring required by a risk assessment.
2953

2954 TIPS

2955 GUIDANCE

2956 • Consider that the use of malicious and unauthorised detection and repair software alone is not usually
2957 adequate or may not be available, so it should be complemented by additional measures such as
2958 (indicative, non-exhaustive list):
2959 o implementing rules and measures that prevent or detect the use of unauthorised software;
2960 o implementing measures that prevent or detect the use of known or suspected malicious websites;
2961 o reducing vulnerabilities that can be exploited by malicious software;
2962 o controlling the execution of applications on user workstations or user end devices (including
2963 smartphones or tablets);
2964 o employing web application filters to reduce exposure to malicious content.
2965 • Consider email filters as essential tools for detecting and blocking malicious and unauthorised software.
2966 Different types of filtering are (indicative, non-exhaustive list):
2967 o content filtering;
2968 o blocklist filtering;
2969 o antivirus filtering;
2970 o phishing filters; and

91
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

2971 o machine learning filters.

2972 EXAMPLES OF EVIDENCES

2973 • Documented alternative countermeasures such as:

2974 o Securing of all physical and logical data interfaces;
2975 o Network isolation and implementation of segmented network security zones that limit the impact of a
2976 malicious software incident;
2977 o Comprehensive system hardening measures to minimise the risk of malicious software incidents.
2978 o Logs which confirm that administrative privileges are controlled and monitored.
2979 • Logs from email filters.
2980

2981 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.5.32, A.8.7 BE-CyFun®2023 BASIC: [Link]-2.1, [Link]-1.1, [Link]-
4.1, [Link]-4.1
IMPORTANT: [Link]-2.4, [Link]-5.1
ESSENTIAL: [Link]-2.5, [Link]-1.6,
[Link]-2.3, [Link]-4.2, [Link]-5.2
NIST CSF v2.0 [Link]-01, [Link]-09, FI-Kybermittari ARCHITECTURE-2, ARCHITECTURE-3
[Link]-05, [Link]-01, [Link]-
02, [Link]-03, [Link]-04
ETSI EN 319 401 REQ-7.7-05 EL – Ministerial Cybersecurity Handbook: Part B: 6.9,
decision 6.10, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7,
1027/2019 - 7.8, 7.9, 7,10
Article 4 - Self-assessment tool: 7.9, 7.10, 7.11,
paragraph 13, 17 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.8,
8.9, 8.10
CEN/TS 18026:2024 OPS-04, OPS-05, CS-03 ES-Royal Decree Article 24, Annex II: 4.3.6
311/2022
2982

2983

2984 6.10 VULNERABILITY HANDLING AND DISCLOSURE

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

2987 GUIDANCE

2988 • Adopt a framework for assessing the severity of vulnerabilities e.g CVSS, EPSS, SANS vulnerability
2989 assessment framework etc.

2990 EXAMPLES OF EVIDENCES

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

2994

92
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

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

3004 GUIDANCE

3005 • Address without undue delay vulnerabilities assigned to the highest classification (e.g. ”critical” in CVSS) or
3006 equivalent (e.g. as defined by the national CSIRT). Accepting the risk of such vulnerabilities, and not
3007 addressing them, is not advisable, where possible.
3008 • Share information obtained from the technical vulnerability scans with designated personnel throughout the
3009 entity and authorities to help eliminate similar vulnerabilities in other information systems.
3010 • Disclose not yet known vulnerabilities to designated CSIRT according to national Coordinated Vulnerability
3011 Disclosure (CVD) policies, where applicable.
3012 • Identify a single point of contact and communication channels for network and information security related
3013 issues with suppliers and service providers.

3014 EXAMPLES OF EVIDENCES

3015 • Logs of a vulnerability assessed as critical to check if it was addressed.

3016 • Licenses or subscriptions for vulnerability scanning tools.
3017 • Configuration files of the vulnerability scanning tools to ensure they are set up to scan the entire relevant
3018 infrastructure and are updated with the latest vulnerability definitions.
3019 • Logs from vulnerability management tools showing scan schedules, results, and follow-up actions.
3020 • Documented technical vulnerability scan reports.
3021 • SIEM logs for records of detected vulnerabilities and related alerts from monitoring channels.
3022 • Reports from third-party security assessments or penetration tests.
3023 • Evidence of addressed findings from these assessments for vulnerabilities assessed as critical.
3024 • Records from a vulnerability disclosed, if any, according to the national CVD policy.
3025 • Interview the single point of contact and communication channels for information security related issues with
3026 suppliers and service providers.
3027

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

3032 • Define and establish the roles and responsibilities associated with vulnerability management.

3033 EXAMPLES OF EVIDENCES

3034 • Records showing timelines and responsible employees for each remediation effort as well as verification of
3035 fixes.

93
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3036 • Records or logs of past vulnerability mitigation plans or schedules.

3037 • Records of a vulnerability which was not addressed and the relevant justification.
3038

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

3041 GUIDANCE

3042 • Review the technical vulnerability monitoring channels’ information at least biannually.
3043 • Consider inventorying sources likely to report technical vulnerabilities in the identified components and
3044 distribute updates (software publisher websites, CERT website, ENISA website)47.

3045 EXAMPLES OF EVIDENCES

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

3057 TIPS

3058 GUIDANCE

3059 • Create and maintain procedures for identifying, assessing, prioritising, and remediating vulnerabilities.
3060 • Make sure that suppliers and service providers report vulnerabilities of their systems or products or services
3061 that present a risk to the security of the network and information systems of the entity (supply chain policy,
3062 5.1.4).
3063 • Perform vulnerability scans, and record evidence of the results of the scans, when significant incidents or
3064 significant changes to operations or risks occur.
3065 • Review and, where appropriate, update the channels of monitoring vulnerability information when significant
3066 incidents or significant changes to operations or risks occur.

3067 EXAMPLES OF EVIDENCES

3068 • Documented procedures for identifying, assessing, prioritising, and remediating vulnerabilities.
3069 • Contracts with suppliers and service providers which require technical vulnerability reporting, handling and
3070 disclosure.
3071 • Evidences from supplier and service providers vulnerability related communications or reports
3072 • Records of ad-hoc scans performed in response to significant incidents or changes to the infrastructure,
3073 including the dates and reasons for these scans.

47
Cyber fundamentals, [Link]-12, Centre for Cyber Security Belgium, accessible at:
[Link]

94
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3074 • Change management logs to verify that vulnerability scans are conducted following significant incident or
3075 changes to the infrastructure or to the threat landscape.
3076 • Records of internal audits or reviews of the vulnerability management procedures.
3077 • Findings and corrective actions taken from these audits.
3078
3079

3080 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.8.848 BE-CyFun®2023 BASIC: [Link]-1.1
IMPORTANT: [Link]-1.2, [Link]-2.1,
[Link]-8.1, [Link]-8.2, [Link]-4.1,
[Link]-5.1
ESSENTIAL: [Link]-3.3, [Link]-5.2,
[Link]-5.2
NIST CSF v2.0 [Link]-01, [Link]-02, [Link]- FI-Kybermittari THREAT-1
04, [Link]-05, [Link]-06,
[Link]-02, [Link]-03, [Link]-
08, [Link]-06, [Link]-01,
[Link]-02, [Link]-03, [Link]-
04
ETSI EN 319 401 REQ-7.8-13, REQ-7.8-13A, EL – Ministerial Cybersecurity Handbook: Part B:
REQ-7.9-10, REQ-7.9-11 decision 14.1, 14.2, 14.3
1027/2019 - Self-assessment tool: 15.1, 15.3,
Article 4 - 15.4, 15.5
paragraph 14
CEN/TS 18026:2024 OIS-03, OPS-17, OPS-18, ES-Royal Decree Article 8, Article 10, Article 21, Article
OPS-19, OPS-20, OPS-21, 311/2022 34, Annex II: 4.7.3, 5.8.2
DEV-06

3081

48
ISO/IEC 29147 provides detailed information on receiving vulnerability reports. ISO/IEC 30111 provides detailed information about handling and
resolving reported vulnerabilities.

95
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3082 7. POLICIES AND PROCEDURES TO

3083 ASSESS THE EFFECTIVENESS OF
3084 CYBERSECURITY RISK-
3085 MANAGEMENT MEASURES

3086 7.1.1. For the purpose of Article 21(2), point (f) of Directive (EU) 2022/2555, the relevant entities shall establish,
3087 implement and apply a policy and procedures to assess whether the cybersecurity risk-management measures taken
3088 by the relevant entity are effectively implemented and maintained.

3089 GUIDANCE

3090 • Take into account well known standards when developing the policy and procedures for assessing the
3091 efficient implementation of the measures.49
3092 • Implement a policy for assessing the effectiveness of implementation of measures which is proportionate
3093 to the risk posture of the entity in line with the risk assessment.

3094 EXAMPLES OF EVIDENCES

3095 • Documented policy and procedures for effectiveness assessments which is based on standards.
3096

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

3106 GUIDANCE

3107 • When selecting measures for assessing effectiveness of implementation take into account the cost of their
3108 implementation.
3109 • Consider one or more of the following indicative methods for assessing the effectiveness of
3110 implementation of a measure, according to the risk treatment plan (section 2.1):
3111 o self-assessment;
3112 o benchmarking against a measure’s checklist or a standard;
3113 o vulnerability assessment;

49
Additionally to those mentioned in the mapping table at the end of this section, consider also the following:
a) ISO/IEC 27004:2016, Information technology — Security techniques — Information security management — Monitoring, measurement,
analysis and evaluation.
b) ITIL (Information Technology Infrastructure Library).

96
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3114 o penetration testing (e.g. internal, external, red/blue team);

3115 o secure code review;
3116 o audit (e.g. internal, external, compliance); and
3117 o performance monitoring.
3118 • The assessment service can be provided by an external entity or by specially authorised employees of the
3119 entity.
3120 o In case of externals, confidentiality and non-disclosure terms should be included in the contract.
3121 o Internal employees should be suitably trained, and the entity should consider their objectivity and
3122 impartiality. The entity should pay particular attention to the elements of point 2.3. of the Annex
3123 to the Regulation concerning impartiality of the employees. For instance, they should not come
3124 from the department or division whose systems are being inspected or should not have been
3125 involved in developing the code and in installing or operating the system being audited for this
3126 purpose.
3127 • Define key performance indicators (KPIs) to measure the effectiveness of measures including notable
3128 examples like (indicative, non-exhaustive list)50:
3129 o the cost of implementation and maintenance e.g. CAPEX/OPEX.
3130 o the number of employees who have attended cyber security trainings;
3131 o the number of vulnerabilities detected;
3132 o time to remediation;
3133 o incident response times; and
3134 o number of non-compliances (consider the elements of point 2.2. of the Annex to the Regulation
3135 concerning the compliance monitoring).
3136 • If possible, use the same KPIs for each assessment and utilize standardized templates and checklists to
3137 ensure consistency and thoroughness.
3138 • Although the frequency of monitoring and measurement of measures, addressed under point 7.2.1 (a) of
3139 the Annex of the Regulation, depends on the entity's risk assessment, the entity may follow this indicative,
3140 non-exhaustive guideline:
3141 o continuously monitor and measure the effectiveness of mitigating measures designed to address
3142 real-time threats (e.g., firewalls, IDS/IPS)’
3143 o monitor and measure the effectiveness of security measures related to the threat landscape
3144 biannually (e.g., vulnerability management, incident response plans);
3145 o annually assess the overall effectiveness of all measures;
3146 o measure the effectiveness of measures related to a specific incident following that incident; and
3147 o measure the effectiveness of measures related to a specific systems or one of its components
3148 following significant changes to this system or this component.

3149 EXAMPLES OF EVIDENCES

3150 • Evidence that management has received reporting on the effective implementation of the measures.
3151 • Evidence that monitoring and measurement results are reported to the management bodies (point 2.3.3.
3152 of the Annex to the Regulation concerning the compliance monitoring).
3153 • Documented objectives and KPIs for the implementation of the measures.
3154 • Documented analysis and evaluation of the results from the evaluations.

50
ENISA’s cyber security investment reports offer a good reference for measuring effectiveness of measures e.g. NIS Investments report 2023,
[Link] last accessed 19 October 2024.

97
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3155 • Logs or records from previous effectiveness assessments.

3156 • Plans or schedules for future effectiveness assessments.
3157 • Documented roles and responsibilities.
3158

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

3161 GUIDANCE

3162 • Review policy and procedures for the assessment of the effectiveness of the measures at least every two
3163 years, taking into account
3164 o changes to the information systems;
3165 o changes to the environment of operation; and
3166 o trends related to threats and vulnerabilities.
3167 • Update the policy and procedures based on findings from security tests (Annex to the Regulation, point 6.5)
3168 and the independent review of policy on the security of the network and information systems (Annex to the
3169 Regulation, point 2.3), if applicable.
3170 • Take into account the results of the assessment and consider them when identifying and prioritising appropriate
3171 risk treatment options and measures (point 2.1.3 of the Annex of the Regulation).

3172 EXAMPLES OF EVIDENCES

3173 • Logs or records from previous policy reviews.

3174 • Plans or schedules for future effectiveness reviews.
3175 • Risk treatment plan which takes into account the results of the effectiveness assessments.
3176 • Minutes from meetings where security testing results are discussed and based on these results the
3177 effectiveness of other policies is reviewed and their improvements are discussed.
3178 • Records showing updates to other policies and procedures with a view to the assess their effectiveness.
3179

3180
3181 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 6.2, 9.1, 9.3 BE-CyFun®2023 BASIC: [Link]-1.1
IMPORTANT: [Link]-7.1, [Link]-8.1,
[Link]-8.2, [Link]-9.1, [Link]-3.1,
[Link]-1.2, [Link]-1.1
ESSENTIAL: [Link]-7.2, [Link]-7.3,
[Link]-9.2
NIST CSF v2.0 [Link]-03, [Link]-06, [Link]- FI-Kybermittari CRITICAL-2, RISK-4, RISK-5,
01, [Link]-02, [Link]-03, Management activities
[Link]-04
ETSI EN 319 401 Clause 5, ref. to ISO/IEC EL – Ministerial Cybersecurity Handbook: Part B:
27005:2011 decision 14.1, 14.2, 14.3, 14.4, 14.5
1027/2019 Self assessment tool: 15.1, 15.2, 15.3,
Article 4 - 15.4, 15.5, 15.6, 15.7, 15.8, 15.9
paragraph 14
CEN/TS 18026:2024 ISP-02, OPS-20, CO-04 ES-Royal Decree Article 31, Article 32, ANNEX III -
311/2022 Security audit

98
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3182 8. BASIC CYBER HYGIENE

3183 PRACTICES AND SECURITY
3184 TRAINING

3185 8.1 AWARENESS RAISING AND BASIC CYBER HYGIENE PRACTICES

3186 8.1.1. For the purpose of Article 21(2), point (g) of Directive (EU) 2022/2555, the relevant entities shall ensure that their
3187 employees are aware of risks, are informed of the importance of cybersecurity and apply cyber hygiene practices.

3188 GUIDANCE

3189 • Implement cybersecurity awareness programs:

3190 o Use various formats, such as workshops, webinars, and e-learning modules.
3191 o Use multiple communication channels (emails, newsletters, intranet) to keep employees informed
3192 about cybersecurity updates, threats, and cyber hygiene practices for users.

3193 EXAMPLES OF EVIDENCES

3194 • Awareness raising program, e.g. a comprehensive outline of the program, detailing the objectives, content,
3195 frequency, syllabus, and schedule of the program.
3196

3197 8.1.2. The relevant entities shall offer to all employees, including members of management bodies, an awareness raising
3198 programme, which shall:
3199 (a) be scheduled over time, so that the activities are repeated and cover new employees;
3200 (b) be established in line with the network and information security policy, topic-specific policies and relevant procedures
3201 on network and information security;
3202 (c) cover cybersecurity risk-management measures in place, contact points and resources for additional information and
3203 advice on cybersecurity matters, as well as cyber hygiene practices for users.

3204 GUIDANCE

3205 • Include cyber hygiene practices for users (indicative, non-exhaustive list):
3206 o clear desk and screen policy,
3207 o use of passwords and other authentication means,
3208 o event reporting,
3209 o safe email use and web browsing,
3210 o protection from phishing and social engineering,
3211 o secure use of mobile devices,
3212 o secure connection practices,
3213 o backup practices,
3214 o secure teleworking practices and more.
3215 • Include in the programme the following topics (indicative, non-exhaustive list):
3216 o Train personnel to recognize social engineering attacks, such as phishing, pre-texting, and
3217 tailgating.

99
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3218 o Train personnel to be aware of causes for unintentional data exposure. Example topics include
3219 erroneous delivery of sensitive data, losing a portable end-user device, or publishing data to
3220 unintended audiences.
3221 o Train personnel on the dangers of connecting to, and transmitting data over, insecure networks
3222 for entity’s activities. If the entity has remote workers, training should include guidance to ensure
3223 that all users securely configure their home network infrastructure.
3224 o Train personnel on understanding malicious and unauthorised software, on the importance of
3225 malicious software detection and on the risks and consequences of using unauthorised software.
3226 • Offer to employees contact points and resources for additional advice.
3227 • To implement the awareness raising program, consult available sources, such as ENISA’s AR-in-a-Box.51
3228 and the Cybersecurity Skills Academy52.

3229 EXAMPLES OF EVIDENCES

3230 • Awareness raising program, i.e. a comprehensive outline of the program, detailing the objectives, content,
3231 frequency, syllabus, schedule of the program.
3232 • Copies of the awareness raising materials distributed to employees, including handouts, e-mails,
3233 presentations, and online modules.
3234 • Logs, sign-in sheet, certificates of completion or acknowledgements given to employees upon completing
3235 the program, that show which employees followed the awareness raising program.
3236

3237 8.1.3. The awareness raising program shall be tested in terms of effectiveness, updated and offered at planned intervals
3238 taking into account changes in cyber hygiene practices, and the current threat landscape and risks posed to the relevant
3239 entities.

3240 GUIDANCE

3241 • Offer cybersecurity awareness raising programmes periodically.

3242 • Test the effectiveness of the awareness raising program, e.g. by using quizzes.
3243 • Review and update the awareness raising program at least annually.

3244 EXAMPLES OF EVIDENCES

3245 • Logs, sign-in sheet, certificates of completion or acknowledgements given to employees upon completing
3246 the program, that show which employees followed the awareness raising program.
3247 • Results from any quizzes or assessments conducted to measure the employees’ understanding of the
3248 topics covered.
3249 • Employee feedback forms on the awareness raising program, which can provide insight into the
3250 effectiveness of the program and areas for improvement.
3251 • Review and update records showing that the program is reviewed regularly and updated as necessary.
3252

3253
3254

51
[Link]
52
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, available at [Link]
[Link]/legal-content/EN/TXT/?uri=COM%3A2023%3A207%3AFIN, last accessed 5.10.2024.

100
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3255 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 7.3, A.6.3, A.8.7 BE-CyFun®2023 BASIC: [Link]-1.1
IMPORTANT: [Link]-1.2
ESSENTIAL: [Link]-1.3
NIST CSF v2.0 [Link]-01, [Link]-02, [Link]- FI-Kybermittari WORKFORCE-2, WORKFORCE-3,
01, [Link]-02, [Link]-03, WORKFORCE-4, PROGRAM-2
[Link]-04
ETSI EN 319 401 REQ-7.2-02, REQ-7.2-03, EL – Ministerial Cybersecurity Handbook: Part B:
REQ-7.2-04 decision 10.4, 10.5, 10.6, 10.7, 10.8, 10.9,
1027/2019 - 10.10, 10.11, 10.12, 10.13, 10.14,
Article 4 - 10.15, 12.1
paragraph 16 Self-assessment tool: 11.1, 11.5,
11.6, 13.1
CEN/TS 18026:2024 HR-04, DOC-01 ES-Royal Decree Annex II: 5.2.3
311/2022
3256

3257 8.2 SECURITY TRAINING

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

3260 GUIDANCE

3261 • Assess which roles within the entity require security relevant skills and expertise.
3262 • Offer training that focuses on the specific security skills required by the identified roles.
3263 • Consider the European Cybersecurity Skills Framework (ECSF)53.

3264 EXAMPLES OF EVIDENCES

3265 • A comprehensive outline of the training program, detailing the objectives for different roles and how to
3266 reach them, content, and frequency of the training.
3267

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

3271 GUIDANCE

3272 • Provide role-specific network and information security training.

3273 • Consider various training methods, such as online courses, workshops, hands-on labs, and simulations
3274 • Consider various types of trainings, such as courses, certifications, or attending security conferences or
3275 webinars.
3276 • Examples of trainings may include secure system administration courses for IT professionals, OWASP ®
3277 awareness and prevention trainings for web application developers, and advanced social engineering
3278 awareness training for high-profile roles.

3279 EXAMPLES OF EVIDENCES

53
[Link] last accessed 5.10.2024.

101
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3280 • A comprehensive outline of the training program, detailing the objectives for different roles and how to
3281 reach them, content, and frequency of the training.
3282

3283 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
3284 shall be assessed. Training shall take into consideration security measures in place and cover the following:
3285 (a) instructions regarding the secure configuration and operation of the network and information systems, including
3286 mobile devices;
3287 (b) briefing on known cyber threats;
3288 (c) training of the behaviour when security-relevant events occur.

3289 GUIDANCE

3290 • Topics to include to the programme may include (indicative, non-exhaustive list):
3291 o Train personnel on authentication best practices, such as MFA, password creation, and
3292 credential management.
3293 o Train personnel on how to identify and properly store, transfer, archive, and destroy sensitive
3294 data.
3295 o Train personnel to recognize a potential incident, such as unusual email attachments,
3296 unexpected system behaviour, and suspicious network traffic.
3297 o Train staff on how to report events promptly and accurately, including the use of designated
3298 communication channels.
3299 o Train personnel to understand how to verify and report out-of-date software or any failures in
3300 automated processes and tools. Part of this training should include notifying IT personnel of any
3301 failures in automated processes and tools.
3302 o Provide regular updates on the latest cyber threats.
3303 • Test the security knowledge of employees to make sure that they have sufficient and up-to-date security
3304 knowledge.

3305 EXAMPLES OF EVIDENCES

3306 • Comprehensive outline of the training program, detailing the objectives for different roles and how to reach
3307 them, content, and frequency of the training.
3308 • Assessment results from any quizzes or assessments conducted to measure the employees’
3309 understanding of the topics covered.
3310

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

3313 GUIDANCE

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

3316 EXAMPLES OF EVIDENCES

3317 • Logs, sign-in sheets, certificates of completion or acknowledgements given to employees upon completing
3318 the training, that show which that employees who transferred to new positions or roles attended training
3319 sessions relevant to the new position or role.

102
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

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

3322 GUIDANCE

3323 • Provide cybersecurity trainings periodically.

3324 • Review and update the training program at least annually.

3325 EXAMPLES OF EVIDENCES

3326 • Logs, sign-in sheets, certificates of completion or acknowledgements given to employees upon completing
3327 the training, that show which employees attended the training sessions.
3328 • Training materials distributed to employees, including handouts, presentations, and online modules.
3329 • Updates showing that the training program is reviewed and updated regularly to keep up with the latest
3330 cybersecurity threats and best practices.
3331 • Employee feedback forms on the training sessions, which can provide insight into the effectiveness of the
3332 training and areas for improvement.
3333

3334 TIPS

3335 GUIDANCE

3336 • Encourage participation in threat intelligence sharing communities to stay informed about emerging
3337 threats.
3338
3339 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 7.2, A.6.3 BE-CyFun®2023 BASIC: [Link]-1.1
IMPORTANT: [Link]-1.2, [Link]-5.1,
[Link]-1.1
ESSENTIAL: [Link]-1.3
NIST CSF v2.0 [Link]-01, [Link]-01, [Link]- FI-Kybermittari WORKFORCE-1, WORKFORCE-2,
02, [Link]-03, [Link]-04 WORKFORCE-3, WORKFORCE-4
ETSI EN 319 401 REQ-7.2-03 EL – Ministerial Cybersecurity Handbook: Part B:
decision 12.1, 12.2, 12.3, 12.4, 12.5
1027/2019 - Self-assessment tool: 13.1, 13.2,
Article 4 - 13.3, 13.4, 13.5, 13.6
paragraph 16
CEN/TS 18026:2024 HR-04, PM-01 ES-Royal Decree Annex II: 5.2.4
311/2022

3340

103
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3341 9. CRYPTOGRAPHY

3342 9.1.1. For the purpose of Article 21(2), point (h) of Directive (EU) 2022/2555, the relevant entities shall establish,
3343 implement and apply a policy and procedures related to cryptography, with a view to ensuring adequate and effective
3344 use of cryptography to protect the confidentiality, authenticity and integrity of data in line with the relevant entities’ asset
3345 classification and the results of the risk assessment carried out pursuant to point 2.1.

3346 GUIDANCE

3347 • Ensure that the comprehensive policy and procedures related to cryptography are in line with relevant
3348 regulations and state of the art standards.

3349 EXAMPLES OF EVIDENCES

3350 • Documented policy on cryptography and procedures related to cryptography.

3351

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

3372 GUIDANCE

3373 • Ensure that the policy and procedures cover cryptographic mechanisms, such as digital signatures and
3374 hashes, to:
3375 o protect the confidentiality and integrity of data in transit and at rest;
3376 o detect unauthorized changes to data at rest marked as critical; and
3377 o secure disposal of the data after their lawful use.

104
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3378 • Set up a mechanism (either manual or automated) for the selection, establishment and management
3379 (including updating) of cryptographic keys.
3380 • Apply encryption in sensitive information transfer (e.g. key generation, key management).
3381 • Enforce encryption on electronic media which contain confidential/sensitive information.
3382 • Ensure confidentiality and integrity of the data with cryptographic mechanisms, when, for example
3383 (indicative, non-exhaustive list):
3384 o sharing information;
3385 o scanning;
3386 o using secure online (e.g. client side cloud encryption) and offline storage; and
3387 o removing sensitive data from storage media.
3388 • Maintain availability of information in the event of the loss of cryptographic keys, e.g. by escrowing of
3389 encryption keys.
3390 • Produce, control, and distribute symmetric and asymmetric cryptographic keys using key management
3391 technology and processes.
3392 • Use automated cryptographic key management mechanisms to:
3393 o generate keys for different cryptographic systems and different applications;
3394 o generate and obtaining public key certificates;
3395 o distribute keys to intended users; and
3396 o deal with compromised keys.
3397 • Keep logs for key management activities like:
3398 o key generation;
3399 o keys destruction; and
3400 o key archiving;
3401 • Ensure the protection of cryptographic keys against modification and loss.
3402 • Ensure the protection of secret and private keys against unauthorized use and disclosure.
3403 • Ensure the authenticity of public keys.
3404 • Physically protect equipment used to generate, store and archive keys
3405 • Limit the use of ad hoc cryptographic processes.
3406 • Consider, where appropriate, a cryptographic agility approach54. Key features of this approach are:
3407 o Flexibility in algorithm selection.
3408 o Modular design of the architecture where cryptographic components can be changed or updated
3409 independently without impacting the entire system.
3410 o Regular updates and patching.
3411 o Compliance with the legislative frameworks as well as governance of the use of the cryptography
3412 within the entity’s networks and information systems.
3413 o Future proofing by considering quantum cryptographic algorithms.

3414 EXAMPLES OF EVIDENCES

3415 • Documented policy on cryptography which is in line with relevant regulations and state of the art standards.
3416 • Documented guidelines for encryption.

54
Crypto-agility, or cryptographic 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 crypto-agility by
allowing the use of different cryptographic parameters, such as key types and hash algorithms.

105
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3417 • Acceptable, in line with the state of the art, encryption algorithms, key lengths, protocols 55 or family of
3418 protocols56.
3419 • Safeguards to protect the secrecy of secret (private) key(s) are in place
3420 • Evidence for the existence of cryptographic mechanisms which support in ensuring confidentiality and
3421 integrity of the data at rest as well as in transit.
3422 • Evidence of the existence of a mechanism (either manual or automated) for the establishment and
3423 management of cryptographic keys.
3424 • Evidence of encryption implementation on various systems (e.g., databases, files, communications).
3425 • Access control mechanisms for cryptographic keys and encrypted data.
3426 • Verification that access is restricted to authorized personnel and that actions related to cryptographic keys
3427 are logged and monitored.
3428 • Assessments of cryptographic measures for protecting data privacy.
3429 • Evidence of secure key generation.
3430 • Internal or external audit reports focusing on cryptographic measures.
3431 • Evidence that the entity follows cryptographic best practices, including documentation of how new best
3432 practices are identified and incorporated.
3433

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

3436 GUIDANCE

3437 • Ensure the cryptography policy aligns with relevant industry standards and with the advancements in the
3438 field.
3439 • Review the cryptography policy and procedures at least annually.
3440 • Maintain a procedure that specifies how reviews of the cryptography policy and procedures are conducted,
3441 including responsible personnel and review intervals.
3442 • Ensure that changes to the cryptographic measures are tested before applied.
3443 • Ensure that changes to the cryptographic measures are communicated to employees.

3444 EXAMPLES OF EVIDENCES

3445 • Logs of changes made to the cryptography policy and procedures

3446 • Test plans and results that demonstrate the implementation and effectiveness of updated cryptographic
3447 measures.
3448 • Records of notifications or reminders sent to relevant personnel about upcoming reviews of the
3449 cryptography policy and procedures.
3450 • Communication records informing personnel about updates to the cryptography policy following
3451 advancements in the field or significant changes.

55
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 SSL/TLS and SSH.
56
A family of cryptographic protocols refers to 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.

106
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3452 • Evidence that the entity remains up to date with the last developments in cryptography (e.g. member of
3453 cryptographic bodies or consortia (e.g., IETF, Cryptographic Research Groups), subscriptions to
3454 cryptographic journals/feeds, mailing lists, or news feeds).
3455

3456 TIPS

3457 GUIDANCE

3458 • Train employees and make them aware of the use of cryptographic measures in the entity.
3459 • Make sure network and information systems automatically encrypt and secure all portable and removable
3460 media.

3461 EXAMPLES OF EVIDENCES

3462 • Records of training programs related to cryptography for employees.

3463 • Employees are aware of the confidentiality and integrity of the data and communications and procedures
3464 and what it implies for their work.
3465 • Employees handling sensitive information are aware of and understand the cryptography policies and
3466 procedures.
3467

3468 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.5.31, A.8.24 BE-CyFun®2023 IMPORTANT: [Link]-6.1

ESSENTIAL: [Link]-3.4, [Link]-8.1

NIST CSF v2.0 [Link]-01, [Link]-02, [Link]- FI-Kybermittari ARCHITECTURE-5
01, [Link]-02, [Link]-03,
[Link]-04
ETSI EN 319 401 Clause 7.5, ref. to clause 10 EL – Ministerial Cybersecurity Handbook: Part B: 5.5,
of ISO/IEC 27002:2013 decision 6.22, 9.10, 9.16, 11.1, 11.2, 11.3,
1027/2019 - 11.4, 11.5, 11.6, 11.7, 11.8
Article 4 - Self-assessment tool: 6.7, 10.7, 12.1,
paragraph 11 12.2, 12.3, 12.4, 12.5, 12.6, 12.7
CEN/TS 18026:2024 ISP-02, CKM-01, CKM-02, ES-Royal Decree Annex II: 4.3.10, 5.5.2
CKM-03, CKM-04 311/2022

3469

107
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3470 10. HUMAN RESOURCES

3471 SECURITY

3472 10.1 HUMAN RESOURCES SECURITY

3473 10.1.1. For the purpose of Article 21(2), point (i) of Directive (EU) 2022/2555, the relevant entities shall ensure that their
3474 employees and direct suppliers and service providers, wherever applicable, understand, demonstrate and commit to
3475 their security responsibilities, as appropriate for the offered services and the job and in line with the relevant entities’
3476 policy on the security of network and information systems.

3477 EXAMPLES OF EVIDENCES

3478 • List of employees and their assignment to roles.

3479 • Documented evidence of regular training sessions on security of network and information systems for
3480 employees, direct suppliers, and service providers, wherever applicable. This includes attendance
3481 records, training materials, and feedback forms.
3482 • Signed acknowledgements from employees, direct suppliers, and service providers, wherever applicable,
3483 confirming they have read, understood, and agreed to comply with policy.
3484 • Reports from internal or external audits assessing the understanding and implementation of security
3485 responsibilities among employees, direct suppliers and service providers, wherever applicable.
3486 • Inclusion of security responsibilities in employee performance reviews and evaluations.
3487 • Contracts with direct suppliers and service providers that include clauses on security responsibilities and
3488 compliance with the entity’s policies.
3489 • Certifications or attestations from recognized bodies confirming adherence to security standards and
3490 policies.
3491

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

3501 GUIDANCE

3502 • Implement regular awareness raising on cyber hygiene practices for users, tailored to different roles and
3503 responsibilities (Annex to the Regulation, point 8.1).
3504 • Communicate clear and concise cyber hygiene practices for users to all employees, suppliers, and service
3505 providers. Require acknowledgement of receipt and understanding (Annex to the Regulation, point 8.1).

108
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3506 • Provide specialised training for users with administrative or privileged access, focusing on their specific
3507 responsibilities (Annex to the Regulation, point 8.2).
3508 • Establish performance metrics related to security responsibilities and include them in management
3509 evaluations.
3510 • Hold regular briefings for members of management bodies on the importance of network and information
3511 system security, their specific responsibilities, and the potential impact of incidents (Annex to the
3512 Regulation, point 8.2).
3513 • Conduct thorough reference checks to verify the candidate’s previous experience and performance in
3514 similar roles.
3515 • Implement vetting procedures, including background checks (Annex to the Regulation, point 10.2), to
3516 ensure the candidate’s suitability for the role.
3517 • Validate any relevant certifications claimed by the candidate to ensure they are current and legitimate.
3518 • Use written tests or practical assessments to evaluate the candidate’s knowledge and skills related to
3519 network and information system security.
3520 • Use interview panels that include security experts to assess the candidate’s technical and behavioural
3521 competencies.
3522 EXAMPLES OF EVIDENCES

3523 • Training and awareness raising material such as videos, slides, emails, newsletters, posters and intranet
3524 announcements.
3525 • Documented records that all users with administrative or privileged access were properly informed and
3526 are aware of and are following their network and information security roles, responsibilities, and authorities
3527 .
3528 • Contractual agreements, policy on the security of network and information systems, terms and conditions,
3529 code of conduct, other documentation confirming that all users have understood and are following the
3530 standard cyber hygiene practices for users(signed employment contracts, any proof of informing
3531 employees about their responsibilities having to do with network and information security).
3532 • Records of security training sessions provided to employees, including attendance logs and training
3533 schedules.
3534 • Evidence, e.g attendance certificates, that suppliers and service providers receive security training
3535 relevant to their roles.
3536 • Mechanisms for hiring qualified personnel (e.g. reference check, validation of certifications, written tests)
3537 are in place.
3538

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

3542 GUIDANCE

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

3545 EXAMPLES OF EVIDENCES

3546 • Up to date list employees and their assignment to roles.

3547 • Records of the review process, including the criteria used, the findings, and any changes made.

109
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3548
3549 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 7.1, 7.2, A.6.2, A.6.3 BE-CyFun®2023 BASIC: [Link]-1.1, [Link]-1.1, [Link]-
4.3, [Link]-11.1
IMPORTANT: [Link]-6.1, [Link]-1.2,
[Link]-3.1, [Link]-2.2, [Link]-4.6,
[Link]-11.2, [Link]-6.2
ESSENTIAL: [Link]-1.2, [Link]-3.2,
[Link]-3.3
NIST CSF v2.0 [Link]-02, [Link]-04, [Link]- FI-Kybermittari WORKFORCE-1, WORKFORCE-2,
01, [Link]-02, [Link]-03, WORKFORCE-3, THIRD-PARTIES-1,
[Link]-04 THIRD-PARTIES-2, Management
activities
ETSI EN 319 401 REQ-7.2 EL – Ministerial
decision
1027/2019 -
CEN/TS 18026:2024 HR-01, HR-02, HR-03 ES-Royal Decree Article 15, Annex II: 5.2
311/2022
3550

3551

3552 10.2 VERIFICATION OF BACKGROUND

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

3556 GUIDANCE

3557 • Identify which roles, responsibilities and authorities require verification of background, based on the criteria
3558 in 10.2.2(a).
3559 • Perform verification of background of employees, and where applicable of direct suppliers and service
3560 providers in accordance with point 5.1.4.

3561 EXAMPLES OF EVIDENCES

3562 • Documented background verification process.

3563 • Results of verification of background of employees, and where applicable of direct suppliers and service
3564 providers in accordance with point 5.1.4.
3565

3566

110
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

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

3574 GUIDANCE

3575 • Define criteria for roles, responsibilities and authorities which will be exercised only by persons who have
3576 undergone background verification. An indicative, non-exhaustive list is the following:
3577 o Executives and senior management.
3578 o Roles with access to sensitive information.
3579 o Roles with financial responsibilities.
3580 o Roles involved with procurement and vendor management.
3581 o Roles that grant access to physical assets or responsible for physical security.
3582 • Define criteria and limitations for verification of background (e.g. who is eligible to screen people and how,
3583 when and why verification reviews are carried out).
3584 • Include in the verification of background, a check of the criminal records of the person concerned with
3585 regards to offences which would be relevant for a specific position.
3586 • Collect and handle information on job candidates taking into consideration any applicable law, regulations,
3587 and ethics, including the protection of personal data. This may include the collection of professional
3588 references.
3589 • Include screening requirements in the contractual agreements between the entity and the direct suppliers
3590 and service providers, in case of personnel contracted with an external supplier.
3591 • Periodically repeat verification in order to confirm ongoing suitability of personnel, depending on the
3592 criticality of a person’s role, responsibilities and authorities.

3593 EXAMPLES OF EVIDENCES

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

3606

111
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

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

3609 GUIDANCE

3610 • Review and update, where necessary, procedure for verification of background at least annually.

3611 EXAMPLES OF EVIDENCES

3612 • Records of periodic or continuous verification of background for roles requiring ongoing clearance.
3613 • Review comments or change logs of the procedure.
3614

3615
3616 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 A.6.1 BE-CyFun®2023 BASIC: [Link]-11.1
IMPORTANT: [Link]-11.2

NIST VSF v2.0 [Link]-04, [Link]-01, [Link]- FI-Kybermittari WORKFORCE-1

02, [Link]-03, [Link]-04
ETSI EN 319 401 REQ-7.2-10 EL – Ministerial
decision
1027/2019 -
CEN/TS 18026:2024 HR-02 ES-Royal Decree -
311/2022
3617

3618

3619 10.3 TERMINATION OR CHANGE OF EMPLOYMENT PROCEDURES

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

3622 GUIDANCE

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

3625 EXAMPLES OF EVIDENCES

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

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

3632 GUIDANCE

3633 • Ensure these clauses cover the protection of confidential information, return of company property, and
3634 restrictions on accessing the entity’s network and information systems.
3635 • Timely revoke access to network and information systems upon termination or role change.
3636 • Identify and document all assets to be returned upon termination or change of employment.

112
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3637 • After a change of employment, brief and inform personnel on the procedures in place.

3638 EXAMPLES OF EVIDENCES

3639 • Records confirming the timely return of entity’s assets.

3640 • Records confirming the timely revocation of access rights.
3641 • Copies of written notifications to the employee about the termination or change in employment status.
3642

3643 TIPS

3644 GUIDANCE

3645 • Identify and transfer to another individual network and information security roles and responsibilities held
3646 by any individual who leaves the organisation.
3647 • Conduct thorough exit interviews to remind departing employees of their ongoing security responsibilities.
3648 Use this opportunity to collect company property and revoke access to systems.
3649 • Monitor for any unauthorized access attempts by former employees. Use security tools to detect and
3650 respond to suspicious activities. Maintain logs of access attempts and investigate any anomalies.
3651 • Regularly review and update policies related to post-employment security responsibilities to ensure they
3652 remain effective and aligned with current legal and regulatory requirements. Maintain the history of
3653 changes in order to ensure that it remains effective.
3654 • Take into account changes or past incidents when reviewing the process
3655 • Involve legal and HR departments in the review process to ensure comprehensive coverage.

3656 EXAMPLES OF EVIDENCES

3657 • Records of all contractual agreements, NDAs, exit interviews, access revocations, and any legal actions
3658 taken.
3659 • Documentation showing that the process is reviewed regularly and updated as necessary.
3660 • Evidence that the employee’s access to the entity’s systems and facilities has been revoked or altered
3661 according to a process.
3662 • Documentation of process for personnel changes, including, responsibilities for managing changes,
3663 description of rights of access and possession of assets per role, procedures for briefing and training
3664 personnel in new roles (e.g. standardized checklists used during the termination process to ensure all
3665 necessary steps are taken).
3666

3667
3668

113
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3669 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.6.5 BE-CyFun®2023 BASIC: [Link]-3.1, [Link]-4.3, [Link]-
11.1
IMPORTANT: [Link]-11.2

NIST CSF v2.0 [Link]-04 FI-Kybermittari WORKFORCE-1, ACCESS-1, ACCESS-2,

ACCESS-3
ETSI EN 319 401 EL – Ministerial
decision
1027/2019 -
CEN/TS 18026:2024 HR-05, HR-06 ES-Royal Decree Annex II: 3.2
311/2022
3670

3671

3672 10.4 DISCIPLINARY PROCESS

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

3676 GUIDANCE

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

3684 EXAMPLES OF EVIDENCES

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

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

3697 GUIDANCE

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

114
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3700 EXAMPLES OF EVIDENCES

3701 • Review and update records showing that the disciplinary process is reviewed regularly and updated as
3702 necessary.
3703

3704 TIPS

3705 GUIDANCE

3706 • Include the disciplinary process for handling violations of network and information system security policies
3707 in the overall disciplinary process of the entity, if available.
3708 • Recognize that deliberate violations of the policy on the security of network and information systems may
3709 require immediate actions.
3710 • Do not initiate the disciplinary process without verifying that a violation of network and information system
3711 security policies has occurred.
3712 • Consider the following factors for the process:
3713 a) the nature (who, what, when, how) and gravity of the violation and its consequences;
3714 b) whether the offence was intentional (malicious) or unintentional (accidental);
3715 c) whether or not this is a first or repeated offence;
3716 d) whether or not the employee that did the violation was properly trained.
3717 • Use the process as deterrent to prevent employees from violating the network and information system
3718 security policies.
3719 • Reward individuals who demonstrate excellent behaviour regarding network and information security as a
3720 means to promote and encourage good behaviour.

3721 EXAMPLES OF EVIDENCES

3722 • Disciplinary process documentation which outlines the types of violations which may be subject to
3723 disciplinary actions, and which steps to be taken when a violation occurs.
3724

3725
3726 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 5.28, A.6.4 BE-CyFun®2023 BASIC: [Link]-3.1
IMPORTANT: [Link]-3.2

NIST CSF v2.0 [Link]-01, [Link]-02, [Link]- FI-Kybermittari WORKFORCE-1

03, [Link]-04
ETSI EN 319 401 REQ-7.2-05 EL – Ministerial
decision
1027/2019 -
CEN/TS 18026:2024 HR-01 ES-Royal Decree Annex II: 3.2
311/2022

3727

115
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3728 11. ACCESS CONTROL

3729 11.1 ACCESS CONTROL POLICY

3730 11.1.1. For the purpose of Article 21(2), point (i) of Directive (EU) 2022/2555, the relevant entities shall establish,
3731 document and implement logical and physical access control policies for the access to their network and information
3732 systems, based on business requirements as well as network and information system security requirements.

3733 GUIDANCE

3734 • Implement and maintain logical and physical access restrictions to network and information system
3735 based on access-control policies.

3736 EXAMPLES OF EVIDENCES

3737 • Access control policy document or documents which outline the access control requirements, procedures,
3738 and responsibilities.
3739

3740 11.1.2. The policies referred to in point 11.1.1. shall:

3741 (a) address access by persons, including staff, visitors, and external entities such as suppliers and service providers;
3742 (b) address access by network and information system processes;
3743 (c) ensure that access is only granted to users that have been adequately authenticated.

3744 GUIDANCE

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

3761 EXAMPLES OF EVIDENCES

3762 • Access control policy document which outlines the access control requirements, procedures, and
3763 responsibilities.
3764 • User access lists showing the list of users and their corresponding access levels to various network and
3765 information systems.

116
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3766 • Authentication protocols, meaning documentation of the authentication methods in place, such as multi-
3767 factor authentication.
3768 • Authorization mechanisms with details how permissions are granted, reviewed, and revoked, ensuring
3769 that access rights are in line with roles, responsibilities and authorities of users.
3770 • Access logs that record user access activities, which can be used to track and audit user behaviour within
3771 the system.
3772 • Access rights review records showing alignment with asset classifications.
3773 • Records of access control assessments that align access rights with physical security requirements.
3774 • Network diagrams showing access control measures for different connection types, network access
3775 control policies.
3776 • Logs showing dynamic access control decisions based on user behaviour or environment factors
3777

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

3780 GUIDANCE

3781 • Review the policies at least annually.

3782 EXAMPLES OF EVIDENCES

3783 • Past incident reports with records of any security incidents related to access control, including
3784 unauthorized access attempts and the responses to such events.
3785 • Change management records of any changes made to access rights, showing adherence to the policy
3786 during modifications.
3787 • Review and update records showing that the policies are reviewed regularly and updated as necessary.
3788 • Reports from internal or external audits that assess the effectiveness and compliance of the access control
3789 policy.
3790

3791 TIPS

3792 GUIDANCE

3793 • Consider the two most frequently overarching principles used in the context of access control:
3794 o need-to-know: an entity is only granted access to the information which the that entity requires in
3795 order to perform its tasks (different tasks or roles mean different need-to-know information and
3796 hence different access profiles);
3797 o need-to-use: an entity is only assigned access to information technology infrastructure where a
3798 clear need is present.
3799 • Consider the following when specifying access control rules:
3800 o establishing rules based on the premise of least privilege “(“Everything is generally forbidden
3801 unless expressly permitted””) rather than the weaker rule “(“Everything is generally permitted
3802 unless expressly forbidden”;”);
3803 o changes in user permissions that are initiated automatically by the network and information
3804 system and those initiated by a system administrator;
3805 o when to define and regularly review the approval.

117
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3806 • Consider ways to implement access control, such as MAC (mandatory access control), DAC (discretionary
3807 access control), RBAC (role-based access control) and ABAC (attribute-based access control) depending
3808 on the business needs of the organisation.
3809 • Take into account that access control rules can also contain dynamic elements (e.g., a function that
3810 evaluates past accesses or specific environment values).

3811 EXAMPLES OF EVIDENCES

3812 • Access control policy document which outlines the access control requirements, procedures, and
3813 responsibilities.
3814 • Access reviews showing adherence to need-to-know and need-to-use principle.
3815 • Change management records of any changes made to access rights, showing adherence to the policy
3816 during modifications.
3817 • Access control system configurations showing adoption of MAC, DAC, RBAC, or ABAC depending on
3818 business needs.
3819

3820
3821 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 Α.5.15, A.7.2, Α.8.3, Α.8.21, BE-CyFun®2023 BASIC: [Link]-5.1, [Link]-1.1, [Link]-
A9 4.1, [Link]-11.1
IMPORTANT: [Link]-6.1, [Link]-1.2,
[Link]-2.2, [Link]-4.6, [Link]-5.4,
[Link]-6.1, [Link]-3.2, [Link]-3.3,
[Link]-5.1, [Link]-11.2, [Link]-2.1,
[Link]-3.2, [Link]-3.3, [Link]-6.1,
[Link]-7.1
ESSENTIAL: [Link]-1.1, [Link]-3.3,
[Link]-2.2
NIST CSF v2.0 [Link]-05, [Link]-01, [Link]- FI-Kybermittari ACCESS-1, ACCESS-2, ACCESS-3,
02, [Link]-03, [Link]-04 ACCESS-4, ARCHITECTURE-3
ETSI EN 319 401 REQ-7.4-04A, REQ-7.4-06, EL – Ministerial Cybersecurity Handbook: Part B: 4.1
REQ-7.4-10 decision
1027/2019 - Self-assessment tool: -
Article 4 -
paragraph 8
CEN/TS 18026:2024 OIS-02, ISP-02, IAM-01 ES-Royal Decree Article 17, Annex II: 4.2
311/2022
3822

3823

118
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3824 11.2 MANAGEMENT OF ACCESS RIGHTS

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

3835 GUIDANCE

3836 • Ensure each user has access only to information necessary for their role (‘need-to-know’).
3837 • Restrict user permissions to the minimum necessary for their duties (‘least privilege’). Regularly review
3838 and adjust access rights as needed.
3839 • Implement a segregation of duties matrix.
3840 • Establish and follow a process for requesting and approving access, preferably automated. The process
3841 should:
3842 o cover granting access rights to assets upon new hire or role change of a user.
3843 o obtain authorization from the owner of the asset. Separate approval for access rights by
3844 management bodies can also be appropriate.
3845 o ensure that access rights are activated (e.g. by service providers) only after authorization
3846 procedures are successfully completed.
3847 o consider the business requirements and the entity’s access control policy.
3848 o consider segregation of duties, including segregating the roles of approval and implementation
3849 of the access rights and separation of conflicting roles.
3850 o verify that the level of access granted is in accordance with access control policy and is consistent
3851 with other information security requirements such as segregation of duties.
3852 o consider giving temporary access rights for a limited time period and revoking them at the
3853 expiration date, in particular for temporary personnel or temporary access required by personnel.
3854 • Establish and follow a process, preferably automated, for revoking access to assets. The process should:
3855 o timely disable accounts upon termination, rights revocation, or role change of a user, as needed.
3856 Disabling accounts, instead of deleting accounts, may be necessary to preserve audit trails.
3857 o modify access rights of users who have changed roles or jobs.
3858 o remove or adjust access rights, which can be done by removal, revocation or replacement of
3859 keys, authentication information, identification cards or subscriptions.
3860 • Limit third-party access based on need and duration. Use temporary access accounts with expiry dates
3861 and regularly review third-party access rights.
3862 • Ensure third parties sign agreements acknowledging their access responsibilities and obligations.
3863 • Keep a detailed and up-to-date central record (register or database) of all granted access rights, including
3864 user names, roles, permissions, and dates of access changes.
3865 • Establish and maintain an inventory of the authentication and authorization systems, including those
3866 hosted on-site or at a remote service provider.

119
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3867 • Implement logging for all access rights management activities. Logs should include details of who granted
3868 or modified access, when, and what changes were made.

3869 EXAMPLES OF EVIDENCES

3870 • Clear definitions of user roles and their corresponding access rights.
3871 • A central record (register or database) detailing all granted access rights, including user names, roles,
3872 access levels, and dates of access changes.
3873 • Approved access request forms supporting entries in the access rights register.
3874 • Periodic access reviews meaning evidence of regular reviews of user access rights to ensure they remain
3875 appropriate over time.
3876 • System logs showing all access rights management activities (creation, modification, and deletion).
3877 • Audit trail logs demonstrating access rights management, including timestamps, user IDs, and actions
3878 performed.
3879 • Records of incidents related to access rights management, including unauthorized access attempts and
3880 corrective actions.
3881 • Evidence of systems enforcing access controls, such as Identity and Access Management (IAM) solutions.
3882 • Reports from internal or external compliance audits verifying alignment with the access control policy.
3883 • Physical inspection results of access control systems and their use, if applicable.
3884

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

3888 GUIDANCE

3889 • Regularly review physical and logical access rights taking into account:
3890 o users’ access rights after termination or change of employment;
3891 o authorisations for privileged access rights.
3892 • Review and update the inventory of the authentication and authorization systems regularly.
3893 • Perform access control reviews of assets to validate that all privileges are authorised, on a recurring
3894 schedule at a minimum annually, or more frequently.

3895 EXAMPLES OF EVIDENCES

3896 • A central record (register or database) detailing all granted access rights, including user names, roles,
3897 access levels, and dates of access changes.
3898 • Approved access request forms supporting entries in the access rights register.
3899 • Periodic access reviews meaning evidence of regular reviews of user access rights to ensure they remain
3900 appropriate over time.
3901 • System logs showing all access rights management activities (creation, modification, and deletion).
3902 • Audit trail logs demonstrating access rights management, including timestamps, user IDs, and actions
3903 performed.
3904 • Records of incidents related to access rights management, including unauthorized access attempts and
3905 corrective actions.
3906 • Reports from internal or external compliance audits verifying alignment with the access control policy.
3907 • Physical inspection results of access control systems and their use, if applicable.

120
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3908 • Review and update records showing that the access rights are reviewed regularly and updated as
3909 necessary.
3910

3911 TIPS

3912 GUIDANCE

3913 • Centralize access control for all assets through a directory service or SSO provider, where supported.

3914 EXAMPLES OF EVIDENCES

3915 • Evidence of a centralized directory service or SSO provider to manage access control, supported by
3916 documentation, logs, audit reports, and records.
3917

3918
3919 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 Α.5.18, A.9 BE-CyFun®2023 BASIC: [Link]-5.1, [Link]-1.1, [Link]-
1.1, [Link]-4.3, [Link]-11.1
IMPORTANT: [Link]-6.1, [Link]-1.2,
[Link]-2.2, [Link]-6.1, [Link]-3.2,
[Link]-5.1, [Link]-11.2, [Link]-2.1,
[Link]-6.1, [Link]-7.1
ESSENTIAL: [Link]-1.1
NIST CSF v2.0 [Link]-05, [Link]-01, [Link]- FI-Kybermittari ACCESS-1, ACCESS-2, ACCESS-3,
02, [Link]-03, [Link]-04 ACCESS-4, ARCHITECTURE-3,
WORKFORCE-1, SITUATION-1,
SITUATION-2
ETSI EN 319 401 REQ-7.4-05 EL – Ministerial Cybersecurity Handbook: Part B: 4.3,
decision 4.6, 4.7, 4.8, 2.11, 2.14, 9.9
1027/2019 - Self-assessment tool: 5.3, 5.4, 5.5,
Article 4 - 5.6, 5.7, 5.8, 5.9, 5.13, 5.14
paragraph 8
CEN/TS 18026:2024 OIS-02, IAM-04, IAM-05, ES-Royal Decree Article 20, Annex II: 4.2.1, 4.2.2,
PSS-03, HR-05 311/2022 4.2.3, 4.2.4, 4.2.5, 4.2.6
3920

3921

3922 11.3 PRIVILEGED ACCOUNTS AND SYSTEM ADMINISTRATION ACCOUNTS

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

3925 GUIDANCE

3926 • Allocate privileged access rights to users as needed and, on an event-by-event basis in line access control
3927 policy referred to in point 11.1 (i.e., only to individuals with the necessary competence to carry out activities
3928 that require privileged access and based on the minimum requirement for their functional roles).
3929 • Identify users who need privileged access57 to a network and information system (e.g., operating systems,
3930 database management systems and applications).

57
“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.

121
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3931 • Maintain an authorization process and a record of all allocated privileged access rights, which is consistent
3932 with the process for granting and revoking access rights (Annex to the Regulation, point 11.2.2).
3933

3934 11.3.2. The policies referred to in point 11.3.1. shall:

3935 (a) establish strong identification, authentication such as multi-factor authentication, and authorisation procedures for
3936 privileged accounts and system administration accounts;
3937 (b) set up specific accounts to be used for system administration operations exclusively, such as installation,
3938 configuration, management or maintenance;
3939 (c) individualise and restrict system administration privileges to the highest extent possible,
3940 (d) provide that system administration accounts are only used to connect to system administration systems.

3941 GUIDANCE

3942 • Introduce higher authentication requirements for privileged access rights, such as re-authentication or
3943 authentication step-up before using privileged access rights.
3944 • Define and implement expiry requirements for privileged access rights.
3945 • Establish specific rules to avoid the use of generic administration user IDs (such as “root”) and manage
3946 and protect authentication information of such identities.
3947 • Grant temporary privileged access only for the necessary time to implement approved changes or activities
3948 (e.g. for maintenance activities), rather than permanently granting privileged access rights.
3949 o Consider the frequency of the system administration operations: daily tasks (e.g., backups, email
3950 routing) versus weekly or monthly tasks (e.g., reviewing memory and disk space).
3951 • Log all privileged access for audit purposes;
3952 • Assign separate identities with privileged access rights to individual users, rather than sharing or linking
3953 identities. Group identities for easier management if needed.
3954 • Use identities with privileged access rights exclusively for administrative tasks, not for day-to-day general
3955 tasks like checking email or accessing the web. Use separate user identities for these activities.
3956 • Ensure users are aware of their privileged access rights or when they are in privileged access mode, e.g.
3957 using specific user identities, user interface settings or specific equipment.
3958 EXAMPLES OF EVIDENCES
3959 • Measures for privileged access control and monitoring for privileged accounts, including the granting and
3960 revoking of privileged access rights.
3961 • Access assignment records showing how access rights are initially granted, based on job roles and
3962 responsibilities.
3963 • Clear definitions of user roles and the corresponding access rights associated with each role.
3964 • Audit trail and monitoring logs that capture the use of access rights, including any unauthorized access
3965 attempts and actions taken in response.
3966

3967

122
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

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

3971 GUIDANCE

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

3974 EXAMPLES OF EVIDENCES

3975 • Review and update records showing that the access rights are reviewed regularly and updated as
3976 necessary.
3977 • Periodic access reviews meaning evidence of regular reviews of user access rights to ensure they remain
3978 appropriate over time.
3979 • Change management logs of changes to access rights, reflecting any alterations due to role changes or
3980 termination of employment.
3981 • Compliance audits with reports from internal or external audits that verify the management of access rights
3982 aligns with the policy and regulatory requirements.
3983
3984

3985 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 Α.8.2, A.8.18, A.9 BE-CyFun®2023 BASIC: [Link]-1.1, [Link]-4.3
IMPORTANT: [Link]-4.7, [Link]-2.1
ESSENTIAL: [Link]-4.9
NIST CSF v2.0 [Link]-01, [Link]-02, [Link]- FI-Kybermittari ACCESS-1, ACCESS-2, ACCESS-3,
03, [Link]-04 ACCESS-4, ARCHITECTURE-3
ETSI EN 319 401 REQ-7.4-07 EL – Ministerial Cybersecurity Handbook: Part B: 4.4,
decision 4.5, 4.7
1027/2019 - Self-assessment tool: 5.10, 5.11,
Article 4 - 5.12, 5.13
paragraph 8

CEN/TS 18026:2024 ISP-02, IAM-05, IAM-06 ES-Royal Decree -

311/2022
3986

3987

123
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

3988 11.4 ADMINISTRATION SYSTEMS

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

3991 EXAMPLES OF EVIDENCES

3992 • Regularly maintained logs that track access to system administration systems58.
3993 • Audit reports from internal or external security audits that assess compliance with the policy.
3994

3995 11.4.2. For that purpose, the relevant entities shall:

3996 (a) only use system administration systems for system administration purposes, and not for any other operations;
3997 (b) separate logically such systems from application software not used for system administrative purposes,
3998 (c) protect access to system administration systems through authentication and encryption.

3999 GUIDANCE

4000 • Implement strict access controls to ensure that administrative systems are used exclusively for their
4001 intended purpose. For instance, allow access to system administration systems only to authorised
4002 personnel with specific roles (e.g., system administrators, IT staff).
4003 • Physically or logically isolate administrative systems from other application servers, e,g, use network
4004 segmentation to create separate zones for system administration systems and other systems, e.g.
4005 application servers. If applicable, physically inspect server racks to ensure separation.
4006 • Require strong authentication mechanisms such as multi-factor authentication (MFA) for accessing
4007 system administration systems.
4008 • Encrypt communication channels (e.g., SSH, HTTPS) to protect data in transit to and from system
4009 administration systems.
4010 • Encrypt sensitive configuration files and credentials stored on system administration systems.

4011 EXAMPLES OF EVIDENCES

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

4019 TIPS

4020 GUIDANCE

4021 • Regularly audit system logs to monitor usage patterns and identify any unauthorised activities.
4022 • Train personnel on the on the proper use of system administration systems

4023 EXAMPLES OF EVIDENCES

4024 • Regularly maintained logs that track access to administration systems.

58
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): a) system monitoring, b)
configuration management, c) security management, d) user management and e) back-up and recovery.

124
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4025 • Incident response records of any incidents related to system administration system misuse or
4026 unauthorized access.
4027 • User training records meaning evidence that personnel have been trained on the proper use of system
4028 administration systems, e.g. training materials, attendance records, or completion certificates.
4029
4030
4031 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 Α.8.2, A.8.18 BE-CyFun®2023 BASIC: [Link]-4.4
IMPORTANT: [Link]-5.4

NIST CSF v2.0 FI-Kybermittari ACCESS-1, ACCESS-2, ACCESS-3,

ACCESS-4, ARCHITECTURE-2,
ARCHITECTURE-3, ARCHITECTURE-5
ETSI EN 319 401 REQ-7.4-07 EL – Ministerial Cybersecurity Handbook: -
decision
1027/2019 - Self-assessment tool: -
Article 4 -
paragraph 8
CEN/TS 18026:2024 OIS-02, IAM-06, IAM-09 ES-Royal Decree -
311/2022
4032

4033

4034 11.5 IDENTIFICATION

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

4037 GUIDANCE

4038 • Establish and maintain an inventory of all identities managed in the entity.
4039 o The inventory should include both user and privileged or system administrator identities. The
4040 inventory, at a minimum, should contain the person’s name, username, start/stop dates, the
4041 department and the level of privileges for each identity.
4042 o Establish and maintain an inventory of service identities. The inventory, at a minimum, should
4043 contain department owner, review date, and purpose.

4044 EXAMPLES OF EVIDENCES

4045 • Documented policy or procedure related to identity management, if available.

4046 • Reports from internal or external audits that verify the management of identities aligns with the policy and
4047 regulatory requirements.
4048

4049

125
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4050 11.5.2. For that purpose, the relevant entities shall:

4051 (a) set up unique identities for network and information systems and their users;
4052 (b) link the identity of users to a single person;
4053 (c) ensure oversight of identities of network and information systems;
4054 (d) apply logging to the management of identities.

4055 GUIDANCE

4056 • Consider that providing or revoking access to assets is usually a multi-step procedure:
4057 o confirming the business requirements for an identity to be established;
4058 o verifying the identity of an entity before allocating them a logical identity;
4059 o establishing an identity;
4060 o configuring and activating the identity. This also includes also configuration and initial setup of
4061 related authentication services; and
4062 o providing or revoking specific access rights to the identity, based on appropriate authorization or
4063 entitlement decisions (see Annex to the Regulation, point 11.2).
4064 • Make sure that identities assigned to network and information systems (non-human users) are subject to
4065 appropriately segregated approval and independent ongoing oversight.

4066 EXAMPLES OF EVIDENCES

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

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

4078 EXAMPLES OF EVIDENCES

4079 • Approval records for exceptions.

4080

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

4083 GUIDANCE

4084 • Validate that all active identities are authorised, on a recurring schedule at minimum quarterly, or more
4085 frequently.
4086 • Disable or remove, in a timely fashion, identities which they are no longer required, e.g. delete or disable
4087 any dormant identities after a predefined period of days of inactivity, where supported.

4088 EXAMPLES OF EVIDENCES

4089 • Review and update records showing that the identities are reviewed regularly and updated as necessary.

126
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4090 • Records of changes to identities, reflecting any alterations due to role changes or termination of
4091 employment or inactivity.
4092

4093 TIPS

4094 GUIDANCE

4095 • Centralize identity management through a directory or identity service.

4096 EXAMPLES OF EVIDENCES

4097 • Evidence of the systems in place, such as Identity and Access Management (IAM) solutions.
4098
4099
4100 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 Α.5.16 BE-CyFun®2023 BASIC: [Link]-1.1, [Link]-4.1
IMPORTANT: [Link]-1.2, [Link]-3.3,
[Link]-4.5, [Link]-4.7, [Link]-6.1
ESSENTIAL: [Link]-4.9, [Link]-6.2
NIST CSF v2.0 [Link]-01, [Link]-05, [Link]- FI-Kybermittari ACCESS-1
02
ETSI EN 319 401 REQ-7.4-08 EL – Ministerial Cybersecurity Handbook: Part B: 4.2,
decision 4.3, 4.7
1027/2019 - Self-assessment tool: 5.2, 5.6, 5.7,
Article 4 - 5.13
paragraph 8
CEN/TS 18026:2024 IAM-02, IAM-03, IAM-06 ES-Royal Decree Article 20, Annex II: 4.2.1, 4.2.2,
311/2022 4.2.3, 4.2.4, 4.2.5, 4.2.6, 5.1.2
4101

4102

4103 11.6 AUTHENTICATION

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

4106 GUIDANCE

4107 • Authentication technologies are methods used to verify the identity of users, devices, or systems before
4108 granting access to resources. Here are some common authentication technologies (indicative, non-exhaustive
4109 list):
4110 o Password-Based Authentication.
4111 o Two-Factor Authentication (2FA).
4112 o Multi-Factor Authentication (MFA).
4113 o Biometric Authentication.
4114 o Token-Based Authentication, e.g one-time passcode (OTP).
4115 o Certificate-Based Authentication.
4116 o Single Sign-On (SSO).
4117 o OAuth: An open standard for access delegation, commonly used for token-based authentication and
4118 authorization.

127
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4119 EXAMPLES OF EVIDENCES

4120 • Access control policy documents outlining secure authentication procedures and technologies.
4121 • Logs from authentication systems showing successful and failed authentication attempts, which
4122 demonstrate secure implementation.
4123 • Evidence of the systems in place that enforce access controls, such as Identity and Access Management
4124 (IAM) solutions.
4125 • Internal or external audit reports verifying the implementation of secure authentication procedures aligned
4126 with the access control policy.
4127

4128 11.6.2. For that purpose, the relevant entities shall:

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

4138 GUIDANCE

4139 • Use unique authentication credentials for all entity’s assets. Best practice implementation includes, at a
4140 minimum, an 8-character password for accounts using MFA and a 14-character password for accounts not
4141 using MFA.
4142 • Consider that the allocation and management process of authentication information should ensure that:
4143 o passwords or PINs generated automatically during enrolment processes as temporary secret
4144 authentication information are non-guessable and unique for each user; and that users are required
4145 to change them after the first use;
4146 o procedures are established to verify the identity of a user prior to providing new, replacement or
4147 temporary authentication information;
4148 o authentication information, including temporary authentication information, is transmitted to users in
4149 a secure manner (e.g. over an authenticated and protected channel); the use of unprotected (clear
4150 text) electronic mail messages is avoided;
4151 o users acknowledge receipt of authentication information;
4152 o default authentication information as predefined or provided by suppliers is changed immediately
4153 following installation of systems or software;
4154 o records of significant events concerning allocation and management of authentication information
4155 are kept and their confidentiality granted; and that the record -keeping method is approved (e.g.
4156 using an approved password vault tool).
4157 • When passwords are used as authentication information, the password management system should:
4158 o allow users to select and change their own passwords and include a confirmation procedure to
4159 address input errors;
4160 o enforce strong passwords
4161 o force users to change their passwords at first login;

128
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4162 o enforce password changes as necessary, for example after a security incident, or upon termination
4163 or change of employment when a user has known passwords for identities that remain active (e.g.
4164 shared identities);
4165 o prevent re-use of previous passwords;
4166 o prevent the use of commonly -used passwords and compromised usernames, password
4167 combinations from hacked systems;
4168 o not display passwords on the screen when being entered; and
4169 o store and transmit passwords in protected form.
4170 • Perform password encryption and hashing according to approved cryptographic techniques for passwords.
4171 • Generate an alert when a potential attempted or successful breach of log-on controls is detected.

4172 EXAMPLES OF EVIDENCES

4173 • Logs or reports related to authentication.

4174 • Compliance audits from internal or external audits that verify the management of identities aligns with the
4175 policy and regulatory requirements.
4176 • Documentation showing that the identities are reviewed regularly and updated as necessary.
4177 • Records of changes to identities, reflecting any alterations due to role changes or termination of
4178 employment.
4179

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

4182 GUIDANCE

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

4188 EXAMPLES OF EVIDENCES

4189 • Access control policy documents outlining secure authentication procedures and technologies.
4190

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

4192 GUIDANCE

4193 • Conduct periodic audits of authentication procedures and technologies to ensure they remain state-of-the-
4194 art and effective against emerging threats.
4195 • Stay updated on advancements in authentication technology and integrate new methods as they become
4196 available.

4197 EXAMPLES OF EVIDENCES

4198 • Internal or external audit reports detailing the results of periodic audits on authentication procedures and
4199 technologies.
4200 • Logs showing the implementation of new authentication technologies and methods as they become
4201 available

129
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4202 TIPS

4203 GUIDANCE

4204 • Advise any user with access to or using authentication information for the following:
4205 o secret authentication information such as passwords are kept confidential. Personal secret
4206 authentication information is not to be shared with anyone. Secret authentication information used in
4207 the context of identities linked to multiple users or linked to non-personal entities are solely shared
4208 with authorized persons;
4209 o affected or compromised authentication information is changed immediately upon notification of or
4210 any other indication of a compromise;
4211 o when passwords are used as authentication information, strong passwords according to best
4212 practices recommendations are selected, for example: passwords are not based on anything
4213 somebody else can easily guess or obtain using person-related information (e.g. names, telephone
4214 numbers and dates of birth); passwords are not based on dictionary words or combinations thereof;
4215 use easy to remember passphrases and try to include alphanumerical and special characters;
4216 passwords have a minimum length;
4217 o the same credentials are not used across distinct network and information systems; and
4218 o the obligation to follow these rules are also included in terms and conditions of employment.

4219 EXAMPLES OF EVIDENCES

4220 • Documentation of training sessions for employees on secure authentication practices and technologies.
4221 • Records of awareness programs or communications to employees about the importance of secure
4222 authentication.

4223

4224 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 Α.5.17 BE-CyFun®2023 BASIC: [Link]-3.2
IMPORTANT: [Link]-1.2, [Link]-1.4,
[Link]-2.2
ESSENTIAL: [Link]-6.2
NISTCSF v2.0 [Link]-05, [Link]-03, [Link]- FI-Kybermittari ACCESS-1, ACCESS-2, ACCESS-3,
01, [Link]-02, [Link]-03, ACCESS-4, ARCHITECTURE-2,
[Link]-04 ARCHITECTURE-3, ARCHITECTURE-5
ETSI EN 319 401 REQ-7.4-08 EL – Ministerial Cybersecurity Handbook: Part B: 5.1,
decision 5.2, 5.3, 5.4, 5.5, 5.8, 5.10
1027/2019 - Self-assessment tool: 6.1, 6.2, 6.6,
Article 4 - 6.7, 6.8, 6.10
paragraph 8
CEN/TS 18026:2024 IAM-07, IAM-08 ES-Royal Decree Article 20, Annex II: 4.2.1, 4.2.2,
311/2022 4.2.3, 4.2.4, 4.2.5, 4.2.6
4225

4226

130
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4227 11.7 MULTI-FACTOR AUTHENTICATION

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

4231 GUIDANCE

4232 • Select appropriate MFA methods based on the entity’s security needs and user convenience:
4233 o SMS-based OTP (One-Time Password): Simple but less secure due to risks like SIM swapping.
4234 o Authenticator Apps: Generate time-based OTPs.
4235 o Push Notifications: Send an approval request to a user’s device.
4236 o Hardware Tokens: Physical devices generating OTPs.
4237 o Biometrics: Fingerprints, facial recognition, etc.

4238 EXAMPLES OF EVIDENCES

4239 • Logs showing MFA being used accessing network and information systems.
4240 • Access control policy outlining how different MFA methods are assigned.
4241

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

4244 GUIDANCE

4245 • Determine which network and information systems require the use of MFA protection based on the
4246 classification of the asset to be accessed.
4247 • Analyse user roles and the level of access required by each role to determine appropriate MFA methods.
4248 • Consider multi-factor authentication, in particular when accessing systems from a remote location, accessing
4249 system administration systems, access to sensitive information, etc.
4250 • Enforce multi-factor authentication on Internet-facing systems, such as email, remote desktop, and Virtual
4251 Private Network (VPNs)59
4252 • Define when and how MFA is required (e.g., every login, once per session, for high-risk actions).

4253 EXAMPLES OF EVIDENCES

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

59
Cyber fundamentals, [Link]-3, Centre for Cyber Security Belgium, accessible at:
[Link]

131
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4262 TIPS

4263 GUIDANCE

4264 • Integrate MFA with Single Sign On (SSO) solutions for seamless access.
4265 • Implement secure fallback methods for users who lose access to their MFA methods.
4266 • Educate users about the importance of MFA and how to use it.
4267 • Regularly monitor MFA logs for suspicious activity.
4268 • Keep the MFA system and associated devices updated.
4269 • Combine multi-factor authentication with other techniques to require additional factors under specific
4270 circumstances, based on predefined rules and patterns, such as access from an unusual location, from an
4271 unusual device or at an unusual time.
4272 • Evaluate and choose a MFA provider that fits entity’s requirements:
4273 o Ease of Integration: Ensure the MFA solution integrates well with the existing systems.
4274 o User Experience: Aim for a balance between security and user convenience.
4275 o Scalability: Choose a solution that can grow with the entity.
4276 o Support and Reliability: Ensure the provider offers robust support and high reliability.
4277 • Pilot test the MFA solution with a small group of users.
4278 • Ensure that MFA implementation meets legal requirements (e.g., GDPR).

4279 EXAMPLES OF EVIDENCES

4280 • Manuals, configuration files, or screenshots demonstrating the successful integration of MFA with an SSO
4281 provider.
4282 • Records of training sessions, attendance lists, and training materials provided to users about MFA importance
4283 and usage
4284 • Regularly generated reports from MFA systems showing log monitoring activities and any detected suspicious
4285 activities.
4286 • Configuration files showing the implementation of additional authentication factors based on predefined rules.
4287
4288
4289 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 Α.8.5 BE-CyFun®2023 BASIC: [Link]-3.2
IMPORTANT: [Link]-1.2, [Link]-1.4

NIST CSF v2.0 [Link]-03 FI-Kybermittari ACCESS1

ETSI EN 319 401 Ref. to clause 2 of EL – Ministerial Cybersecurity Handbook: Part B: 5.6,
CA/Browser Forum network decision 5.7, 5.9, 10.3
security guide 1027/2019 - Self-assessment tool: 6.3, 6.4, 6.5,
Article 4 - 6.9, 11.3
paragraph 8
CEN/TS 18026:2024 OPS-23, IAM-06, IAM-07 ES-Royal Decree Article 20, Annex II: 4.2.1, 4.2.2,
311/2022 4.2.3, 4.2.4, 4.2.5, 4.2.6

4290

132
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4291 12. ASSET MANAGEMENT

4292 12.1 ASSET CLASSIFICATION

4293 12.1.1. For the purpose of Article 21(2), point (i) of Directive (EU) 2022/2555, the relevant entities shall lay down
4294 classification levels of all assets, including information, in scope of their network and information systems for the level
4295 of protection required.

4296 GUIDANCE

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

4298 EXAMPLES OF EVIDENCES

4299 • Documented classification levels for the assets.

4300

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

4307 GUIDANCE

4308 • Ensure that classifications and associated protective measures for assets consider business needs,
4309 including:
4310 o sharing or restricting information,
4311 o protecting integrity and authenticity of information,
4312 o ensuring availability, and
4313 o complying with legal requirements concerning the confidentiality, integrity or availability of the
4314 information.
4315 • Define and communicate a classification for sensitive information, such as (indicative example):
4316 o Public - freely accessible to all, even externally,
4317 o Internal - accessible only to members of the entity,
4318 o Confidential - accessible only to those whose duties require access).
4319 • Use classifications derived by national law, international agreements or international accepted strategies
4320 for information sharing information like the Traffic Light Protocol (TLP).
4321 • Align the classification with the access control policy (Annex to the Regulation, point 11.1)
4322 • Classify assets according to the identified classification levels.
4323 • Classify assets other than information in accordance with the classification of the information, they store,
4324 process, handle or protect.

4325 EXAMPLES OF EVIDENCES

4326 • Latest, updated list of the assets of the entity and their classification based on the identified classification
4327 levels.

133
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

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

4330 GUIDANCE

4331 • Define criteria for reviewing the classification over time.

4332 • Review the classification at least annually, taking into account:
4333 o regulatory changes; and
4334 o changes in the value, sensitivity and criticality of the assets throughout their life cycle

4335 EXAMPLES OF EVIDENCES

4336 • Documentation showing the schedule for reviews

4337 • Records of the most recent review and logs detailing changes made during the last review, including
4338 reclassifications and the addition/removal of assets.
4339

4340 TIPS

4341 GUIDANCE

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

4344 EXAMPLES OF EVIDENCES

4345 • Personnel knows classification levels and protection requirements for each level.
4346

4347
4348 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 A.5.9, A.5.12, A.5.13 BE-CyFun®2023 BASIC: [Link]-5.1

NIST CSF v2.0 [Link]-05 FI-Kybermittari CRITICAL-1, CRITICAL-2, ASSET-1,

ASSET-2, RESPONSE-4, THIRD-
PARTIES-1
ETSI EN 319 401 REQ-7.3.1-02 EL – Ministerial Cybersecurity Handbook: Part B: 1.4
decision
1027/2019 Self assessment tool: 2.5, 2.6
Article 4 -
paragraph 2
CEN/TS 18026:2024 AM-05 ES-Royal Decree Article 40, Annex II: 4.3.1, 4.1.1
311/2022
4349

4350

134
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4351 12.2 HANDLING OF ASSETS

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

4355 GUIDANCE

4356 • Ensure that employees, direct suppliers and service providers, and any other third party who uses or
4357 handles assets of the entity, are aware of the policy.

4358 EXAMPLES OF EVIDENCES

4359 • Policy for the proper handling of assets.

4360 • User manuals or instructions provided to employees, direct suppliers and service providers, and any other
4361 third party who uses or handles assets of the entity.
4362 • Documentation showing that employees have completed training sessions on the asset handling policy
4363 • Forms or electronic records where employees, direct suppliers and service providers, and third parties
4364 have signed to acknowledge they have read and understood the policy.
4365

4366 12.2.2. The policy shall:

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

4372 GUIDANCE

4373 • Identify, document and implement a policy for handling assets throughout their life cycle (acquisition, use,
4374 storage, transportation and disposal).
4375 • Ensure that the policy includes at least safe storage, safe transport; and irretrievable deletion and
4376 destruction. For example:
4377 o Create user manuals and training materials on the correct and secure use of assets.
4378 o Establish guidelines for secure storage.
4379 o Define protocols for secure transfer.
4380 o Outline methods for data wiping and physical destruction, ensuring complete and irretrievable
4381 deletion.
4382 • Cover the correct usage of any asset used outside the entity’s premises (e.g., mobile device) in the policy.
4383 • Ensure that assets may be transferred to external premises only after approval by authorized management
4384 bodies, in accordance with the policy.
4385 • Link the asset handling policy with the asset classification by providing handling details for each
4386 classification level.

4387 EXAMPLES OF EVIDENCES

4388 • Documented policy for handling assets.

4389 • User access lists, access request forms, and approval records.
4390 • Incident reports related to asset handling (e.g., loss, theft, damage).

135
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

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

4393 GUIDANCE

4394 • Review and update, at least annually, the policy for asset handling.

4395 EXAMPLES OF EVIDENCES

4396 • Up-to date policy for asset handling

4397 • Review records or history of changes.
4398
4399
4400 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 A.5.9, A.5.10, A.5.14, A.7.10 BE-CyFun®2023 BASIC: [Link]-1.1, [Link]-3.1, [Link]-
4.1
IMPORTANT: [Link]-1.2, [Link]-6.1,
[Link]-6.1, [Link]-3.2, [Link]-3.3
NIST CSF v2.0 [Link]-01 FI-Kybermittari PROGRAM-2, ASSET-1, ASSET-2,
ASSET-5, ARCHITECTURE-5,
ARCHITECTURE-6, WORKFORCE-1
ETSI EN 319 401 REQ-7.3.2 EL – Ministerial Cybersecurity Handbook: Part B: 1.1,
decision 1.3, 1.6, 1.7, 1.8
1027/2019 Self assessment tool: 2.1, 2.2, 2.4,
Article 4 - 2.7, 2.8, 2.9, 2.10
paragraph 2
CEN/TS 18026:2024 ISP-02, AM-02, AM-03 ES-Royal Decree Article 40, Annex II: 4.3.1
311/2022
4401

4402

4403 12.3 REMOVABLE MEDIA POLICY

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

4408 GUIDANCE

4409 • Define, document and implement a policy on the management of removable media.
4410 • Communicate the policy to employees and third parties who handle removable storage media in order to
4411 ensure that they are aware of the policy.

4412 EXAMPLES OF EVIDENCES

4413 • Documented policy on the management of removable media, including at least the points in 12.3.2.
4414 • User manuals or instructions provided to employees and third parties concerning the correct usage of the
4415 removable media.
4416 • Documentation showing that employees and third parties have completed training sessions on the policy
4417 or forms or electronic records where employees and third parties have signed to acknowledge they have
4418 read and understood the policy.

136
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4419 • Evidence of ongoing awareness campaigns, such as posters, emails, or intranet posts, reminding
4420 employees about the risks and policies associated with removable media.
4421

4422 12.3.2. The policy shall:

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

4431 GUIDANCE

4432 • Align the policy with the asset classification (requirement 12.1) and include at least the following:
4433 o definitions and scope of removable media;
4434 o authorization requirements;
4435 o usage guidelines;
4436 o measures for control and protection of removable media while in storage and in transit;
4437 o techniques to protect information on removable storage media; and
4438 o incident response procedures for lost or compromised media.
4439 • Configure network and information systems to disable the autorun feature for all removable media to
4440 prevent automatic execution of potentially malicious software.
4441 • In the case where connection of removable media is not prohibited for an organisational (business) reason,
4442 removable media should be scanned for malicious code with up-to-date software against malicious code
4443 before they are connected to the entity’s network and information systems;
4444 • Encrypt sensitive data stored on removable media using strong cryptographic algorithms to protect against
4445 unauthorized access
4446 • Use encryption to protect data stored on portable storage devices, ensuring that unauthorized users
4447 cannot access the data if the device is lost or stolen.
4448 • Implement physical security measures such as secure storage locations and tracking logs for portable
4449 storage devices.

4450 EXAMPLES OF EVIDENCES

4451 • Configuration settings of endpoint protection software, if any.

4452 • Audit logs that track the use of removable media, including insertion, removal, and data transfer activities.
4453 • Reports of incidents involving removable media, if any.
4454

137
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

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

4457 GUIDANCE

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

4459 EXAMPLES OF EVIDENCES

4460 • Up-to date removable media policy.

4461 • Review records or history of changes.
4462

4463 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A.7.7, A.7.10 BE-CyFun®2023 BASIC: [Link]-3.1
IMPORTANT: [Link]-1.2, [Link]-1.1,
[Link]-2.2
ESSENTIAL: [Link]-1.1, [Link]-3.4
NIST CSF v2.0 [Link]-01, [Link]-01, [Link]- FI-Kybermittari ARCHITECTURE-3g, ARCHITECTURE-
02, [Link]-03, [Link]-04 5g, ARCHITECTURE-6c
ETSI EN 319 401 REQ-7.3.2 EL – Ministerial Cybersecurity Handbook: Part B: 1.5
decision
1027/2019 Self assessment tool: 2.2, 3.11
Article 4 -
paragraph 2
CEN/TS 18026:2024 ISP-02, AM-02, PS-04 ES-Royal Decree Annex II: 5.3.3
311/2022
4464

4465

4466 12.4 ASSET INVENTORY

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

4469 GUIDANCE

4470 • Ensure that all assets, including hardware, software, data, and services, are listed in the inventory.
4471 • Regularly verify the accuracy of the inventory entries.
4472 • Update the inventory promptly to reflect any changes, such as new assets, decommissioned assets, or
4473 changes in asset status (see also Annex to this regulation, point 6.4)
4474 • Use standardized naming conventions and categorization methods to maintain consistency across the
4475 inventory.
4476 • Make sure that inventory entries contain the data in the guidance above (sampling).
4477 • Implement validation rules within the inventory to ensure data entered is complete and consistent.

4478 EXAMPLES OF EVIDENCES

4479 • Documentation for the inventory of assets

4480 • Up to date inventory of assets
4481 • Review records or history of changes.

138
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4482 • Records of key metrics tracked, such as the number of assets, types of assets, compliance with inventory
4483 policies, and the timeliness of updates.
4484

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

4490 GUIDANCE

4491 • Consider adding the following to the inventory (indicative, non-exhaustive list):
4492 o asset unique ID;
4493 o asset’s type, e.g. software including virtual machines (version), hardware (operating
4494 system/firmware), services, facilities, HVAC systems, personnel, physical records;
4495 o asset owner;
4496 o asset description;
4497 o asset location;
4498 o date of asset’s last update/patch;
4499 o asset classification consistent with the risk assessment;
4500 o type of information and its classification processed in asset;
4501 o asset end of life, where applicable; and
4502 o logging requirements.

4503 EXAMPLES OF EVIDENCES

4504 • Configuration of the asset inventory tool, if any.

4505

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

4508 GUIDANCE

4509 • Conduct regular reviews to verify the accuracy and completeness of the inventory.
4510 • History of changes is maintained.

4511 EXAMPLES OF EVIDENCES

4512 • Up to date inventory of assets including history of changes.

4513 • Regular reports generated on inventory status, changes, and audit findings.
4514

139
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4515 TIPS

4516 GUIDANCE

4517 • Use a tool that supports the comprehensive tracking and management of assets.
4518 • Ideally, the tool supports automated discovery of assets and regular scan for new assets and update of
4519 the inventory. Alternatively, consider manual update procedures.
4520 • Configure the chosen tool to capture the defined attributes and categories, ensuring it supports relevant
4521 functionalities such as tagging, searching, and reporting.
4522 • Set up automated alerts for missing or incomplete data, discrepancies, and anomalies detected in the
4523 inventory.

4524 EXAMPLES OF EVIDENCES

4525 • Configuration settings of the asset management tool.

4526
4527
4528 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 A.5.9 BE-CyFun®2023 BASIC: [Link]-1.1, [Link]-2.1
IMPORTANT: [Link]-1.2, [Link]-1.3,
[Link]-2.2, [Link]-2.4, [Link]-3.3,
[Link]-7.1
NIST CSF v2.0 [Link]-01, [Link]-02, FI-Kybermittari ASSET-1, ASSET-4
[Link]-03, [Link]-04,
[Link]-07, [Link]-08, [Link]-
01, [Link]-02, [Link]-03,
[Link]-04
ETSI EN 319 401 REQ-7.3 EL – Ministerial Cybersecurity Handbook: Part B: 1.2,
decision 1.9, 1.10
1027/2019 Self assessment tool: 2.3, 2.11
Article 4 -
paragraph 2
CEN/TS 18026:2024 AM-04 ES-Royal Decree -
311/2022
4529

4530

140
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4531 12.5 DEPOSIT, RETURN OR DELETION OF ASSETS UPON TERMINATION OF

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

4538 GUIDANCE

4539 • Define procedures to ensure that assets are deposited, returned or irrevocably deleted on termination of
4540 employment or contractual relationships.
4541 • Make sure that the procedures clearly identify all assets to be returned, according to the asset inventory
4542 (point 12.4.1), which can include (indicative, non-exhaustive list):
4543 o user endpoint devices;
4544 o portable storage devices;
4545 o specialised equipment;
4546 o authentication hardware (e.g., access cards, mechanical keys, physical tokens and smartcards);
4547 o physical copies of information.

4548 EXAMPLES OF EVIDENCES

4549 • Documented procedures for the timely return of assets upon termination of employment.
4550 • Logs or records indicating that data on returned assets was deleted according to the procedures.
4551 • Completed exit checklist forms that include asset return and data deletion steps, signed by the departing
4552 employee and relevant supervisors.

4553 TIPS

4554 GUIDANCE

4555 • In cases where employees (and other third parties) use their own personal equipment, follow procedures
4556 to ensure that all relevant information is traced and transferred to the entity and securely deleted from the
4557 equipment.
4558 • Keep record of the implementation of the policy (list of employees who have left or contractors whose
4559 contracts have ended and list of assets they returned, including return date).
4560 • Make sure that relevant terms are part of the employment or service contract.
4561 • Communicate to employees the procedures during the induction process and also during the exit process.
4562 • Check that there is an employee exit interview process and the return of the assets is linked with it.
4563 • Where the deposit, return or deletion of assets is not possible (indicative, non-exhaustive list):
4564 o Ensure that any credentials associated with the assets are revoked or disabled.
4565 o Isolate the assets by placing them in a separate network segment.
4566 o Use access control lists to restrict access to and from the isolated assets.
4567 o Ensure that only authorized personnel can interact with these assets.
4568 o Configure firewalls to block any traffic to and from the isolated assets.
4569 o Physically or logically disable the network interfaces of the assets.
4570 o Continuously monitor the isolated assets and log any access attempts.

4571 EXAMPLES OF EVIDENCES

141
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4572 • Personnel is aware of the procedures .

4573 • Communication materials, such as emails or intranet posts, that remind employees of their obligations
4574 upon termination.
4575 • Statements confirming that data was irrevocably deleted, especially for external employees or contractors.
4576 • Documentation of the termination process, including coordination between HR and IT departments.
4577 • Sample checks of lists of employees/contractors and the assets they were assigned as well as those they
4578 returned.
4579
4580
4581
4582 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 A.5.11, A.5.18, A.8.24 BE-CyFun®2023 BASIC: [Link]-11.1
IMPORTANT: [Link]-3.2, [Link]-11.2

NIST CSF v2.0 FI-Kybermittari WORKFORCE-1

ETSI EN 319 401 REQ-7.3.2 EL – Ministerial
decision
1027/2019 -
CEN/TS 18026:2024 AM-01 ES-Royal Decree Annex II: 5.5.5
311/2022
4583
4584

4585

142
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4586 13. ENVIRONMENTAL AND

4587 PHYSICAL SECURITY

4588 13.1 SUPPORTING UTILITIES

4589 13.1.1. For the purpose of Article 21(2)(c) of Directive (EU) 2022/2555, the relevant entities shall prevent loss, damage
4590 or compromise of network and information systems or interruption to their operations due to the failure and disruption
4591 of supporting utilities.

4592 GUIDANCE

4593 • Consider supporting utilities that ensure the continuous operation of network and information systems,
4594 such as (indicative, non-exhaustive list):
4595 o Power Supply: Electricity to keep systems running.
4596 o Water: For cooling and other operational needs.
4597 o Gas: For heating or backup power generation.
4598 o HVAC (Heating, Ventilation, and Air Conditioning): To maintain optimal operating conditions.
4599 o Telecommunications: Internet and network connectivity.
4600 • Include in the risk assessment the potential failure and disruption in supporting utilities.

4601 EXAMPLES OF EVIDENCES

4602 • List of supporting utilities, and associated risk assessment results.

4603 • Measures to protect against the failure and disruption of supporting utilities.
4604

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

4618 GUIDANCE

4619 • Consider the availability of supporting utilities in the business continuity plan (Annex to the Regulation,
4620 point 4.1).
4621 • Consider the availability of supporting utilities, when implementing backup management (Annex to the
4622 Regulation, point 4.2).

143
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4623 • Consider implementing measures for the protection of supporting utilities, such as (indicative, non-
4624 exhaustive list),
4625 o active/passive cooling;
4626 o automatic restart after power interruption;
4627 o battery backup power;
4628 o diesel generators;
4629 o backup fuel;
4630 o Uninterruptable Power Supply (UPS), hot standby power generators;
4631 o sufficient fuel delivery SLA;
4632 o delivery companies, redundant cooling;
4633 o spare parts for components of network and information systems; and
4634 o power backup systems.

4635 EXAMPLES OF EVIDENCES

4636 • Description of different types of supporting utilities.

4637 • Measures to protect against the failure and disruption of supporting utilities.
4638

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

4641 GUIDANCE

4642 • Conduct routine tests of protection measures.

4643 • Set up periodic reviews to evaluate the effectiveness of current protection measures.

4644 EXAMPLES OF EVIDENCES

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

4650 TIPS

4651 GUIDANCE

4652 • Make employees aware of dependencies to supporting utilities.

4653 • Train staff on how to respond effectively to failures and disruptions of supporting utilities.
4654 • Set up monitoring systems to detect utility failures or disruptions.

4655 EXAMPLES OF EVIDENCES

4656 • Records of internal communications, emails, or newsletters highlighting the importance of supporting
4657 utilities and their impact on operations.
4658 • Logs demonstrating the detection and recording of any utility failures or disruptions.
4659
4660

144
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4661 MAPPING TO STANDARDS & FRAMEWORKS

European and international frameworks National Frameworks
ISO 27001:2022 A. 7.11 BE-CyFun®2023 BASIC: [Link]-3.1, [Link]-1.1
IMPORTANT: [Link]-1.1, [Link]-3.2,
[Link]-7.1, [Link]-9.1, [Link]-2.1,
[Link]-6.1, [Link]-6.2, [Link]-3.1,
[Link]-5.1, [Link]-1.2, [Link]-2.1,
[Link]-1.1
ESSENTIAL: [Link]-1.2, [Link]-7.2,
[Link]-7.3, [Link]-9.2, [Link]-2.2,
[Link]-5.2
NIST CSF v2.0 [Link]-02, [Link]-06, FI-Kybermittari RESPONSE-4, CRITICAL-3
[Link]-03, [Link]-05,
[Link]-07, [Link]-10, [Link]-
01, [Link]-02, [Link]-03,
[Link]-04
ETSI EN 319 401 For network connections EL – Ministerial Cybersecurity Handbook: Part B: 15.5
REQ-7.8-12 decision
1027/2019 - Self-assessment tool: 16.6
Article 4 -
paragraph 9
CEN/TS 18026:2024 PS-05 ES-Royal Decree Annex II: 5.1.1, 5.1.2, 5.1.3, 5.1.4,
311/2022 5.1.5, 5.1.6, 5.1.7
4662

4663

4664 13.2 PROTECTION AGAINST PHYSICAL AND ENVIRONMENTAL THREATS

4665 13.2.1. For the purpose of Article 21(2)(e) of Directive (EU) 2022/2555, the relevant entities shall prevent or reduce the
4666 consequences of events originating from physical and environmental threats, such as natural disasters and other
4667 intentional or unintentional threats, based on the results of the risk assessment carried out pursuant to point 2.1.

4668 GUIDANCE

4669 • Consider risks associated with current and forecasted physical and environmental threats to the network
4670 and information systems.
4671 o Include in the assessment the (physical) locations of the entity’s facilities.
4672 • Based on the results of the risk assessment determine the assets that need to be protected from physical
4673 and environmental threats.
4674

4675 13.2.2. For that purpose, the relevant entities shall, where appropriate:

4676 (a) design and implement protection measures against physical and environmental threats;

4677 (b) determine minimum and maximum control thresholds for physical and environmental threats;

4678 (c) monitor environmental parameters and report to the competent internal or external personnel events outside the
4679 minimum and maximum control thresholds referred to in point (b).

4680 GUIDANCE

4681 • Implement measures against physical and environmental threats. Parameters to consider are (indicative,
4682 non-exhaustive list):

145
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4683 o purpose and scope;

4684 o network and information systems in scope.
4685 o description of facilities;
4686 o roles and responsibilities;
4687 o management commitment;
4688 o coordination among organisational units;
4689 o compliance with national and EU law, including personal data protection.
4690 • Consider the following examples of physical and environmental threats (indicative, non-exhaustive list):
4691 o fire,
4692 o flood,
4693 o earthquake,
4694 o explosion,
4695 o theft/vandalism,
4696 o civil unrest,
4697 o toxic waste/chemical spill,
4698 o climate change,
4699 o pollution/environmental emissions.
4700 • Consider measures against physical and environmental threats such as (indicative, non-exhaustive list):
4701 o Physical access control measures (e.g. IDs, badges, logs; visitor management system, physical
4702 barriers)
4703 o Surveillance systems (e.g. CCTV, entry points, exits, locking mechanisms, security personnel)
4704 o Climate control (e.g. Temperature and humidity controls, HVAC systems)
4705 o Fire prevention and response measures (e.g. fire alarms, smoke detectors, sprinkler systems,
4706 fire extinguishers)
4707 o Flood protection measures (e.g. barriers, water sensors, pumps)
4708 • Consider enhanced (maximum) measures to be activated during heightened threat levels or specific
4709 scenarios. Examples of such measures include (indicative, non-exhaustive list):
4710 o Increased security personnel, advanced biometric access controls, and lockdown procedures.
4711 o Enhanced monitoring systems, redundant power supplies, and advanced environmental sensors.

4712 EXAMPLES OF EVIDENCES

4713 • Detailed documentation showing the design and implementation of measures against physical and
4714 environmental threats.
4715 • Reports outlining the defined minimum and maximum control thresholds for various threats.
4716 • Logs from environmental monitoring systems showing continuous tracking of parameters like
4717 temperature, humidity, and security breaches.
4718 • Records of incidents where parameters fell outside the defined thresholds, including the actions taken
4719 and notifications sent to relevant personnel.
4720

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

4724 GUIDANCE

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

4728 EXAMPLES OF EVIDENCES

146
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

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

4734 TIPS

4735 GUIDANCE

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

4740 EXAMPLES OF EVIDENCES

4741 • Documented physical and environmental security policy, including description of facilities and network and
4742 information systems in scope.
4743 • Results of periodic simulations and awareness raising activities.
4744

4745
4746 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 A. 7.3, A.7.5 BE-CyFun®2023 BASIC: [Link]-1.1
IMPORTANT: [Link]-5.1, [Link]-7.1,
[Link]-9.1, [Link]-3.1, [Link]-5.1,
[Link]-1.2, [Link]-2.1, [Link]-1.1
ESSENTIAL: [Link]-5.2, [Link]-7.2,
[Link]-7.3, [Link]-9.2, [Link]-5.2
NIST CSF v2.0 [Link]-02, [Link]-01, [Link]- FI-Kybermittari RISK-1, RISK-2, RISK-3, RISK-4,
02, [Link]-03, [Link]-04 THREAT-2, RESPONSE-3
ETSI EN 319 401 Clause 7.6 EL – Ministerial Cybersecurity Handbook: Part B: 15.5
decision
1027/2019 - Self-assessment tool: 16.6
Article 4 -
paragraph 9
CEN/TS 18026:2024 PS-05 ES-Royal Decree Annex II: 5.1.1, 5.1.2, 5.1.3, 5.1.4,
311/2022 5.1.5, 5.1.6, 5.1.7
4747

4748

147
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4749 13.3 PERIMETER AND PHYSICAL ACCESS CONTROL

4750 13.3.1. For the purpose of Article 21(2)(i) of Directive (EU) 2022/2555, the relevant entities shall prevent and monitor
4751 unauthorised physical access, damage and interference to their network and information systems.

4752 GUIDANCE

4753 • Implement perimeter physical access control, which takes into account the measures for protection against
4754 physical and environmental threats.

4755 EXAMPLES OF EVIDENCES

4756 • Documented policy for physical security measures, including description of facilities and network and
4757 information systems in scope.
4758

4759 13.3.2. For that purpose, the relevant entities shall:

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

4765 GUIDANCE

4766 • Consider in the risk assessment risks associated with unauthorised physical access, damage, and
4767 interference to network and information systems.
4768 • Based on the results of the risk assessment determine the assets of high criticality and the impact of their
4769 compromise. This will help in identifying the perimeter for such assets.
4770 • Prevent unauthorised physical access to facilities and set up adequate measures.
4771 o Physical access control measures designed to protect the entity as a whole will also protect
4772 individual assets.
4773 o Consider introducing further specific access control measures for specific assets or facilities.
4774 • Consider physical security measures (indicative, non-exhaustive list):
4775 o physical access controls such as key cards, biometric scanners, locks, and security personnel to
4776 restrict access to areas with high criticality.
4777 o electronic control of entrance and audit trail.
4778 o segmentation of spaces according to authorization levels and their contents.
4779 o CCTV cameras and monitoring systems to continuously observe sensitive areas.
4780 o fencing, barriers, and security patrols for securing physical perimeter.
4781 o guards and/or alarms to monitor every physical access point to the facility where the information
4782 system resides,24 hours per day, 7 days per week.
4783 • Develop and enforce procedures for granting, reviewing, and revoking physical access rights (see Annex
4784 to the Regulation, point 11.2).
4785 o Identify a designated official within the entity to review and approve the list of personnel with
4786 authorized physical access.
4787 o Maintain a list of personnel with authorized access to facilities and their authorization level.

4788 EXAMPLES OF EVIDENCES

4789 • Risk assessment results

148
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4790 • Existence of physical security measures

4791 • Procedures for granting, reviewing, and revoking physical access rights according to Annex to the
4792 Regulation, point 11.2.
4793

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

4796 GUIDANCE

4797 • Review physical access lists.

4798 • Employ intrusion tests that includes, unannounced attempts to bypass or circumvent measures associated
4799 with physical access points to the facility.
4800 • Perform security checks at the physical boundary of the facility or network and information system for
4801 unauthorized exfiltration of information or removal of information system components.

4802 EXAMPLES OF EVIDENCES

4803 • Periodic simulations and awareness raising activities to assess the readiness of personnel and the
4804 adequacy of the procedures to physical access control.
4805 • Schedule and results of tests and security checks.
4806 • Up to date list of personnel with authorized physical access to facilities.
4807

4808 TIPS

4809 GUIDANCE

4810 • Enforce physical access authorization to network and information systems in addition to the physical
4811 access controls for the facility.
4812 • Remove individuals from the facility access list when access is no longer required.
4813 • Document procedures for emergencies.
4814 • Log and monitor personnel physical access (entry and exit) through an entry control system.
4815 • Authenticate visitors before authorizing access to the facility. Escort visitors according to security policies
4816 and procedures. Maintain visitor’s access records to the facility.
4817 • Employ automated mechanisms to facilitate the maintenance and review of visitor access records.
4818 • Make sure that employees are aware of the existence of a secure area on a need-to-know basis.
4819 • Define and communicate to the personnel an intruder response process or emergency procedures.
4820 • Communicate physical access control measures to employees.
4821 • Separate facilities managed by the entity from those managed by third parties.
4822 • Employ automated mechanisms to recognize types of intrusions and initiate defined response actions.
4823 • Employ video surveillance of operational areas and retain video recordings for defined time period,
4824 according to GDPR.
4825 • Keep physical access records as dictated by applicable regulations or based on an entity-defined period
4826 by approved policy. Keep and store physical access records in case of an audit or investigation.
4827 • Respect risk assessment results before taking actions on damaged devices containing sensitive data.

4828 EXAMPLES OF EVIDENCES

4829 • Perimeter incident response procedures is in place.

149
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4830 • Personnel clearly display the identity.

4831

4832
4833 MAPPING TO STANDARDS & FRAMEWORKS
European and international frameworks National Frameworks
ISO 27001:2022 A. 7.1, A.7.2, A.7.4 BE-CyFun®2023 BASIC: [Link]-1.1, [Link]-2.1, [Link]-
3.1, [Link]-4.1, [Link]-4.2, [Link]-4.3,
[Link]-11.1
IMPORTANT: [Link]-6.1, [Link]-1.2,
[Link]-2.2, [Link]-3.3, [Link]-4.6,
[Link]-6.1, [Link]-3.2, [Link]-3.3,
[Link]-5.1, [Link]-11.2, [Link]-2.1,
[Link]-2.1, [Link]-3.2, [Link]-6.1,
[Link]-7.1
ESSENTIAL: [Link]-2.3, [Link]-2.4,
[Link]-3.4, [Link]-4.8, [Link]-1.1,
[Link]-2.2
NIST CSF v2.0 [Link]-06, [Link]-02 FI-Kybermittari RISK-1, RISK-2, RISK-3,
ARCHITECTURE-3, ACCESS-3
ETSI EN 319 401 Clause 7.6 EL – Ministerial Cybersecurity Handbook: Part B:
decision 15.1, 15.2, 15.3, 15.4, 15.6
1027/2019 - Self-assessment tool: 16.1, 16.2,
Article 4 - 16.3, 16.4, 16.5, 16.7
paragraph 9
CEN/TS 18026:2024 PS-01, PS-02, PS-03, PS-04 ES-Royal Decree Annex II: 4.2.5, 4.2.6
311/2022

4834

150
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4835 ANNEX I NATIONAL FRAMEWORKS

4836 Belgium

4837 Belgium has completed the transposition of the NIS2 directive and transposed it into national legislation. In that
4838 legislation, a special role is reserved for the CyberFundamentals framework (CyFun® - [Link]).

4839 Finland

4840 Traficom’s (the Finnish Transport and Communications Agency) national recommendation on cybersecurity risk
4841 management measures for supervisory authorities and the Cybermeter/Kybermittari are the two instrumental
4842 documents for the national regulatory framework. The recommended cybersecurity risk management measures are
4843 mapped to the Cybermeter/Kybermittari's objectives and practices that enables organisations to do self-assessment
4844 on their cybersecurity capabilities and optimize their security investments. Voluntary sharing quantitative self-
4845 assessment data to NCSC-FI enables creation of benchmarking data and improves situation awareness of NCSC-FI.
4846 The Cybermeter/Kybermittari is a maturity model and developed by the National Cyber Security Centre (NCSC-FI)
4847 and it is based on Cybersecurity Capability Maturity Model (C2M2) and the NIST Cybersecurity Framework.

4848 Germany

4849 In Germany there is an Advisory on what requirements should be seen as state of the art. The document is available
4850 at:
4851 [Link]

4852 Greece

4853 The Greek Cybersecurity Framework consists of:

4854 a) the law 4577/2018 and the ministerial decision 1027/2019;

4855 b) the Cybersecurity Handbook available at: [Link]

4856 [Link]; and

4857 c) the self-assessment tool, available at: [Link]

4858 [Link] .

4859 The Cybersecurity Handbook and the self-assessment tool are based on globally accepted international standards and
4860 guidelines (CIS Controls, ISO 27002, NIST 800-53, OWASP, etc.) and will be dynamically modified to follow changes
4861 in standards, the current threat landscape and the legal and regulatory framework.

4862 Spain

4863 The Royal Decree 311/2022, of May 3, regulates the National Security Framework or National Security Framework
4864 (ENS or NSF), which is the legal regulation of mandatory compliance for all entities of the Spanish public sector and
4865 also of mandatory application to the information systems used by private companies to provide services to the above
4866 mentioned public entities.

4867 The full text of the ENS is available at:

4868 [Link]

4869

151
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4870 ANNEX II GLOSSARY

4871

4872 Information. Data in context. In the text, we use primarily information, unless we refer specifically to data (e.g. data
4873 breach etc.).

4874 Entity. the relevant entities in scope of the Commission Implementing Regulation (EU) 2024/2690. In other standards
4875 or good practices, the terms organisation or enterprise or business may be used.
4876 Asset. Anything that has value to the entity including information. Overall, the assets of a network and information
4877 system are personnel, processes, information, software and hardware.

4878 Management bodies as in the context of Article 20 of the NIS2 Directive.

4879 Policy: intentions and direction of an organization, as formally expressed by its management bodies.
4880 Topic-specific policy: a policy on a specific subject or topic, as formally expressed by the relevant to the topic
4881 management bodies.
4882 Process: an activity which transforms an input to output.
4883 Procedure: specified way to carry out an activity or a process60. The entity can document their needs for more
4884 detailed information in a way that is efficient for them beyond the policy. This is mainly procedures and processes.
4885 Rule: accepted principle or instruction that states the entity’s expectations on what is required to be done, what is
4886 allowed or not allowed. Rules can be formally expressed in topic-specific policies and in other types of documents.61
4887 User: all legal and natural persons which have access to the entity’s network and information systems (Recital (10) of
4888 the Regulation).
4889 Personnel: persons doing work under the entity’s direction62. The concept of personnel includes the entity’s
4890 members, such as the governing body, management bodies, employees, temporary staff, contractors and volunteers.
4891 In this document it is used interchangeably with the term employees.
4892 Direct suppliers and service providers, including their personnel.
4893 Measure: this term refers to a cybersecurity risk-management measure as referred to in NIS2. It is used similarly to
4894 the term ‘control,’ which denotes a measure that modifies risk 63. Additionally, the terms ‘measure’ and ‘protection
4895 measure’ are used interchangeably.
4896 Facilities: the physical location housing entity’s network and information systems.

4897 Event: refers to an information security event meaning an identified occurrence indicating a possible information
4898 security breach or failure of controls64.
4899 Suspicious event: an event that appears unusual or a previously unknown situation which might be a potential security
4900 threat. To make clearer the difference between an event and a suspicious event consider an example when a legitimate
4901 user fails to login once due to a typo error. This is an event. However, the situation where a user fails to login after five
4902 attempts this might be considered a suspicious event.

4903 Incident: an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or
4904 processed data or of the services offered by, or accessible via, network and information systems (NIS2 Article 6 Nr 6).

4905 Significant incident: an incident which meets the criteria of Article 3 of the Regulation.

4906 Crisis: an abnormal or extraordinary event or situation which threatens an organisation or community and requires a
4907 strategic, adaptive and timely response in order to preserve its viability and integrity24.

4908 Incident handling. any actions and procedures aiming to prevent, detect, analyse, and contain or to respond to and
4909 recover from an incident (NIS2 Article 6 Nr 8).

4910 Critical: one of the classification levels assigned to entity’s assets following an assessment of their criticality, including
4911 the asset classification (point 12.1 of the Annex of the Regulation).

60
[SOURCE:ISO 30000:2009, 3.12]
61
[SOURCE: ISO/IEC 27002:2022, 3.1.32]
62
[SOURCE: ISO/IEC 27002:2022, 3.1.20]
63
[SOURCE: ISO/IEC 27002:2022, 3.1.8]
64
[SOURCE: ISO/IEC 27002:2022, 3.1.14]

152
 IMPLEMENTING GUIDANCE
Draft for public consultation | October 2024

4912 Privileged access. refers to the necessary permissions granted to specific users of the network and the information
4913 system of the entity, in order for them to perform tasks which regular users cannot.

4914 Cyber hygiene practices. Preamble 20 of the Regulation addresses cyber hygiene practices for two target groups
4915 under the Directive 2022/2555: (a) essential and important entities, and (b) for their users. Cyber hygiene practices for
4916 essential and important entities refer to a common baseline set of practices, which are already covered by the technical
4917 and methodological requirements of cybersecurity risk-management measures outlined in the Annex to this Regulation.
4918 Therefore, no additional guidance for cyber hygiene practices for essential and important entities is deemed necessary.
4919 Cyber hygiene practices referring to users are explicitly mentioned in the guidance and are included in section 8.1 of
4920 this guidance.

4921

153
 XX-00-00-000-XX-X
ABOUT ENISA
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:
[Link].

ISBN 000-00-0000-000-0
doi: 0000.0000/000000