--- title: "Creating an Incident Response Plan: Template and Guide" date: 2026-03-03T11:25:00+01:00 author: FAST LTA canonical_url: "https://www.fast-lta.de//en/blog/incident-response-plan-erstellen-vorlage-und-anleitung" section: "Entries: Articles" --- ### The 8 Sections of an Incident Response Plan [\#](#the-8-sections-of-an-incident-response-plan "The 8 Sections of an Incident Response Plan") #### 1. Executive Summary and Purpose [\#](#1-executive-summary-and-purpose "1. Executive Summary and Purpose") **What belongs here:** - Definition: what constitutes an ​“incident” for this organization? A suspicious login attempt? A detected malware find? A data loss? Define this clearly. - Purpose of the plan: fast, structured response to cybersecurity events. - Scope: which systems, departments, and areas does this plan cover? All critical systems? Including branch LANs? - Authorization signatures: who approved this plan and when? **Tip:** The executive summary should fit on one page. It is intended for C‑level executives who do not need technical details. #### 2. Incident Severity Levels [\#](#2-incident-severity-levels "2. Incident Severity Levels") Not all incidents are equally critical. Define a clear classification system: - **SEV 1 (Critical):** Complete failure of critical systems, active ransomware, data loss. Response time: under 15 minutes. Escalation: immediately to CEO and board; start the regulatory clock (NIS2 early warning within 24 hours). - **SEV 2 (High):** Impairment of productive systems, suspicious admin activity. Response time: under 1 hour. Escalation: CIO and security. - **SEV 3 (Medium):** Unusual activity, individual users affected. Response time: under 4 hours. Escalation: IT security team. - **SEV 4 (Low):** Suspicious but blocked activity, false positives. Response time: under 1 day. Escalation: documentation only. **Tip:** Severity should depend on both impact (how many users are affected?) and likelihood (is this a real attack?). #### 3. Roles and Responsibilities [\#](#3-roles-and-responsibilities "3. Roles and Responsibilities") **Incident Commander:** Coordinates the entire response. Clear chain of command, not decision by committee. - Typically the IT security lead or CIO - Responsibility: escalation, decision-making, communication **IT Incident Response Team:** Technical execution. - System administrators, network engineers - Responsibility: isolation, forensics support, recovery **Forensics Lead:** Collection, preservation, and analysis of evidence. - IT security specialist or external consultant - Responsibility: chain of custody, evidence preservation **Legal and Compliance:** Reporting obligations, data protection, liability. - General Counsel or Data Protection Officer - Responsibility: advising on NIS2 reporting (24-hour early warning, 72-hour notification, final report within one month) and GDPR (72-hour notification to the supervisory authority under Article 33, notification of affected individuals under Article 34) **Communications:** Internal and external communication. - HR / PR manager - Responsibility: employee announcements, customer announcements, media **Senior Management Escalation:** Board, CEO, CFO. - Responsibility: board information, business decisions - Note: under NIS2, management bodies must approve and oversee cybersecurity risk measures and can be held personally accountable **Tip:** Document for each role: name, phone, email, and the designated backup. This list must be available OFFLINE, printed and stored in a safe. #### 4. Trigger Criteria [\#](#4-trigger-criteria "4. Trigger Criteria") When is the IR plan activated? Be specific: - Ransomware suspicion (suspicious executable detected, files with unknown extensions) - Active malware detection (EDR alert, ambiguous pattern) - Unauthorized access (suspicious SSH session, RDP login from a high-risk location) - Data loss / exfiltration (unusual data volumes transferred to external destinations) - Denial-of-service attack (DDoS, resource exhaustion) - Physical security incident (server room break-in) #### 5. Escalation Paths [\#](#5-escalation-paths "5. Escalation Paths") **Example for SEV 1:** 1. Alert in the SIEM: wake the team leads (at any time) 2. Incident Commander is informed (under 5 minutes) 3. IT response team begins isolation (under 15 minutes) 4. CEO and board are notified (under 30 minutes) 5. NIS2 early warning to the competent national authority or CSIRT (within 24 hours; in Germany this is the BSI) 6. External forensics are engaged (if not possible internally) **Tip:** ​“Call, don’t email” for SEV 1. Emails get overlooked. Maintain an on-call phone roster. #### 6. Incident Handling: The 6 Phases [\#](#6-incident-handling-the-6-phases "6. Incident Handling: The 6 Phases") **Preparation (before the incident):** - Backups are secured (offline or immutable copy in place) - The recovery environment is ready to deploy - Tools are available (forensics, isolation) **Detection and Analysis (0 to 2 hours):** - The alert is confirmed - Real incident or false positive? - Severity is assigned - The incident is documented (ID, time, description) **Containment (2 to 4 hours):** - Affected systems are isolated - Further spread is prevented - But: do not shut everything down immediately; forensics needs live evidence **Eradication (4 to 24 hours):** - Malware is removed - Attacker access is closed (change all passwords) - Vulnerabilities are remediated **Recovery (1 to 7 days):** - Systems are restored from clean backups - Functionality is verified - Phased return to production **Post-Incident Review (1 to 2 weeks):** - What happened? Why? - What could we have done better? - Documentation, documentation, documentation #### 7. Regulatory Reporting Obligations [\#](#7-regulatory-reporting-obligations "7. Regulatory Reporting Obligations") The NIS2 Directive sets EU-wide deadlines for significant incidents: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month, addressed to the competent national authority or CSIRT. In Germany, NIS2 was transposed by the NIS2UmsuCG (in force since 6 December 2025), and reports go to the BSI. Financial entities additionally follow the DORA incident reporting régime (Regulation (EU) 2022⁄2554, applies since 17 January 2025). If personal data is affected, GDPR Article 33 requires notification of the supervisory authority within 72 hours. **What must be in the IRP:** - Who contacts the authority? (Legal plus security) - How much information do you provide in the early warning? (Enough to meet the requirement, without speculation) - Who are the authority contacts and what is the reporting portal? (Document in advance) - What do you document for regulatory purposes? (Timestamps of all actions, who decided what) **Tip:** The notification is not just a compliance obligation. National authorities and CSIRTs can provide threat intelligence and practical help. #### 8. Communication Plan [\#](#8-communication-plan "8. Communication Plan") Not just internal communication, but external too: **Internal communication (employees):** - Who informs employees that an incident is underway? - How often are updates provided? - What do you say when you do not yet know what is happening? (Honesty beats false reassurance) **External communication (customers):** - When must customers be informed? (Typically when their data is affected or the service is impaired) - What is the template for the customer notification? - Who signs it? (CEO or CFO, not just IT) **Media handling:** - Who speaks with journalists? (One prepared person only) - What is the holding statement for the first hour? **Regulatory communication:** - NIS2 authority or CSIRT (24-hour early warning, 72-hour notification) - Data protection supervisory authority (if personal data is affected, 72 hours) - Insurer (cyber insurance requires fast notification) **Tip:** Write the templates NOW, not during the incident. A sample: ​“We have detected a security event. Our team is working on it. Security is our priority. Details will follow within 24 hours.” --- ### Additional Requirement: Disaster Recovery Plan Available Offline [\#](#additional-requirement-disaster-recovery-plan-available-offline "Additional Requirement: Disaster Recovery Plan Available Offline") The IR plan itself is only half the picture. You also need a linked Disaster Recovery Plan that shows how to restore systems. And this plan MUST be available offline: - Printed copy in the safe (updated quarterly) - Copy in a secure vault or at the bank - Recovery runbooks for every critical system Why offline? Because if your IT is completely down, you cannot access the wiki. You need a physical document showing where the backups are, how to access the recovery environment, and in what sequence systems are restored. --- ### Frequently Asked Questions [\#](#frequently-asked-questions "Frequently Asked Questions") **How often should we update the IRP?** At least annually. Immediately after any major incident. After major system changes (new software, new partner). **What is a ​“good” IRP?** One that is actually used and understood. That means training sessions for the response team and tabletop exercises at least twice a year. **Do small companies also need an IRP?** Yes. An SMB IRP is simpler (perhaps 5 pages instead of 20), but absolutely necessary, especially if the company falls in scope of NIS2 as an important entity. --- ### Further Resources [\#](#further-resources "Further Resources") → IT Resilience Guide (/en/blog/it-resilienz-leitfaden/) → Recovery Runbook (/en/blog/recovery-runbook/) → NIS2 and IT Resilience Requirements (/en/blog/nis2-it-resilienz-anforderungen/) → Tabletop Exercise Ransomware: Instructions and Scenarios (/en/blog/tabletop-exercise-ransomware/) ### GDPR The GDPR (General Data Protection Regulation, EU 2016/679) is the European regulation for the protection of personal data — particularly relevant for IT infrastructure in Art. 5 (principles), Art. 17 (right to erasure), Art. 28 (processors) and Art. 32 (security of processing). [Mehr erfahren →](https://www.fast-lta.de//en/glossary/gdpr) ### DORA DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/dora) ### Disaster Recovery Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery) ### Ransomware Ransomware is malware that encrypts data on infected systems and demands a ransom for decryption — with the goal of forcing organizations and public bodies to pay by paralyzing their operations. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/ransomware) ### GDPR The GDPR (General Data Protection Regulation, EU 2016/679) is the European regulation for the protection of personal data — particularly relevant for IT infrastructure in Art. 5 (principles), Art. 17 (right to erasure), Art. 28 (processors) and Art. 32 (security of processing). [Mehr erfahren →](https://www.fast-lta.de//en/glossary/gdpr) ### Ransomware Ransomware is malware that encrypts data on infected systems and demands a ransom for decryption — with the goal of forcing organizations and public bodies to pay by paralyzing their operations. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/ransomware) ### Disaster Recovery Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery)