Plan Not Accessible
The plan is stored on the file server – exactly where the ransomware encrypted it. Without a printed or offline version, it’s missing when it’s needed.
Incident Response & Forensics
Incident Response Plan and Playbooks for When It Matters
Clear roles, clear paths, clear decisions.
A cyberattack leaves no time for fundamental questions. With an incident response plan that fits your organization, it’s clear in advance who decides, who gets informed and which steps follow – with playbooks for typical attacks and with the reporting deadlines under the GDPR, NIS2 and DORA in mind.
- Individual quote
- Support with reporting obligations
- Vendor-independent
Definition
What Is an Incident Response Plan?
An incident response plan (IR plan) sets out in binding terms how your organization handles IT security incidents – from the first alert through containment and recovery to the post-incident review. It defines roles and decision-making authority, escalation and reporting lines, and internal and external communication. It’s complemented by incident response playbooks: short, action-oriented procedures for specific scenarios such as ransomware or an account takeover.
People also often talk about an IT emergency plan – sometimes meaning recovery after IT outages of any kind, sometimes specifically the handling of attacks. What matters is that incident handling and business continuity management mesh: a serious attack is always an emergency for business operations as well.
When an incident hits, the clock is ticking: under Art. 33 GDPR, reportable personal data breaches must be notified without undue delay and, where feasible, within 72 hours of becoming aware of them; for significant incidents at entities subject to NIS2, an early warning to the joint reporting office of the BSI (Germany’s Federal Office for Information Security) and the BBK (Federal Office of Civil Protection and Disaster Assistance) is due even sooner – no later than 24 hours after becoming aware of the incident. If you only clarify during the incident who assesses, reports and approves, you lose exactly the time you need for containment and evidence preservation.
Laws and standards also call for this preparation: in Art. 21, NIS2 explicitly lists incident handling, business continuity and crisis management among the cybersecurity risk-management measures; ISO/IEC 27001:2022 includes controls in Annex A for planning and preparing incident management; and the BSI’s IT-Grundschutz framework dedicates module DER.2.1 “Security Incident Handling” to the topic.
Our Approach
How We Build Your Incident Response Plan
It starts with an inventory: Which rules, contact lists and service provider contracts already exist? Which systems and processes are business-critical? And which requirements apply to you – for example from the GDPR, NIS2 and DORA, from your customers or from your cyber insurance policy?
In workshops with senior management, IT, data protection, communications and business units, we develop your plan from this. We follow recognized frameworks such as ISO/IEC 27035, BSI Standard 200-4 on business continuity management and NIST SP 800-61 Rev. 3, but we map your actual organization: Who can be reached at night? Who is allowed to disconnect the network from the internet? Which service provider has which access?
Every playbook follows the established phases of incident handling and contains clear decision points, guidance on evidence preservation and suitable communication templates.
Typical Gaps
Why Emergency Plans Fail When It Counts
Unclear Decision-Making Authority
Is the head of IT allowed to stop production or cut the internet connection? Without clear authority, people debate instead of act.
Outdated Contact Lists
Former employees, old mobile numbers, no deputies – and the IT service provider can only be reached during business hours.
No Fallback Channel
Email, chat and telephony run through the compromised environment. Without an independent communication channel, attackers may be reading along.
Reporting Obligations Without Ownership
Nobody knows who checks whether the data protection supervisory authority, the joint reporting office of the BSI and the BBK or BaFin (Germany’s Federal Financial Supervisory Authority) must be informed, who writes the report and who approves it.
Destroyed Evidence
Well-intentioned reboots or hasty reinstallations destroy evidence that’s needed for the investigation, reports and insurance.
Never Rehearsed
A plan that nobody knows won’t be applied under pressure. Only an exercise shows whether the procedures hold up.
Starting Points
The Right Starting Point for Your Maturity Level
No Plan Yet
Building from Scratch
No binding rules for security incidents so far? We develop the core plan and the most important playbooks – compact and practical.
- Roles, escalation and reporting lines
- Playbooks for the most likely scenarios
- Emergency card for all employees
Plan in Place
Revision
Your plan is showing its age or doesn’t cover new requirements? We check it against current attack patterns and obligations and close the gaps.
- Alignment with NIS2, DORA and ISO/IEC 27001:2022
- Updating contacts, systems and service providers
- Adding missing playbooks
Lessons Learned
After an Incident
A security incident has exposed weaknesses? We turn the findings into a robust plan so that the next emergency unfolds in a more orderly way.
- Evaluation of how the incident unfolded
- Targeted adjustment of plan and playbooks
- Linking with the results of the digital forensics
Process
Six Steps to Your Incident Response Plan
Practical and tailored to your organization – like all services in our Incident Response & Forensics practice.
-
01
Initial Consultation & Quote
We clarify the starting point, goals and scope. On this basis, you receive an individual quote.
-
02
Inventory
Interviews and document review covering existing rules, critical processes, service providers and regulatory requirements.
-
03
Plan, Roles & Reporting Lines
In workshops, we define the classification, roles, escalation levels, reporting matrix and communication plan.
-
04
Playbooks
For the prioritized scenarios, we create procedures along the phases of detection and analysis, containment, eradication, recovery and post-incident review.
-
05
Approval & Rollout
Senior management approves the plan. We present it to the teams involved and make sure it’s also available offline.
-
06
Exercise & Review
In an exercise, we test whether the plan holds up – for example as part of our Crisis & Tabletop Exercises. We then set a schedule for regular reviews.
Deliverables
Your Response Plan: Compact, Clear, Practical
You won’t get binders full of paper, but documents your team can work with under pressure: short, unambiguous and tailored to roles. All documents are also available as print and offline versions – so they remain available when your IT isn’t.
- Incident response plan with classification and activation criteria
- Responsibility matrix including deputies
- Escalation and reporting matrix with deadlines and templates
- Communication plan with pre-approved text modules
- Playbooks for your prioritized scenarios
- Emergency card and contact list for printing
- Executive summary with open items and recommendations
Be Ready Before It Gets Serious
A plan doesn’t prevent an attack – but it largely determines how quickly, and how methodically, you can act again afterward. Let’s talk about your starting point.
FAQ
Frequently Asked Questions About Incident Response Plans
Didn’t find your question? Call us at +49 2932 465265-0 or email info@rootsektor.de.
What’s the difference between an incident response plan, an IT emergency plan and BCM?
The incident response plan governs how security incidents are handled – from detection to the post-incident review. The IT emergency plan in the narrower sense ensures that IT services resume after outages of any kind, and business continuity management (BCM) under BSI Standard 200-4 safeguards time-critical business processes even during severe disruptions. In a serious cyberattack, all three mesh; that’s why we explicitly define the interfaces.
Are we required to have an incident response plan?
That depends on your industry and size. For entities subject to NIS2, incident handling, business continuity and crisis management are among the minimum measures under § 30 BSIG (German BSI Act); senior management must implement them and oversee their implementation (§ 38 BSIG). DORA requires financial entities to have, among other things, ICT response and recovery plans. And even without an explicit obligation, the GDPR’s reporting deadlines can hardly be met without defined procedures.
Which reporting deadlines does the plan need to cover?
You report reportable personal data breaches to the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of them (Art. 33 GDPR); if the breach is likely to result in a high risk to the individuals concerned, you must also notify them without undue delay (Art. 34 GDPR). Entities subject to NIS2 report significant incidents to the joint reporting office of the BSI and the BBK: an early warning no later than 24 hours and an incident notification no later than 72 hours after becoming aware of the incident, and a final report no later than one month after that notification. Financial entities report major ICT-related incidents under DORA to the competent supervisory authority, usually BaFin – the initial notification generally within four hours of classifying the incident as major and no later than 24 hours after becoming aware of it, followed by an intermediate and a final report. The legal assessment of each individual case is a matter for your legal or data protection advisors.
How extensive should a playbook be?
As short as possible, as specific as necessary. A good playbook covers just a few pages: trigger, immediate measures, decision points, responsible persons, guidance on evidence preservation, communication and criteria for recovery. Technical details such as command sequences or system lists belong in appendices maintained by your IT team.
How often should the plan be reviewed?
At least once a year, after significant changes such as new systems or a change of service provider, and after every major incident. You should update contact lists much more often. For most financial entities, DORA requires the ICT response and recovery plans to be tested at least annually anyway – exercises are a proven way to do that.
We have an acute incident right now – what should we do?
Then planning can wait. Disconnect affected systems from the network, but don’t shut them down, and call our 24/7 emergency hotline at +49 2932 465265-0 or use the Report an emergency form; you’ll find more immediate steps under IT Emergency Response. We’ll be glad to develop the plan once the situation has stabilized – drawing on the lessons from the incident.
Related pages
Talk to Us About Your Response Plan
Briefly describe your starting point – whether you want to start from scratch or revise an existing plan. We’ll agree on the next steps with you in confidence. In an acute security incident, please use the 24/7 emergency hotline +49 2932 465265-0 or the Report an emergency form.