NIST CSF 2.0Implementation GuideJune 13, 2026· 13 min read
How to Implement the NIST CSF 2.0 Respond Function: A Practitioner's Guide
How your organization responds to a cybersecurity incident determines whether it becomes a manageable disruption or a catastrophic event. The difference between organizations that recover cleanly and those that suffer prolonged outages and regulatory penalties almost always comes down to preparation - specifically, whether they had a practiced, documented response capability before the incident happened. This guide covers all four RS categories with steps for building a response capability that holds up under pressure.
What the Respond Function Covers
In CSF 2.0, the Respond function has four categories: RS.MA (Incident Management), RS.AN (Incident Analysis), RS.CO (Incident Response Reporting and Communication), and RS.MI (Incident Mitigation). CSF 2.0 reorganized the Respond function significantly from CSF 1.1 - the old five categories were consolidated into four with updated content, and the Communication category (RS.CO) was elevated in prominence to reflect the growing importance of regulatory notification obligations.
Before you start: The Respond function only works if it's practiced. A 50-page incident response plan that no one has read and no one has drilled provides false assurance - it is a hypothesis, not a capability. Plan for regular tabletop exercises from the beginning - not as an afterthought after the plan is "finished."
RS.MA - Incident Management
The plan that everyone agrees needs to exist right up until an actual incident, at which point someone says "wait, where do we keep that document?"
RS.MA requires the organization to have a defined process for managing cybersecurity incidents - from detection through closure. This is the operational backbone of your response capability.
RS.MA-01 through RS.MA-05
Define your incident response process before you need it
RS.MA covers: executing incident response plans (RS.MA-01), tracking and documenting incidents (RS.MA-02), categorizing and prioritizing incidents (RS.MA-03), escalating incidents as needed (RS.MA-04), and testing the incident response plan (RS.MA-05).
How to implement:
Document your Incident Response Plan (IRP). At minimum it should cover: scope and purpose, incident classification criteria (P1–P4 or equivalent), roles and responsibilities during an incident, response phases (preparation, detection, containment, eradication, recovery, lessons learned), contact information for all key stakeholders (internal and external), and integration with your business continuity plan
Define incident severity tiers with clear criteria: what makes something P1 vs P3? Examples - P1: ransomware confirmed, production system down, or confirmed data exfiltration. P3: phishing attempt with no confirmed compromise, isolated malware detection on non-critical endpoint. Consistent classification prevents overreaction to minor events and underreaction to major ones
Establish an incident tracking mechanism: a ticketing system, a shared incident log, or a dedicated IR platform. Every incident must have a documented record - what was detected, when, by whom, what actions were taken, and when it was closed
Define escalation paths: who does the on-call analyst call at 2am when they find a confirmed ransomware infection? Who notifies the CEO? Who calls legal counsel? Who contacts the cyber insurer? These decisions should be pre-made and documented, not improvised during an active incident
Test your plan annually with at minimum a tabletop exercise (RS.MA-05). Test specific scenarios relevant to your threat profile - ransomware, BEC, supply chain compromise. After each exercise, document findings and improvements
Common mistake: The IRP identifies an "Incident Response Team" but the team has never met, doesn't know their roles, and the contact information in the plan is out of date. An untested plan with stale contacts is not a response capability - it's documentation that creates false confidence.
RS.AN - Incident Analysis
RS.AN requires the organization to analyze detected incidents to understand their scope, impact, and root cause. This is the forensic and investigative component of incident response - moving from "something bad happened" to "we understand what happened, how, and what the full impact is."
RS.AN-01 through RS.AN-08
Understand what happened before you start recovering
RS.AN covers: investigating notifications from detection systems (RS.AN-01), understanding incident impacts (RS.AN-03), performing forensic analysis (RS.AN-04), collecting and preserving evidence (RS.AN-06), performing root cause analysis (RS.AN-07), and estimating the size of the incident (RS.AN-08).
How to implement:
Establish an evidence collection procedure before incidents occur: how do you preserve a compromised system for forensic analysis without destroying evidence? Document your acquisition process - memory capture, disk imaging, log preservation - for the most likely incident types
For most small and mid-size organizations, forensic analysis beyond basic log review requires external IR support. Identify and contract with an IR firm before you need them - a retainer agreement gives you priority access and pre-negotiated rates during an active incident when every hour matters
Root cause analysis (RS.AN-07) is not optional - understanding how an attacker got in is essential to preventing recurrence. For every significant incident, document the initial access vector, the attacker's lateral movement, and the point where containment became possible
Estimate incident scope early (RS.AN-08) and update the estimate as investigation progresses - the initial "one compromised endpoint" assessment has a way of becoming "twelve systems and the domain controller" once forensics starts. Build scope estimation into your response process, not as an afterthought
Document every analysis action and finding with timestamps - investigation records become evidence in regulatory proceedings and insurance claims. Undocumented actions that affected the evidentiary integrity of a system can create significant legal and insurance complications
Common mistake: Teams rush to remediate - reimaging systems, resetting passwords, removing malware - before completing forensic analysis. This destroys evidence, may remove the only copy of data needed to understand the full scope, and often leaves attacker persistence mechanisms in place because the root cause wasn't understood. Contain first, investigate, then remediate.
RS.CO - Incident Response Reporting and Communication
Executives say they want to be notified immediately. What they mean is: notified when you have answers. Decide which one before an incident, not during.
RS.CO is the most legally and operationally significant category in the Respond function. It requires the organization to coordinate and share information internally, with stakeholders, with affected parties, and with regulatory bodies during and after incidents. Getting communication wrong during an incident can create regulatory penalties and insurance complications that exceed the cost of the incident itself.
RS.CO-01 through RS.CO-05
Know your notification obligations and have templates ready
RS.CO covers: coordinating with internal and external stakeholders (RS.CO-01), sharing incident information internally (RS.CO-02), reporting to authorities as required (RS.CO-03), coordinating with external providers (RS.CO-04), and voluntary sharing of incident information with external parties (RS.CO-05).
How to implement:
Build a notification matrix into your IRP: list every regulatory notification obligation that applies to your organization, the trigger conditions, the notification timeline, the notifying party, and what information must be included. This should be ready before an incident - not researched during one
Key notification timelines: CMMC/DFARS cyber incident reporting to DoD within 72 hours; HIPAA breach notification within 60 days; most state breach notification laws within 30–90 days; cyber insurance notification (check your policy - often 24–72 hours); PCI DSS card brand notification within 24 hours. Missing notification windows creates regulatory exposure independent of the incident itself
Prepare communication templates in advance: a draft customer notification letter, a draft board/executive briefing template, a draft regulatory notification, and a draft press statement for significant incidents. Drafting these under pressure during an active incident increases error rates and may produce communications that create legal liability
RS.CO-04 requires coordinating with external service providers during incidents - if your MSP, cloud provider, or a SaaS vendor is involved in an incident (either as victim or as affected party), your IRP needs to define that coordination process. Have vendor contact information documented in advance, including security and IR contacts, not just account managers
Engage legal counsel early in any significant incident. Attorney-client privilege can protect certain incident investigation communications and reports - engagement after the fact may not preserve that privilege for earlier communications
Common mistake: Organizations notify their cyber insurer days or weeks after an incident begins - often discovering mid-response that their policy requires notification within 24–72 hours of discovery. Late notification can void coverage or reduce the insurer's willingness to approve IR vendor costs. The cyber insurer notification call should be one of the first actions in your P1 response process.
RS.MI - Incident Mitigation
RS.MI requires the organization to contain and mitigate the impacts of cybersecurity incidents - stopping the spread, removing the threat, and preventing recurrence. This is the operational response layer where decisions get made quickly under pressure.
RS.MI-01 through RS.MI-02
Contain first, eradicate second, recover third
RS.MI has two subcategories: containing incidents (RS.MI-01) and mitigating the effects of incidents (RS.MI-02). The ordering matters enormously in practice.
How to implement:
Define containment actions for your most likely incident types. For ransomware: immediately isolate affected systems from the network (pull the network cable or disable the NIC via management tools), revoke credentials that may be compromised, and preserve the affected systems for forensics before reimaging. For BEC: revoke the compromised account's tokens, reset credentials with MFA re-enrollment, review all mail rules set by the account, and check for forwarding rules
Pre-authorize containment actions in your IRP: the first responder needs to know whether they have authority to isolate a production server without waiting for management approval. Requiring approval for every containment action adds dwell time during which damage compounds
Document a decision tree for the most common incident types - what triggers isolation, what triggers credential revocation, what triggers external notification. Pre-made decisions reduce response time and reduce errors under stress
After containment, eradication should be thorough and verified - not assumed. Scan cleaned systems with different tools than those that may have been compromised. Validate that persistence mechanisms (scheduled tasks, registry keys, startup items, backdoor accounts) have been fully removed before reconnecting systems
Track all mitigation actions taken with timestamps - these records feed into RS.AN root cause analysis and into regulatory documentation if notification is required
Common mistake: Organizations contain by reimaging the affected system and consider the incident closed - without determining how the attacker got in, whether other systems are compromised, or whether the attacker has persistence mechanisms elsewhere. Reimaging one system while the attacker still has domain admin credentials is not containment, it's giving them a fresh endpoint to work from.
Evidence tip: For the Respond function, evidence is your IRP document, exercise records (tabletop agendas, attendee lists, and after-action reports), incident tickets with documented timelines and actions, and notification records where applicable. The most common gap is no exercise records - having a plan but no evidence it was ever tested.
Policy Documentation for Your CSF 2.0 Respond Program
Your incident response process needs written policy backing - from incident classification criteria to communication obligations to evidence handling requirements. Our NIST CSF 2.0 Full Policy Bundle includes Respond function policy language alongside all five other CSF 2.0 functions, giving you the policy layer that GV.PO requires.
Your Incident Response Plan is the primary documentation artifact for the Respond function. RS.MA requires a defined incident response process - the IRP documents that process. RS.AN requires procedures for analyzing incidents - the IRP should include investigation procedures and forensic considerations. RS.CO requires notification procedures - the IRP should include stakeholder communication templates, regulatory notification timelines, and contact information. The IRP is how you demonstrate that the Respond function is implemented.
RS.CO-03 requires sharing information with designated authorities per applicable legal and regulatory requirements. Key obligations: HIPAA requires HHS and individual notification within 60 days of discovery; PCI DSS requires card brand notification within 24 hours; CMMC/DFARS requires DoD reporting within 72 hours; most US states require breach notification within 30–90 days. Cyber insurance policies often have separate 24–72 hour notification requirements. Late notification can void coverage - check your policy and build notification timelines into your IRP.
At minimum, conduct an annual tabletop exercise where key stakeholders walk through a realistic incident scenario. More mature programs add functional exercises (testing specific technical procedures) and full-scale exercises. RS.MA-05 specifically requires testing response plans. Scenarios should reflect your actual threat landscape - ransomware, business email compromise, and supply chain compromise are the most relevant for most organizations. After each exercise, document findings and track improvements to completion.
Containment (RS.MI) is the immediate action to stop an incident from spreading - isolating a compromised host, revoking compromised credentials, blocking a malicious IP. Eradication is removing the threat entirely - deleting malware, closing the exploited vulnerability, removing all attacker footholds. You contain first to limit damage, then eradicate to remove the threat, then recover to restore operations. Skipping containment to jump straight to eradication while the attacker still has access is a common and costly mistake.
Not specifically - CSF 2.0 doesn't require external IR support. However, most small and mid-size organizations don't have the internal forensics capability to handle significant incidents effectively. An IR retainer gives you access to forensics expertise, legal privilege protections, and response resources you can't build in-house at reasonable cost. Many cyber insurance policies include or require an approved IR firm. Check your policy - using a non-approved vendor may affect reimbursement.