Key takeaway
Treat the plan as an operating document that shows who decides what and when, how evidence is preserved, and how services are restored.
Purpose and outcomes of a response plan
The plan defines who receives a report, how signals are assessed, how impact is contained and how operations are restored. Preparation has seven objectives: reduce damage and losses, strengthen security, support compliance work, shorten recovery, protect reputation and customer trust, improve threat understanding, and prepare employees. Connect each objective to an owner, procedure and exercise scenario.
More consistent decisions
Agreed roles, priorities and escalation criteria make decisions clearer under pressure.
Service recovery
Known critical services and dependencies make recovery order and acceptable downtime easier to plan.
Trust and communication
Approved internal channels and notification authority reduce the risk of inaccurate, delayed or conflicting statements.
Learning and readiness
Exercises, incident records and reviews expose weak handoffs and missing access.
Reading NIST and SANS models accurately
The common six-stage SANS model uses Preparation, Identification, Containment, Eradication, Recovery and Lessons Learned. Earlier NIST SP 800-61 Rev. 2 (2012) grouped work into four phases: Preparation; Detection and Analysis; Containment, Eradication and Recovery; and Post-Incident Activity. These remain useful historical operating models. NIST SP 800-61 Rev. 3, published in April 2025, supersedes Rev. 2 and integrates response into cybersecurity risk management across NIST CSF 2.0 rather than prescribing a separate linear four-phase cycle. It connects Detect, Respond and Recover with the preparation enabled by Govern, Identify and Protect.
| Model | What it provides | How to use it |
|---|---|---|
| Six-stage SANS model | An operational sequence from preparation through lessons learned. | Map its terms to your runbooks and escalation rules. |
| NIST SP 800-61 Rev. 2 | Four grouped phases; superseded by Rev. 3 in 2025. | Recognize references in existing policies; do not present it as current NIST guidance. |
| NIST SP 800-61 Rev. 3 / CSF 2.0 | Connects incident response with organization-wide cybersecurity risk management. | Plan governance, identification and protection alongside detection, response and recovery. |
Core parts of the plan
Base the plan on a current asset inventory, system dependencies and working communication channels. Name a backup for each role and define who receives authority if the primary owner is unavailable. Set incident categories and severity levels in terms your team uses, and explain how a technical signal becomes a business impact assessment.
Assets and priorities
Inventory servers, networks, applications, accounts, data types, cloud tenants, suppliers and critical service dependencies. Name service owners and recovery order.
Roles and authority
Identify the incident lead, technical investigators, system owners, leadership, legal and privacy specialists, HR and communications as appropriate. Record who may authorize isolation, account disabling, external notifications and recovery.
Communications and escalation
Define internal channels, backup contact methods, call trees, update cadence and the authorized spokesperson. If compromise is suspected, do not rely on corporate email or collaboration tools that may be untrusted.
Records and evidence
Record the timeline, decisions, approvals, observation sources, actions and evidence custody. An incident platform such as Jira Service Management can automate escalation if the organization has configured and tested that integration. Link investigation, forensic and recovery records; set evidence retention and sharing procedures with appropriate specialists.
Operational sequence during an incident
After an incident is classified, analysis, containment, communications, evidence preservation and recovery planning may proceed in parallel. This sequence turns familiar SANS stages into practical actions; use it with NIST Rev. 3’s risk-management approach.
Prepare and activate
Prepare the response team, runbooks, monitoring, backups and contact lists. When an incident threshold is met, appoint a lead, open an incident record and align time sources.
Detect, validate and assess impact
Validate alerts, user reports and system records in context. Identify affected assets, accounts, data, possible spread and business services; record unknowns explicitly.
Contain and preserve evidence
Take approved steps to limit spread: disconnect a device, restrict an account, revoke a session or quarantine a file. Consider effects on service, evidence and ongoing investigation; an unnecessary shutdown or deletion can destroy evidence.
Eradicate and recover
Identify and remove malware, backdoors and persistence, fix the exploited weakness and rotate credentials. Restore from a trusted, verified source; monitor for normal operation and signs of remaining threats.
Review and exercise again
Summarize the timeline, impact, actions and open risks. Identify what worked, which data or access was missing and whether escalation lagged; update the plan and controls with named owners and due dates.
Impact, communication and recovery objectives
Assess data sensitivity, service criticality, possible financial and operational effects, supplier dependencies and likelihood of spread. For each critical function, the recovery time objective (RTO) sets the target limit for downtime; the recovery point objective (RPO) sets the acceptable data-loss interval. These are targets, not guarantees, and should connect to owners, priorities, backups and tests. Assess legal or regulatory notification duties with qualified counsel based on incident facts and applicable jurisdiction.
External notifications
Name the owner for customer, partner, insurer, regulator and law-enforcement communications, with fact validation and sequencing.
Recovery dependencies
Record recovery order for identity, DNS, networking, backup catalogs, cloud accounts and critical suppliers. Verify recovery sources were not affected by the incident.
Define MTTR precisely
MTTR may mean average time to repair or restore; some teams use the acronym for time to respond or resolve. State the start and end events, incident population and formula in each report. For example, three failures causing six total hours of downtime give a two-hour mean time to repair. Read the average alongside severity, service impact and RTO because it can hide the effect of individual incidents.
Selecting an incident response partner
First identify your gaps: do you need around-the-clock monitoring, forensics, containment, eradication, recovery, exercises or post-incident review? The agreement should define service scope, escalation contacts, coverage hours and how response time is measured, system access, data handling and report contents. Get provider statements about availability and response speed in writing.
Needs and experience
Check experience with your technologies, sector and scenarios, team composition, current credentials and sample methodology. Seek references from organizations of similar size and complexity.
Scope, availability and integration
Ask about monitoring hours, geographic and technical coverage, on-call contact, integrations, investigation depth and on-site support. Clarify whether availability is an SLA and what exclusions apply.
Communication and reporting
Clarify who leads the incident, update cadence and decision approvals. Review a sample report for timeline, scope, methods, findings, limitations and recommendations.
Cost and follow-up support
Compare retainer, per-incident and subscription models, extra charges, cancellation and renewal terms. Ask about root-cause review, remediation planning, exercises and secure return or deletion of data after service ends.
Exercise the plan and report the incident
Review the plan at least annually and after significant technology, team or business changes; set exercise depth and cadence to risk. Include role owners from leadership through system teams in tabletop exercises, and check backup channels and authority. An incident report should describe the impact and owners for follow-up, as well as what happened.
What is a response plan and why have one?
The plan documents roles, response procedures, communications and post-incident review. Even under pressure, the team knows its decision authority, escalation path and next step.
How often should a plan be updated and tested?
Review the plan and run an exercise at least annually. After significant infrastructure, supplier, team or business changes, and after an incident, update the procedures and test the changes.
What belongs in an incident report?
Include incident type, affected systems and timeline; detection and analysis methods and exploited weakness; containment, eradication and recovery actions; known data, financial and reputational impact; uncertainties; lessons and specific actions with owners and due dates. Do not present unverified figures as facts.
How many stages should a response plan use?
There is no single required count. The familiar SANS model has six stages; earlier NIST SP 800-61 Rev. 2 used four grouped phases and was superseded by Rev. 3 in 2025. Align the current plan with NIST CSF 2.0 risk management and tailor its stages to your roles, authority and recovery needs.