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.

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.

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.

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.