How to Build an Incident Response Plan: Step-by-Step Guide with Template

An incident response plan is a written, board-approved document that defines how an organisation detects, contains, and recovers from a cybersecurity incident. German organisations building one in 2026 face a constraint most international templates ignore: the NIS2UmsuCG law starts a legal clock the moment an incident becomes significant, with an early warning due to the Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI) within 24 hours and an incident notification with an initial assessment within 72 hours.

Only 43% of German companies currently rate themselves as well prepared for a cyberattack, down from 50% a year earlier, even though 58% report having suffered damage from one in the past 12 months (Bitkom, Wirtschaftsschutz 2026). This article sets out the elements a complete plan needs, how each response phase becomes a section of the plan, the roles that carry personal legal liability, and a German reporting timeline that fuses NIS2, DSGVO, and BSI obligations into a single clock, plus a template structure a team can copy directly.

What is an incident response plan?

An incident response plan is a written, board-approved document that assigns roles, defines response phases, and sets communication rules for detecting, containing, and recovering from a cybersecurity incident. The plan is the governing document; incident response is the underlying discipline it describes. The fundamentals of incident response cover that discipline in full; this article covers the document that turns it into a repeatable, auditable process.

A plan differs from a playbook in scope. The plan governs the whole program: roles, phases, escalation criteria, and reporting duties. A playbook is one scenario-specific instruction sheet inside that plan, covering a single attack type such as ransomware or a compromised account. Later sections of this guide cover both.

Why does every German organisation need a written incident response plan in 2026?

German organisations need a written incident response plan because most companies are already being hit and most rate their own preparation as inadequate. 58% of German companies suffered damage from a cyberattack in the past 12 months, yet only 43% consider themselves well prepared, down from 50% the year before (Bitkom, Wirtschaftsschutz 2026). That gap between exposure and readiness is exactly what a written plan closes: it moves decisions about isolating a host, notifying a regulator, or briefing the press out of a moment of crisis and into a document tested in advance.

The gap carries legal weight for a large share of the German economy now. Article 21(2)(b) of the NIS2 Directive lists incident handling among the minimum cybersecurity risk-management measures that obligated organisations must implement, alongside business continuity, supply-chain security, and multi-factor authentication. An organisation without a documented incident-handling process is not simply unprepared; it is failing a specific, named legal requirement, not a general best practice.

How does an incident response plan differ from an IT-Notfallplan or business continuity plan?

An incident response plan and an IT-Notfallplan (IT emergency plan) govern different problems. The incident response plan handles cybersecurity incidents specifically: intrusions, data breaches, ransomware, and similar deliberate or malicious events. An IT-Notfallplan, built on the BSI’s business-continuity framework, handles any disruption to critical processes, including a fire, a power outage, or a pandemic, regardless of cause.

	Incident response plan	IT-Notfallplan / business continuity plan
Governs	Cybersecurity incidents specifically	Any disruption to critical business processes
Standard	BSI-Baustein DER.2.1, SANS PICERL, NIST SP 800-61	BSI-Standard 200-4, ISO 22301
Trigger	A detected or suspected compromise	Any event that interrupts a critical process
Core output	Contained, eradicated, and reported incident	Restored business operations within a defined Recovery Time Objective

The distinction has a legal basis, not just a practical one. NIS2 Article 21(2)(b) requires incident handling as one obligation; Article 21(2)(c) separately requires business continuity and crisis management, including regularly tested backup and disaster-recovery procedures. These are 2 distinct, both-mandatory duties under the same law, not 2 names for the same document. ISO 22301, the international business-continuity standard, sets the framework for the business-continuity side; this article covers the incident response side.

What elements does a complete incident response plan contain?

A complete incident response plan contains 8 core elements, each answering a specific operational question during an active incident.

Element	Answers
Scope and objectives	Which systems, data, and business units the plan covers
Severity classification	How the organisation grades an incident (Critical, High, Medium, Low)
Roles and responsibilities	Who does what, and who has authority to make which decision
Communication plan	Who is told what, when, and through which channel
Reporting timeline	Which external deadlines apply, and who owns each one
Playbooks	Step-by-step instructions for specific, recurring scenarios
Tools	Which systems detect, investigate, and execute the response
Testing and lessons learned	How and how often the plan is rehearsed and updated

Severity classification deserves particular attention, because it decides which incidents cross the NIS2 significance threshold and start the 24-hour clock covered later in this guide. A Business Impact Analysis supplies the inputs for that decision: it sets a Maximum Tolerable Period of Disruption and a Recovery Time Objective for each critical process, and the incident response plan reuses those same tiers to decide how urgently to respond and whom to notify.

How do the incident response phases translate into sections of the plan?

Each incident response phase becomes a plan section that fixes one decision in advance. The plan follows the 6-phase PICERL model (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned) formalised by SANS. The phases themselves belong to the incident response discipline explained in the fundamentals article linked above. The plan only records who decides what, by when, and with which artefact.

Phase	Decision the plan fixes in advance	Artefact the plan must contain
Preparation	Which team, tools, and external partners exist before an incident	Contact list, retainer contracts with forensics and legal counsel, tool inventory
Identification	Which criteria turn an alert into an incident, and which incidents count as significant under NIS2	Severity matrix linked to the NIS2 significance threshold
Containment	Who may isolate a host or disable an account, and when evidence preservation takes priority	Containment authority matrix, evidence-preservation rule
Eradication	Which conditions confirm that the attacker has no remaining access	Eradication checklist with sign-off owner
Recovery	Which systems return to production first, and who approves the return	Recovery order derived from the Business Impact Analysis
Lessons Learned	Who owns the review and how quickly corrections flow back into the plan	Post-incident report template with a fixed deadline

The containment row carries the hardest trade-off. Isolating a compromised host protects the rest of the network, and it also destroys volatile evidence the forensic team needs later. A plan that assigns this decision to a named role before an incident removes the trade-off from a moment of pressure.

NIST reframed the same territory in April 2025. Special Publication 800-61 Revision 3 withdrew the older 4-phase lifecycle and maps incident response activities onto the 6 functions of the NIST Cybersecurity Framework (CSF) 2.0 (Govern, Identify, Protect, Detect, Respond, Recover). An organisation already aligned to CSF 2.0 can label the plan sections with CSF functions instead; the decisions in the table stay the same.

Which roles and responsibilities belong in an incident response plan?

An incident response plan assigns 6 roles, each with a distinct scope of authority and, in Germany, a distinct level of legal exposure.

Role	Responsibility	German-specific note
Incident Commander	Leads the response, allocates tasks, and tracks the reporting clock	Often the SOC lead or a rotating on-call security manager
Technical Lead	Directs forensic analysis, containment, and eradication	Works directly with the SIEM and SOAR consoles
Communications Lead	Manages internal updates, press statements, and customer notices	Coordinates with legal counsel before any public statement
Data Protection Officer (Datenschutzbeauftragter, DPO)	Assesses the notification duty under Article 33 of the EU General Data Protection Regulation (Datenschutz-Grundverordnung, DSGVO) and drafts the report to the supervisory authority	A legally mandated role for many German companies, independent of NIS2 status
Geschäftsführung (managing directors)	Approves the plan and authorises major decisions such as a service shutdown	Keeps final responsibility under § 38 BSIG even when tasks are assigned to others; liable to the company for culpable breaches under § 43 GmbHG (§ 93 AktG for an AG board)
External counsel and forensics	Advises on legal exposure, evidence handling, and law enforcement contact	Engaged in advance through a retainer, not sourced during the incident

Neither the NIS2 Directive nor the BSIG requires appointing a dedicated Chief Information Security Officer (CISO); the roles above can sit with existing IT or SOC leadership as long as the incident-handling capability itself exists. Staffing all 6 roles internally is difficult under current market conditions: 79,000 IT positions stood unfilled in Germany in 2026, and 78% of companies report an active shortage of IT specialists (Bitkom, Der Arbeitsmarkt für IT-Fachkräfte, 2026 edition). Smaller organisations commonly cover the technical and communications roles through a managed SOC or an external CISO arrangement rather than building a full team in-house.

How do you build the German reporting timeline into the plan?

A German incident response plan builds its reporting timeline around a single event: the moment an incident becomes significant. Under Article 23(3) of the NIS2 Directive, an incident qualifies as significant when it has caused or is capable of causing severe operational disruption or financial loss, or when it has affected or is capable of affecting other persons through considerable damage. From that moment, NIS2, DSGVO, and BSI obligations run on the same clock rather than 3 separate ones.

Time from significance	NIS2UmsuCG obligation	DSGVO obligation	Owner
Immediately	Incident Commander activates the plan	Data Protection Officer opens the Article 33 risk assessment	Incident Commander, DPO
Within 24 hours	Early warning to the BSI, stating whether unlawful or malicious action or a cross-border impact is suspected	Internal risk assessment continues; no separate 24-hour DSGVO clock	Incident Commander
Within 72 hours	ncident notification to the BSI with an initial assessment of severity and impact and, where available, indicators of compromise	Notification to the competent supervisory authority under Article 33, unless the breach is unlikely to create risk to individuals	Incident Commander, DPO
Without undue delay after high risk is confirmed	No separate NIS2 deadline event at this point	Notification to affected individuals under Article 34, when the breach poses a high risk to their rights and freedoms	DPO, Communications Lead
Within 1 month of the 72-hour notification	Final report to the BSI: root cause, impact, and mitigation measures taken	No separate DSGVO deadline event at this point	Incident Commander, Technical Lead

Germany’s NIS2 transposition, the NIS2UmsuCG, applies to organisations with more than 50 employees or annual turnover above €10 million, and to critical-infrastructure operators regardless of size. Fines for a besonders wichtige Einrichtung (essential entity) reach up to €10 million, and for a wichtige Einrichtung (important entity) up to €7 million; for entities with a worldwide turnover above €500 million, the cap becomes 2% or 1.4% of that turnover.

What does an incident response playbook look like for a specific scenario?

An incident response playbook translates the plan’s general phases into scenario-specific, step-by-step instructions for a single, recurring attack type. A plan typically holds multiple playbooks side by side, one per scenario the organisation expects to face.

Scenario	Trigger signal	First 3 actions	Owning phase
Ransomware	Mass file-encryption events, unusual processes writing ransom notes	Isolate affected hosts, disable compromised accounts, activate offline backups	Containment
Compromised account	Impossible-travel logins, privilege escalation outside a change window	Terminate active sessions, force a credential reset, review logs for lateral movement	Identification
DDoS	Sudden traffic spike, connection-table exhaustion on edge devices	Activate the scrubbing provider, notify the internet service provider, switch to pre-agreed emergency capacity	Containment
Data exfiltration	Large outbound transfer to an unfamiliar domain, data-loss-prevention alert	Block the destination, preserve logs as evidence, assess the DSGVO Article 33 notification duty	Reporting

Each of these scenarios can run largely on its own once triggered, provided the organisation has automated the response in advance. A dedicated SOAR playbook covers how that automation works in detail: enrichment against threat intelligence, identity containment through the directory service, and case consolidation onto a single analyst dashboard.

What role do SIEM and SOAR play in executing the plan?

A Security Information and Event Management (SIEM) system supplies the evidence layer the plan depends on. It collects and stores logs on infrastructure kept separate from the production environment, so log data survives even when an attacker destroys local systems during encryption. That separation is what makes the BSI’s 72-hour reporting window achievable rather than aspirational, and it is the practical backbone behind BSI-Baustein DER.2.1’s requirement to document the handling of security incidents.

A Security Orchestration, Automation, and Response (SOAR) platform executes the playbooks the plan defines. When the SIEM correlates events into a confirmed incident, the SOAR platform runs the predefined sequence automatically, isolating hosts and disabling accounts without waiting on manual review, and opens a case file that becomes the incident timeline referenced throughout this guide.

Speed produced this way is measurable. IBM’s Cost of a Data Breach Report 2025 puts the global average breach lifecycle, the combined time to identify and contain an incident, at 241 days, the lowest figure recorded in 9 years, and found that organisations using AI and automation extensively cut their average breach cost by roughly $1.9 million and shortened that lifecycle by 80 days compared to organisations that do not. Context and AI in incident management sharpen that automated response further: enriching an alert with asset criticality and ownership data from a configuration management database (CMDB) cuts false positives before a SOAR playbook ever executes.

How do you test an incident response plan?

An organisation tests an incident response plan through tabletop exercises: structured discussions where a facilitator walks the response team through a simulated scenario without touching production systems. A tabletop exercise verifies that every role in the plan knows their responsibilities and that the communication tree actually reaches the right people, gaps that a document review alone cannot surface. Standard guidance treats the plan as a living document and recommends reviewing it on a quarterly basis, updating it as staff, infrastructure, and business processes change.

Testing carries a specific evidentiary weight in Germany. Operators of critical facilities (Betreiber kritischer Anlagen) must prove their security measures to the BSI every 3 years through security audits, inspections, or certifications under § 39 BSIG, with the first deadline set by the BSI no earlier than 3 years after an organisation first qualifies. Besonders wichtige Einrichtungen can be ordered by the BSI to undergo audits at any time. An untested plan sitting in a document repository gives an auditor nothing to verify; a dated record of a tabletop exercise does.

What evidence do auditors expect for an incident response plan?

Auditors reviewing a German incident response plan expect evidence in 3 categories: a documented process, tested execution, and retained records. The documented process maps to BSI-Baustein DER.2.1 (Behandlung von Sicherheitsvorfällen), which sets out how an organisation should structure the handling of security incidents inside the broader IT-Grundschutz framework. Tested execution means dated records of tabletop exercises or live drills, not the plan document alone. Retained records means the SIEM’s log archive, held separately from production and readable months after an incident closes, since that archive is what turns a NIS2 final report into a documented reconstruction rather than a best-effort guess.

Critical-infrastructure (KRITIS) operators face an additional layer: § 39 BSIG sets separate evidence duties for these organisations, replacing the now-repealed § 8a BSIG, and typically requires proof at shorter, more frequent intervals than the general NIS2 3-year window applies.

Frequently asked questions

Is an incident response plan legally required in Germany? Yes, an incident response plan is effectively required for NIS2-obligated organisations in Germany. Article 21(2)(b) of the NIS2 Directive lists incident handling among the minimum cybersecurity risk-management measures that besonders wichtige Einrichtungen and wichtige Einrichtungen must implement, and KRITIS operators face separate evidence duties under § 39 BSIG. Organisations outside NIS2 scope face no equivalent statutory mandate, though DSGVO Article 33’s 72-hour reporting clock is difficult to meet without one.

What is the difference between an incident response plan and an incident response playbook? An incident response plan is the complete governing document: roles, phases, communication rules, and the reporting timeline. An incident response playbook is one scenario-specific instruction sheet inside that plan, covering a single attack type such as ransomware or a compromised account. A plan typically contains several playbooks, one per major scenario the organisation expects to face.

How often should a company update its incident response plan? A company should update its incident response plan at least once a year, and immediately after any significant incident, infrastructure change, or new regulatory obligation. Organisations that can sustain it review the plan quarterly, treating it as a living document rather than a static file.

Who is responsible for the incident response plan in a German company? Responsibility for the incident response plan sits with the Geschäftsführung (managing directors), even though day-to-day ownership typically sits with IT or SOC leadership. Under § 38 BSIG, the Geschäftsführung keeps the final responsibility for the underlying risk-management duty even when it assigns the work to others, and managing directors who culpably breach that duty are liable to their own company for the resulting damage under § 43 GmbHG, or § 93 AktG for a stock corporation’s board.

Summary

A German incident response plan works only when it fuses 2 things most templates keep apart: the operational phases of Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned, and a reporting timeline that satisfies NIS2, DSGVO, and BSI obligations inside the same 24-hour and 72-hour windows. Only 43% of German companies currently call themselves well prepared for a cyberattack, and 58% have already suffered damage from one, according to Bitkom’s Wirtschaftsschutz 2026 survey. Writing the plan is the first step; assigning roles that carry real legal weight, rehearsing the plan through tabletop exercises, and keeping SIEM log evidence outside the blast radius of an attack are what make it hold up under both an active incident and a regulator’s audit.