Incident Response Guide: Plans, Playbooks and Retainers

Most organisations have an incident response plan, but far fewer have one that names who can take a critical system offline at 3am, which provider will answer the phone, and what the first hour of a ransomware or mailbox compromise looks like. Incident response is the organisational capability that turns detection into decisions: declaring an incident, assigning roles, containing and eradicating the threat, meeting reporting deadlines and learning from what happened. This guide covers the NIST SP 800-61 Rev. 3 model, plan contents, CSIRT roles, severity and declaration, playbooks, containment and eradication strategy, retainers, regulatory clocks, exercises and post-incident review. It is written for security leaders, CSIRT managers and the legal, communications and IT colleagues who share the response. Forensic evidence collection and analysis is a separate discipline.

Key takeaways

• Rev. 3 makes response part of risk management. NIST SP 800-61 Rev. 3 (April 2025) replaces the four-phase lifecycle with the CSF 2.0 Functions: Govern, Identify and Protect support preparation, Detect, Respond and Recover are the response itself, and Improvement (ID.IM) feeds lessons into all of them.
• One coordinator, written authority. The NCSC is blunt: "There must be a central point of co-ordination, no matter who is involved." Name the incident lead, their deputies and who may shut down a critical service before you need them.
• Playbooks cover the first hours. Start with your top three to five incident types and write at least the first few hours of each, including who to call, triage, containment and evidence preservation.
• Containment is a timing decision. Acting before the scope is known tips off the attacker and leaves persistence behind; eradicate only when all access paths, including service accounts and keys, are accounted for.
• Retainers and reporting clocks are set in peacetime. Agree provider terms, onboarding and tooling before an incident, and map every regulatory deadline (GDPR 72 hours, NIS2 24 hours, SEC four business days) into the plan.

The NIST SP 800-61 Rev. 3 model

SP 800-61 Rev. 2 (2012) described a cycle of preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Rev. 3, published on 3 April 2025 as a CSF 2.0 Community Profile, says that "Incident response is now considered a critical part of cybersecurity risk management" because incidents now run for weeks or months and a linear, periodic cycle no longer fits. Its Table 1 maps the old phases onto CSF 2.0.

Rev. 3 also fixes vocabulary. An event is "any observable occurrence that involves computing assets"; an adverse event has negative consequences; an incident actually or imminently jeopardises confidentiality, integrity or availability, or violates law or security policy. ISO/IEC 27035-1:2023 describes the same ground as preparing, detecting, reporting, assessing, responding and learning lessons, and applies equally to external incident response providers.

What the incident response plan must contain

• Scope and authority: an incident response policy (Rev. 3 recommends one) that gives the incident lead authority to act and names who decides on high-impact actions such as shutting down or rebuilding critical services.
• Contacts: the NCSC lists the IR team or provider, IT, senior management, legal, PR, HR and insurers, with at least two contact methods for each and two or more people per role.
• Escalation criteria: thresholds that move an incident up the chain, with out-of-hours contacts and required response times.
• A process flow: a one-page flowchart from report to closure, plus forms for tracking actions and decisions.
• Out-of-band communications: an always-available conference bridge and a channel that does not depend on the corporate email, identity provider or chat platform the attacker may control. CISA's federal playbook tells responders to notify users of compromised systems by phone, not email.
• Legal and regulatory triggers: what counts as reportable, when to involve counsel, and pre-drafted regulator notifications.
• Links to continuity: the NCSC ties incident response to disaster recovery, business continuity and crisis management.

Reporting deadlines

Map sector and contractual obligations (regulators, customers, insurers) into the same table. Under the SEC rule the clock starts at the materiality determination, so record how and when that decision was made. Use pre-approved holding statements, keep one owner for external messaging (RC.CO-04 asks for approved methods and messaging), and run internal updates on the cadence set by severity.

Roles and the CSIRT

FIRST defines a CSIRT (also CIRT or cyber incident response team) as "an organizational unit (which may be virtual) or a capability that provides services and support to a defined constituency for preventing, detecting, handling, and responding to computer security incidents". Most CSIRTs are virtual: a small core that pulls in others when an incident is declared.

Staffing models: an in-house CSIRT gives the fastest context but is costly to staff around the clock; an MSSP or MDR provider gives 24x7 detection and first response; most organisations run a hybrid with a retained provider for surge and forensics. Rev. 3 notes that third parties may be limited in what they can do, for example sharing only sanitised information, so define their responsibilities in contracts.

Classification, severity and declaration

The NCSC recommends assessing severity against availability (impact on business output), confidentiality (sensitive data accessed or stolen) and integrity (whether data or systems can still be trusted), and categorising incidents by type: malicious code including ransomware, denial of service, phishing, unauthorised access, insider activity, data breach and targeted attack. The matrix below is an example to tailor; CIS Safeguard 17.9 asks you to establish and maintain such thresholds.

Declaration: CSF DE.AE-08 asks that incidents are declared when defined criteria are met. Write those criteria down, and include deconfliction: CISA's playbook says to rule out authorised activity, such as a penetration test or an administrator's change, before declaring. Declaration starts the clocks for reporting and evidence handling, so record its exact time.

Playbooks

Rev. 3 notes that playbooks, with actionable steps for specific scenarios, are more usable than other formats, and recommends documented procedures for urgent emergency tasks such as redeploying the primary authentication platform. The NCSC advises starting with the three to five most likely and highest-impact incident types and says, "As a minimum, you should document a set of simple instructions which will cover at least the first few hours of each incident." CISA's federal playbook, written for US civilian agencies under Executive Order 14028, is a useful model: its checklist runs from declare, scope, collect and preserve, and technical analysis through to contain, eradicate, recover, post-incident and coordination.

Keep each playbook short, owned by a named person, reviewed after every use and linked to technical runbooks.

Containment, eradication and recovery

The NCSC says to take containment steps "once you're certain it's safe to do so" and to consider how the attacker might react. CISA's playbook warns against "tipping off" an attacker, for example by submitting malware samples to public analysis services or notifying users by email, because some adversaries monitor defenders and change tactics.

1. Contain: isolate hosts (EDR isolation keeps the management channel for investigation), block malicious domains and IPs, disable compromised accounts, and adjust detections to slow the attacker.
2. Preserve: CISA says to capture a memory and disk image when an endpoint needs forensic analysis, and to ensure "that all evidence has been collected" before eradication.
3. Plan eradication as one event: CISA's playbook requires that "all means of persistent access into the network have been accounted for" first. Reset credentials, remove persistence, reimage from clean sources (rebuild hardware for firmware rootkits) and apply missing patches in one coordinated window, so the attacker cannot re-enter through a path you left open.
4. Recover: RC.RP-03 asks you to verify backup integrity before use, including checking backups for indicators of compromise; restore in business priority order and confirm normal operation (RC.RP-05).
5. Watch for re-entry: monitor heightened detections for long enough to cover the attacker's known persistence, then declare the end of recovery (RC.RP-06).

Where identity fits

Eradication is mostly an identity exercise. Attackers persist through added accounts, new MFA methods, OAuth grants, service account passwords, API keys and signing keys, and a reset that covers only human passwords leaves those in place. The Cloudflare Thanksgiving Breach shows the cost: credentials not rotated after an earlier supplier breach let a nation-state attacker in weeks later. Inventory every non-human identity the attacker could have read and rotate them in the eradication window. If the identity provider itself is compromised, you will need tested break-glass access. See the Leaked Credential Response Playbook and the Break-Glass Account Guide.

Retainers and third-party support

Rev. 3 recommends contacting your incident response service provider when appropriate (RS.MA-01) and including suppliers in incident planning, response and recovery (GV.SC-08). In the UK, the NCSC's assured Cyber Incident Response (CIR) scheme assesses providers at Standard and Enhanced levels, and the NCSC says "all UK organisations should use an NCSC-assured Cyber Incident Response provider".

• Response time: a contractual time to first call and to on-site or remote engagement, at your busiest risk times.
• Scope: forensics, malware analysis, cloud and SaaS investigation, threat actor negotiation support, recovery engineering and surge staffing.
• Hours model: prepaid hours that can be redeployed to exercises, assessments or playbook work if unused.
• Onboarding before need: pre-approved access, deployed or ready-to-deploy collection tooling, environment documentation and named contacts. A retainer that starts with procurement on day one is not a retainer.
• Insurer alignment: many cyber policies specify panel providers; check whether your retained firm is acceptable to your insurer before an incident.
• Engagement through counsel: some organisations engage the provider through legal counsel to support legal privilege; whether that protection applies depends on jurisdiction, so take legal advice.
• Contract terms: data handling, confidentiality, report ownership and supplier incident disclosure (GV.SC-05).

Exercises and post-incident review

Drills, tabletops and training

An incident response drill is a rehearsal of part of the plan under realistic conditions, such as reaching the on-call executive at night, running a containment step or restoring from backup. A tabletop exercise is a facilitated discussion of a scenario; a functional or technical exercise has teams perform the actions. Rev. 3 (ID.IM-02) notes that exercises evaluate the programme and prepare staff and third parties, and points to NIST SP 800-84 for test, training and exercise programmes. CIS Safeguard 17.7 asks for routine exercises.

• Free scenario material: CISA Tabletop Exercise Packages provide objectives, scenarios, discussion questions, facilitator templates and an after action report template, covering ransomware, insider threat, phishing and industrial control systems. The NCSC's free Exercise in a Box offers 20 exercises on 12 topics.
• Cadence: one executive tabletop a year, a technical exercise for each priority playbook a year, and quarterly contact and bridge tests.
• Include suppliers: run at least one exercise a year with your retained provider and a key cloud or SaaS supplier.

Post-incident review

CISA calls it a hotwash: a review of root cause, procedural gaps, roles, training and tooling. The NCSC asks for two reviews in one, of the incident (what could have prevented it or detected it sooner) and of the response (what worked, what data was missing). Rev. 3 recommends lessons-learned meetings at the end of recovery (ID.IM-03) and an after-action report (RC.RP-06), and says lessons should be shared as soon as they are identified. CIS Safeguard 17.8 asks for post-incident reviews.

1. Hold the review within two weeks and rebuild the timeline from the scribe's log, separating facts from assumptions.
2. Run it blameless: focus on conditions and decisions, not individuals.
3. Turn each finding into an owned action with a due date, and add enterprise detections for every attacker technique that succeeded, as CISA's playbook recommends.
4. Update the plan and playbooks, and track actions to closure.

Building and measuring the programme

Phased rollout

1. Govern: approve the policy, name the incident lead and executive decision maker, and agree severity criteria.
2. Prepare: write the plan and contact list, set up out-of-band channels, and sign a retainer with onboarding completed.
3. Write playbooks: start with the top three to five incident types and test each in a tabletop before relying on it.
4. Pilot: run the process on real low and medium incidents for a quarter, adjust thresholds, then extend to critical scenarios.
5. Exercise and improve: run the annual cycle above and feed results into ID.IM.

Small organisations can meet most of this with a short plan, two or three playbooks, an MDR service and a retainer. Large organisations need a standing CSIRT, case management (open-source platforms such as TheHive or commercial SOAR), regional legal input and playbooks per business unit.

Metrics

• Time to declare: median time from first alert to declaration for confirmed incidents.
• Time to contain: median time from declaration to containment, by severity.
• Re-compromise rate: incidents where the attacker returned through a path not closed during eradication.
• Reporting compliance: regulatory notifications made within deadline, as a percentage.
• Exercise coverage: priority playbooks exercised in the last 12 months.
• Action closure: post-incident actions closed within 90 days.

Common failure patterns

• No decision authority: responders wait hours for someone to approve isolation. The Colonial Pipeline Ransomware Attack shows how quickly an IT incident becomes an operational shutdown decision.
• Partial eradication: rotating user passwords but not service accounts, tokens and keys, as in the Cloudflare case above.
• Containing too early: blocking one indicator alerts the attacker, who switches to a backup access path the team has not yet found.
• Communicating on compromised channels: discussing the response over email or chat the attacker can read.
• Shelfware plans: contact lists out of date, playbooks never exercised, retainer never onboarded.
• Lessons not learned: reviews held but actions never closed, so the same gap appears in the next incident.

Framework mapping

Practitioner checklist

• Name the incident lead, deputies and the executive who can approve shutting down a critical service.
• Write declaration criteria and a severity matrix with escalation targets and update cadence.
• Keep a contact list with two methods per person and an out-of-band bridge, and test it quarterly.
• Write playbooks for your top three to five incident types, covering at least the first hours.
• Sign and onboard a retainer, and confirm your insurer accepts the provider.
• Map every reporting deadline and pre-draft regulator and customer notifications.
• Make eradication a single coordinated event that includes service accounts, tokens and keys.
• Verify backups for compromise before restoring.
• Exercise each priority playbook yearly, including one exercise with suppliers.
• Hold a blameless review after every significant incident and track actions to closure.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
• NCSC: Cyber incident response processes
• ISO: ISO/IEC 27035-1, Information security incident management, Part 1: Principles and process
• FIRST: CSIRT Services Framework
• NCSC: Cyber Incident Response (CIR) scheme
• CISA: Tabletop Exercise Packages
• NIST: SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities

Related NHI Mgmt Group resources: Leaked Credential Response Playbook · Break-Glass Account Guide · ITDR Guide · Ransomware Prevention Guide · AI Agent Observability and Incident Response Guide