Incident response plan: outline, phases and roles

This guide gives you an outline you can adopt right away, explains roles and escalation and shows what to watch for in production environments. The examples are invented.

What the law and standards require

• BSIG: § 30(2) no. 2 BSIG (German BSI Act) lists incident handling as a minimum measure for important and essential entities. It is based on Art. 21(2)(b) NIS2 Directive.
• Implementing Regulation (EU) 2024/2690: For certain digital services, such as cloud and data center providers or managed service providers, it gets specific. Under Annex point 3.1, you need a policy with roles, responsibilities and procedures for detection, analysis, containment, recovery, documentation and reporting. Point 3.1.2 explicitly names communication plans for escalation and reporting, escalation schemes, contact lists and templates. For all other entities, this is a good benchmark.
• Reporting duties: For significant incidents, § 32 BSIG requires an early warning within 24 hours of becoming aware, an incident notification within 72 hours and a final report no later than one month after the notification. Manufacturers report under Art. 14 CRA, controllers report personal data breaches under Art. 33 GDPR. Your plan has to contain these channels.
• BSI and standards: The IT-Grundschutz module DER.2.1 "Handling security incidents" describes the approach from the BSI's point of view. ISO/IEC 27001 lists controls 5.24 to 5.28 in Annex A, from planning to the collection of evidence.

The six phases

The division into phases is common practice; it goes back to NIST SP 800-61 Rev. 2, which grouped the same steps into four phases (Revision 3 of April 2025 maps the tasks to the functions of the NIST Cybersecurity Framework 2.0). In substance you also find it in Implementing Regulation (EU) 2024/2690, Annex points 3.5 and 3.6.

1. Preparation. Roles, contact lists, emergency access, logging, backups and exercises are in place before anything happens.
2. Detection and analysis. A report or an alert is assessed: is it an incident, how severe is it, what is affected? From here, the clock runs for any reporting deadlines.
3. Containment. The spread is stopped, for example by separating network segments, locking accounts or switching off remote access. Evidence is secured before systems are rebuilt.
4. Eradication. The cause is removed: malware, compromised credentials, open vulnerabilities.
5. Recovery. Systems return to operation step by step, checked, from clean backups and under observation.
6. Lessons learned. What went well, what went badly, what was the cause, what do we change? The results feed into the plan, the risk assessment and your measures.

An outline for your plan

The following outline has proven itself. Keep the main part short and move details to annexes, so nobody has to leaf through pages during an incident.

Roles and escalation

• Incident manager: leads the incident, keeps the log and makes operational decisions. One person with a deputy, not "IT".
• Technical team: IT, OT and, if you have one, an external provider for incident response or forensics.
• Management: decides on shutdowns that affect operations, on reports and on external communication.
• Data protection: checks whether personal data is affected.
• Communications: approves texts for staff, customers and the press.

Tie escalation to severity levels. An example: the technical team handles level 1 alone, from level 2 the incident manager is informed, from level 3 management, and at level 4 the crisis team convenes. Write down who can be reached outside business hours and who decides when nobody can be reached.

Contact lists that work in an emergency

• Internal: incident manager, deputies, management, IT, OT, data protection, communications, with mobile numbers.
• External: IT service provider, machine and plant suppliers, forensics provider, cyber insurer, legal counsel.
• Authorities: the reporting office under § 32 BSIG, the data protection authority, the police. In Germany, each federal state has central cybercrime contact points for businesses (ZAC).
• Available offline: a printout is kept in two places. If email and the phone system are down, a list on the network does not help.
• Tested: call the numbers at least once a year. Outdated contacts are the most common gap found in exercises.

OT specifics

In production, priorities differ from office IT. Your plan has to address this explicitly.

• Safety before availability before confidentiality: people and plant first. Shutting down can be more dangerous than controlled continued operation.
• Shutdowns only by agreement: operations has a say in network separation and shutdowns. Record in advance where you can separate without endangering processes, typically at the boundaries between zones.
• Plan for island operation: can the line keep running without the MES, without central user management and without remote access?
• Supplier remote access: how is it blocked at once, and who approves it again?
• Recovery: controller programs, project files and configurations need their own tested backups. Record who may restore them and whether the manufacturer has to be present.
• Evidence: many controllers keep hardly any logs. A passive network capture at the zone boundaries helps with the analysis.

An example from industry

The example is invented. A plastics processor with three lines receives an alert from its IT service provider at night: files on the file server are being encrypted.

• Detection: at 2:30 a.m., the on-call engineer rates the incident as level 4 and calls the incident manager.
• Containment: as the plan says, the connection between office IT and the production network is cut at the firewall. The lines keep running in island mode with locally stored recipes.
• Reporting: in the morning, management rates the incident as significant. The early warning reaches the reporting office within 24 hours, and the insurer is informed in parallel.
• Recovery: the file server is restored from an immutable backup. The connection to production is only reopened after the engineering workstations have been checked.
• Lessons learned: the machine supplier's mobile number was outdated, and a remote access ran over a forgotten modem. Both become measures with a due date and an owner.

Checklist

• The scope covers IT and OT.
• Severity levels are described with examples.
• Every role has a person and a deputy.
• Escalation also covers nights, weekends and holidays.
• Reporting channels for NIS2, the CRA and the GDPR are recorded with a responsible person.
• Contact lists are current, tested and available offline.
• OT separation points and island operation are agreed with operations.
• Backups of controllers and configurations exist and are tested.
• The plan is aligned with business continuity.
• At least one exercise a year, results recorded as measures.

Incident response in Complass

A plan in the file share and incidents in email threads: in an emergency, everyone searches in a different place. In Complass, everything is in one place:

• Record incidents: significant security incidents under § 32 BSIG, reports under Art. 14 CRA, personal data breaches under Art. 33 GDPR and internal incidents. You are offered what matches your modules.
• Guided check of the reporting duty: questions based on the legal text lead to a decision, with a mandatory justification.
• Deadlines in view: reporting stages with a calculated deadline, email reminders to the people responsible. You submit the report itself in the authority's reporting portal.
• Everything on the incident: affected assets, comments, evidence files, timeline, measures straight into the action plan and a PDF report.
• Lessons learned: after closing, you record what went well and what went badly, the root cause and improvements.
• Crisis team and contacts: with business continuity, you maintain the crisis team, emergency teams and external contacts with deputies and availability, brought together in the emergency manual as a PDF or Word file to print.

Frequently asked questions

How long should an incident response plan be?

As short as possible. The main part should be readable in a few minutes. Details such as short playbooks and templates belong in annexes.

Do we need a separate plan for OT?

Not necessarily a separate plan, but separate sections. Separation points, island operation, supplier remote access and the recovery of controllers work differently in OT than in office IT.

How do incident response and business continuity fit together?

Incident response handles the security incident. Business continuity keeps operations going when processes fail. Above a set threshold, the crisis team takes over. Implementing Regulation (EU) 2024/2690 requires both plans to be consistent.

How often should we practice the plan?

The BSIG does not name a fixed number. A proven approach is at least one exercise a year, for example a tabletop review of the plan, and a review after every major incident or significant change.

Who has to approve the plan?

Management. Under § 38(1) BSIG, management has to implement and oversee the measures under § 30 BSIG, and incident handling is one of them.

In a demo, we show you with the demo company how an incident runs in Complass, from the first alert to lessons learned.

Request a demo Try it for 14 days

Read more

• Guide "NIS2 reporting duty in practice"
• Guide "CRA reporting for manufacturers: Art. 14"
• Guide "Business continuity under NIS2: BIA, plans and exercises"
• Whitepaper on reporting duties
• Incident management in Complass
• NIS2 in Complass

Not legal advice. This guide gives a general overview and does not replace an assessment of the individual case. The current wording of the BSIG, the NIS2 Directive, Implementing Regulation (EU) 2024/2690, the CRA and the GDPR, the publications of the BSI and your licensed editions of the standards are authoritative. As of November 2026.