How to Build a Simple Incident Response Plan

Write the one-page version first. Who decides, who they call, how to reach them out of hours, what gets disconnected, and who speaks to customers. A team can act on that at 02:00. Nobody acts on a 40-page policy, and the plans that fail in practice usually fail because the person who needed them could not find a phone number.

The plan is one page, and it has phone numbers on it

Start with the incident commander: one named person, with one named deputy, who has the authority to take systems offline without asking anyone’s permission. Then the call list: the engineer with production access, the person who can reach your hosting provider, your lawyer or data protection adviser, and whoever signs off customer communication. Mobile numbers, not internal chat handles, because the plausible first move in a serious intrusion is that you lose trust in your own identity provider.

• Incident commander and deputy, with explicit authority to disconnect, revoke and rebuild.
• Technical responders: who holds break-glass credentials, and where those credentials live offline.
• Communications: one voice to customers, one to staff. Draft the holding statement in advance.
• External help: your provider’s emergency contact, your insurer’s notification line, your regulator’s reporting page.
• Evidence: where the running log lives, and the rule that nobody rebuilds a machine before logs are copied.

Print it. Put a copy in the office, give one to each person on the list, and keep a copy in a password manager that does not depend on your corporate single sign-on. We have watched a team spend 40 minutes trying to reach an on-call engineer whose number existed only in the directory they had just locked themselves out of.

What changed in the official guidance

In April 2025 NIST published SP 800-61 Revision 3, which supersedes the 2012 edition most incident response plans were originally copied from. The change of emphasis is useful even if you never read the document: rather than a standalone four-phase lifecycle, incident response is now described as part of continuous cybersecurity risk management, mapped onto the Cybersecurity Framework 2.0 functions, with the stated aim of helping organisations prepare for incidents, reduce how many happen, and improve how quickly they detect, respond and recover.

In plain terms: preparation and governance are part of the plan, not a preface to it. The UK NCSC’s incident management collection makes the same point from a different angle, pushing organisations to decide in advance what they would do, who would do it, and how they would know. If you want one practical takeaway from both, it is that the “lessons learned” step is the one that compounds, and it is also the one everybody skips.

How incidents actually start

Plan for the common openings rather than the dramatic ones. Microsoft’s 2025 Digital Defense Report, drawing on its own incident response engagements, found 28% of breaches started with phishing or social engineering, 18% through unpatched web-facing assets and 12% through exposed remote services. Verizon’s 2026 Data Breach Investigations Report, published in May 2026, reported that vulnerability exploitation reached 31% of breaches and passed stolen credentials as the leading entry point for the first time in the report’s 19-year history.

Those three routes should shape your playbooks. A phishing-led compromise needs a credential revocation and session-invalidation drill. An unpatched web asset needs someone who can take a service offline and a current inventory of what is exposed. Exposed remote services need the boring quarterly check that nothing new has been published to the internet since the last one. Verizon also notes that attackers are using AI to shorten the window between a vulnerability being published and being exploited from months to hours, which is an argument for pre-approved emergency patching rather than a faster change-approval meeting.

Severity tiers, so nobody has to improvise

Three tiers is enough. The point of writing them down is that the person who finds something at midnight does not have to judge whether it is worth waking anyone. The response times below are the targets we recommend for a small team with no 24/7 rota; they are our operational guidance rather than a published benchmark, and you should set your own to match the hours you actually staff.

The first sixty minutes

1. Timestamp it. Note the time you became aware and what you were told. That moment starts your regulatory clock and anchors the whole timeline.
2. Open the log. One shared document, append-only in practice, every decision with a time against it. Future-you writing the post-incident report will be grateful.
3. Contain without destroying. Isolate the device from the network, revoke the session and the credential, rotate the key. Do not reimage, do not delete, do not power off a machine you may need memory from. The #StopRansomware Guide is explicit about preserving evidence while you contain.
4. Check the identity blast radius. If one account went, look for new mail rules, new MFA registrations, new OAuth grants and new admin roles. Attackers set up persistence before they do anything visible.
5. Decide the tier out loud and tell the group. Ambiguity about severity is what produces two people doing contradictory things.
6. Say something internally. A short, factual update to staff stops the rumour loop and stops well-meaning people from “helping” in ways that destroy evidence.

Notification, and the clock you cannot pause

If personal data is involved, the UK ICO expects notification within 72 hours of becoming aware where the breach is notifiable, and says plainly that you should report even when you do not yet have the full picture. The EU rule is the same 72 hours to your supervisory authority. Awareness means the point at which someone in your organisation has a reasonable degree of certainty that a breach occurred, so the clock can be running for days before senior management hears about it.

Put the mechanics in the plan: which regulator, which online form, who has the login, what insurance policy number to quote, and which contractual notification deadlines you have signed up to with customers. Enterprise contracts frequently demand notice in 24 or 48 hours, which is tighter than the law. Our note on data protection compliance basics covers the regulatory side in more detail.

Test it with a 45-minute tabletop

Book 45 minutes, invite six people, and read out a scenario. “At 07:40 a customer emails to say our invoices are arriving from a lookalike domain, and finance says two have been paid.” Then go round the table: what do you do first, who do you call, what do you tell the customer, and what do you need that you do not have? Write the gaps on a list. Fix three of them.

• Run it twice a year, with a different scenario: ransomware on a file server, a departing employee’s access, a supplier breach that exposes your data.
• Include someone non-technical. They ask the questions that reveal missing decisions.
• Time-box it. A tabletop that runs for three hours will not be repeated.
• The output is a short list of fixes with owners, not a report.

Supplier incidents deserve their own rehearsal now. Verizon’s 2026 report found third-party involvement in breaches up 60%, with breaches involving a third party reaching 48% of all breaches, so the scenario where someone else loses your data is no longer the unlikely one.

What slowness costs

IBM’s 2026 Cost of a Data Breach Report puts the global average cost of a breach at a record USD 4.99 million, 12% above the previous year, and frames it as roughly USD 1,100 an hour of exposure. Detection and escalation together with lost business made up 63% of that cost, and organisations making extensive use of security AI and automation saved an average of USD 1.93 million per breach. Those averages are enterprise-weighted, so read them as direction rather than a quote for your business.

The direction is consistent and it points at the same place a plan does: the cost of an incident is mostly the cost of the time it takes you to understand and stop it. A plan with names, numbers and pre-agreed authority removes hours from that. Recovery, as opposed to response, is a separate discipline, and we cover it in business continuity planning for growing companies. The preventative half, particularly for distributed teams, is in cybersecurity essentials for distributed and remote teams.

Incident response is part of our cybersecurity service, delivered remotely worldwide. Want a one-page plan written against your actual systems, and a tabletop to prove it works? Get in touch with Eudora Technology to talk about your project.