Creating an Incident Response Plan: Template and Practical Example

Why an incident response plan is not a nice-to-have

The ransomware attack hits the company on Thursday evening at 10:15 PM. The IT manager notices it on Friday morning when the first employees can no longer log in. He calls the managing director, who is currently at a trade show. The managing director asks: What should we do? The IT manager knows the technical side, but organizationally all the basics are missing. Who informs the customers? Who talks to the press if they call? Who reports to the BSI? Who decides whether the ransom is paid? And who coordinates all of this while IT simultaneously tries to contain the damage?

Without an incident response plan, these are all open questions at a moment when you have no time for open questions. Every minute you spend clarifying responsibilities is a minute in which the attack can spread, deadlines can pass, and the trust of customers and partners can erode.

An incident response plan, or IRP for short, solves this problem. It defines in advance who does what, in what order, with what resources, and through which communication channels. It is not a theoretical document for the drawer but an operational guide that must work in a crisis.

NIS2 explicitly requires the management of security incidents in Article 21 as one of the ten minimum measures. ISO 27001 dedicates Controls A.5.24 through A.5.28 to the topic. And GDPR assumes with its 72-hour reporting deadlines that you have a functioning reporting process in place. An IRP is therefore not only operationally sensible but also a regulatory requirement.

What an incident response plan is and what it is not

An IRP is not a general emergency plan, not a business continuity plan, and not a disaster recovery plan. It is delineated as follows:

In practice, these documents interlock. During a severe ransomware attack, you start with the IRP, activate the BCP in parallel to maintain business operations, and use the DRP for technical recovery. The IRP is the document that comes into play first and controls the initial response.

A good IRP for a mid-market company is 15 to 25 pages. Not 5 (too superficial) and not 80 (nobody reads it in an emergency). It must be written so that someone under stress can find the relevant information in under two minutes. Clear structure, checklists, contact lists, and decision trees instead of flowing text.

Structure and outline of an IRP

A complete incident response plan is divided into eight sections. Each section has a clear function and should be independently usable, so you can jump directly to the relevant chapter in an emergency.

Section 1: Purpose and scope

Here you define what the plan covers and what it does not.

Purpose: The IRP describes the structured process for detecting, assessing, containing, eradicating, and reviewing security incidents in the company.

Scope: All IT systems, networks, and data of the company, including cloud services and externally hosted systems. Physical security incidents (break-in, fire) are addressed in the separate crisis management plan, unless they have an IT component.

Definition of security incident: A security incident is any event that actually or potentially impairs the confidentiality, integrity, or availability of the company's information assets.

Section 2: Roles and responsibilities

The heart of the IRP. This is where it is defined who takes on which task. In a company with 50 to 200 employees, four core roles are required, with individuals able to hold multiple roles.

Role 1: Incident Manager

The incident manager is the central coordination point during an incident. They have overall responsibility for incident handling and make operational decisions.

In a company with 80 employees, the incident manager is often the IT manager or the ISB. What matters is that this person has decision-making authority without having to ask executive management for every measure. If the incident manager decides at 10 PM to disconnect the network from the internet, that must be within their authority.

Role 2: Technical Response Team

The team that does the operational work: analysis, containment, eradication, recovery.

For a mid-market company, this realistically means: two to three IT employees from the existing team plus an external service provider who can be brought in for severe incidents. Tools like ISMS Lite help maintain roles, contact details, and escalation levels centrally, so all information is immediately available in an emergency. ab 500 Euro pro Jahr oder als Einmalkauf für 2.500 Euro, ohne Seat-Lizenzen oder versteckte Kosten gets you all modules including incident management. This service provider should be contracted before an emergency, not sought during a crisis. A retainer contract with an incident response provider costs a low four-figure amount per year and secures response times of a few hours. The requirements for external partners should be documented in a supplier security policy.

Role 3: Communications Lead

Underestimated and decisive in an emergency. Someone must manage internal and external communications while the technical team works on the incident.

In many mid-market companies, there is no PR department. Then this role falls to executive management or a trusted senior leader. What matters is that exactly one person is responsible for communications. When three different people make different statements, it escalates the crisis.

Role 4: Management Liaison

The link between the incident response team and executive management.

Section 3: Escalation levels

Not every incident requires the same level of attention and resources. Three clearly defined escalation levels help calibrate the response proportionally to the incident.

Level 1: Standard Incident

Level 2: Elevated Incident

Level 3: Crisis

Section 4: Process phases

The operational core of the IRP describes the six phases of incident handling. Each phase has clear entry conditions, activities, and outcomes.

Phase 1 - Detection and Reporting: Security incidents are detected through technical monitoring, employee reports, or external tips. Every report is recorded in the ticket system and assigned to the incident manager. Goal: Within 15 minutes, an initial assessment exists on whether it is a real incident.

Phase 2 - Initial Assessment and Classification: The incident manager assesses the incident using the severity scale (1-10) and assigns the appropriate escalation level. They activate the corresponding roles and inform participants. Goal: Within 30 minutes, severity, escalation level, and activated resources are established.

Phase 3 - Containment: The technical team stops the incident from spreading. Short-term measures (isolate systems, lock accounts) are implemented immediately. Long-term measures (temporary workarounds, forensic capture) follow in parallel. Goal: The spread is stopped, evidence is secured.

Phase 4 - Eradication: The cause of the incident is identified and eliminated. Malware is removed, vulnerabilities are patched, compromised credentials are rotated. Goal: The attack vector is closed, all artifacts are removed.

Phase 5 - Recovery: Systems are brought back online step by step, starting with the most business-critical. Each system is intensively monitored after startup. Goal: Normal operations are restored, elevated monitoring is in place.

Phase 6 - Post-Incident Review: Within two weeks of completion, a lessons-learned workshop takes place. Incident documentation is finalized. Improvement measures are defined, prioritized, and put into implementation. Goal: The IRP and security measures are improved based on insights gained.

Section 5: Communication plan

Communication during a security incident is at least as important as the technical response. Poor communication amplifies crises; good communication limits damage. The communication plan governs who informs whom, when, and through which channel.

Internal communication:

External communication:

Messaging guidelines:

Define in advance what may and may not be communicated externally. As a ground rule:

• Confirm the incident factually without revealing technical details
• Describe measures taken at a high level
• Do not disclose information about the attack vector or the attackers
• Make no statements about the extent of damage before the analysis is complete
• All external communication is approved by the communications lead before sending

A prepared messaging template for the most common case, a ransomware attack, could be structured as follows:

To customers: "On [date], we detected a security incident in our IT infrastructure. We immediately initiated countermeasures and are working with external specialists on investigation and remediation. [Specific note on impact to the customer]. We will inform you as soon as further findings are available."

To press: "We can confirm that there has been a security incident. The investigation is ongoing. We are cooperating with the relevant authorities. To protect the ongoing investigation, we cannot share further details at this time."

Section 6: Contact list

The most important page of the entire plan. In a crisis, every participant must be reachable in under one minute. This list must be kept current and available both digitally and in print - because during a ransomware attack, the digital address book may not be accessible.

Print this list and place it in at least three physical locations in the company: IT manager's office, executive management office, and server room. If IT is encrypted and you only stored the numbers digitally, you face an avoidable problem.

Section 7: Tools and resources

List which tools and resources are available to the incident response team. These include:

Technical tools:

• SIEM system: [Name, access]
• EDR solution: [Name, admin access]
• Forensics tools: [Live USB, disk imaging software]
• Network analysis: [Wireshark, tcpdump, Netflow analysis]
• Log management: [Central log server, access]
• Backup system: [Name, access, location of offline backups]

Organizational resources:

• BSI reporting form: [URL, credentials]
• Data protection authority reporting form: [URL, credentials]
• Incident documentation template: [Storage location]
• Communication templates: [Storage location]
• Retainer contract external IR provider: [Contract number, activation process]
• Cyber insurance policy: [Contract number, covered services, claims process]

Fallback communication: What happens when email and Teams/Slack no longer work? Define an alternative communication channel. This can be a Signal group, a private WhatsApp channel, or in an emergency simply phone calls. The channel must be set up in advance and known to all participants.

Section 8: Maintenance and testing

An IRP is a living document. It must be regularly updated and tested, or it will become outdated and fail in an emergency.

Review cycle: At least annually, additionally after every actual incident and for significant changes to IT infrastructure or organizational structure.

Responsible for maintenance: The ISB or the designated incident manager.

Versioning: Every change is versioned. The current version is clearly marked. Old versions are archived but not deleted.

A sample IRP to take away

Here is the compressed structure of an IRP that you can use as a starting point for your own document. Replace the placeholders with your company-specific data.

Cover page and metadata

Document outline

1. Purpose and Scope (1 page)

   • Why this plan exists
   • Which systems and locations are covered
   • Definition of security incident
   • Delineation from BCP, DRP, and crisis management plan

2. Roles and Responsibilities (2-3 pages)

   • Incident Manager (including authorities and deputy)
   • Technical Response Team (including minimum staffing)
   • Communications Lead
   • Management Liaison
   • External Partners (IR provider, attorney, insurance)

3. Severity Scale and Escalation Levels (2 pages)

   • Severity 1-10 with examples
   • Level 1 Standard, Level 2 Elevated, Level 3 Crisis
   • Activated roles per level
   • Response times per level
   • Authorities per level

4. Process Phases (3-4 pages)

   • Phase 1: Detection and Reporting
   • Phase 2: Initial Assessment and Classification
   • Phase 3: Containment (short-term and long-term)
   • Phase 4: Eradication
   • Phase 5: Recovery
   • Phase 6: Post-Incident Review and Lessons Learned
   • Per phase: Checklist with concrete tasks

5. Communication Plan (2-3 pages)

   • Internal communication matrix
   • External communication matrix
   • Messaging guidelines (prepared for ransomware, data leak, DDoS)
   • Approval process for external communications

6. Reporting Obligations (1-2 pages)

   • NIS2: Deadlines, reporting portal, content
   • GDPR: Deadlines, reporting portal, content
   • Decision tree: Is the incident reportable?

7. Contact List (1 page)

   • All roles with phone numbers (work + private)
   • External service providers and authorities
   • Fallback communication channel

8. Tools and Resources (1 page)

   • Technical tools with access information
   • Forms and templates with storage locations
   • Fallback systems and offline resources

9. Appendix (2-3 pages)

   • Incident documentation template
   • Initial assessment checklist
   • Reporting obligation checklist
   • Change history

Testing the IRP: Practice makes the difference

An IRP that has never been tested gives you a false sense of security. You believe you are prepared and discover in an emergency that phone numbers are outdated, authorities are not clarified, and half the team does not know where the plan is.

Test method 1: Tabletop exercise

The simplest and most effective method. All participants sit together (or on a video call) and walk through a scenario without actually touching systems.

Conducting a tabletop exercise:

Preparation (1 hour):

• Select and write out a scenario (ransomware on Friday evening is a classic)
• Prepare a timeline with injections (new information fed in during the exercise)
• Designate an observer to take notes

Execution (2-3 hours):

• Moderator describes the initial situation
• Participants explain what they would do, based on the IRP
• Moderator injects new information (the managing director is unreachable, the backup server is also encrypted, the press is calling)
• Participants react to the new developments
• Observer notes gaps, delays, and ambiguities

Debrief (1 hour):

• What worked?
• Where were there ambiguities or blockages?
• What information was missing?
• What adjustments to the IRP are necessary?

A concrete tabletop scenario:

Thursday, 10:15 PM. The night shift warehouse worker notices that the inventory management system is no longer responding. He calls the IT on-call service.

Injection 1 (10 minutes): The IT employee discovers a ransomware note on the server. The attackers demand EUR 200,000 in Bitcoin. Three more servers are also encrypted.

Injection 2 (30 minutes): Investigation shows the backup server is also affected. The last clean offline backups are two weeks old. The ERP system with all customer data is encrypted.

Injection 3 (60 minutes): A journalist from a regional newspaper calls asking about the cyberattack. Apparently an employee posted about it on social media.

Injection 4 (90 minutes): The attackers post excerpts from your customer database on the darknet as leverage. Names, addresses, and order histories of 5,000 customers are publicly visible.

This scenario tests nearly all aspects of the IRP: detection outside business hours, escalation, containment, communication (internal, external, press), reporting obligations (NIS2 and GDPR), and strategic decisions (ransom yes or no). In ISMS Lite, such exercise scenarios can be documented and resulting measures tracked directly as tickets.

Test method 2: Simulated incident

One step further is a simulated incident where actions are actually carried out, though in a controlled environment:

• A simulated phishing attack is sent to the company (coordinated with management beforehand)
• Detection and reporting by employees is observed
• The incident response process is run through as if it were a real incident
• Only after completion of the initial assessment is it revealed that it was an exercise

This method is more intensive but yields more realistic results because participants act under real stress.

Test frequency

The five most common weaknesses in incident response plans

From practice, typical patterns emerge where IRPs fail in an emergency:

Weakness 1: Outdated contact information. The most common and simultaneously most avoidable error. Employees change departments, leave the company, change their phone number. If in an emergency you call the incident manager and a stranger answers, you have a problem that a quarterly contact list check would have completely prevented.

Weakness 2: Unclear authorities. The IRP says the incident manager decides on containment. But may they disconnect the network from the internet if that stops production? May they engage an external service provider for EUR 15,000 without consultation? If authorities are not explicitly documented and approved by management, they lead to delays and conflicts in an emergency.

Weakness 3: No fallback communication channel. When the entire IT is encrypted, email and Teams no longer work either. Without a pre-defined alternative channel - be it a messenger group, a phone tree, or a physical meeting - coordination breaks down.

Weakness 4: Missing engagement of executive management. When executive management has never read the IRP and first hears about reporting obligations and escalation levels during a crisis, the understanding of urgency is missing. This is exactly why the topic of awareness for executives is so important. Executive management must know the plan, understand their own role, and ideally have participated in at least one tabletop exercise.

Weakness 5: The plan is stored on the encrypted system. An irony that occurs more often than you would think: The IRP exists only as a digital document on the file server, which is not accessible during a ransomware attack. Print the plan, store it at multiple physical locations, and ensure at least one person has the contact list saved on their personal smartphone.

From blank page to finished IRP: A realistic timeline

If you are starting from zero and want to create a complete IRP, it is not a month-long project but not a matter of one hour either. Here is a realistic timeline for a company with 50 to 200 employees:

After eight weeks, you have a functional IRP. It will not be perfect, and it does not need to be. What matters is that it exists, that the relevant people know it, and that it is regularly tested and improved.

Every tabletop exercise will uncover weaknesses, every actual incident will require adjustments, and every organizational update will necessitate revisions. This is not a sign of immaturity but of a living process. An IRP that does not change is an IRP that is not being used.

Further reading

• Detecting, assessing, and reporting a security incident - the complete process
• Creating a recovery plan: Guide with template for SMEs
• IT emergency handbook: Structure, content, and PDF template
• Planning and conducting a tabletop exercise: How to test your emergency plan
• NIS2 reporting deadlines overview: 24h, 72h, 1 month - what is due when

The most important step is the first one: Sit down and write who gets called during a security incident and what that person should then do. Everything else builds on that.