How to Build an Incident Response Plan That Works Under Pressure

It is 02:00 on a Saturday. File servers are being encrypted, and someone has to decide whether to cut the company off from the internet. Who makes that call? Who tells the regulator, and by when? If the answers live in people's heads or an unopened binder, the first hours will be spent arguing rather than containing.

An incident response plan exists to settle those arguments in advance. A good one is short enough to use under stress, specific about who decides what, and rehearsed often enough that people trust it. A poor one satisfies an auditor but stays silent on the questions that matter at 02:00.

This guide, written for security leaders and executives at growing companies, shows how to build a good one using NIST's current guidance.

How NIST SP 800-61 Revision 3 Frames Incident Response

Revision 2 described a circular life cycle from preparation to post-incident activity. NIST now says that model assumed incidents were rare, narrow and resolved within a day or two, whereas today they are frequent and can take weeks or months to recover from.

NIST SP 800-61r3 maps incident response onto the six Functions of NIST CSF 2.0. Govern, Identify and Protect cover preparation. Detect, Respond and Recover are the response itself. NIST also stresses continuous improvement: lessons should often be shared as soon as they are identified, not held until recovery ends.

For a growing company, that framing has two practical consequences for how the plan is written.

• It is a governance document as much as a technical one, because leadership owns the decisions with the greatest business impact.
• It must be synchronised with business continuity plans, as NIST explicitly recommends.

Roles and Decision Rights: Settle Who Decides in Advance

NIST lists a wide cast with incident response responsibilities, from leadership and incident handlers to legal, public affairs, human resources and asset owners. Where a managed security or cloud provider will act for you, NIST recommends the contract defines its responsibilities and authority to act on your behalf.

Few plans state what each role may decide, even though NIST lists authorities among the key elements of an incident response policy, such as which roles may disconnect or shut down technology assets. Write down, by role and with a named deputy, who can make each of these decisions.

• Declare an incident and set or change its severity
• Isolate a production system, a site or the whole network
• Disable any account, including an executive's or a critical service account
• Engage an external incident response firm, outside counsel and the cyber insurer
• Decide whether regulators, law enforcement or customers must be notified, and approve the wording
• Authorise any contact with an extortionist, always with legal counsel involved

NIST suggests designating an incident lead for each incident. The incident lead coordinates and should not also be the senior technical investigator, because nobody can run the room and analyse memory images at the same time. Add a scribe whose only job is a timestamped log of decisions and actions.

Severity Levels That Trigger Action, Not Debate

NIST recommends triaging each report to confirm an incident and estimate its severity, then prioritising it by scope, likely impact, time-criticality and available resources. Your severity scale should turn that analysis into automatic consequences. The table below is an example to adapt, not a standard.

Let anyone raise severity, but only the incident lead lower it. But severity is not reportability: a SEV 3 mailbox compromise can still be a notifiable personal data breach, so every incident above SEV 4 needs a quick notification assessment.

Playbooks for the Incidents You Are Most Likely to Face

NIST suggests documenting procedures for the most common incident types and for critical processes, such as redeploying your primary authentication platform. CISA's incident response playbooks are a useful model.

Which scenarios deserve a playbook depends on who is likely to target you. That is where preparation benefits from threat intelligence services that map threat-actor techniques to your controls, detections and most likely incident paths, and supply indicators and behaviour patterns your team can feed into playbooks. For most growing companies, three scenarios come first.

Ransomware

CISA's #StopRansomware Guide advises isolating affected systems immediately and powering devices down only if they cannot be disconnected, because powering down loses evidence held in volatile memory. It also recommends out-of-band communication, such as phone calls, so attackers are not tipped off. A ransomware playbook should cover the following.

• Isolation steps for endpoints, servers, remote access and identity systems, and who executes them
• Verifying the integrity of backups before restoring, as NIST recommends
• Checking for lateral movement and persistence before declaring any system clean
• Establishing whether data was stolen before encryption, using the techniques in our guide to data exfiltration detection
• A payment decision process with counsel and sanctions screening, informed by OFAC's 2021 advisory that facilitating ransomware payments may violate US sanctions regulations

Business Email Compromise

The FBI's 2025 IC3 Annual Report recorded more than $3 billion in reported business email compromise losses. Speed decides whether money comes back: the IC3 advises victims to contact their financial institution immediately to request a recall of the funds, and to file a complaint with the IC3 regardless of the amount lost. The playbook should also cover resetting credentials and revoking sessions, removing attacker-created inbox rules and forwarding, checking registered MFA methods, and reviewing what personal data the mailbox held.

Cloud Account Takeover

One compromised cloud administrator session can create new users, keys and workloads. The playbook should cover revoking sessions and tokens, rotating keys and secrets, reviewing permission changes and auditing for new resources or billing abuse. Export the provider's audit logs early, as retention varies, and know which actions your provider will take under the shared responsibility model.

The First Hours of an Incident

Give the incident lead a short sequence to follow while the facts are still unclear.

1. Validate and declare. Confirm the incident, assign severity and an incident lead, and open a record with the time of discovery.
2. Move to a clean channel. Assume email and chat may be compromised and convene on a pre-agreed out-of-band bridge.
3. Scope before you strike. NIST warns that underestimating an incident's magnitude can let it continue on other targets unnoticed.
4. Contain with evidence in mind. Isolate rather than wipe, and image a sample of affected systems before rebuilding.
5. Start the regulatory clocks. Record when the organisation became aware, and have legal begin the notification assessment.
6. Call your partners. Engage your incident response provider and counsel, and notify your insurer as your policy requires.
7. Set the rhythm. Fix the update cadence for executives and staff, and keep to it.

NIST is candid that every response strategy involves trade-offs: observing an attacker can conflict with restoring operations quickly. Make that call explicitly and record who made it. For well-understood scenarios, automated threat remediation can execute pre-approved containment without waiting for a human, and AI-assisted SOC triage helps ensure real incidents are declared rather than lost in alert noise.

Evidence Preservation: Protect the Facts You Will Need Later

Most incidents never reach a courtroom, but NIST points out that collected incident data is still evidence, and recommends preserving the integrity and provenance of both that data and the record of actions taken.

RFC 3227 still applies: collect the most volatile evidence first, from memory through to disk and logs, and document a chain of custody showing who collected each item, when, and who has held it since. In practice, that means four habits.

• Keep a timestamped log of every action and decision
• Hash forensic images and record where, when and by whom they were acquired
• Export identity, endpoint, network and cloud logs before retention limits delete them
• Restrict access to incident records, which NIST notes can contain sensitive details about vulnerabilities and individuals

If forensic depth is beyond your team, decide now who will provide it. Enigma Labs' cyber incident response services cover containment, forensic investigation with chain-of-custody handling, recovery and a post-incident hardening plan, on a pre-arranged retainer or as an emergency engagement.

Communications and Notification Clocks

NIST groups incident communication into coordination, formal notification, public communication and voluntary information sharing. Each needs an owner. Prepare holding statements, name a single spokesperson and agree what goes to the board.

The regimes below are common for companies operating in Europe and the US. They are illustrative, not exhaustive: your obligations depend on jurisdiction, sector and contracts, and this is not legal advice.

Sector rules can be stricter: under DORA, EU financial entities must send an initial notification within four hours of classifying an incident as major. Under GDPR, processors must notify their controller without undue delay. The European Data Protection Board treats a controller as aware once it has a reasonable degree of certainty that a security incident has compromised personal data, and information may be provided in phases. Failing to meet these GDPR obligations can attract fines of up to €10 million or, for an undertaking, 2% of total worldwide annual turnover, whichever is higher. A Commission Digital Omnibus proposal from November 2025 would raise the GDPR threshold to high-risk breaches and extend the deadline to 96 hours, but at the time of writing it has not been adopted.

Exercises and Post-Incident Review

A plan that has never been exercised is a hypothesis. NIST rates improvements identified from tests and exercises, including those run with suppliers, as a high priority, and points to NIST SP 800-84 for tabletop and other formats. CISA's Tabletop Exercise Packages include cyber scenarios such as ransomware.

Build a simple, repeatable cycle, and add realistic friction such as a key person being unreachable.

• Run a technical tabletop with the core response team at least twice a year, rotating the scenario
• Run an executive exercise at least annually, focused on shutdown, disclosure and ransom decisions
• Drill the hard tasks: restoring from backup, revoking every session in your identity provider, switching to the out-of-band channel

A penetration test agreed with leadership but unannounced to responders can double as a live check of detection and escalation. If you are working towards ISO 27001 or NIS2 readiness, exercise records also show that incident management works in practice.

After every significant incident, hold a blameless review as recovery concludes. NIST describes it as a chance to review what happened and how effective the response was, and to hear from everyone involved. Turn findings into owned, dated actions, and review the plan periodically and whenever a significant improvement is identified.

Conclusion

An incident response plan is a set of decisions made calmly in advance so they need not be made in a panic. Give named people clear authority, define severity by business impact, know your notification clocks, protect evidence from the first minute and rehearse until the plan feels routine. For outside support, an Enigma Labs incident response retainer includes tabletop exercises and an annual plan review, with legal and scoping agreements signed before an incident happens.