What is an incident response plan?

An incident response plan is a written, tested set of procedures that tells your organisation exactly how to detect, contain, eradicate and recover from a cyber incident, and who makes which decision while it is happening. It names the people, the escalation paths, the legal and regulatory clocks, and the technical steps, so that under pressure your team follows a rehearsed routine rather than improvising. A plan that lives in a PDF nobody has opened is not a plan, it is a liability dressed up as readiness.

The UK reference point is the National Cyber Security Centre. Its incident management guidance and the broader NCSC framing of prepare, respond and recover give you a sound spine. The plan turns that guidance into something specific to your systems, your suppliers and your obligations.

When do you need one?

You need an incident response plan before you have an incident, which means now. Boards tend to commission one after a near miss, a failed audit, a customer security questionnaire, or a regulator asking pointed questions. Any of those is a fair trigger, but waiting for the breach itself is the most expensive route. The IBM Cost of a Data Breach Report 2025 put the global average cost of a breach at USD 4.44 million, and a large share of that cost is driven by slow, disorganised response rather than the intrusion itself.

If you process personal data, sell to enterprise customers, sit in a regulated sector, or fall inside the expanded scope of NIS2, a tested plan is no longer optional. Our NIS2 compliance work routinely surfaces incident response as the control that is weakest on paper and weakest in practice. The regulation expects you to handle, report and learn from incidents, and it expects management to be accountable for that.

The phases an incident response plan must contain

A credible plan covers the full lifecycle, not just the technical clean up. The widely used structure runs through preparation, detection and analysis, containment, eradication, recovery, and post incident review. Each phase needs named owners and explicit triggers.

• Preparation. Asset inventory, logging, contact lists, retainers with forensics and legal support, and the training that means people recognise the plan when they need it.
• Detection and analysis. How an alert becomes a declared incident, how you classify severity, and the threshold that escalates to executives and the board.
• Containment. Short term moves to stop the spread, isolating systems and accounts, and the decision rights to take production offline if that is the right call.
• Eradication. Removing the attacker’s access, closing the route in, and confirming the environment is genuinely clean before you reconnect anything.
• Recovery. Restoring services in a controlled order, validating data integrity, and watching for the attacker coming back through a door you missed.
• Post incident review. An honest account of what happened, what the plan got right, and the changes you will fund as a result.

Around those phases sit the parts boards forget: regulatory notification timelines, customer and press communications, and the legal privilege questions that shape how you commission forensics. These belong in the plan, written down, agreed in calm conditions.

Who owns the plan?

The CISO or equivalent owns the plan and keeps it current. The board owns the consequences. That distinction matters because incident readiness is a governance question, not just a technical one. Directors are accountable for whether the organisation can withstand a serious attack, and they cannot delegate that accountability away even when they delegate the work.

If you do not have a permanent security leader, a virtual CISO or CISO as a service arrangement gives you a named owner without a full time hire. For organisations carrying both technology and security gaps at once, a fractional CIO and CISO can hold the plan and the wider operating model together. The point is that an unowned plan rots. Someone senior has to be answerable for keeping it tested and true.

How to build and test the plan

Start by mapping what you are actually defending: your critical systems, your data, your key suppliers, and the single points of failure that would hurt most. Build the response procedures around those realities rather than a generic template. Then assign every role a named person and a deputy, because incidents do not wait for someone to come back from leave.

Testing is where most plans fail. A plan that has never been rehearsed will not work under stress. Run tabletop exercises that walk the leadership team through a realistic scenario, ransomware, a supplier compromise, a data exfiltration, and watch where decisions stall. The gaps you find in a two hour exercise are far cheaper than the gaps you find at 2am during a live breach. Our cyber security consulting engagements use these exercises to expose the difference between a plan that reads well and a plan that holds.

Regulators have shown they will act when controls and response fail. The ICO fined British Airways £20 million in 2020 and Interserve £4.4 million in 2022, both cases where the handling of security shortcomings, not only the breach, drew scrutiny. Demonstrable preparation and a competent response change how those situations end.

Connecting incident response to board governance

A plan only earns its keep when the board can see and challenge it. That means incident readiness should appear on the board agenda with the same regularity as financial risk. Directors should know who declares an incident, what would trigger a call to them, and how the organisation would meet its regulatory reporting clocks. This is the territory of board cyber governance, and it is where many organisations discover their plan exists in the security team’s head but nowhere the board can interrogate it. Where AI tools are now part of the estate, your plan also needs to account for incidents involving shadow AI and the governance that should surround it.

Why Starkhorn

Starkhorn is led by Daniel J. Jacobs, who has spent over 20 years in technology and security, 15 of them in leadership roles, including Interim Group Technology Director at VetPartners, the BC Partners-backed veterinary group, and CIO and CISO at Jardine Motors Group. He is the author of The Strategy Bridge and holds PRINCE2, ITIL Foundation and full membership of the Institute of Interim Management.

Having held CIO and CISO accountability at group level, Daniel has sat in the chair where the incident response plan has to work and the board is watching, which is the perspective he brings to building and testing yours.

Frequently asked questions