Incident Response
Incident response is the organised handling of a security incident from detection to recovery. The NIST phases, the NIS2 and CRA deadlines, and what to prepare up front.
Updated This page as Markdown
In short
Incident response is the structured process with which an organisation detects, analyses, contains, eradicates and recovers from a security incident, and learns from it afterwards. NIST SP 800-61 describes the lifecycle; NIS2 Article 23 and the Cyber Resilience Act Article 14 add legal reporting duties with a 24-hour early warning and a 72-hour notification. The quality of the response is decided before the incident, by the plan, the roles and the monitoring that exist when it starts.
What is incident response?
Incident response is what an organisation does when something has gone wrong with its security: a system is compromised, data has leaked, ransomware is spreading, or a product in the field is being attacked. The aim is to limit the damage, restore normal operation, meet reporting duties and prevent a repeat.
NIST SP 800-61 Rev. 2 described the lifecycle in four phases that most teams still use: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Rev. 3 (2025) reframes incident response as part of cybersecurity risk management and maps the activities to the six functions of the NIST Cybersecurity Framework 2.0, which makes the point that preparation (Govern, Identify, Protect) and detection (Detect) are as much part of incident response as the response itself.
Where is it defined?
NIST SP 800-61 is the most widely used reference for the process. In the EU, the legal duties come from NIS2, Directive (EU) 2022/2555: Article 21(2)(b) requires incident handling as a risk management measure and Article 23 sets the reporting duties for significant incidents (early warning within 24 hours, incident notification within 72 hours, final report within one month). For manufacturers of products with digital elements, the Cyber Resilience Act, Regulation (EU) 2024/2847, adds Article 14: actively exploited vulnerabilities and severe incidents affecting the product are reported via the ENISA single reporting platform with the same 24-hour and 72-hour rhythm. For vehicles, UN R155 paragraph 7.2.2.2 (g) requires processes to detect and respond to attacks, and paragraph 7.4 requires reporting to the approval authority. ISO/IEC 27001 Annex A and ISO/SAE 21434 Clause 13 cover the same process for their domains.
What it means in practice
Incidents are decided in the first hours, and the first hours go well only if the decisions were made before. Who may pull the plug on the production network? Who speaks to customers? Where is the contact list when the mail server is encrypted? Which authority do you report to, and who writes the report with the technical facts in a form a non-engineer can read? Companies that have exercised this once, even on a tabletop, respond in a different league from those who read the plan for the first time during the incident.
The second decisive factor is detection. The 24-hour clock in NIS2 and the CRA starts when you become aware, and attackers typically have days to weeks inside a network before anyone notices. Continuous monitoring with a SOC turns “we found out from the ransom note” into “we isolated the first host on Friday night”. For manufacturers the same applies to the product: a vulnerability handling process that monitors advisories for the components in your software bill of materials is what makes the CRA deadline achievable.
Common misunderstandings
Incident response is not the same as restoring from backup. Restoring before you know how the attacker got in and whether they are still there brings them back with the data. It is also not finished when systems are back: the post-incident review, the report to the authority and the fixes to detection and architecture are part of the process. And it is not only an IT topic: for a device maker, an exploited vulnerability in the product is an incident with its own reporting duty, even if no internal system was touched.
FAQ
Frequently asked questions
What has to be reported, and how fast?
Under NIS2 Article 23, essential and important entities report significant incidents to their CSIRT or competent authority: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report within one month. Under the Cyber Resilience Act Article 14, manufacturers report actively exploited vulnerabilities and severe incidents affecting their products: early warning within 24 hours, notification within 72 hours, final report later. Both clocks start when you become aware, which makes detection part of the legal duty.
What belongs in an incident response plan?
Who is on the team and how to reach them at 3 a.m.; who decides on isolating systems, shutting down production and paying nobody; how evidence is preserved; which external contacts exist (forensics, legal counsel, insurer, authorities); the reporting templates and deadlines; and playbooks for the likely cases such as ransomware, a compromised mail account or a lost device. Keep a printed copy; the incident may take your file server with it.
Does Zyberum do incident response?
Our managed SOC Zyberdome covers the detection and first-response part: monitoring, triage, alerting you with a recommended action and isolating affected endpoints where agreed. We also help write and exercise the incident response plan, including the NIS2 and CRA reporting procedures, and we support manufacturers whose products are affected by an incident with the technical analysis. Large-scale forensics and legal negotiation are done with specialised partners of your choice.
Sources
- NIST SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST SP 800-61 Rev. 2 Computer Security Incident Handling Guide
- EUR-Lex: Directive (EU) 2022/2555 (NIS2), Article 23 reporting obligations
- EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14 reporting obligations of manufacturers
Related pages
- GlossarySOC (Security Operations Center)A SOC monitors systems around the clock, detects attacks and coordinates the response. What it consists of, what NIS2 expects, and when a managed SOC is better.
- GlossaryNIS2NIS2 (Directive (EU) 2022/2555) sets cybersecurity duties for essential and important entities in 18 sectors. Scope, ten measures, reporting deadlines, German law.
- InsightsThe CRA 24-Hour Reporting Duty: What Manufacturers Must DoThe Cyber Resilience Act reporting duty applies since 11 September 2026. The deadlines (24 hours, 72 hours, 14 days, one month), what triggers them, and how to be ready.
- InsightsThe Ten NIS2 Measures of Article 21(2), ExplainedNIS2 Article 21(2) lists ten risk management measures every affected entity must implement. What each one means, how they map to German law, and where to start.
- ServicesEnterprise-grade protection. SMB-friendly price.24/7 managed security for SMBs: SentinelOne endpoint protection, SOC analysts, incident response and reports at a fixed monthly price per device.
