Incident Response Plan: The Parts That Decide the Outcome

Most incident response plans are written to be filed, not to be used. They list the six phases, name a team that has since changed jobs, and end with a review date nobody keeps. The test is not whether the document exists. The test is what happens in the first twenty minutes of an incident, when a night-shift engineer has to decide whether to isolate a production database and cannot reach anyone who is allowed to say yes. A plan that does not answer that question has already failed, whatever its page count. This guide is about the four decisions a plan exists to pre-make, the order of operations that preserves the evidence you will need later, the clocks that start whether or not you are ready, and how to lawfully put outside help on standby before you need it.

A plan is a set of decisions, not a document

The industry standard moved and most templates did not. NIST Special Publication 800-61 was the source of the phase diagram - preparation, detection and analysis, containment, eradication and recovery, post-incident activity - that appears in almost every plan written in the last decade. Revision 3, finalised in April 2025, superseded the 2012 edition and dropped that life cycle altogether, recasting incident response as a set of outcomes spread across the six functions of the Cybersecurity Framework: Govern, Identify, Protect, Detect, Respond and Recover. NIST's own framing is that organisations should use whichever model suits them. The useful part of the change is what it implies: preparation is not a phase that happens before the incident. It is a standing capability that is either there or is not.

That reframing matters because it kills the most common way plans fail. A plan drafted as a narrative of future phases invites people to imagine a calm sequential response. Real incidents do not have phases; they have a stream of decisions made under time pressure with partial information, and every one of those decisions was either pre-made by someone thinking clearly a year earlier, or invented by someone exhausted at 3am. Your plan's only real job is to move as many of those decisions as possible into the second category.

Four decisions the document exists to pre-make

Strip away the template and four things have to be settled in writing, with names and deputies, before anything technical is worth discussing.

The contact table is the section that decays fastest and the one nobody re-checks. Put a review date against it alone, quarterly, and treat an out-of-date number as a finding rather than a chore. A retainer reference that nobody can find at 3am is worth nothing; the number alone is not enough either, because the firm will ask for the engagement reference before it wakes an analyst.

Severity written as triggers, not adjectives

Nearly every plan has a severity scale and nearly every scale is useless, because it is written with adjectives: critical, high, medium, low. An adjective is a judgement call, and judgement calls are exactly what you are trying to remove. Write each level as a test someone can apply without asking anyone.

• Level 1. Confirmed unauthorised access to, or execution on, a system that holds customer data or moves money; ransomware on any production host; a privileged account or the identity provider believed compromised; any confirmed exfiltration.
• Level 2. A single endpoint with confirmed malware and no evidence of lateral movement; a business email compromise with a confirmed fraudulent payment attempt; loss of a device holding unencrypted regulated data.
• Level 3. A blocked intrusion attempt with no success; a policy violation; lost hardware that was encrypted and remotely wiped.
• Level 4. A suspicious report that turns out to be benign, logged for the trend line.

Each level then maps to a response tier and a clock: who is paged, how fast, whether the commander is woken, whether legal is notified, whether the executive team is told. The scale should also state what automatic escalation looks like when the answer is "we do not know yet" - because unknown is where most incidents actually start, and a plan that has no tier for uncertainty gets treated as Level 3 until it is Level 1.

Pre-authorised containment, with a blast radius

The single most expensive delay in a real incident is the hunt for permission. Write the authority down with a limit attached, so nobody has to weigh a career against a subnet at 3am.

A workable formulation looks like this: the on-call security engineer may isolate up to twenty hosts, disable up to ten accounts and revoke application tokens without approval, and must notify the commander within fifteen minutes of doing so. Isolating a production database cluster, disabling a service account that a revenue system depends on, blocking a domain used by a business partner, or taking a site down requires the commander. Anything that stops revenue, affects safety systems or touches a regulated system requires the commander plus the business owner plus legal. Every one of those thresholds is arbitrary; the point is that they exist, they are written, and they were agreed before anyone was frightened.

Two details get missed. First, isolation means network isolation, not power-off. Pulling the power destroys memory-resident evidence you cannot get back, which is the next section. Second, the authority is worthless without a tested access path. Confirm before you need it that the named responders can actually reach the endpoint console, the identity provider's admin plane, the cloud control plane and the log platform at 3am, from a device that is not the one they usually use, with MFA that is not tied to the phone that just got wiped. Keep break-glass credentials somewhere that does not require the systems they protect, and test the access path quarterly rather than assuming it.

The retention cliff: your evidence expires before you notice the breach

Here is the number that should shape your logging budget. IBM's 2025 Cost of a Data Breach study, covering 600 organisations breached between March 2024 and February 2025, puts the mean time to identify and contain a breach at 241 days - a nine-year low, and 17 days faster than the year before. Organisations that found the breach with their own teams identified it in 172 days. Read those numbers against the default retention of the platforms almost everyone runs.

• AWS CloudTrail event history: 90 days of management events, per region, and no data events unless you created a trail that captures them.
• Microsoft 365 unified audit log: 180 days on standard licences, one year for Entra, Exchange and SharePoint records on E5-class licences.
• Microsoft Entra ID sign-in and audit logs: seven days on the free tier, 30 days with P1 or P2.
• Okta System Log: 90 days.
• Azure Activity Log: 90 days.

An intruder who arrives in January and is discovered in June has been sitting inside a window that closed in April. The lateral movement, the initial access and the account creation are simply gone, and the investigation starts from whatever the attacker left behind rather than from what they did. This is not a hypothetical; it is the ordinary case, and it is why the retention argument belongs in the plan rather than in a ticket to the platform team.

The plan should therefore state, for each tier of system: what is collected, the retention period in days, where it goes, who can export it, and how fast. Then compare each retention period to your realistic detection time, not to your hopes. If detection takes five months and identity logs last 30 days, the gap is the finding. Forwarding to a platform you control, with a retention you set and an export you can prove, is the fix; extending the vendor's retention after the fact does not recover records that already expired.

The first hour, in an order that does not destroy evidence

Almost every instinct a competent engineer has in the first hour is forensically destructive. The plan has to say this plainly, because the instincts will win otherwise.

Two ordered lists belong in the plan as appendices so nobody has to compose them during an incident. The first is the credential reset order: identity provider first, then mail, then the systems that trust them, then service accounts, then endpoints - resetting an endpoint password before the identity provider is theatre. The second is the containment order for a business email compromise, where mailbox rules, delegated access and OAuth grants each have to be checked separately, because each one of them survives a password change.

Evidence that survives scrutiny

If the incident ends in a claim, a dismissal, a regulatory inquiry or a prosecution, someone will ask how you know what you say you know. Four habits make the difference, and all of them are cheap before the incident and impossible after it.

• Hash at capture. Record a cryptographic hash of every image and export when it is taken, and re-hash on transfer. Store the hash list separately from the media.
• One custodian per item, written down. Who had it, when, and what they did with it. A copied image with no chain of custody is an allegation, not evidence.
• Contemporaneous notes over reconstructed narrative. Notes written during the incident carry weight that a summary written three weeks later does not, whatever its quality.
• Never analyse the only copy. Work on duplicates. Treat the original as sealed.

The decision log from the previous section is the piece most organisations omit and the one that most often decides how a regulator or a court reads the response: not whether you were breached, but whether you behaved reasonably once you knew. A log that shows a defensible sequence - isolated at this time, escalated at this time, notified at this time, on this advice - is a different document from a silence with a breach on either side of it.

The clocks, by regime

Notification deadlines are the part of a plan most likely to be out of date and most expensive to get wrong, because the clock usually starts at awareness rather than at certainty. You will be deciding whether to notify while you still do not know the scope. That is the design, not a flaw. Put the numbers in the plan with their sources so nobody has to look them up under pressure, and put the decision to notify in legal's hands, in writing.

• GDPR, Article 33: notify the supervisory authority within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in a risk to rights and freedoms. Where notification is late it must be accompanied by reasons for the delay. Article 34 governs telling the data subjects, without undue delay, where there is a high risk.
• NIS2, Article 23: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report within one month.
• DORA, Article 19: for financial entities, an initial notification within four hours of classifying an incident as major and no later than 24 hours after becoming aware, an intermediate report within 72 hours of the initial notification, and a final report within one month of the latest intermediate. The timing details sit in Delegated Regulation (EU) 2025/301, and the clock does not pause for a weekend.
• SEC Form 8-K, Item 1.05: material cybersecurity incidents, four business days after the registrant determines the incident is material.
• HIPAA breach notification: 60 calendar days from discovery for breaches affecting 500 or more individuals, with concurrent notice to HHS.
• FTC Safeguards Rule: notification to the FTC as soon as possible and no later than 30 days after discovery, for security events affecting 500 or more consumers at covered non-bank financial institutions.
• US state breach laws: mostly 30 to 72 days, with different definitions of personal information and different thresholds. Check the states where the affected people live, not where you are.
• PCI DSS v4.0, requirement 12.10: an incident response plan that is prepared and tested at least annually, with the testing evidence retained.

Two practical conventions belong next to this list. First, record the timestamp at which each clock started and the evidence for it, because "when did you become aware" is a question you will be asked precisely. Second, brief outside counsel early: in most jurisdictions the notification duty is the entity's, but the assessment of whether a breach is reportable is a legal judgement, and the sequence of advice-then-decision is what a regulator expects to see.

Hiring an outside responder before you need one

Every plan says to contact the forensic firm. Almost none says what the firm will ask for, how fast it can actually start, or what has to be in place for it to be allowed to touch your systems. That gap turns a bad night into a bad week.

The commercial shape is a retainer: a small annual fee for guaranteed response within a stated window, against hourly rates during the engagement. That is the version worth buying, and it is worth being sceptical about the window. A two-hour response frequently means an on-call analyst replies within two hours, not that a team is imaging your servers. Ask what specifically starts inside the window, and get the answer in the contract.

The technical shape is the part people forget. An outside firm cannot lawfully begin collecting from your estate on a phone call. It needs a signed engagement that identifies the entity that owns the assets, the scope, the systems in scope, the data-handling terms, the permitted actions, and an authorisation to act from someone entitled to give it. In a group, that is often not the IT manager who is making the call. Getting this signed at 3am - when the person who can sign is asleep and the firm's legal team is also asleep - is exactly the delay a pre-signed master agreement exists to remove.

This is also where most organisations discover that the useful outside help is broader than forensics. A responder that can image disks but cannot revoke a session, read an identity provider's logs or rewrite a firewall rule is a specialist you still have to coordinate. When you look for a firm, ask what it will do in the first two hours and who does it. Our digital forensics practice and the ransomware recovery service both describe the engagement from the client side, and the hacker-for-hire engagement guide sets out the authorisation any lawful engagement requires.

Privilege: the question that decides how you hire them

Whether the investigation is directed by outside counsel is a decision with real consequences, and it is best made before an incident, because it changes who hires whom.

The reason is legal privilege. In the United States, work performed at the direction of counsel in anticipation of litigation may attract work-product protection, which can keep a forensic report out of a claimant's hands. In England and Wales the position is narrower and less forgiving: legal advice privilege covers communications with lawyers, and litigation privilege covers documents created for the dominant purpose of litigation, but a factual investigation commissioned for operational reasons is not automatically protected, a point the courts have made more than once. European regimes differ again, and privilege may not survive a regulator's statutory information request in the form a company hopes.

So the plan should state which model you are using, and what it costs you. A counsel-directed engagement buys a measure of protection and costs speed and money: an extra layer of instructions, a lawyer in the room, and a report that may be written for a court rather than for your engineers. An operational engagement is faster and cheaper and produces a document you may have to hand over. Neither is wrong. Choosing by accident is.

Extortion is a legal and financial decision, not a technical one

The plan needs one paragraph that says who decides about payment, and it should say clearly that the decision is not the incident commander's. Technically, payment is the least interesting option on the table; legally and financially it is the most exposed.

The legal layer is real and it varies by jurisdiction. In the United States, the Treasury's Office of Foreign Assets Control has been explicit that facilitating a ransom payment to a sanctioned person or entity can itself create sanctions exposure, and it has published guidance on the risk factors and on the value of reporting to law enforcement and cooperating. In the United Kingdom, firms in the regulated sector face reporting obligations under the Proceeds of Crime Act and the Terrorism Act, alongside sanctions reporting to OFSI. Several jurisdictions restrict payment to designated groups outright. None of this is advice; it is the reason the plan names the people who must be in the room - legal, finance, the insurer and the board - and states that the commander may not authorise a payment.

There is also a practical layer the plan should record, because it is what stops a rushed decision. Attackers' decryption tools frequently fail to restore all data, restored data is often corrupt, and payment marks the organisation as one that pays. The honest position for a plan is that recovery comes from backups and rebuilds, that payment is a decision taken by people who understand the legal exposure, and that the technical team's job is to make the no-payment option viable - which it only is if the backups were tested before the incident, not during it.

Communicating on a channel you do not own

Assume the attacker can read your email and your chat. This is not paranoia; a compromised mailbox is one of the most common incident types, and thread hijacking means the intruder is already inside a real conversation.

• Pick the out-of-band channel in advance and test it quarterly with everyone who will be on the call, including the outside firm and counsel.
• Keep a contact list that does not live in the platform under attack. A printed page in a wallet is unfashionable and it works.
• Write the employee instruction before you need it. Do not discuss this incident on any company channel, call this number instead - that sentence has to exist in advance, in every language your staff read.
• Pre-draft three statements: we are investigating; we have contained it and here is what we know; and here is what affected you and what we are doing. Only the third should ever name a cause.

What not to say in the first 48 hours, ever: an attribution, a cause, and the phrase "no data was accessed". Attribution is a claim you cannot support and will have to retract. "No data was accessed" is the sentence that turns an incident into a credibility problem, because it is usually written before anyone has looked at the logs. Say what you know, say what you do not know, and give the time of the next update.

The tabletop that actually tests the plan

Most exercises test the participants' imagination. A useful one tests the plan's gaps, and it does that by removing the things the plan assumes.

Design each exercise around one scenario and four injections. For a business email compromise: the finance director is unreachable, the insurer's number in the appendix is disconnected, the identity provider's admin console requires MFA on a phone that was wiped, and the CFO wants to send a customer email within the hour. Then watch what breaks. The value is not in whether the team handles it. It is in the list of assumptions that failed, each of which becomes a line in the plan.

Three rules make the difference. Include the people who are not security people - legal, finance, communications, the executive who will have to sign something. Run it against the written plan with the plan open, because an exercise where everyone works from memory tests memory. And record the artefacts: the timeline, the decisions, the failures, and the date each fix was made. A tabletop with no written output is a meeting.

After the incident: the clean-backup trap

The recovery phase has one ordering rule that most organisations get wrong, and it is expensive when they do. Restoring from backup over a compromised system destroys the evidence of how the compromise happened. If the system has not been imaged and preserved, restore later. If it is the only evidence of the intrusion path, preserving it is the priority even though it delays recovery - the alternative is rebuilding onto the same unpatched entry point.

Then define clean before anything returns to production, in writing, per system. For most estates that means: rebuilt from a known-good image rather than cleaned in place, credentials rotated in the right order, the entry point identified and closed, and monitoring at a heightened level for a stated period - 30 days is a common choice, with a named owner watching it. A definition of clean that says "the malware scanner is quiet" is not a definition; it is a hope.

The after-action review has its own trap: writing a document that reads like a confession, with unverified attribution and speculative root cause, then circulating it widely. Keep the factual timeline and the remediation list separate from the analysis, mark the analysis as preliminary, and route it through counsel if there is any prospect of litigation or a regulatory action.

The clause list auditors ask for

If the plan exists partly to satisfy someone, here is what they will actually look for. ISO/IEC 27001:2022 Annex A 5.24 through 5.28 covers planning and preparation, assessment and decision on events, response, learning from incidents, and the collection of evidence - the last one being the clause that most often exposes a chain-of-custody gap. NIST SP 800-61 Revision 3 is the current reference framework. PCI DSS v4.0 requirement 12.10 requires the plan and its annual test. HIPAA's security management process, 45 CFR 164.308(a)(6), requires incident procedures and response and reporting. SOC 2 picks it up in CC7.3 through CC7.5, covering evaluation of security events, response to incidents and recovery. NIS2 Article 21(2)(b) requires incident handling capability and Article 23 the reporting, and DORA adds the financial-sector clock above.

The evidence an auditor wants is rarely the plan itself. It is the current review date, the last test and its output, a real incident with its timeline and decisions, and a list of remediations with dates. A plan reviewed two years ago and never exercised is a finding under most frameworks, and it is a fair one.

Where lawful outside help fits

Incident response is one of the few areas where the market contains both legitimate specialists and outright fraud, and the difference is visible before any money changes hands.

A legitimate engagement has paperwork before it has tooling: a signed authorisation from the entity that owns the assets, a scope naming the systems, a time window, data-handling terms, an explicit prohibition on anything beyond the agreed actions, and a way to stop. A forensic firm works from copies, preserves originals, and documents what it did. It does not offer to attack the other side, it does not offer to identify the intruder by breaking into anything, and it does not offer a guaranteed recovery for a fee paid in cryptocurrency.

The fraud markers are consistent: they contact you first after a breach they should not know about, they promise an outcome, they want payment in crypto, they ask for credentials or remote access, or they offer to attack the other side. There is no lawful service that recovers data by breaking into the attacker. Recovery runs through your backups, your insurer, law enforcement, the courts and, where a platform is involved, the platform's own account recovery process. If you are bringing in help, ask for the authorisation letter, the scope and the data-handling terms first, and treat any hesitation about those three as the answer. Our data recovery service and the forensics practice both start from that paperwork, and you can ask for a scoping call without committing to anything.

The short version

A plan that works is short, specific and rehearsed. Name who can declare an incident and who commands it, and give responders written authority with a blast radius so nobody negotiates at 3am. Write severity as tests rather than adjectives, and put the escalation rule for "we do not know yet" where people will find it. Compare your log retention to your real detection time, because a 30-day identity log against a 172-day detection mean is an empty investigation. Preserve before you clean: isolate at the network layer, capture memory, export logs, revoke sessions, and never restore over the only evidence. Put the notification clocks in the plan with their article numbers and give the reportability decision to legal. Sign the outside-responder engagement before you need it, decide in advance whether counsel directs it, and write down that the payment question is not the incident commander's to answer. Then run one exercise a year that removes the assumptions, and keep the output. Eleven pages that people can apply beat sixty that nobody opens, and the only plan that exists is the one somebody actually used.