What is incident response?
Incident response sets out what happens between the first sign of an incident and its review: who assesses, who decides, who reports and who restores operations. The procedure has to be in place before the first incident, because statutory reporting deadlines run from awareness of the incident.
For particularly important entities (besonders wichtige Einrichtungen; "essential entities" in the NIS2 Directive) and important entities, handling security incidents is one of the minimum measures under § 30(2) sentence 2 no. 2 of the BSI Act (BSIG).
When does an event become a security incident?
A security event is an observation that may be relevant to security, such as a series of failed sign-ins or an alert from endpoint detection and response. Under § 2 no. 40 BSIG, a security incident is an event that compromises the availability, integrity or confidentiality of data or services.
Under § 2 no. 11 BSIG, an incident is significant if it has caused or can cause severe operational disruption or financial loss, or considerably harms or can harm other persons. This applies unless an ordinance under § 56(5) BSIG specifies the term. For entities of the types listed in § 30(3) BSIG, Article 3 of Implementing Regulation (EU) 2024/2690 specifies the threshold. Under it, an incident is significant if, for example, it has caused or can cause direct financial loss above 500,000 euros or 5% of the previous year's turnover, whichever is lower.
Set out in writing who classifies an event as an incident and within what time an event must be assessed. Without that rule, the person on duty decides by feel.
What are the phases of incident response?
| Phase | Content |
|---|---|
| Preparation | roles, availability, escalation paths, decision rights, contracts |
| Detection and analysis | reporting channels for staff and technology, initial assessment, severity rating |
| Containment | stop the spread without destroying traces |
| Eradication | remove the cause: compromised accounts, malware, exploited vulnerability |
| Recovery | controlled return to normal operations with increased monitoring |
| Post-incident review | root cause analysis, measures, update of risk assessment and procedure |
NIST SP 800-61 Revision 3 of April 2025 replaced the four-phase model of Revision 2 and maps incident handling to the Functions of the NIST Cybersecurity Framework 2.0. A phase model still works for your own plan; just do not present the four-phase model as current NIST guidance.
Which reporting duties apply after an incident?
| Legal framework | Who it applies to | Deadline | Recipient |
|---|---|---|---|
| GDPR, Article 33 GDPR | controllers in the event of a personal data breach, unless it is unlikely to result in a risk | without undue delay and, where feasible, within 72 hours of becoming aware | competent data protection authority |
| BSIG, § 32 BSIG | particularly important and important entities in the event of a significant security incident | early initial report within 24 hours and report within 72 hours, both from becoming aware; final report one month after the 72-hour report; interim report only on request | joint reporting office of the BSI and the BBK |
| DORA, Article 19 of Regulation (EU) 2022/2554 | financial entities in the event of major ICT-related incidents; classification under Delegated Regulation (EU) 2024/1772 | initial notification within 4 hours of classification as major, at the latest 24 hours after becoming aware. Intermediate report within 72 hours of the initial notification, final report one month after the intermediate report (Article 5 of Delegated Regulation (EU) 2025/301) | competent authority under Article 46 DORA |
| CRA, Article 14 of Regulation (EU) 2024/2847 | manufacturers, for actively exploited vulnerabilities and severe incidents affecting their products, since 11 September 2026 | early warning within 24 hours, notification within 72 hours | CSIRT designated as coordinator, in Germany the BSI, and ENISA via the single reporting platform |
Under § 28(5) BSIG, § 32 BSIG in principle does not apply to providers of public telecommunications networks and services or to energy companies subject to §§ 5c to 5e EnWG. Under § 28(6) BSIG it does not apply to financial entities under DORA; the DORA row applies to them. One incident can trigger several reports at once, for example under § 32 BSIG and as a personal data breach under Article 33 GDPR.
Example: two reporting deadlines, one point in time
Fictional example: a particularly important entity notices an attack on its file server. The sequence, times and contents are invented for illustration.
| Time | What happens | Decision and deadline |
|---|---|---|
| Mon 5 Oct 2026, 07:40 | Endpoint detection and response reports unusual encryption on the file server. | The on-call team assesses; still an event. |
| Mon 5 Oct 2026, 09:10 | Analysis confirms encrypted files and the exfiltration of a folder with HR data. | The incident lead classifies it as a significant security incident and a personal data breach. Early initial report by Tue 6 Oct 2026, 09:10; report under § 32 and under Article 33 GDPR by Thu 8 Oct 2026, 09:10. |
| Mon 5 Oct 2026, 09:30 | The server is disconnected and a memory image is secured. | containment before recovery, so that traces are preserved |
| Mon 5 Oct 2026, 14:00 | The early initial report goes to the joint reporting office. | deadline met |
| Tue 6 Oct 2026, 15:00 | Report under § 32(1) no. 2 BSIG and notification to the data protection authority submitted | final report by 6 Nov 2026; if the incident is ongoing, a progress report takes its place. |
In this example 09:10 counts as the point of awareness, because only the analysis confirms the incident; both deadlines run from then. Record that time, the reasons for the classification and the person who made it. If the breach is likely to result in a high risk to the affected employees, the controller must also inform them under Article 34 GDPR.
What must be in place before the first incident
- availability outside business hours and a deputy arrangement
- who decides to take a production system offline, and who is informed
- a contact list that is available without the directory service and mailboxes, and a communication channel outside the possibly compromised infrastructure
- rules for securing evidence before systems are rebuilt
- an incident response retainer: a framework contract with forensics and recovery providers that agrees capacity, response time and hourly rates in advance
The guide Implementing an ISMS describes where incident response fits when an ISMS is built.
How does incident response differ from business continuity?
Incident response deals with the cause: who got in, through what, and what was changed. Business continuity management deals with the effect: how critical business processes keep running while the cause is still being investigated. In larger incidents both run in parallel and coordinate, for example when a quick restore from backup would overwrite traces. The German BSI Standard 200-4 describes the method for the continuity part.
The post-incident review establishes why the incident was not detected earlier, which control failed and which held, and which assumption in the risk assessment was wrong. Its results feed vulnerability management, risk analysis and exercise planning.
Incident response in Rizzqo
For each system, Rizzqo shows whether it holds personal data and who is responsible for it. That answers the first question for a report under Article 33 GDPR: is personal data involved? Measures from the post-incident review run as tasks that sync both ways with Jira.