NIST SP 800-61 Rev.3: NIST SP 800-61 Rev.3 – Tutorial (about 60 minutes)

NIST Special Publication 800-61 Revision 3 is the US National Institute of Standards and Technology's guidance on cybersecurity incident response, rewritten in 2025 so that responding to incidents is treated as part of everyday cybersecurity risk management rather than as a separate emergency activity. It is used by security leaders, security operations and incident response teams, IT and cloud engineers, risk and compliance staff, and the managed service providers who support them, in organisations of every size and sector. After this tutorial you will be able to explain the new life cycle model, read the CSF 2.0 Community Profile at the heart of the document, turn its recommendations into a practical plan, and show how your incident response capability is evaluated and improved.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is NIST SP 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, written by Alex Nelson, Sanjay Rekhi, Murugiah Souppaya and Karen Scarfone and published by NIST in April 2025 (final release dated 3 April 2025, after an initial public draft in April 2024). It is final and current, and it supersedes Revision 2, the Computer Security Incident Handling Guide of August 2012. Revision 3 is a full rewrite, not a light update: it no longer contains the step-by-step handling procedures of Revision 2, and instead organises its advice around the six Functions of the NIST Cybersecurity Framework (CSF) 2.0. NIST keeps the frequently changing material, such as links to playbooks and technical guides, on a separate Incident Response project page so it can be updated without a new revision; that page was last updated in November 2025. The publication is free to download and, as a US government work, not subject to copyright in the United States. No newer revision or draft had been announced. Verified 2026-10-29 on the NIST Computer Security Resource Center (CSRC).

Who this is for: security analysts and incident handlers, security operations centre (SOC) leads, IT and cloud engineers, security managers, risk, audit and compliance professionals, legal and communications staff, and people who learned the older four-phase NIST model and want to understand what changed.

Prerequisites: none. A general idea of how an organisation runs its IT (accounts, servers, cloud services, backups, logs) helps. Every term from the Cybersecurity Framework is explained when it first appears, so you do not need to know CSF 2.0 beforehand.

By the end of this tutorial:

You will be able to explain why NIST rewrote SP 800-61, what problem Revision 3 solves and how its scope differs from Revision 2.
You will be able to define the key terms (event, adverse event, incident, indicator of compromise, containment, eradication, recovery and others) and use them consistently.
You will be able to describe the CSF 2.0-based life cycle model, including the split between preparation, incident response and continuous improvement, and map the old four phases onto it.
You will be able to read a row of the Community Profile, interpret its priority and its recommendations, considerations and notes, and cite an item with its unique identifier.
You will be able to plan practical incident response work: roles, policy, plans, playbooks, detection, triage, containment, recovery and communication, including work with third parties.
You will be able to explain how incident response capability is assessed and evidenced when there is no "SP 800-61 certificate".
You will be able to relate SP 800-61r3 to CSF 2.0, SP 800-53, ISO/IEC 27035, ISO/IEC 27001 and other incident guidance.

Lesson 1 – Origins, purpose and scope

Why incident response guidance matters

Every organisation that depends on technology will suffer cybersecurity incidents, from a single infected laptop to ransomware that stops production or a compromised software update that reaches thousands of customers. The organisation cannot control what attackers do or when. It can control how well prepared it is, how quickly it notices trouble, how effectively it responds and how much it learns. Incident response is the discipline that covers those activities.

NIST has published incident handling guidance in the SP 800-61 series since the early 2000s. Revision 2, released in 2012, became one of the most widely cited incident response documents in the world. Its four-phase life cycle (Preparation; Detection and Analysis; Containment, Eradication and Recovery; Post-Incident Activity) was copied into many corporate plans, far beyond the US federal agencies it was written for.

Why a rewrite was needed

Revision 3 explains frankly that the world described in 2012 no longer exists. At that time incidents were relatively infrequent, most had a narrow and well-defined scope, and response and recovery often finished within a day or two. Under those conditions it made sense to treat incident response as a separate set of activities carried out by a dedicated team, and to draw it as a neat circle in which lessons learned at the end fed preparation for the next incident.

Today incidents happen far more often and cause much greater damage. Recovery from a large incident can take weeks or months, and cloud services, managed providers and software supply chains mean one incident can involve many organisations. Lessons often need sharing the moment they are discovered. NIST therefore concluded that incident response must be woven into the whole of cybersecurity risk management.

A second reason was practical. Detailed technical handling advice ages quickly. Rather than keep a large static document current, NIST moved technical detail and links to a project website and to mappings in its online reference tool, and kept the publication focused on outcomes, recommendations and considerations that stay valid for longer.

Purpose in one sentence

SP 800-61r3 helps organisations build incident response recommendations and considerations into all of their cybersecurity risk management activities, so that they are better prepared, suffer fewer and less damaging incidents, and detect, respond to and recover from incidents more efficiently and effectively. It also gives everyone a shared vocabulary for talking about incident response plans and activities, inside the organisation and with partners, suppliers and regulators.

Scope: what Revision 3 is and is not

It is guidance, not a regulation. NIST develops it under its statutory responsibilities for federal information security, and non-government organisations may use it voluntarily.
It is written for most organisations, regardless of sector, size or other factors. NIST notes that narrower versions, for example for federal agencies, small businesses or educational institutions, could be developed later.
It covers cybersecurity incidents only. Other adverse events, such as storms or power cuts, belong to business continuity and disaster recovery, although the plans must work together.
It is organised as a CSF 2.0 Community Profile: a selection and prioritisation of Cybersecurity Framework outcomes with incident-specific advice added.
It is not a procedure manual. It does not tell you which tool to use or which commands to run. Those details live in playbooks, vendor documentation and the resources NIST links from its project page.
It does not insist on its own model. NIST says organisations should use whichever incident response life cycle framework or model suits them best, as long as incident response is considered throughout their risk management.

That last point surprises many readers. Revision 3 offers a CSF-based model because so many organisations already use the CSF, but it explicitly allows a different model, for example one inherited from Revision 2 or an international standard, if it fits better.

Lesson 2 – Key concepts and vocabulary

Incident response conversations go wrong quickly when people use words loosely. These are the terms you will meet most often.

Event – any observable occurrence involving computing assets (physical or virtual platforms, networks, services, cloud environments), such as a user signing in.
Adverse event – an event with a negative consequence, whatever the cause. The publication deals only with adverse cybersecurity events, meaning events with a potentially negative impact on cybersecurity.
Cybersecurity incident – NIST uses the US legal definition from the Federal Information Security Modernization Act of 2014 (FISMA). In plain words, an incident is something that actually or imminently puts the confidentiality, integrity or availability of information or systems at risk without lawful authority, or that violates (or imminently threatens to violate) law, security policies, security procedures or acceptable use policies. Not every adverse event is an incident; analysis decides.
Incident response – the remediation or mitigation of violations of security policies and recommended practices; in practice, everything done to detect, analyse, contain, eradicate and recover from incidents and to communicate about them.
Indicator of compromise (IoC) – a technical artefact or observable, such as a malicious file hash, a suspicious domain or an unusual login pattern, suggesting that an attack is imminent, under way or has already succeeded.
Tactics, techniques and procedures (TTPs) – the behaviour of an attacker described at three levels: tactics are the broad goals, techniques describe how a goal is pursued, and procedures are the detailed, specific steps.
Cyber threat intelligence (CTI) – threat information that has been gathered, analysed and enriched so that it gives the context needed for decisions, for example which groups target your sector and how.
Triage – the preliminary review of a new report to confirm that an incident has really occurred and to estimate its severity and urgency.
Escalation and elevation – escalation means adding resources or extending time frames for an incident; elevation means involving a higher level of management. The two are often confused.
Containment – preventing an incident from expanding, for example by isolating an infected server or disabling a stolen account, so that damage stops spreading and the organisation is not overwhelmed.
Eradication – removing the incident's effects and the attacker's footholds: deleting malware, removing persistence mechanisms, disabling breached accounts and fixing the exploited weaknesses.
Recovery – restoring affected assets and operations to normal, verifying that they work correctly and are clean, and declaring when recovery is complete.
Root cause analysis – working out not only what happened but how and why, including systemic weaknesses in processes or architecture that allowed it.
Evidence and chain of custody – evidence is data on which proof can be based; chain of custody is the documented record of who collected, handled and stored it, which matters if legal action is possible.
Playbook – a documented set of actionable steps for people to follow in a particular scenario, such as a ransomware outbreak or a compromised cloud account.
Community Profile – a baseline of CSF outcomes published for organisations with shared interests, such as a sector, technology or threat type.

Events, adverse events and incidents

The first three terms shape the whole detection process. Organisations generate millions of events every day; a small fraction look potentially harmful, such as a burst of failed logins or a process encrypting many files. Analysts and tools examine these potentially adverse events, correlate them and compare them with defined incident criteria. Only when the criteria are met is an incident declared, and that declaration is the formal trigger that starts the incident response plan. Many organisations lose time because nobody is sure who may declare an incident or what the criteria are; Revision 3 treats both as things to settle in advance.

Lesson 3 – The new life cycle model and the structure of the publication

The six CSF 2.0 Functions

Revision 3 is built on the NIST Cybersecurity Framework 2.0, published in February 2024. CSF 2.0 organises cybersecurity outcomes into six Functions, each divided into Categories and then Subcategories. The Functions are:

Govern (GV) – strategy, expectations and policy for managing cybersecurity risk are set, communicated and monitored.
Identify (ID) – the organisation's current cybersecurity risks are understood.
Protect (PR) – safeguards to manage those risks are used.
Detect (DE) – possible attacks and compromises are found and analysed.
Respond (RS) – actions are taken regarding a detected incident.
Recover (RC) – assets and operations affected by an incident are restored.

NIST stresses that all six Functions play a vital role in incident response. Govern, Identify and Protect help prevent some incidents, prepare for those that still happen, reduce their impact and drive improvement. Detect, Respond and Recover help organisations discover, manage, prioritise, contain, eradicate and recover from incidents, and handle reporting, notification and other communications.

Three layers instead of one circle

The new model replaces the old circle with three levels. One level is preparation: Govern, Identify and Protect. These are broad risk management activities that support incident response but are not part of responding to a particular incident. Another is incident response itself: Detect, Respond and Recover. Between them sits continuous improvement, represented by the Improvement Category of the Identify Function, known as ID.IM. Lessons learned from every activity in every Function flow into Improvement, where they are analysed and prioritised, and the results flow back out to inform all six Functions.

Figure 1 – The Revision 3 life cycle model: preparation and incident response layers, with Improvement (ID.IM) collecting lessons from all Functions and feeding changes back.

The important change is that improvement is no longer a single "post-incident" step. If an analyst notices during detection that an attacker technique bypasses existing safeguards, that lesson is passed on right away, so protection or monitoring can be adjusted while the incident is still running.

Mapping the old phases to the new Functions

Because so many organisations know the Revision 2 model, the publication includes a table mapping the old phases to CSF 2.0 Functions. In summary, the old Preparation phase corresponds to Govern, all of Identify, and Protect. Detection and Analysis corresponds to Detect, Respond and Identify's Improvement Category. Containment, Eradication and Recovery corresponds to Respond, Recover and Improvement. Post-Incident Activity corresponds to Improvement. Notice that Improvement appears in three of the four rows: learning is now expected throughout, not only at the end.

NIST adds that larger, more technology-dependent organisations are likely to gain most from a model that emphasises continuous improvement.

How the document is organised

After an executive summary the publication has three sections and three appendices:

Section 1, Introduction – definitions, examples of modern incidents, purpose and scope.
Section 2, Incident response as part of cybersecurity risk management – the life cycle model (2.1), roles and responsibilities inside and outside the organisation (2.2), and incident response policies, processes and procedures (2.3).
Section 3, the CSF 2.0 Community Profile – the core of the publication, in two tables: Table 2 covers Preparation and Lessons Learned (Govern, Identify and Protect, including ID.IM), and Table 3 covers Incident Response (Detect, Respond and Recover).
Appendices – A, a list of abbreviations; B, a glossary; C, a change log summarising what changed from Revision 2.

Reading a row of the Community Profile

Each CSF Function, Category and Subcategory has its own row in one of the two tables. A row shows the CSF identifier (for example RS.MA-02), the CSF outcome description, a priority for incident response, and a final column of advice. The priority has three values. High means the element works as a core incident response activity for most organisations. Medium means it directly supports incident response. Low means it supports incident response only indirectly. NIST presents these priorities as a starting point, and organisations are encouraged to adjust them to their own situation.

The advice column contains numbered items of three kinds. An item starting with R is a recommendation, something the organisation should do. An item starting with C is a consideration, something it should consider doing. An item starting with N is a note that adds information. Appending the item to the CSF identifier gives a label that is unique within the profile: for example, GV.OC-03.R1 is the first recommendation for Subcategory GV.OC-03, which is about understanding legal, regulatory and contractual requirements. Advice given at a Function or Category level also applies to everything beneath it.

Figure 2 – How the publication is structured, from its sections down to a single Community Profile row and its R, C and N items.

Where the priorities sit

Most elements in Table 2 are not specific to running a response, so they carry Low or Medium priority and many have no recommendations; NIST stresses that this does not make them unnecessary. A few preparation elements stand out as High: having an incident response policy within the organisation's cybersecurity policies (GV.PO), receiving cyber threat intelligence (ID.RA-02), using threats, vulnerabilities, likelihoods and impacts to understand risk (ID.RA-05), choosing and tracking risk responses (ID.RA-06), learning from tests, exercises and real operations (ID.IM-02 and ID.IM-03), maintaining incident response and related plans (ID.IM-04), and creating, protecting and testing backups (PR.DS-11).

Every element in Table 3 is specific to responding to incidents, so all of them are High and all have recommendations or considerations. The main Categories there are Continuous Monitoring (DE.CM) and Adverse Event Analysis (DE.AE) under Detect; Incident Management (RS.MA), Incident Analysis (RS.AN), Incident Response Reporting and Communication (RS.CO) and Incident Mitigation (RS.MI) under Respond; and Incident Recovery Plan Execution (RC.RP) and Incident Recovery Communication (RC.CO) under Recover.

Lesson 4 – How it works in practice

A Community Profile is a list of outcomes, so you still need to turn it into people, documents and routines. This lesson walks through the practical building blocks, following the order an organisation usually puts them in place.

Roles and responsibilities

Revision 2 pictured incident response as the work of a single team. Revision 3 recognises that success now depends on many internal and external parties, and that roles can differ by incident. Typical roles include:

Leadership, which oversees and funds incident response and may decide on high-impact actions such as shutting down a critical service.
Incident handlers, who verify incidents, analyse data and evidence, prioritise work, limit damage, find root causes and restore operations. They may be on staff, on contract (for example a SOC run by a managed security services provider) or available when needed from a parent company or partner.
Technology professionals: security, system, network and cloud engineers, administrators and software developers.
Legal, which reviews plans and contracts and advises on notification law and possible prosecution or lawsuits.
Public affairs and media relations, ideally with a media strategy prepared in advance.
Human resources, for onboarding and offboarding practices and suspected malicious insiders; physical security and facilities, for combined physical and logical attacks.
Asset owners, who know what to restore first and must be kept informed.

Large organisations with several incident response teams should run them as one coordinated federation, with consistent processes, training and information sharing.

Figure 3 – The many parties that an incident lead coordinates during a response, inside and outside the organisation.

Working with third parties

Some third parties fill a primary role, such as a provider that performs detection, response and recovery around the clock; others, such as cloud and internet providers, join for particular kinds of incident. In this shared responsibility model the contract should state who does what, how information flows, who may act on the organisation's behalf and what the provider may not do, such as sharing sanitised incident details with other customers. A provider often sees attacks sooner because it correlates activity across customers, but it also holds privileged access, so a compromise of the provider must be managed as a risk too. Under Govern, the profile highlights including incident disclosure and information sharing in supplier requirements (GV.SC-05) and including relevant suppliers in incident planning, response and recovery (GV.SC-08).

Policy, plan, procedures and playbooks

Revision 3 describes a layered set of documents. The incident response policy sets the rules. Although every policy is tailored, most contain the same elements: a statement of management commitment; purpose and objectives; scope (to whom and what it applies, and when); definitions of events, incidents, investigations and related terms; roles, responsibilities and authorities, such as who may confiscate, disconnect or shut down equipment; guidelines for prioritising incidents, estimating severity, starting recovery and keeping operations running; and performance measures.

The incident response plan is the roadmap for putting the capability into action. Under ID.IM-04 the profile notes that several plans are relevant to incident response, notably the incident response plan itself, vulnerability management plans and business continuity plans, and recommends keeping business continuity and incident response plans synchronised, since incidents can undermine business resilience. Plans should reflect the organisation's own requirements, mission and size, and should be reviewed periodically or whenever a significant improvement is identified.

Procedures explain how to carry out technical and operational processes; they can be exercised and used for training. Since nobody can cover every situation, NIST suggests focusing on the most common incident types and on processes urgently needed in emergencies, such as redeploying the primary authentication platform. Many organisations package procedures as playbooks; CISA, the US Cybersecurity and Infrastructure Security Agency, publishes examples that NIST points to.

Detection: monitoring and analysis

Under Detect, continuous monitoring (DE.CM) should cover networks, computing hardware and software, the physical environment, personnel activity and external service providers. Tools need tuning so that false positives (alarms about harmless activity) and false negatives (missed attacks) stay acceptable.

Adverse event analysis (DE.AE) turns monitoring data into decisions. Because the volume is huge, NIST recommends technical solutions, such as a security information and event management (SIEM) system, to filter events down to what humans can review. Analysts correlate sources, estimate impact and scope, integrate threat intelligence and declare an incident when the activity meets the defined criteria (DE.AE-08). Finding incidents earlier in the attack life cycle limits their impact and scope.

Response: management, analysis, mitigation and communication

Once an incident is declared, Incident Management (RS.MA) takes over. The plan is executed in coordination with relevant third parties; NIST suggests designating an incident lead for each incident and, where useful, calling on an incident response service provider and starting business continuity or disaster recovery plans. Reports are triaged and validated (RS.MA-02), then categorised by type, such as data breach, ransomware, account takeover or denial of service, and prioritised (RS.MA-03). A key recommendation is that incidents should not be handled first come, first served. Prioritisation, escalation, elevation and the decision to begin recovery should all rest on a set of risk evaluation factors. Examples NIST gives are asset criticality, functional impact, data impact, the stage of observed activity, the characterisation of the threat actor and recoverability. The status of each incident should be tracked, including a summary, related indicators, assigned actions with time frames and next steps.

Choosing a strategy involves trade-offs: watching an attacker or investigating deeply may conflict with returning to normal quickly. Redirecting an attacker into an isolated sandbox to gather evidence delays containment and can let the attacker escalate access, so NIST advises discussing it with the legal department first.

Incident Analysis (RS.AN) establishes the sequence of events, the assets involved, the vulnerabilities, threats and actors that played a part, and the underlying root causes. Investigation actions are recorded, and the integrity and provenance of records and incident data are preserved, since collected data is treated as evidence even when prosecution is unlikely. Estimating the true magnitude (RS.AN-08) is one of the hardest parts: responders should search other potential targets as well as the known ones, or the incident may continue unseen.

Incident Mitigation (RS.MI) covers containment (RS.MI-01) and eradication (RS.MI-02). Tools can be configured to act automatically, for example quarantining malware or moving an endpoint to an isolated network, and providers can be authorised to act against incidents such as large denial-of-service attacks. Handlers should still be able to choose actions manually. Pre-agreed criteria, considering the incident type and how long a temporary measure may stay, speed these choices up.

Incident Response Reporting and Communication (RS.CO) falls into four kinds of activity, which are easy to blur. Coordination means keeping everyone with a role informed about current and planned actions. Notification means formally informing affected customers, employees, partners, regulators or others, often because the law requires it. Public communication means telling the public, for example in response to media questions. Information sharing means passing threat information, usually voluntarily, to others such as a sector Information Sharing and Analysis Center (ISAC). Notification laws vary by sector and location and change frequently, so the plan should state what must be reported to whom and when, and designated people should handle contacts with law enforcement and regulators.

Recovery

Recovery (RC) restores systems from clean backups, rebuilds systems, patches, changes passwords and tightens controls; against a sophisticated attacker it may even mean replacing hardware. The recommendations stress verifying the integrity of backups and other restoration assets before using them (RC.RP-03), restoring essential services in the right order with system owners confirming success (RC.RP-04), checking restored assets for indicators of compromise and fixing root causes before production use (RC.RP-05), and declaring the end of recovery against criteria, with an after-action report that documents the incident, the actions taken and the lessons learned (RC.RP-06). Recovery communication (RC.CO) continues the reporting work, including regular updates to senior leadership and approved public messages about how the organisation is recovering and preventing a recurrence.

Figure 4 – A typical path through Detect, Respond and Recover for one incident, with communication running in parallel and lessons feeding Improvement.

Real incidents rarely move in a straight line: analysis may reveal new affected systems and send responders back to containment. The figure shows the logical order of outcomes, not a strict sequence.

Improvement

Improvement (ID.IM) gathers lessons from evaluations such as self-assessments, third-party assessments and audits (ID.IM-01), from tests and exercises including those run with suppliers (ID.IM-02), and from real operations, including incident response and recovery (ID.IM-03). Improvements may change the incident response programme itself, its plan, policy and procedures, or other parts of risk management, for instance blocking an attacker technique that current safeguards missed. A "lessons learned" meeting near the end of a major incident remains valuable, but it is one source among many.

Lesson 5 – Assessment, evidence and compliance

There is no SP 800-61 certificate

NIST does not certify organisations against SP 800-61r3, does not accredit auditors for it and does not run a conformance scheme. The publication is a set of recommendations and considerations, not a list of auditable "shall" requirements. Any claim of being "SP 800-61 certified" should be treated with caution. What organisations can do is show, with evidence, that their incident response capability achieves the outcomes in the profile to a level that matches their risk.

Individual professionals can obtain incident handling credentials from private training and certification bodies, but these are not issued or endorsed by NIST and do not certify an organisation.

Using the profile for self-assessment

Because Revision 3 is a CSF 2.0 Community Profile, it slots neatly into the way the CSF is normally used. CSF 2.0 describes an Organizational Profile made of a Current Profile, the outcomes the organisation achieves today, and a Target Profile, the outcomes it aims to achieve. A Community Profile such as SP 800-61r3 can serve as the starting point for the target. The gap between current and target becomes an action plan with owners and dates. CSF 2.0 also offers Tiers (Partial, Risk Informed, Repeatable and Adaptive) to describe how rigorous an organisation's overall risk governance and management practices are; these characterise the programme as a whole and are not scores for individual subcategories.

A sensible self-assessment rates each High-priority row as met, partially met or not met, with evidence, and reviews Medium and Low rows more lightly, recording why any priority was changed.

What evidence looks like

An approved policy with the key elements of Section 2.3, and a plan synchronised with continuity plans, plus playbooks.
A roles and authorities matrix, contact lists, and contracts defining third-party duties.
Monitoring coverage maps, alert tuning records and documented declaration criteria.
Incident tickets showing triage, risk-based prioritisation, status tracking, evidence handling and closure.
Backup restoration test records, exercise reports, after-action reports and an improvement log.
Performance measures such as time to detect and time to contain.

Who assesses, and where obligations come from

Assessment is usually done by internal audit, the security team itself, an independent consultant, or a customer or regulator reviewing the organisation's practices. For US federal agencies, FISMA and Office of Management and Budget policy require incident handling capabilities, and the incident response control family (IR) in NIST SP 800-53 is assessed as part of the Risk Management Framework; NIST's online reference tool maps CSF outcomes to SP 800-53 controls. Outside government, obligations to have an incident response capability, or to report incidents within set time limits, come from sector regulators, data protection laws, contracts and cyber insurance policies. SP 800-61r3 does not set those deadlines; it tells you to identify every applicable requirement (GV.OC-03) and build it into your plans.

Exercises as assessment

Exercises are one of the most revealing forms of assessment; NIST refers to SP 800-84 for tabletop exercises, simulations and other tests. They show whether people know their roles, whether contact lists work and whether third parties respond as promised. The results feed ID.IM-02.

Lesson 6 – Worked example: a logistics company applies Revision 3

The organisation

Harbourline Logistics is a fictional freight company with about 900 employees in four countries. It runs a warehouse system in a public cloud, uses a software-as-a-service email suite, keeps finance and file servers in a small data centre, and outsources round-the-clock monitoring to a managed security services provider (MSSP). Its old plan followed the Revision 2 phases and named only the internal security team. After a customer asked for evidence of incident readiness, the chief information security officer (CISO) adopted SP 800-61r3.

Step 1 – Assess the current state

The CISO's deputy assessed each High-priority profile row in a spreadsheet with the infrastructure, legal and communications managers. The policy did not define who could declare an incident or shut down systems. The MSSP contract said the provider would "alert" Harbourline but gave it no authority to isolate endpoints at night. Monitoring covered the data centre well but barely covered the cloud platform. Backups existed but had never been restored in a test. Nobody had mapped notification duties across the four countries.

Step 2 – Set targets and fix governance

Harbourline treated the profile as its Target Profile, raised the priority of the supplier rows (GV.SC-05 and GV.SC-08) because of its dependence on the MSSP and the cloud provider, and recorded that change with its reason. Legal compiled the notification requirements for each country and for key customer contracts (GV.OC-03). The policy was rewritten to include management commitment, scope, definitions, a roles and authorities table, prioritisation guidelines and performance measures. The MSSP contract was amended so that the provider could automatically isolate an endpoint showing ransomware behaviour, with a phone call to Harbourline's on-call handler within fifteen minutes, and so that it could not share Harbourline details with other customers without approval.

Step 3 – Prepare detection and plans

Cloud audit logs and identity provider sign-in logs were sent to the MSSP's SIEM (PR.PS-04 and DE.CM). The team wrote incident declaration criteria and three playbooks: compromised account, ransomware and supplier compromise. Backups for the file and finance servers were moved to storage that cannot be altered for thirty days, and a quarterly restore test was scheduled (PR.DS-11). The business continuity plan was updated to refer to the incident response plan, and vice versa (ID.IM-04). A tabletop exercise with the MSSP, the cloud provider's support team and the communications manager showed that the media holding statement had no approver; that gap was fixed the same week (ID.IM-02).

Step 4 – A real incident

Four months later, at 02:10 on a Sunday, the SIEM correlated three signals: a finance clerk's account signing in from an unusual country, the creation of a mailbox forwarding rule, and, an hour later, a file server process renaming files at high speed. The MSSP analyst checked the activity against the declaration criteria and declared an incident (DE.AE-08). The MSSP's automated containment isolated the file server, as the amended contract allowed, and the analyst phoned Harbourline's on-call handler, who became the incident lead (RS.MA-01).

The incident lead triaged the report, confirmed it, categorised it as ransomware combined with account takeover and rated it high priority using the policy's risk factors: a critical asset, high functional impact, possible data impact, and attacker activity at a late stage (RS.MA-02 and RS.MA-03). Because the incident might cause a multi-day outage, the lead elevated it to the CISO and the operations director, and escalated it by calling in the MSSP's incident response retainer team (RS.MA-04).

Step 5 – Analyse, contain, eradicate

Analysts preserved disk images and logs with a chain-of-custody form, kept a timestamped action log in a restricted channel (RS.AN-06 and RS.AN-07), and reconstructed the sequence: a phishing email had captured the clerk's password and a session token, the attacker had used the account to reach a file share, and from there had deployed ransomware tooling on the file server. Searching beyond the known targets (RS.AN-08) found the same tooling, not yet executed, on a second server, which was also isolated. The team disabled the clerk's account and revoked its sessions, removed the forwarding rule, deleted the attacker's scheduled tasks, and blocked the attacker's infrastructure (RS.MI-01 and RS.MI-02). Root cause analysis pointed to a weak point: the finance group was exempt from phishing-resistant multi-factor authentication (RS.AN-03).

Step 6 – Communicate

The incident lead updated leadership every four hours (RS.CO-03). Logs showed outbound transfers from the file share, so Legal used the pre-built matrix to notify data protection authorities, affected employees and key customers within the required time limits (RS.CO-02). The communications manager issued the pre-approved holding statement when a journalist called, and the team shared the attacker's indicators with its sector ISAC.

Step 7 – Recover and close

The recovery portion of the plan began on Monday morning (RC.RP-01). Before restoring, engineers scanned the immutable backups for the attacker's tools and checked their integrity (RC.RP-03). They restored the finance server first, then the shared file areas used by warehouses, following the business priority list, and system owners confirmed each service (RC.RP-04). Restored servers were checked for indicators of compromise and patched before going back online (RC.RP-05). Recovery updates went to staff and customers (RC.CO-03). On Thursday the incident lead declared the end of recovery against the policy criteria and wrote the after-action report (RC.RP-06).

Step 8 – Improve

The improvement log received five actions (ID.IM-03), including removing the multi-factor exemption, a detection rule for new mailbox forwarding rules and a new tabletop scenario. Two had already been made during the incident, because the analyst passed the lesson on at once, exactly as the continuous improvement layer intends. The CISO also presented the incident to the board, and its lessons were used to adjust next year's security strategy (GV.OV-01).

What the example shows

The response succeeded mostly because of preparation: a contract allowing automatic containment, logs in monitoring, declaration criteria, a notification matrix, tested backups and rehearsed communication. That is the central message of Revision 3: capability is built through governance, identification and protection, then proven in detection, response and recovery.

Lesson 7 – Relationship to other standards and frameworks

SP 800-61r3 sits in a family of related documents. Knowing the neighbours helps you decide which to use for what, and avoids duplicate work.

Document	Owner	Main purpose	Relationship to SP 800-61r3
NIST Cybersecurity Framework (CSF) 2.0	NIST	Outcome-based framework for managing cybersecurity risk across six Functions	The foundation: SP 800-61r3 is a CSF 2.0 Community Profile and uses its Functions, Categories and Subcategories as its structure.
NIST SP 800-61 Revision 2 (2012)	NIST	Detailed computer security incident handling guide with a four-phase life cycle	Superseded by Revision 3. Its phases map onto CSF Functions; some organisations still use its model, which Revision 3 allows.
NIST SP 800-53 Rev. 5 (IR family)	NIST	Catalogue of security and privacy controls, including incident response controls such as handling, monitoring, reporting and the response plan	Controls that can implement the profile's outcomes; NIST's reference tool maps CSF outcomes to them. Required for US federal systems (baselines in SP 800-53B).
NIST SP 800-184	NIST	Guide for cybersecurity event recovery planning	Referenced by the Recover rows for deeper guidance on recovery planning and execution.
ISO/IEC 27035 series	ISO and IEC	International standard on information security incident management (principles and process, planning and preparing, operations)	Similar ground, with its own phases and terms; useful for international organisations. Parts 1 and 2 were revised in 2023.
ISO/IEC 27001:2022 (Annex A 5.24–5.28)	ISO and IEC	Certifiable information security management system, with controls for incident planning, assessment, response, learning and evidence	A certifiable management system; SP 800-61r3 can supply practical content for those incident controls.
CISA incident and vulnerability response playbooks	CISA (US)	Operational procedures for federal civilian agencies	Example playbooks that NIST points to for turning profile outcomes into step-by-step procedures.

How the pieces fit

If your organisation already uses CSF 2.0, SP 800-61r3 is the natural next layer: the same identifiers, with incident-specific priorities and recommendations added to your profiles. The CSF describes what to achieve; SP 800-53 describes controls that can achieve it, and the NIST Cybersecurity and Privacy Reference Tool (CPRT) maps one to the other. Organisations certified to ISO/IEC 27001 can use SP 800-61r3 alongside ISO/IEC 27035: the ISO standards provide the management system and international terminology, and the NIST profile adds recommendations tied to the CSF taxonomy. Keep one vocabulary in your own documents and map the other to it, rather than writing two parallel plans.

Other neighbours

SP 800-61r3 also points to SP 800-84 for exercises, SP 800-150 for threat information sharing, SP 800-92r1 for log management planning, SP 800-216 for vulnerability disclosure and SP 800-218 (the Secure Software Development Framework) for incidents involving released software. Attack technique knowledge bases such as MITRE ATT&CK are useful for describing attacker TTPs during detection and analysis, but they are catalogues of behaviour, not incident response frameworks.

Common pitfalls and best practices

Pitfalls

Treating Revision 3 as a procedure manual. Teams looking for step-by-step handling instructions conclude the document is "too high level". It is intentionally outcome-based; the procedures are yours to write, using playbooks and linked resources.
Relabelling the old plan. Replacing the words "Preparation" and "Post-Incident Activity" with CSF Function names without changing behaviour misses the point: improvement must happen throughout, and preparation must be risk management.
Ignoring Low and Medium rows. A low incident response priority does not mean the outcome is optional for the organisation; it means it supports incident response indirectly.
Vague third-party arrangements. Contracts that do not define authority to act, information flows and notification duties lead to delays at the worst possible moment.
Handling incidents first come, first served. Without risk-based prioritisation, a minor alert can consume the team while a critical one waits.
Underestimating magnitude. Cleaning the obviously affected systems while skipping a wider search lets the attacker stay elsewhere.
Restoring from untested or compromised backups. Restoration assets can contain the attacker's tools; restoring them reinfects the environment.
Leaving notification law to the moment. Researching legal deadlines during an incident costs time the law may not allow.

Best practices

Write down who can declare an incident and who can shut systems down. Put the authority in the policy and the contact details in the plan.
Tailor the profile and record the reasons. Adjust priorities for your environment and keep the rationale, so reviewers understand your choices.
Prioritise with explicit risk factors. Use factors such as asset criticality, functional and data impact, attack stage, actor and recoverability, from simple to sophisticated as your maturity grows.
Combine automation with human judgement. Let tools and providers contain common threats automatically, but keep the ability for handlers to choose actions manually.
Exercise with your suppliers. Include the MSSP, cloud provider and key vendors in tabletop exercises and feed the results into the improvement log.
Share lessons immediately. Pass a newly discovered technique or detection gap to the people who can act on it during the incident, not only in the final report.
Keep plans synchronised. Review incident response, business continuity and disaster recovery plans together and update them after major incidents.
Protect incident records. Restrict access to incident logs and evidence, preserve their integrity, and retain them according to policy.

Summary and key takeaways

NIST SP 800-61 Revision 3 (April 2025) is the current NIST incident response guidance and supersedes the 2012 Revision 2 handling guide.
It treats incident response as an integral part of cybersecurity risk management and organises its advice as a CSF 2.0 Community Profile.
Its life cycle model has three layers: preparation (Govern, Identify, Protect), incident response (Detect, Respond, Recover) and continuous improvement through ID.IM, which collects lessons from every Function.
Each profile row carries a High, Medium or Low priority and may include recommendations (R), considerations (C) and notes (N), cited as identifiers such as GV.OC-03.R1.
Successful response depends on many internal roles and third parties, whose responsibilities and authorities must be agreed in advance.
Key response practices include risk-based prioritisation, careful scoping of magnitude, a mix of automated and manual containment, protected records and evidence, and four distinct kinds of communication.
There is no SP 800-61 certification; organisations demonstrate capability through Current and Target Profiles, evidence, exercises, audits and the controls of related frameworks.
Organisations may keep another life cycle model if it suits them better, as long as incident response is built into all risk management activities.

Reflection questions

Think of the last significant incident or outage in your organisation. Which lessons from it could have been shared while it was still happening, and who should have received them?
Which three rows of the Community Profile would you raise above NIST's default priority for your organisation, and why?
For your most important service provider, what authority to act during an incident does the contract currently give, and what would you change?
List the risk evaluation factors you would use to prioritise incidents in your environment. How would you keep the scheme simple enough to apply at three in the morning?
If an auditor asked you tomorrow to prove that your incident response plan works, which pieces of evidence could you show, and which are missing?