How to Create an Effective Cyber Incident Response Plan (IRP)

Most enterprises will face a serious cyber incident. Whether it stays a contained disruption or becomes a crisis is usually decided before it starts: by who has authority to act, who notifies regulators, and which external specialists are already on call.

A cyber incident response plan (IRP) is the documented, rehearsed set of decisions your organisation makes in advance so nobody has to make them under pressure. Under NIS2 and DORA, regulators now expect to hear from you within 24 hours of an incident. That makes the plan a compliance requirement as much as an operational one.

This guide covers what a plan needs to include, who belongs on the response team, how to divide responsibility between internal staff and external specialists, and how to prove the plan works before you need it.

Why your business needs a response playbook beyond firewalls

Preventive security controls, such as firewalls, endpoint protection, and intrusion prevention systems, fail. They all reduce risk, but none eliminate it. A determined attacker, a misconfigured server, or an employee clicking the wrong link can bypass your defenses in seconds.

What happens next is what matters.

Without a cyber incident response plan, organisations improvise. People scramble to figure out who is in charge, what systems are affected, and who needs to be told. Decisions get made by whoever happens to be in the room, and evidence gets destroyed by well-intentioned IT staff trying to fix things quickly. Often, hours pass before anyone contacts legal or communications.

An IRP replaces that improvisation with decisions made in advance. It defines who does what, when they do it, and how they communicate throughout a cyber attack or security event. Treat it as a playbook rather than a rigid script: a structured framework that gives your team clear roles, escalation paths, and decision criteria so they can act quickly under pressure.

The scope extends beyond IT. A real IRP touches legal, communications, executive leadership, HR, and often third-party vendors. A ransomware attack is a business continuity problem, a legal problem, and a reputational problem, in addition to a technical problem, and your response plan needs to reflect this.

The business case for a strong cybersecurity incident response plan

The financial argument is straightforward. IBM’s 2025 Cost of a Data Breach Report puts the global average cost of a breach at $4.44 million, and the UK average at £3.29 million.

Breaches that organisations identified internally cost around $900,000 less than those disclosed by the attacker. IBM also lists planning and regularly testing incident response among its top recommendations for reducing breach costs. The savings come from detection speed and response readiness, and both depend on a plan that exists before the incident does.

But cost reduction is not the only reason this matters.

Speed protects trust

When customers learn about a breach, their reaction depends heavily on how quickly and transparently you respond. A company that detects an incident in hours, contains it, and communicates proactively looks competent. One that discovers a breach weeks later, after a journalist calls for comment, looks negligent.

Regulatory exposure compounds the damage

GDPR, NIS2 and DORA all set notification deadlines measured in hours or days (covered in detail below). Missing them adds fines and regulatory scrutiny to an incident that is already expensive, and makes the public side of recovery harder.

Board-level accountability is growing

Cybersecurity has moved from an IT line item to a board agenda item, and regulation now makes that explicit. NIS2 requires the management bodies of in-scope organisations to approve cybersecurity risk-management measures and oversee their implementation, and it allows them to be held liable for failures. DORA requires financial entities to inform their management body of at least major ICT-related incidents. A documented, tested IRP is how leadership demonstrates that oversight. Not having one is a liability.

Assembling your cyber incident response team (CSIRT)

The people who execute an IRP are what make it work or fail. Your Computer Security Incident Response Team (CSIRT) needs to be assembled, trained, and empowered before anything goes wrong.

Here are the roles that matter:

Incident response lead

This person runs the response. They coordinate activities across teams, make escalation decisions, and serve as the single point of authority during an active incident. This role requires someone who can stay calm, prioritise under pressure, and communicate clearly with both technical and non-technical stakeholders.

Security analysts

They do the investigative work, analysing alerts, examining logs, identifying indicators of compromise, and establishing the scope and nature of the threat. This is where deep technical expertise in threat detection and digital forensics lives.

IT and infrastructure

These are the people who actually isolate systems, apply patches, restore from backups, and rebuild compromised environments. They work closely with security analysts but focus on execution rather than investigation.

Communications

Someone needs to manage messaging, internally and externally. Employees need to know what is happening, and customers may need to be notified, as well as media inquiries needing a consistent, approved response.

Legal and compliance

Legal counsel establishes notification obligations, manages regulatory communications, and advises on evidence preservation. They need to be in the room early, not called after decisions have already been made.

Executive sponsor

A senior leader (often the CTO, CIO, or CISO) who has authority to allocate resources, approve spending during an incident, and make business-level decisions like whether to shut down a revenue-generating system.

In-house vs. external support

Most mid-to-large enterprises do not have a full incident response team on staff, and that is normal. Specialised forensics capabilities, threat intelligence, and 24/7 monitoring often come through external partners or retainer agreements.

The key is establishing those relationships before an incident occurs. Under NIS2, an early warning is due within 24 hours of becoming aware of a significant incident, and DORA’s initial notification deadline is no later than 24 hours from awareness. A day is not enough to find, vet, contract and onboard a forensics partner. It is barely enough for a partner already on retainer to start producing the facts your notification depends on.

In our experience, organisations that try to staff every incident response function internally find that the skills they need most in a crisis are the hardest to recruit and the least used day to day. Forensics, threat hunting and malware analysis all fall into this category. A hybrid model works better. Your internal team owns coordination, decisions and communications, and an external specialist handles deep forensics and threat hunting under terms agreed in advance. The IRP’s job is to define exactly where one hands over to the other.

Core components of an effective IRP

Every IRP has to cover certain ground. Miss any of these, and you will find the gaps during a real incident.

Response methodology

Your plan needs a structured approach to handling incidents, and there’s no reason to invent one. Most organisations build on NIST SP 800-61 or the SANS incident handling model. NIST’s latest revision (Rev. 3, 2025) aligns incident response with the NIST Cybersecurity Framework 2.0 and treats it as part of wider risk management rather than a standalone security process.

Whichever framework you adopt, the plan should define how incidents are classified by severity, what triggers escalation at each level, and who has authority to declare an incident. That last point matters because becoming aware of a significant incident is what starts your regulatory clocks.

Scenario-specific playbooks

A generic ‘respond to incident’ procedure is not enough. You need playbooks for specific scenarios, from ransomware and data breaches involving customer PII to insider threats, distributed denial-of-service attack, compromised credentials, and supply chain compromise. Each type of incident has different containment strategies, different communication needs, and different recovery procedures.

Communication plan

This is where many IRPs fall short. Your communication plan should specify:

Asset and network documentation

Your team cannot protect what they cannot see. The IRP should reference or link to current network diagrams, asset inventories, data flow maps, and system dependencies. During an incident, knowing which systems are connected to which and where sensitive data lives saves valuable time.

Remediation and evidence procedures

Document how compromised systems will be cleaned, rebuilt, or replaced. Equally important is to document how evidence will be preserved, as forensic evidence is fragile. Rebooting a compromised server to get it back online can destroy the data you need to understand the attack and meet legal obligations.

Primary frameworks and regulations for incident response

An incident response plan should reflect the regulatory requirements that apply to your organisation. In the EU, GDPR and NIS2 are the two frameworks most likely to shape your plan, and DORA takes precedence for financial entities. UK organisations follow UK GDPR and the NIS Regulations 2018, which the Cyber Security and Resilience Bill is set to replace. Organisations handling US healthcare data may also need to account for HIPAA.

GDPR

The General Data Protection Regulation (GDPR) establishes specific requirements for responding to personal data breaches. Under Article 33, organisations generally have to notify the relevant supervisory authority within 72 hours of becoming aware of a breach, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms.

Where a breach is likely to result in a high risk to individuals, Article 34 requires organisations to communicate the breach to affected individuals without undue delay.

This makes a documented IRP particularly important for organisations processing personal data. Your response team needs to be able to establish what happened and which personal data was affected, assess the risk to individuals, and provide the information needed for regulatory notification.

Your IRP should therefore define:

The GDPR also requires organisations to maintain records of personal data breaches, including those that do not require notification to a supervisory authority. Incident documentation is therefore part of compliance, not simply an operational record.

NIS2

The EU’s NIS2 Directive expands cybersecurity requirements across a much broader range of organisations than its predecessor, NIS. It applies to organisations in sectors including digital infrastructure, energy, transport, healthcare, manufacturing, financial services, and public administration, subject to the directive’s scope and national implementation.

NIS2 places explicit requirements on cybersecurity risk-management measures, including incident handling, business continuity, crisis management, and disaster recovery.

It also introduces specific incident reporting obligations. Where an incident has a significant impact on the provision of services, organisations covered by NIS2 must provide an early warning within 24 hours of becoming aware of the incident, followed by an incident notification within 72 hours and a final report within one month, subject to the directive’s requirements.

For organisations within scope, an IRP therefore needs to connect technical response with the wider organisational processes required for reporting, business continuity, management oversight, and recovery, as well as explain how technical teams contain an attack.

DORA for financial services

For banks, insurers, investment firms, payment institutions and other EU financial entities, the Digital Operational Resilience Act (DORA) has applied since January 2025 and sets its own incident management and reporting regime. Where DORA applies, its sector-specific rules take precedence over NIS2.

DORA requires financial entities to classify ICT-related incidents against defined criteria and report major incidents to their competent authority in three stages:

The four-hour window is the tightest in this guide. It only works if your IRP already contains DORA’s classification criteria, a named decision-maker for the “major” call, and pre-drafted report templates.

UK requirements

NIS2 does not apply in the UK. UK organisations follow UK GDPR, which mirrors the EU’s 72-hour breach notification requirement (to the Information Commissioner’s Office), and the NIS Regulations 2018 for operators of essential services and relevant digital service providers.

The Cyber Security and Resilience Bill, currently before Parliament, will replace the NIS Regulations, extend scope to managed service providers and data centres, and introduce two-stage reporting: an initial notification within 24 hours and a full report within 72 hours, with copies to the NCSC. If your organisation is likely to fall within scope, build the 24-hour window into your plan now rather than after the Bill becomes law.

GDPR, NIS2 and DORA can apply at once

GDPR, NIS2 and DORA should not be treated as competing incident response frameworks. An organisation may need to comply with all, and a single incident can trigger obligations under each.

For example, a ransomware attack that compromises systems containing personal data could require an organisation to assess its GDPR breach notification obligations while also assessing whether the incident meets NIS2’s threshold for significant impact and reporting. For a bank, the same incident could also trigger DORA reporting, on a shorter clock than either.

This is why an effective IRP should map regulatory requirements to specific response actions. Your team should know which incidents trigger which obligations, who makes each decision, and when notifications are due before an incident occurs.

HIPAA for healthcare-specific requirements

Organisations handling protected health information in the United States may also fall under HIPAA’s Breach Notification Rule, which requires notifying affected individuals, the US Department of Health and Human Services and, in some cases, the media. For organisations operating across jurisdictions, HIPAA sits alongside GDPR rather than replacing it.

Common cyber threats your IRP must address

Your IRP should include specific playbooks for the threat types most likely to affect your organisation. Here are the ones we see most often:

No plan can anticipate every scenario, so build your playbooks around the most probable threats, but design the overall IRP to be flexible enough to handle the unexpected.

Test the plan before an incident does

Writing an incident response plan is only the beginning. The real test is whether your team can use it when something goes wrong.

People change roles, systems change, contact details become outdated, and new types of attacks emerge. Even a well-written IRP can quickly become unreliable if nobody has practised using it.

Testing gives your team a chance to find those problems before they are dealing with a real incident. Start with discussions and scenarios, then move towards exercises that test how your organisation would actually respond.

Start with tabletop exercises

Tabletop exercises are one of the simplest ways to test an IRP. Bring the response team together, present a realistic scenario, and work through what would happen at each stage.

The aim is not to catch people out. It is to uncover gaps in the plan and in people’s understanding of their roles. You might discover that nobody is sure who has authority to isolate a system, that two teams have different escalation procedures, or that an important contact is no longer available.

Tabletop exercises are relatively inexpensive and can involve technical and non-technical teams, including legal, communications, HR, and senior leadership.

Test the response with functional exercises

Functional exercises take the next step by testing specific parts of the response in practice.

Rather than simply discussing what the team would do, you might simulate isolating a compromised system, activating an alternative communications channel, escalating an incident to senior management, or restoring a system from backup.

These exercises require more preparation and resources than a tabletop, but they can expose operational problems that are not obvious during a discussion.

Use full-scale simulations to test the whole organisation

A full-scale simulation recreates an incident as realistically as possible. Teams respond in real time, information is released as the scenario develops, and technical, operational, legal, and communications teams may all need to coordinate their response.

These exercises require considerably more planning and resources, so they are generally more appropriate for organisations with mature incident response programmes or higher-risk environments.

The goal is to see how the organisation performs under pressure and identify where the response breaks down.

Go further with red teaming

Red team exercises take testing as far as it goes. An accredited team simulates a real, targeted attack against your live environment without your defenders knowing the details in advance. That tests detection and response together, rather than the plan on paper. Intelligence-led schemes such as CREST STAR are designed for exactly this.

Turn every exercise into an improvement

An exercise only has value if you act on what it reveals.

After each test, document what worked, what did not, and what the team expected to happen but could not make happen. Assign specific actions to named owners and give them deadlines, then update the IRP, playbooks, contact lists, or technical controls as needed.

The plan should also be reviewed whenever something significant changes, such as a new system or service, a change in team responsibilities, a merger or acquisition, or new regulatory requirements.

An IRP should not be a document you finish once and file away; it should change as the organisation changes, and testing is how you find out what needs to change next.

Key metrics to measure incident response success

Two metrics matter most:

Track both metrics across incidents and exercises, and benchmark against industry data where available, but focus primarily on your own trend line. Are you getting faster? Are your post-incident reviews producing changes that show up in better numbers?

Other useful metrics include the percentage of incidents handled within established severity timelines, the number of incidents that required escalation to external support, and the time between plan reviews or updates. These give you visibility into the operational health of your response capability.

Present these metrics to leadership regularly. They translate security operations into terms that board members and executives can evaluate and act on.