Creating an Incident Response Plan: Template and Guide

The 8 Sections of an Incident Response Plan #

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 #

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 #

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 #

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 #

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 #

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 #

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) ²⁰²²⁄₂₅₅₄, 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 #

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 #

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 #

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 #

→ 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/)