3.4 Event assessment and classification

Requirement

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

Guidance

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

Examples of evidence

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

Requirement

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

Guidance

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

Examples of evidence

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

Tips: guidance

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

Tips: examples of evidence

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