Incident Response Planning: What Happens When Your Business Gets Hacked?

The phone call nobody wants. "We've had a breach." Or perhaps it's less dramatic — a user reports they can't access files, or your IT provider flags unusual activity in the monitoring dashboard. However it arrives, the question is the same: what do you do now?

For businesses without an incident response plan, the answer is improvisation. They make decisions under pressure with incomplete information, sometimes destroying forensic evidence, sometimes extending the attacker's access, almost always making the situation more expensive than it needed to be.

This guide explains what an incident response plan should contain and what actually happens during a cyber incident, so you can prepare before you need it.

Why Planning Matters Before the Incident

Every minute of an active cyber incident costs money. Systems down means staff unable to work. Data being exfiltrated means ongoing breach liability. An attacker who maintains access while you're figuring out what to do is an attacker who can cause more damage.

Studies consistently show that organisations with tested incident response plans recover from incidents faster and at significantly lower cost than those without. The difference isn't marginal — it can be the difference between a costly but manageable incident and an existential threat to the business.

The reason is straightforward: good decisions made in advance are better than good decisions made in a crisis. An incident response plan is a set of pre-made good decisions. It tells you who to call, what steps to take, what to preserve, and what to shut down — before you're under pressure.

The Phases of Incident Response

Identification is the first phase. Something has been detected — an alert from your security tooling, a user report, a notification from your IT provider or a third party. The immediate questions are: what has happened, what systems are affected, and how significant is this?

Not every security alert is a serious incident. Part of the identification phase is triage — determining whether this is a confirmed incident requiring a full response or a less significant event that can be handled through normal processes. This determination should be made by someone with security knowledge, not a general IT helpdesk.

Containment is the priority once an incident is confirmed. The objective is to stop the damage spreading while preserving evidence. This often means isolating affected systems from the network. The tension here is that isolation can affect business operations — you need to make a judgment about how much operational disruption is acceptable in exchange for preventing further spread.

A common mistake at this stage is to immediately shut everything down. This destroys volatile evidence (data in memory, active network connections) that may be critical to understanding what happened. The right approach is to isolate affected systems while preserving as much evidence as possible.

Eradication involves removing the threat from your environment. This might mean removing malware, closing the vulnerability that was exploited, removing attacker-created accounts, and cleaning or reimaging affected systems. Eradication needs to be thorough; incomplete removal of an attacker means they can regain access.

Recovery is the process of restoring systems to normal operation. This is where the quality of your backup strategy becomes apparent. Recovery from backups takes time, and the time depends on the quality and recency of your backups. Businesses with tested, recent, isolated backups recover in hours or days. Those without can take weeks.

Post-incident review is often skipped but is arguably the most valuable phase. A thorough analysis of what happened, how the attacker got in, how long they were present, what data was accessed, and what the response did well and poorly provides the basis for preventing recurrence and improving future response.

What Your Incident Response Plan Should Contain

The plan doesn't need to be lengthy. What it needs to be is usable under pressure.

Roles and responsibilities. Who leads the incident response? Who handles technical investigation? Who manages communications with staff, customers, and regulators? Who makes business continuity decisions? These roles need to be assigned in advance and the relevant people need to know what's expected of them.

Contact lists. Your IT provider or managed security provider. Your cyber insurance provider — call them early; they often have incident response resources available. Legal counsel, particularly if data has been breached. The ICO if reporting is required. Key customers if they need to be notified. Have current contact details for all of these.

Decision criteria. What triggers an escalation to a full incident response? What triggers a notification to the ICO? What criteria determine whether affected systems are isolated versus shut down? Having these decision points thought through in advance prevents paralysis.

Communication templates. Pre-drafted communications for the most likely scenarios — a ransomware attack, a data breach, a system outage — reduce the time and cognitive load of communication decisions during an incident.

Recovery priorities. Which systems need to be restored first? What's the minimum viable technology environment to operate the business? If you have to choose between restoring your email system and your finance system, which is the priority?

Evidence preservation procedures. What should be preserved before systems are reimaged? Where should logs be stored? Who handles forensic investigation?

The ICO Notification Requirement

Under GDPR, if a data breach is likely to result in a risk to individuals, you must report it to the ICO within 72 hours of becoming aware. This is not 72 hours after the breach — it's 72 hours after you become aware that a reportable breach has occurred.

In practice, this means that during an incident, you need to be assessing in parallel whether the incident involves personal data and whether reporting is required. The 72-hour clock starts the moment you have reasonable grounds to believe a reportable breach has occurred.

Missing the notification window has regulatory consequences. More than that, the manner and speed of your reporting demonstrates to the ICO whether you have appropriate processes in place. Organisations that report promptly, clearly, and with evidence of good process are treated very differently from those that report late and incompletely.

Testing Your Plan

A plan that has never been tested may not work when you need it. Table-top exercises — where your team works through a simulated incident scenario — reveal gaps, identify confusion about roles, and surface practical issues with the plan before they matter.

A basic table-top exercise requires two to three hours and can be run internally. More sophisticated exercises can involve realistic simulations with technical components. Either way, the investment is minimal compared to the value of knowing your plan actually works.

Getting Started

If you don't have an incident response plan, start with a single page: who to call, what to shut down first, and when to notify the ICO. That's better than nothing and can be developed over time.

If you want help developing a more comprehensive plan, or if you want to run a realistic incident simulation, we work with businesses across West Sussex on exactly this. Get in touch and we'll help you build something practical.