Skip to content
What should an incident response plan include?
The call comes in at 6:47 on a Tuesday morning. A member of staff has noticed something strange on the system. The files appear to have been renamed. The IT manager cannot log in to the server. By the time senior leadership is assembled, it is clear that a threat actor has been inside the network for days, possibly weeks, and has just triggered the visible part of the cyberattack.
From that moment, every minute matters. Who makes the decisions? Who calls the solicitor? Who talks to customers? Who notifies the ICO? If no one has written down the answers to those questions in advance, the response will be slower, more expensive, and more damaging than it needs to be.
That is what a formal incident response plan exists to prevent.
If you are reading this because a cyber incident is happening right now and you do not know what to do, contact Zensec immediately.
What is a cyber security incident response plan?
An incident response plan is a documented, formally approved set of procedures that outlines what your organisation should do before, during, and after a cybersecurity incident. It covers the incident response process from the moment something is detected through to returning affected systems to normal operation and reviewing what happened.
According to the UK Cyber Security Breaches Survey 2025, only 22% of UK businesses have a formal incident response plan in place. The figure rises to 53% for medium-sized businesses and 75% for large ones, but for the majority of organisations, there is no clear plan in place in the event of a cyber attack. That is a significant gap, given that 43% of UK businesses reported experiencing a breach or attack in the past twelve months.
A plan does not need to be a lengthy document. It needs to be clear, practical, and accessible to the people who will use it under pressure.
The incident response lifecycle
Most incident response frameworks, including the widely referenced NIST guidance from the National Institute of Standards and Technology, structure the incident response lifecycle into four phases: preparation, detection and analysis, containment and recovery, and post-incident activity.
Understanding these phases helps you structure your plan so that each stage has clear owners, clear actions, and clear outcomes.
What should the plan include?
Roles and responsibilities
This is the foundation of any effective response. When a security incident occurs, confusion about who is in charge delays response and allows further damage to spread. The plan must name the incident response team members and define each person’s responsibilities.
A typical incident response team includes an Incident Manager who leads the response and controls communication flows, a Technical Lead who handles the investigation and coordinates security professionals working on affected systems, and a Communications Manager responsible for messaging to external stakeholders, customers, and the press.
Depending on your organisation, you may also need designated contacts from legal, human resources, finance, and your cyber insurance provider. The NCSC recommends including at least two contact methods and two named individuals for each role to account for unavailability during an incident.
Incident detection and classification
The plan should explain how your organisation will identify cyber threats and define what qualifies as an incident requiring a formal response. Not every anomaly is a major breach, and not every breach carries the same level of risk.
A clear classification system, from minor events through to critical cybersecurity incidents, helps your team make appropriate responses quickly rather than treating everything as a maximum-level emergency or, worse, treating a serious incident as routine.
Endpoint detection and logging systems generate most of the early signals in a modern environment. Your plan should describe these incident response steps including:
- What signals look like
- Who reviews them
- At what point they trigger the formal incident management process.
Immediate response and containment
Once an incident is declared, the plan must provide your team with clear instructions for the immediate response. This means isolating affected systems to prevent the incident from spreading, preserving evidence for forensic analysis, and establishing a secure communications channel that does not rely on the potentially compromised network.
The NCSC specifically recommends storing printed copies of the plan offline, precisely because email, internal chat, and document systems may be unavailable or untrustworthy during a live incident.
The immediate response phase is where most organisations that lack formal incident response procedures lose control. Without clear instructions, people act on instinct, and instinct often leads to actions that destroy the evidence needed to understand the root cause.
Communications plan
Your communications plan needs to cover three distinct audiences, and your response efforts will stall if any one of them is neglected.
Internal communications mean keeping the board, senior leadership, and relevant staff informed about incident status without creating panic or spreading inaccurate information. Decisions about business operations, system shutdowns, and expenditure need to reach the right people fast.
External stakeholder communications cover customers, suppliers, partners, and regulators. If customer data or sensitive information has been exposed, your plan should include clear guidance on when and how to notify customers, what to say, and who is authorised to say it. Public relations considerations should be addressed here too: a poorly worded public statement after a data breach can cause as much reputational damage as the breach itself.
Legal obligations are non-negotiable. Under UK GDPR, if a breach is likely to result in a risk to individuals’ rights and freedoms, you must report it to the ICO within 72 hours of becoming aware of it. Failing to meet that requirement can result in fines of up to £8.7 million or 2% of global annual turnover. Your plan should make clear who is responsible for making the assessment, who is responsible for issuing the notification, and where the relevant contact details are stored.
If you hold a cyber insurance policy, the plan should also include your cyber insurance provider’s notification requirements, which often have their own time windows.
Recovery phase
The recovery phase covers the process of safely returning affected systems to normal operation. That means not just restoring from backup but verifying that the threat actor has been fully removed, that the vulnerability they exploited has been addressed, and that systems are clean before being brought back into production. Rushing this stage is how organisations experience a similar breach twice.
Your plan should clearly link to your business continuity and disaster recovery plans so that teams understand which systems are prioritised for restoration and the acceptable thresholds for downtime and data loss.
Post-incident review
A post-incident review, sometimes called a postmortem, is where the value of an incident response is either locked in or lost. Once the immediate pressure has lifted, the team should meet to reconstruct the timeline of events, analyse the root cause, identify what worked in the response and what did not, and document lessons learned.
The NCSC recommends that these reviews focus on processes and systems rather than individuals. Security incidents are almost always the result of a system failure, not a single person’s mistake. Blame-focused reviews produce defensiveness rather than improvement.
The findings should feed directly into updated security policies, security measures, and the incident response plan. A plan that is not regularly reviewed and updated after real incidents is not a living document; it is a filing cabinet.
What makes a plan effective in practice?
A plan that exists only as a document is not enough. The NCSC recommends exercising your plan through tabletop simulations, where your incident response team works through a hypothetical scenario to test their understanding of the process before a real incident tests it. These exercises surface the common challenges: unclear escalation paths, missing contact details, conflicting assumptions about who has authority to take systems offline.
The plan should also be regularly reviewed, at minimum quarterly, to ensure it reflects changes in your organisation, your systems, and the threat landscape.
Common mistakes businesses make during a cyber attack
In many cases, organisations don’t fail because cybersecurity incidents are unavoidable. They fail because their response creates additional damage. Common mistakes include:
- Panicking: Shutting systems down too quickly without preserving evidence can destroy forensic evidence that investigators need not only to understand how the attacker gained access, but also to prevent future incidents.
- Using Compromised Communications Channels: Ensuring business continuity is essential during a breach, but using compromised channels like email can leak additional security information and expose investigative activity.
- Not Understanding Your Responsibilities: Underestimating the regulatory and legal implications of cyber incidents is also a common error.
- Poor Coordination: When a breach occurs, working together ensures that it’s effectively managed. But when multiple teams try to handle it independently, decision-making becomes harder. That’s why appropriate management is essential.
- Restoring Systems Too Soon: Restoring your systems before security teams can identify the root cause leaves you open to further breaches.
Get support today
If you are looking for support in building or testing a robust incident response capability, Zensec’s cyber incident response plan service helps organisations put the right structure in place before a crisis, not during one.
Knowing what to do when an incident occurs is not a luxury for larger organisations. For any business handling sensitive data or customer information, it is a basic operational responsibility.