Quick answer
The Respond function of the NIST Cybersecurity Framework 2.0 (RS) covers the actions an organization takes during an active cybersecurity incident to contain it and limit the damage. It has four categories: Incident Management (RS.MA), Incident Analysis (RS.AN), Incident Response Reporting and Communication (RS.CO), and Incident Mitigation (RS.MI). In short: Respond is how you manage the crisis while it is happening.
Audio presentation
This is part 8 of the SEVN-X Cybersecurity Frameworks Series. A significant cybersecurity incident is a crisis, and few of us are at our best during a crisis. That is exactly why we preach that the time to define your steps is before the breach—not during, and certainly not after you have already had one. A proper analysis and post-mortem after the fact still has to happen, but it is no substitute for preparation.
What is the Respond function in NIST CSF 2.0?
Respond (RS) is the fifth core function of the NIST Cybersecurity Framework 2.0, sitting between Detect and Recover. Its goal is exactly what it sounds like: build the capabilities to respond appropriately to a cyberattack and define the actions that should be taken. Respond supports your ability to contain the effects of an incident, and its outcomes span incident management, analysis, mitigation, reporting, and communication. It is the difference between a controlled response and improvising under pressure.
What are the four categories of the Respond function?
Respond is organized into four categories that together cover the full arc of handling an incident—from declaring it, to investigating it, to communicating about it, to shutting it down.
RS.MA
Incident Management
Managing the response to a detected incident—declaring, triaging, categorizing, escalating, and running it through a defined lifecycle.
RS.AN
Incident Analysis
Investigating what happened and why, and preserving evidence to support forensics and recovery.
RS.CO
Incident Response Reporting and Communication
Coordinating and sharing information with internal and external stakeholders as required by law, regulation, or policy.
RS.MI
Incident Mitigation
Containing and eradicating the incident to stop it from spreading.
RS.MA
Incident Management
RS.MA is about managing responses to detected incidents. It requires that you have a plan and actually execute its defined steps when the moment comes. It has five subcategories.
RS.MA-01
The incident response plan is executed in coordination with relevant third parties once an incident is declared.
Kick off the plan and loop in outside partners the moment you declare.
RS.MA-02
Incident reports are triaged and validated.
Confirm what is real and worth acting on before you spin up the whole team.
RS.MA-03
Incidents are categorized and prioritized.
Sort by type and severity so the worst gets attention first.
RS.MA-04
Incidents are escalated or elevated as needed.
Push it up the chain when it crosses defined thresholds.
RS.MA-05
The criteria for initiating incident recovery are applied.
Know the trigger that hands off from Respond to Recover.
A note from the field: by now, most organizations have an incident response plan—senior leaders have been asking about ransomware for years. But are they good plans, or something downloaded off the internet? A real plan includes playbooks specific to the type of incident (ransomware, business email compromise, data leakage from lost media, and so on). Plans should be tested and improved (that ties to ID.IM-02), and your response personnel have to actually know their roles (PR.AT-02). Incident response exercises are common now, and there is no good reason to skip one—unless you already know your plan does not reflect reality.
RS.AN
Incident Analysis
RS.AN requires investigation to support effective response, forensics, and recovery—understanding what happened, what caused it, and how big it was, while documenting the steps your team took. It has four subcategories.
RS.AN-03
Analysis is performed to establish what has taken place during an incident and its root cause.
Figure out what actually happened, and why.
RS.AN-06
Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved.
Log every investigative step in a way that holds up later.
RS.AN-07
Incident data and metadata are collected, and their integrity and provenance are preserved.
Preserve the evidence without contaminating it.
RS.AN-08
An incident's magnitude is estimated and validated.
Size the blast radius, then confirm it.
There is a heavy dependency here on your DETECT controls. Without solid logging and monitoring, root cause and the finer details can be hard to establish—and you may never know precisely what happened.
RS.CO
Incident Response Reporting and Communication
RS.CO ensures response activities are coordinated with internal and external stakeholders as required by laws, regulations, or policies—including notification of stakeholders and law enforcement. It has two subcategories.
RS.CO-02
Internal and external stakeholders are notified of incidents.
Tell the people who need to know.
RS.CO-03
Information is shared with designated internal and external stakeholders.
Share the right details with the right parties as the incident develops.
Most response plans we see already have an escalation team of internal stakeholders, plus key external and law enforcement contacts. The common gap is contractual: organizations often sign customer contracts with specific breach notification requirements and timelines, and then never keep a consolidated list of those obligations. When an incident hits, that list is exactly what you need and rarely have. On top of that, the SEC's rules require public companies to disclose material breaches in a timely manner.
RS.MI
Incident Mitigation
RS.MI is about performing the activities that prevent an event from expanding and mitigate its effects—containment and eradication. It has two subcategories.
RS.MI-01
Incidents are contained.
Stop the spread.
RS.MI-02
Incidents are eradicated.
Remove the attacker and their footholds.
These are basic but critical steps—and much easier said than done if you have not prepared. Advanced endpoint protection and strong network segmentation help a lot here, and some leading endpoint protection systems include host isolation functionality that lets you cut an infected machine off from the network in seconds.
How do you execute the Respond function effectively?
In practice, an effective response follows a repeatable sequence:
01. Declare and activate. Trigger the plan and loop in relevant third parties (RS.MA-01).
02. Triage and prioritize. Validate reports and categorize by type and severity (RS.MA-02, RS.MA-03, RS.MA-04).
03. Contain, then eradicate. Stop the spread first, then remove the attacker entirely (RS.MI-01, RS.MI-02).
04. Investigate and preserve. Establish root cause and protect the evidence chain (RS.AN-03, RS.AN-06, RS.AN-07, RS.AN-08).
05. Notify the right people. Internal, external, law enforcement, and anyone your contracts or the SEC require (RS.CO-02, RS.CO-03).
06. Hand off to Recover. Apply the defined criteria that start recovery (RS.MA-05).
Two numbers tell you whether your response actually works: mean time to contain (MTTC) and mean time to eradicate (MTTE). If you are not measuring them, you cannot improve them.
Respond vs. Recover: what is the difference?
Respond (RS) is what you do while the incident is active—contain it, investigate it, and communicate about it. Recover (RC) picks up after containment and focuses on restoring systems and confirming a return to normal operations. The two share people and time, so the handoff between them (defined by RS.MA-05) is easy to fumble and worth planning deliberately. Next in this series, we take the same deep dive into the RECOVER function.
Frequently asked questions
NIST CSF Respond FAQs
What makes a good incident response plan?
A good plan is specific to your environment, includes playbooks for each incident type (ransomware, business email compromise, data leakage, and so on), assigns clear roles that personnel actually know, and is tested and improved regularly. A generic plan downloaded from the internet tends to fall apart under real pressure.
Does the Respond function require reporting a breach?
Yes—RS.CO requires notifying and sharing information with internal and external stakeholders as laws, regulations, or policies demand. That can include law enforcement, contractual customer notifications, and, for public companies, timely SEC disclosure of material incidents.
Why does Incident Analysis depend on the Detect function?
Because analysis relies on the data your Detect controls produce. Without good logging and monitoring, establishing root cause and the full scope of an incident becomes difficult, and you may never know precisely what happened.
What is the difference between containment and eradication?
Containment (RS.MI-01) stops the incident from spreading—for example, isolating an infected host. Eradication (RS.MI-02) removes the attacker and their footholds from the environment entirely. You contain first to limit damage, then eradicate to fully close it out.
Key takeaways
- Respond (RS) is the fifth NIST CSF 2.0 function and governs how you act during an active incident.
- It has four categories: Incident Management (RS.MA), Incident Analysis (RS.AN), Incident Response Reporting and Communication (RS.CO), and Incident Mitigation (RS.MI).
- A plan is only as good as its playbooks and its testing—a generic downloaded plan fails under pressure.
- Contain and eradicate fast, preserve the evidence, notify per law and contract, then hand off cleanly to Recover.
Test your response before you need it
The time to build and pressure-test your response is before the breach. SEVN-X can help through incident response planning, tabletop exercises, and ransomware readiness. Our goal is to help you Achieve Better Cybersecurity.
Part of the SEVN-X Cybersecurity Frameworks Series. Authored by Mark Keppler and Steve Foret. Source: NIST Cybersecurity Framework 2.0.