CRA Evidence Docs
Go back to the web Sign In

Incident Reporting

Record severe security incidents, track them through their lifecycle, and capture ENISA submission timestamps for your audit trail.

Info: For the regulatory background (when an incident must be reported, severe-incident criteria, and the ENISA reporting deadlines and what each stage must contain), see Vulnerability handling and reporting and Vulnerability reporting on the CRA compliance hub.

Incident types

Type Description
Data Breach Unauthorised access to or exposure of data
Integrity Compromise Unauthorised modification of product code or data
Availability Disruption Product or service unavailability (DoS, ransomware, outage)
Malicious Code Injection Malware, backdoors, or trojans introduced into product
Authentication Bypass Security control circumvention
Supply Chain Compromise Build system breach or dependency hijacking
Other Incidents not fitting above categories

Creating an incident

  1. Go to Security Events > Report Incident
  2. Fill in: title, type, severity, cause, detection details, affected products
  3. Save

CRA Evidence treats an incident as ENISA-reportable when its Cause is set to "Unlawful/Malicious" or when its Severity is Critical or High. Reportable incidents are flagged and deadline tracking starts automatically from the detection timestamp. Other cause options are: Accidental, Technical Failure, Natural Event, Under Investigation, Unknown.

Recording submissions

After submitting to ENISA's portal:

  1. Open the incident
  2. Click Send Early Warning, Send Incident Notification, or Send Final Report
  3. Timestamp is logged for your audit trail

Deadlines are calculated from when you became aware of the incident. Late notification is better than none. Record your submission even if overdue.

Deadline indicators

CRA Evidence shows a deadline badge on each tracked submission stage so you can see at a glance whether you are on track:

Colour Meaning
Green Deadline not yet reached
Yellow Within 6 hours of deadline
Red Deadline overdue

Incident lifecycle

Single forward path:

Detected -> Confirmed -> Contained -> Eradicated -> Recovered -> Lessons Learned -> Closed
Stage Description
Detected Initial creation and triage
Confirmed Verified as real incident
Contained Immediate threat neutralised
Eradicated Root cause removed
Recovered Normal operations restored
Lessons Learned Post-incident review completed
Closed Incident fully resolved

Each status change is logged with timestamp and user.

Incidents appear in the Active tab of the Security Events Hub while open. They move to History when status reaches Recovered, Lessons Learned, or Closed.

Linking affected products

  1. Open the incident detail page
  2. Click Add Affected Products
  3. Select the products and versions impacted

This ensures your technical file reflects the incident history.

Dashboard alerts

Overdue ENISA notifications show as a banner on the Security Events Hub. The ENISA overdue badge on the hub header shows the count of overdue items (both vulnerabilities and incidents combined).

Export

Incident data is included in technical file exports:

  • Incident timeline and status history
  • ENISA notification timestamps
  • Affected products
  • Remediation actions

This provides auditable evidence of your incident handling.

Best practices

Practice Why
Define reportability criteria upfront Consistent decisions under pressure
Prepare ENISA notification templates Faster response when incidents occur
Practice with tabletop exercises Know who has authority for notifications
Document in real-time Live notes are more reliable than reconstructed timelines
Coordinate security, legal, and comms early Avoid bottlenecks during response

ENISA Single Reporting Platform

Launches September 2026. CRA Evidence will support direct submission when available. Until then, submit through ENISA's portal and record the submission here.

Last updated June 04, 2026
Was this page helpful?
Thanks for your feedback!

Help us improve. What was missing or unclear?