3.3 Event reporting

Requirement

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

Guidance

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

Examples of evidence

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

Requirement

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

Guidance

• Make appropriate means for reporting available to personnel and the entity’s suppliers and customers.
• Consider anonymous reporting to encourage individuals to report security events without fear of reprisal.
• Take into account legal obligations to report an incident to the competent authorities (and CSIRTs) in line with the NIS2 Directive Articles 23 and 30, including any obligations about when the incident should be reported.
• Regularly remind stakeholders of the reporting mechanism through email newsletters, posters and other communication channels.
• Conduct regular exercises or simulations to test the effectiveness of the reporting mechanism.

Examples of evidence

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

Tips: guidance

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

Tips: examples of evidence

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