Incident response
Incidents are not vulnerabilities — and the CRA treats them differently.
Exploitation, compromised devices, compromised update infrastructure, credential compromise, malicious updates: Vellaci records them as incidents with owners, affected products and versions, impact, root cause, mitigation and Member States concerned, and asks the severe-incident question explicitly.
Awareness time discipline
Captured explicitly, timezone-aware, confirmed by a person. Changing it requires a reason, is audited, and recalculates every dependent deadline.
Reportability review
Not reviewed → potentially reportable → confirmed or not reportable, with rationale, reviewer and timestamp. A human decides; Vellaci records.
Status workflow
Open, investigating, contained, mitigating, resolved, closed — with notes, decision history and links to affected findings and versions.
Into the command center
Confirmed incidents open a severe-incident reporting case with the 24 h / 72 h / one-month timeline and prefilled facts.
Evidence and tasks
Attach forensics, logs and communications; assign remediation tasks; export a timeline PDF for regulators, customers or insurers.
Contacts and escalation
Assigned representative, CISO, compliance lead and security contact receive alerts by e-mail, in-app and via Slack, Teams or PagerDuty.
Incident types
What manufacturers actually report.
Exploitation in the field
A vulnerability in a shipped version is being exploited against customers. Usually starts as a vulnerability record and becomes an incident when impact is confirmed; both records stay linked.
Compromised devices or fleets
Devices under attacker control, botnet enrolment, unauthorised firmware. Impact assessment per version and per market.
Compromised update infrastructure
Signing keys, build systems or distribution channels affected. Often severe by definition because it can introduce malicious code into users' systems.
Malicious or tampered update
A release shipped with unwanted code, whether through supply-chain compromise or insider action.
Credential or key compromise
Leaked service credentials, cloud keys or certificates that protect the product's functions or user data.
Third-party or cloud dependency incident
An incident at a remote-data-processing provider the product depends on — in scope when it affects the product's security.
FAQ
Incident questions, answered.
- What is a 'severe incident' under the CRA?
- Article 3(45) and Article 14(5) describe an incident having an impact on the security of a product with digital elements that negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led to the introduction or execution of malicious code in the product or in its users' systems. Whether a specific event meets the threshold is a judgement your organisation records in Vellaci with rationale.
- Why does Vellaci separate incidents from vulnerabilities?
- Because the CRA does. An actively exploited vulnerability and a severe incident share the 24-hour and 72-hour deadlines but have different content requirements and different final-report triggers (14 days after a corrective measure versus one month after the notification). Mixing them in one record produces the wrong deadline.
- What counts as 'becoming aware'?
- The moment the manufacturer has sufficient information to conclude that a severe incident has occurred — not when a ticket was opened and not when the investigation ended. Organisations should define this operationally (for example: confirmation by the security lead) and Vellaci records the timestamp explicitly, with its timezone, confirmed by a named person. Changing it later requires a reason and is audited.
- Who needs to be notified inside the company?
- At minimum the assigned representative with access to the ENISA Single Reporting Platform, the incident owner, the CISO or security lead and the compliance lead. Vellaci's runbook captures those roles once; confirmed incidents alert them by e-mail, in-app and through chat or paging integrations.
- Does the CRA also require notifying users?
- Yes — Article 14(8): where necessary and in particular where the incident is continuing, the manufacturer informs impacted users without undue delay, including about corrective measures they can take. Vellaci drafts the user communication from the incident record and files the sent version as evidence.
Read next
- Guide
Incident or vulnerability? How the CRA treats the two reportable events
Actively exploited vulnerabilities and severe incidents share the 24-hour and 72-hour steps but differ in definition, notification content and final-report trigger. How to classify an event, when one becomes the other, and what to record.
- Guide
CRA Article 14 reporting obligations: a practical guide for manufacturers
What must be reported under Article 14 of the Cyber Resilience Act, by whom, to whom and when — the 24-hour early warning, 72-hour notification and final report — and how to operationalise it now that the obligation is in force (since 11 September 2026).
- Guide
CRA reporting timeline: 24 hours, 72 hours and the final report
How the Article 14 deadlines are computed, where the final-report trigger sits for vulnerabilities versus incidents, how calendar months and daylight-saving time behave, and three worked examples.
- Docs
Incident handling
Records, awareness, reportability, tickets, AI summary.
- Docs
Runbook and drills
Organisation readiness and simulated exercises.
- Free tool
CRA deadline calculator
24-hour, 72-hour and final-report deadlines from an awareness time, using Vellaci's deadline engine.
Prepare the response before the incident.
Configure owners, contacts and the reporting workflow now.