Most organisations score themselves well on Respond because they have an incident response plan, yet CSF 2.0 asks whether 13 specific outcomes are achieved during real incidents, and a plan on a shelf proves almost none of them. Respond is the CSF Function for actions taken once a cybersecurity incident has been detected. CSF 2.0 reorganised it substantially from version 1.1: response planning, improvement and vulnerability intake moved elsewhere, and incident management became its own Category. This guide works through the four Respond Categories at Subcategory level, with NIST's Implementation Examples, the evidence an assessor should expect, measurement, the identity angle and mappings. It is for incident response leads, SOC managers, GRC teams and auditors who know the CSF basics; for the framework as a whole see the NIST CSF 2.0 Guide.
Key takeaways
- Respond starts at declaration. NIST describes it as "Actions regarding a detected cybersecurity incident are taken"; deciding that an event is an incident sits in Detect (DE.AE-08), so the two Functions must share written criteria.
- Four Categories, 13 Subcategories: Incident Management (RS.MA, 5), Incident Analysis (RS.AN, 4), Incident Response Reporting and Communication (RS.CO, 2) and Incident Mitigation (RS.MI, 2).
- Several 1.1 outcomes moved out. Response planning folded into RS.MA-01, improvement moved to ID.IM, and vulnerability disclosure intake moved to ID.RA-08, so a 1.1 assessment cannot simply be relabelled.
- Evidence comes from incident records. Tickets, timelines, decision logs and notification records show whether outcomes are achieved; plans and playbooks only show intent.
- Machine identities widen the blast radius question. RS.AN-08 asks whether the incident's magnitude was estimated and validated, which in most modern incidents means finding every token, key and service account the attacker touched.
Where Respond sits in CSF 2.0
CSF 2.0 (NIST CSWP 29, 26 February 2024) says the Functions should be addressed concurrently, and that actions supporting Respond and Recover "should be ready at all times and happen when cybersecurity incidents occur". In the CSWP's own words, Respond "supports the ability to contain the effects of cybersecurity incidents", with outcomes covering incident management, analysis, mitigation, reporting and communication.
NIST SP 800-61 Revision 3 (final, April 2025), the CSF 2.0 Community Profile for incident response, places preparation in Govern, Identify and Protect, and treats Detect, Respond and Recover as incident response itself, with ID.IM feeding lessons learned back into all six Functions. The practical consequence: Respond is only as good as the inputs it receives from DE.AE (adverse event analysis and declaration) and the hand-off it makes to RC.RP (recovery plan execution) through RS.MA-05. For the Community Profile's priorities and its recommendation, consideration and note items per row, see the NIST SP 800-61 Incident Response Guide; this page stays at the level of the CSF outcomes.
The four Categories and 13 outcomes
Outcome wording below is from the CSF 2.0 Core. The right-hand column summarises NIST's Implementation Examples, which CSWP 29 calls "notional examples of concise, action-oriented steps" and says are not a comprehensive list.
| Subcategory | Outcome | NIST Implementation Examples (summarised) |
|---|---|---|
| RS.MA-01 | The incident response plan is executed in coordination with relevant third parties once an incident is declared | Detection technologies report confirmed incidents; request help from the IR outsourcer; designate an incident lead; start business continuity and disaster recovery plans as needed |
| RS.MA-02 | Incident reports are triaged and validated | Preliminary review to confirm it is cybersecurity-related; apply severity criteria |
| RS.MA-03 | Incidents are categorized and prioritized | Categorise by type (data breach, ransomware, DDoS, account compromise); prioritise by scope, impact and urgency; balance quick recovery against observing the attacker |
| RS.MA-04 | Incidents are escalated or elevated as needed | Track and validate status of all ongoing incidents; coordinate escalation with internal and external stakeholders |
| RS.MA-05 | The criteria for initiating incident recovery are applied | Apply recovery criteria to known and assumed characteristics; weigh operational disruption of recovery |
| RS.AN-03 | Analysis is performed to establish what has taken place during an incident and the root cause of the incident | Sequence of events and assets involved; vulnerabilities, threats and actors; systemic root causes; check deception technology |
| RS.AN-06 | Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved | Every responder records actions immutably; the incident lead documents the incident and preserves its sources |
| RS.AN-07 | Incident data and metadata are collected, and their integrity and provenance are preserved | Collect and safeguard data and metadata (source, time of collection) under chain-of-custody procedures |
| RS.AN-08 | An incident's magnitude is estimated and validated | Search other potential targets for indicators of compromise and persistence; run tools automatically to do so |
| RS.CO-02 | Internal and external stakeholders are notified of incidents | Follow breach notification procedures including affected customers; notify partners per contract; notify law enforcement and regulators per plan criteria and management approval |
| RS.CO-03 | Information is shared with designated internal and external stakeholders | Share securely per agreements; share sanitised TTPs with an ISAC; notify HR of insider activity; update senior leadership; follow supplier contract rules; coordinate crisis communication with critical suppliers |
| RS.MI-01 | Incidents are contained | Automatic containment by security tools and platform features; manual containment by responders; containment by a third party such as an ISP or MSSP; move compromised endpoints to a remediation VLAN |
| RS.MI-02 | Incidents are eradicated | Automatic, manual or third-party eradication actions |
What changed from CSF 1.1
CSF 1.1 had five Respond Categories (RS.RP, RS.CO, RS.AN, RS.MI, RS.IM). The CSF 2.0 catalogue records where each withdrawn outcome went, which matters when you migrate an old Current Profile:
| CSF 1.1 outcome | Where it went in 2.0 | Assessment consequence |
|---|---|---|
| RS.RP-01 response plan executed | RS.MA-01 | Plan execution now judged together with third-party coordination |
| RS.AN-01, RS.AN-02, RS.AN-04 (notifications investigated, impact understood, incidents categorised) | RS.MA-02, RS.MA-03, RS.MA-04 | Triage and categorisation became incident management, not analysis |
| RS.AN-05 vulnerability disclosure processes | ID.RA-08 | Researcher and supplier vulnerability intake is now a risk assessment outcome |
| RS.MI-03 newly identified vulnerabilities mitigated or accepted | ID.RA-06 | Risk response choices sit in Identify |
| RS.CO-01 personnel know their roles | PR.AT-01 | Role awareness is a training outcome |
| RS.CO-04, RS.CO-05 coordination and voluntary sharing | RS.MA-01, RS.MA-04, RS.CO-03 | Coordination folded into management; sharing kept in RS.CO-03 |
| RS.IM-01, RS.IM-02 lessons learned and strategy updates | ID.IM-03, ID.IM-04 | Post-incident improvement is assessed in Identify |
New in 2.0 with no direct 1.1 equivalent are RS.MA-05 (recovery criteria), RS.AN-06 (records of investigator actions) and RS.AN-08 (magnitude estimated and validated).
Implementing Respond outcome by outcome
- Agree declaration and recovery criteria first (DE.AE-08, RS.MA-05): write what makes an event an incident and what conditions allow recovery to start. Without both, RS.MA-02 and RS.MA-05 cannot be assessed. See the Incident Severity Classification Matrix Template.
- Name an incident lead per incident (RS.MA-01): the plan names roles, but the outcome is achieved when each real incident has a recorded lead and recorded third-party engagement (outsourcer, cloud provider, insurer panel).
- Use one tracker for every open incident (RS.MA-04): SP 800-61r3 distinguishes escalation, which "generally refers to increasing resources or time frames", from elevation, which "usually indicates involving a higher level of management". Record both, with timestamps.
- Record the strategy choice (RS.MA-03): contain now or observe first is a decision with trade-offs; write down who decided, why and when. See the Incident Scoping and Containment Strategy Guide.
- Make investigator records tamper-evident (RS.AN-06, RS.AN-07): append-only case notes, hashed evidence and a chain of custody form for anything that may reach a court or regulator. See the Evidence Handling and Chain of Custody Guide.
- Hunt for scope before closing (RS.AN-08): sweep other systems, tenants and identities for the same indicators and persistence; record the sweep and its result.
- Pre-approve notification paths (RS.CO-02): keep a register of regulator, law enforcement, customer and contractual notification triggers with owners and deadlines. See the Breach Notification Laws by Country Guide.
- Define what you will share and with whom (RS.CO-03): ISAC membership, sanitisation rules, supplier contract clauses and a leadership update cadence.
- Pre-authorise containment actions (RS.MI-01): list automatic actions tools may take, manual actions responders may take without further approval, and actions that need business sign-off.
- Verify eradication (RS.MI-02): confirm persistence is removed and credentials are replaced before RS.MA-05 hands over to recovery.
Testing: run a tabletop that exercises each of the 13 outcomes and score them from the exercise record, not the plan. Repeat with a technical exercise for RS.MI and RS.AN-08, where tabletop answers are least reliable. See the Cyber Incident Exercises Beyond Tabletop Guide.
Small versus large organisations: a small organisation can meet most Respond outcomes with a retained IR provider (RS.MA-01 and RS.MI via a third party, which the Implementation Examples explicitly allow), a one-page severity scale, a shared incident log and a notification contact list. Large organisations need a case management system with immutable audit, automated containment playbooks, a legal-led notification process across jurisdictions and contractual sharing rules with critical suppliers.
Evidence and assessment
| Subcategory | Weak evidence | Strong evidence |
|---|---|---|
| RS.MA-01 | Approved IR plan | Incident records showing a named lead, plan invocation time and third-party engagement |
| RS.MA-02, RS.MA-03 | Severity matrix document | Tickets with severity, category and a recorded strategy decision; re-categorisation history |
| RS.MA-04 | Escalation contacts list | Tracker entries showing escalation and elevation with timestamps |
| RS.MA-05 | "Recover when safe" | Written recovery entry criteria and a record of them being applied |
| RS.AN-03 | Incident summary email | Timeline, root cause statement and linked improvement actions in ID.IM |
| RS.AN-06, RS.AN-07 | Shared document with notes | Append-only case log, evidence hashes and chain of custody records |
| RS.AN-08 | "No further impact found" | Documented scope sweep: systems, tenants and identities checked, method and result |
| RS.CO-02 | Notification policy | Notification log with recipient, time, deadline and approver |
| RS.CO-03 | ISAC membership | Records of sanitised sharing and leadership updates during incidents |
| RS.MI-01, RS.MI-02 | EDR deployed | Containment and eradication actions with times, plus verification that persistence was removed |
Metrics that show Respond is working
- Time to contain: from declaration to RS.MI-01 containment, by severity.
- Time to escalate: from declaration to the first required escalation or elevation for high-severity incidents.
- Scope validation rate: share of closed incidents with a documented RS.AN-08 sweep.
- Notification timeliness: share of required notifications sent within the legal or contractual deadline.
- Reopen rate: incidents reopened because eradication was incomplete.
- Evidence integrity: share of incidents whose evidence has hashes and custody records.
Identity and NHI in Respond
Respond says nothing specific about identities, but identity is where most current incidents are contained or lost.
- RS.MA-03 categorisation: "account compromise" is one of NIST's example categories. Split it into human and non-human, because the containment actions differ: session revocation and MFA reset for people, credential rotation and consent revocation for applications and service accounts.
- RS.AN-08 magnitude: list every token, API key, OAuth grant and service account reachable from the compromised identity and check each for use. The Cloudflare Thanksgiving Breach followed a response to the Okta support breach in which four credentials were left unrotated; a nation-state attacker later used them to get in.
- RS.MI-01 containment: pre-authorise disabling a service principal or revoking a token, with a named owner who knows the business impact. See the Identity Incident Response Playbook.
- RS.MI-02 eradication: attacker-added credentials on existing applications and new role assignments are persistence; removal and credential reissue are the eradication evidence.
- AI agents: an agent acting with delegated credentials is a responder target too. See the AI Agent Incident Response Playbook.
Mapping to other frameworks
NIST lists a CSF 2.0 to SP 800-53 Rev 5 mapping, a CIS Controls v8.1 to CSF 2.0 mapping and an ISO/IEC 27001:2022 to CSF 2.0 mapping among the CSF 2.0 Informative References; use those files for formal crosswalks, noting NIST's statement that listing a non-NIST mapping does not imply endorsement. The table is an orientation by control purpose.
| Respond Category | SP 800-53 Rev 5 (related) | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|
| RS.MA Incident Management | IR-4 Incident Handling, IR-5 Incident Monitoring, IR-7 Incident Response Assistance, IR-8 Incident Response Plan | 5.24, 5.25, 5.26 | Control 17 |
| RS.AN Incident Analysis | IR-4, AU-9 Protection of Audit Information, AU-10 Non-repudiation, SI-4 System Monitoring | 5.27, 5.28 | Control 17, Control 8 |
| RS.CO Reporting and Communication | IR-6 Incident Reporting, PM-15 Security and Privacy Groups and Associations | 5.24, 5.26, 6.8 | Control 17 |
| RS.MI Incident Mitigation | IR-4 | 5.26 | Control 17 |
For control-level detail see the NIST SP 800-53 IR Incident Response and the CIS Control 17 Incident Response Management Guide.
Common pitfalls
- Scoring from the plan: RS outcomes describe what happens during incidents; a plan with no incident or exercise records supports little more than intent.
- Carrying 1.1 scores forward: RS.AN-05 and RS.IM scores relabelled as 2.0 Respond overstate it, because those outcomes now live in Identify.
- No recovery entry criteria: teams start restoring before eradication is verified and the attacker returns through the same persistence.
- Closing without a scope sweep: RS.AN-08 skipped because the first host was cleaned; unrotated machine credentials stay valid.
- Editable investigation notes: case notes in shared documents with no integrity control fail RS.AN-06 and weaken any later legal or regulatory position.
- Notification owned by nobody: legal, communications and security each assume another team will notify, and the deadline passes.
Practitioner checklist
- Assess all 13 Respond Subcategories individually, from incident and exercise records.
- Write declaration criteria (with Detect) and recovery entry criteria (RS.MA-05).
- Track every open incident in one system with escalation and elevation timestamps.
- Record the containment strategy decision and its owner for each significant incident.
- Use append-only case logs, evidence hashing and chain of custody.
- Require a documented scope sweep, including machine credentials, before closure.
- Keep a notification register with triggers, deadlines, owners and approvers.
- Pre-authorise containment actions for both human and non-human identities.
- Re-map any CSF 1.1 Respond assessment using the withdrawn-to-new outcome table.
Standards and references
- NIST: The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 800-61 Rev. 3 full text
- NIST: CSF 2.0 Informative References
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework
Related NHI Mgmt Group resources: NIST CSF 2.0 Guide · NIST SP 800-61 Incident Response Guide · Incident Response Guide · NIST CSF 2.0 Detect Function · NIST CSF 2.0 Recover Function