Incident Response
Incident response is the organised process for detecting, containing, investigating, and recovering from cybersecurity incidents — events where a product's security has been or may have been compromised. The EU Cyber Resilience Act requires manufacturers to have incident response capabilities and to notify authorities within strict timeframes when security incidents occur.
Incident response is the organised process for detecting, containing, investigating, and recovering from cybersecurity incidents — events where a product's security has been or may have been compromised. The EU Cyber Resilience Act requires manufacturers to have incident response capabilities and to notify authorities within strict timeframes when security incidents occur.
CVD & Vulnerability ManagementWhat Is Incident Response?
Incident response (IR) is the structured capability that enables an organisation to detect, analyse, contain, eradicate, and recover from cybersecurity incidents — and to learn from them to prevent recurrence. For manufacturers of connected products, security incidents may include: an actively exploited vulnerability in a shipped product; a compromise of the product update infrastructure; a data breach affecting user information collected by the product; or a supply chain compromise that affects product integrity. An effective IR capability requires defined processes, trained personnel, tested playbooks, and pre-established communication channels to regulatory authorities and affected users.
Incident Response Obligations Under the CRA
Article 14 of the CRA establishes specific notification obligations that make incident response capabilities a practical necessity. Manufacturers must notify ENISA within 24 hours of becoming aware of an actively exploited vulnerability in a product, followed by a fuller notification within 72 hours and a final report within 14 days. Meeting the 24-hour window is operationally demanding: the manufacturer must detect the incident, assess its nature and scope, determine that it constitutes an actively exploited vulnerability in a covered product, identify the appropriate ENISA notification channel, and submit the notification — all within one calendar day. Without a pre-established IR process, this timeline is effectively impossible to meet.
How Manufacturers Build CRA-Ready Incident Response
A CRA-ready incident response programme includes: (1) a written IR plan specific to product security incidents, covering detection, triage, escalation, notification, and communication; (2) defined roles and responsibilities — including who owns the ENISA notification obligation; (3) monitored alerting from vulnerability feeds, CVD reports, and threat intelligence sources; (4) pre-drafted notification templates that can be completed and submitted within the 24-hour window; (5) a tested communications plan for notifying affected users after a security incident; (6) regular tabletop exercises to practise the IR plan against realistic scenarios; and (7) a post-incident review process to improve future response. The PSIRT function typically owns product security IR.
Common Mistakes
The most dangerous mistake is conflating IT incident response (which protects the manufacturer's own infrastructure) with product security incident response (which protects users of the manufacturer's products). These are distinct functions requiring distinct plans, stakeholders, and notification obligations. A second error is not having pre-established communication with ENISA and the relevant national CSIRT — discovering the notification process for the first time during an active incident wastes critical hours. Manufacturers also frequently underestimate the user communication dimension: telling affected users clearly what happened, what risk they face, and what action to take is both an ethical obligation and increasingly a regulatory expectation under the CRA and GDPR.
CVD Portal makes Incident Response compliance straightforward.
Public CVD submission portal, acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Free forever for EU manufacturers.
Start your free portalFrequently asked
What is the 24-hour notification deadline under Article 14 of the CRA?+
Article 14(1) requires manufacturers to notify ENISA within 24 hours of becoming aware that a vulnerability in their product is being actively exploited. This early warning notification can be a brief initial alert. It must be followed within 72 hours by a more detailed notification including the product details, vulnerability description, and remediation status. A final comprehensive report is due within 14 days. These deadlines run from the moment the manufacturer becomes aware, not from when they confirm the incident.
Must manufacturers notify users when a security incident affects their product?+
The CRA does not explicitly require individual user notification in all cases, but manufacturers must provide users with information about identified vulnerabilities and available updates. Where a security incident also constitutes a personal data breach, GDPR notification obligations to supervisory authorities (within 72 hours) and potentially to affected individuals apply in parallel. Manufacturers should treat user communication as an expected obligation and prepare templated notifications in advance.
Is a PSIRT the same as an incident response team?+
A PSIRT (Product Security Incident Response Team) is a specialised type of incident response function focused specifically on security vulnerabilities and incidents affecting a manufacturer's products. A general IT incident response team handles security incidents affecting the manufacturer's own IT infrastructure. For CRA compliance purposes, manufacturers need a PSIRT function — or equivalent product security capability — to manage vulnerability reports, CVD processes, and the product-specific incident notification obligations under Article 14.
Related terms
Browse the full CRA Compliance Checklist
See how Incident Response fits into your complete CRA compliance programme.