3.1 Incident handling policy

Requirement

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

Guidance

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

Examples of evidence

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

Requirement

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

Guidance

• Align the incident handling policy with the business continuity and disaster recovery plan (Annex to the regulation, point 4.1) by (indicative, non-exhaustive list):
  • ensuring that they aim to minimise disruptions, protect assets and ensure a swift return to normal operations;
  • identifying interfaces between the incident handling policy and business continuity management;
  • describing workflows which trigger business continuity (Annex to the regulation, points 4.1, 4.2 or 4.3) during an incident; and
  • developing scenarios that test the interaction between these processes and describe the result of this interaction in the incident handling policy.
• Set up a categorisation system for incidents, which refers to the scheme that the entity uses to identify the consequences and the priority of an incident, together with the criteria for categorising events as incidents (18). An indicative, non-exhaustive list of criteria might include one or more of the following:
  • impact on business operations,
  • data sensitivity in accordance with risk management,
  • legal and regulatory impact, including reporting timelines stemming from regulatory framework e.g. GDPR, national regulations,
  • scope and scale meaning the evaluation of how widespread the event is,
  • type of attack (19),
  • malicious software/vulnerability exploitation,
  • criticality of the systems affected,
  • incident containment urgency,
  • potential of data exfiltration or corruption, such as in the case of ransomware,
  • likelihood of recovery,
  • impact on human lives and safety and
  • other criteria on what constitutes a significant incident as per this regulation.
• Ensure that the incident handling policy refers to different types of incidents such as (indicative, non-exhaustive list) :
  • system failures and loss of service availability;
  • malicious code;
  • denial of service;
  • errors;
  • breaches of confidentiality and integrity; and
  • misuse of network and information systems.
• Communicate the incident to relevant stakeholders and personnel according to a communication plan. The communication plan should consider the event reporting mechanism (Annex to the regulation, point 3.3) and may include (indicative, non-exhaustive list) the following:
  • purpose and scope of the plan,
  • roles and responsibilities for communication tasks,
  • list of internal and external stakeholders to be informed,
  • reporting timelines stemming from regulatory framework, e.g. GDPR, national regulations,
  • conditions and procedures for escalation of incidents,
  • channels to be used for communication (e.g. email, intranet, phone calls, social media, press releases),
  • channels of communication need to be tailored based on the target audience (that is internal, client or general public, etc.),
  • methods for stakeholders to provide feedback or ask questions and
  • guidelines for when to communicate and the frequency of updates, along with pre-drafted message templates for various scenarios and the core messages to be communicated.
• Identify the necessary roles and responsibilities to be assigned for incident handling. The entities can use already established skills frameworks, for example the ECSF, to assist them in identifying the necessary skills and knowledge.

Examples of evidence

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

Requirement

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

Guidance

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

Examples of evidence

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

Tips: guidance

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

Tips: examples of evidence

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