Incident Response Plan Template — Building Blocks, Obligations, Costs

When an IT security incident occurs, the first 24 hours determine the total damage. Mid-market companies that are forced to improvise during this window incur, on average, three to five times higher direct follow-on costs than organisations with a well-practised incident response plan. Add to that GDPR fines for missed 72-hour reporting deadlines, NIS2 sanctions with personal liability for management, and long-term reputational damage with customers and suppliers. This template shows which building blocks an effective IR plan must contain, which statutory reporting obligations are triggered and within what timeframes, and what retainer costs management and CFOs should budget for — written pragmatically for companies with 50 to 2,000 employees. How this topic fits into the overall security strategy is covered in detail in our Cybersecurity Guide for Mid-Market Companies.

Why every incident without an IR plan becomes more expensive — GDPR, NIS2, and liability

The financial damage from an IT security incident is made up of several layers. On the direct side: business interruption, recovery costs, external forensics, legal advice, and in some cases ransom payments. For ransomware incidents at mid-market companies, total damages between €200,000 and €4 million have been regularly documented in recent years. This range depends almost entirely on how quickly and how methodically the organisation can respond — not on the technical depth of the incident.

On the regulatory side, three amplifiers are at work. First, GDPR Article 33: as soon as personal data may be involved, a 72-hour deadline begins to notify the competent data protection authority. Missed deadlines are sanctioned in practice as a separate violation — independent of the underlying incident itself. Fines in the six-figure range solely for late notification have been documented by German supervisory authorities. Second, NIS2, which has been in force since October 2024 and introduces staggered reporting obligations for highly important and important entities: 24 hours for the early warning, 72 hours for the formal notification, one month for the final report. Senior management is personally liable for compliance — insurance solutions covering this personal liability are expensive and by no means standard. Third, sector-specific regulators: BaFin for financial services providers, BSI for operators of critical infrastructure, the Federal Network Agency for telecommunications and energy. These deadlines often run in parallel.

At the third level, reputational damage with customers, suppliers, and insurers takes effect. Supplier audits on cybersecurity are now standard in manufacturing, logistics, healthcare, and automotive — any company that had to manage an incident without a documented IR plan and without timely notifications loses points in tenders or entire contracts. Cyber insurers, in turn, almost always require evidence of a practised IR plan as a precondition for coverage. Those who cannot demonstrate one pay higher premiums or receive reduced benefits in the event of a claim. For deeper coverage of the regulatory side, see our cluster article NIS2 Directive for Mid-Market Companies.

The six mandatory building blocks of an effective IR plan

An IR plan is not a 200-page manual that nobody reads when it matters. It is a compact operational guide with clearly assigned responsibilities. In practice, six building blocks can be identified that are indispensable for a mid-market company. What each building block must specifically contain is something we work through with your team or an advisor in a follow-up step.

• Roles matrix with deputiesWho is the Incident Commander, who documents, who communicates externally, who decides on business interruptions? Every role needs a primary person and at least one deputy — otherwise the plan falls apart whenever someone is on leave or off sick.
• Communication chain with 24/7 availabilityPhone numbers, emergency email addresses, a secure out-of-band channel outside your own mail infrastructure. If your own email is affected by the incident, communications must not break down. External stakeholders — the data protection authority, BSI contact, cyber insurer, IT forensic specialists, law firm — must be captured in advance.
• Escalation workflow with clear thresholdsAt what point does an event become an incident? At what point does it escalate to management? At what point to external authorities? Without clear thresholds, in practice either too many events are escalated — and management becomes desensitised — or too few, and critical cases fly under the radar.
• Reporting-obligations block with deadlinesA table of all relevant authorities, their deadlines, the respective notification channels, and template text for the initial notification. In an actual incident, there is no time to draft the right wording from scratch — pre-written building blocks save hours.
• Recovery concept with recovery objectivesRTO (Recovery Time Objective) and RPO (Recovery Point Objective) per business process. Which systems can be offline for how long, and how much data loss is tolerable? These values drive the sequence of recovery and are set by management, not by IT.
• Exercise and review cycleAt least one tabletop exercise per year, at least one full technical exercise every two years, and quarterly review rounds to update contacts and responsibilities. A plan that has never been exercised is almost always worthless when it counts.

Statutory reporting obligations at a glance

The table below summarises the most important reporting obligations that may be triggered by an IT security incident at a mid-market company. It is not a substitute for individual legal advice, but serves as a starting point for board-level communication and plan preparation.

Obligation	Trigger	Deadline from awareness	Recipient
GDPR Article 33	Breach of personal data	72 hours	Competent data protection authority
GDPR Article 34	High risk to data subjects	Without undue delay	Affected individuals directly
NIS2 Early Warning	Significant security incident	24 hours	Competent national authority (BSI in DE)
NIS2 Notification	Significant security incident	72 hours	Competent national authority
NIS2 Final Report	Significant security incident	1 month	Competent national authority
BSI Act §8b	KRITIS operator, significant incident	Without undue delay	BSI directly
BaFin / MaRisk AT 7.2	Financial services provider, IT incident	Without undue delay, max. 4h	BaFin
Cyber insurer	Insured incident	Typically 24–48h	As contractually agreed

Multiple deadlines run in parallel — a ransomware encryption event with data exfiltration at a KRITIS organisation simultaneously triggers the GDPR notification (72h), NIS2 early warning (24h), NIS2 formal notification (72h), BSI notification (without delay), and insurer notification (contractual). Anyone who walks into such a multi-obligation scenario without a prepared template loses the first hours on administrative work while technical containment is delayed. That is exactly what a well-prepared IR plan prevents.

Escalation workflow and recovery levels

The escalation workflow is the organisational backbone of the plan. It describes at which severity level which people are brought in — and crucially, who is authorised to make which decisions. In practice, a three-level model has proven effective: Level 1 covers operational IT disruptions with no security component, handled by the service desk. Level 2 covers security-relevant events with limited scope — for example, a single phishing click with suspicious activity on a workstation. Here the IT security team takes over with defined containment measures. Level 3 covers genuine security incidents with potential impact on personal data, business continuity, or compliance — here management is brought in, the external forensics provider is engaged, and the reporting-obligations block is activated.

The recovery levels are the counterpart on the restoration side. Which business processes must be up and running first? In a manufacturing mid-market company, this is typically production control with logistics and dispatch connectivity, followed by ERP and customer communications, and only then back-office functions such as internal collaboration. The sequence follows from the RTO and RPO values per process — management sets these values, not IT. An observation from several Reepa engagements: in more than half of mid-market companies we advised before an incident, the gap between the RTO expectations of business units and the backup strategy actually in place was the biggest risk finding — larger than any individual technical vulnerability.

Free quick-check of your existing IR plan

You already have an incident response plan but are unsure whether it will hold up in a real incident? We offer a free quick-check: a 30 to 45-minute structured conversation working through the six mandatory building blocks, followed by a concise written assessment using a traffic-light system and a clear recommendation on where adjustments make sense.

Tabletop exercises — what they actually deliver

A tabletop exercise is a facilitated simulation of an incident around the conference table — no technical interventions, no live systems, just the plan, the participants, and a realistic scenario. That may sound unspectacular, but it is the single most effective instrument for improving a plan. In a three-hour exercise, between 12 and 25 concrete gaps are typically uncovered: missing emergency numbers, unclear decision-making authority, conflicting responsibilities between IT and data protection, and incorrect assumptions about backup availability.

Typical scenarios for mid-market companies include ransomware with data encryption in the production environment, data exfiltration via a compromised cloud access key, targeted CEO fraud with fake payment instructions, and a supplier incident with knock-on effects on the company's own supply chain. For organisations subject to NIS2, we recommend at least two exercises per year with different scenarios — this covers the reporting-obligations spectrum more broadly. Management must attend in person, not delegate — because these are precisely the people who make critical decisions in a real incident.

IR retainers and the vendor landscape

In a real incident you need specialists who have seen many incidents before. In-house teams at mid-market companies very rarely reach that level of experience density — simply because they handle too few incidents. An IR retainer is a framework agreement with an external provider that guarantees a response time, a fixed hourly rate, and an agreed escalation process. The range of models is wide.

Market participants can be roughly grouped into three categories. Globally active Big-Four-adjacent providers such as Mandiant, CrowdStrike Falcon Complete, and Palo Alto Unit 42 offer broad incident experience, large teams, and 24/7 availability — with corresponding annual base fees starting at €40,000 for smaller mid-market clients and six- to seven-figure volumes for large accounts. Specialised forensic providers such as Kroll, Coveware, and Arete are particularly sought after for extortion incidents, bringing negotiation experience and legally defensible forensics. Boutique providers and regional specialists — a category that includes Reepa Solutions in the DACH mid-market — focus on companies with fewer than 2,000 employees, offer personal service and leaner contracts starting at €12,000 to €30,000 annual base fee, with smaller teams and a narrower geographic reach.

Which provider is the right fit depends on industry, size, maturity, and risk appetite. An insurance group or KRITIS operator selects a Big-Four-adjacent provider — depth is decisive there. A mid-market mechanical engineering firm with 400 employees is far better served by a boutique retainer, because the ratio of effort to visibility is calibrated differently. What matters is that the contract is in place before an incident occurs — retainer agreements signed after an incident are more expensive and slower to deliver value. For a complementary overview of audit formats, see the cluster article Red Team vs Pentest.

What an IR programme costs for a mid-market company

The costs of building and operating an effective IR programme depend heavily on the starting point. The table below shows typical ranges for mid-market companies with 50 to 2,000 employees. It is intended as guidance — precise proposals require a brief scoping workshop.

Work Package	Effort (days)	External advisor (€)	In-house expectation
Initial assessment + plan draft	6–12	from 7,500	1–2 workshops with management and IT lead
Reporting-obligations block + template text	3–6	from 3,500	Close coordination with DPO and legal counsel
Escalation workflow + roles matrix	4–8	from 4,500	1 day per location
Recovery concept (RTO/RPO)	5–10	from 5,500	With business units per process
First tabletop exercise with management	2–3	from 2,500	Half day of management time — mandatory
Retainer agreement (annual base fee)	—	12,000 – 60,000	Negotiated with IR provider
Hourly rate in a real incident	—	250 – 600 €/h	Typically 80–400 h per incident

Add to this internal personnel costs and ongoing tooling costs — SIEM licences, EDR platforms, backup infrastructure. These do not belong in the IR plan in the strict sense but in the overall cybersecurity budget. Measured against the damage potential of a ransomware incident — in Reepa engagements regularly in the low six-figure range for a 200-person company — the total IR programme represents a modest line item. An observation from multiple engagements: companies that set up a full IR programme after their first real incident recovered on average 60 to 80 percent of their initial build costs at the very next incident — simply through faster and more orderly response.

When you should revise your IR plan now

There are four situations in which revising an existing plan should not wait. First, after a real incident — even if it ended without major damage. The insights from actual deployment are the most valuable source of plan improvements. Second, after any significant architectural change — cloud migration, new locations, major M&A activity. Third, after personnel changes in key roles, because the roles matrix otherwise runs empty. Fourth, at the latest 12 months after the last review, even if nothing major has happened — contacts change, providers change, legal frameworks are refined.

Pragmatically: if you have an IR plan but have not exercised it in more than two years and have not updated it in more than one year, you do not have a working plan — you have a document. The difference becomes visible in a real incident. Unfortunately, always too late.

Frequently asked questions