NIST CSF Respond function explained: what it asks for

What does the NIST CSF Respond function require of an organization?

The Respond Function takes action on a detected cybersecurity incident to contain its effects. In NIST's CSF 2.0 Reference Tool export it has four Categories and 13 Subcategories, and NIST does not offer certifications or endorsements for CSF implementations, so no certificate or fixed price for Respond exists. Your board or customer may ask you to show alignment, but no one will issue a Respond certificate. What you can show is a working incident response capability and evidence that it runs. The organization owns that capability. It must decide who declares an incident, who leads it, how incidents are categorized and escalated, which third parties are notified and when, and how incident data is preserved. An implementation partner can help draft the response plan, runbooks, escalation criteria, notification templates and incident records, and can test them in exercises. Only an independent assessor or auditor can report on whether the capability meets your stated target, and you should confirm with that assessor which evidence they will sample before work starts.

The effort depends on four factors you can check now: how well your detection tools already surface confirmed incidents, how mature your current incident response plan is and whether anyone has exercised it, whether you already have contracted outside responders or a managed security provider with defined duties, and how many third parties your contracts require you to notify. Each adds scope. Vendors and responders you already contract with should be asked for their current service terms, notification windows and points of contact, because those define what Respond must include. Price the work from a written scope that lists these items, not from the Respond label alone.

Which four Categories make up RESPOND, and what each one asks for

RESPOND organizes incident response into four Categories that run in roughly the order an incident unfolds: managing the response, analyzing what happened, communicating it, and containing it. Together they hold the 13 Subcategories of the Function, and the counts per Category are five, four, two and two.

RS.MA Incident management

This Category covers executing the response plan once an incident is declared, along with triage, categorization and prioritization, escalation and the start of recovery. It holds five Subcategories, the largest share of RESPOND. When you review it, check that a named incident lead is assigned for each event, that triage criteria exist before an incident happens, and that escalation paths reach legal, executive and third-party contacts without waiting for someone to ask.

RS.AN Incident analysis

This Category asks how the incident happened, how far it spread and how big it is. It covers root cause analysis, recording investigation actions, preserving incident data and estimating magnitude. It holds four Subcategories. Confirm that evidence handling follows a documented chain of custody, that investigators log each action as they take it, and that your logging retention is long enough to reconstruct the event, since analysis that depends on logs you no longer keep cannot produce a root cause.

RS.CO Incident response reporting and communication

This Category covers notifying stakeholders and sharing incident information. Its two Subcategories concern who must be told, what they must be told and through which channels. Map each notification duty against your contracts, regulators and customers before an incident, because the deadlines they set often run from discovery. Check that the notification list is current and that someone owns the decision to share information outside the organization.

RS.MI Incident mitigation

This Category covers containing an incident so it stops spreading, then eradicating the cause. It holds two Subcategories. Decide in advance which containment actions responders may take on their own, such as isolating an endpoint, and which need approval from the incident lead, since a delay can allow damage to grow. Confirm that the tools you rely on, such as endpoint protection or network controls, can isolate systems without a manual change request.

What happens in the first hours after an incident is declared

This sequence turns a declared incident into coordinated action, so that containment starts from a clear owner, a complete record and evidence that holds up later. Each step leaves an artifact the organization can show to auditors, regulators, customers and its own leadership.

Execute the incident response plan with third parties
Once an incident is declared, the incident response plan is put into action and the relevant third parties are brought in, such as an outsourced incident response provider, a managed security service provider or a key software supplier, as their contracts and the plan allow. The incident lead assigns each party its role. Done means the plan activation is recorded with a time, the people and third parties engaged are named, and each has confirmed its role in writing. Confirm in advance which third parties hold retainers and how quickly they can be reached, because that information is hard to reconstruct during an incident.
Name an incident lead and open the incident record
NIST's Implementation Examples for RS.MA-01 describe designating an incident lead for each incident, so one person owns decisions and coordination from the start. The incident lead opens a single incident record, which is a dated log of what was seen, who acted, and what was decided. Done means the record exists, names the lead and every responder, and is updated as each action happens. Auditors and regulators often ask for this record first, so its timestamps matter more than its polish.
Categorize, prioritize and escalate the incident
The responders classify the event by type and by how much it affects systems, data and business services, then decide which people and governing bodies need to hear about it. Escalation follows the severity thresholds written into the plan, and the record shows which threshold was met and who was told. Done means the category, priority and escalation path are written into the incident record with a time stamp. Confirm that the plan defines these thresholds before an incident occurs, since a severity call made without them is hard to defend later.
Preserve incident data and its provenance
Before systems are changed, responders collect and secure the evidence: logs, memory captures, disk images, alerts and messages, along with notes on where each item came from, who collected it, and how its integrity was protected. Working copies are kept separate from the originals. Done means an evidence set is inventoried with hashes or equivalent integrity records, custody is documented, and the set is stored where it cannot be altered. This preserved set is what supports root cause analysis, legal review and any regulator inquiry, so ask your forensic provider how they handle chain of custody before you need them.
Notify partners and customers as contracts require
The organization identifies which partners, customers and regulators have contractual or legal notice obligations and sends notifications in the form and window those agreements specify. Legal and communications staff review the wording, and the incident lead confirms what has been shared and with whom. Done means each notification is logged with its recipient, date, time, channel and the version of the message sent. Keep the contract clauses that set these obligations in the same folder as the plan, because the notification duties often come from agreements rather than from the framework itself.
Contain and eradicate the incident
Responders choose containment actions that limit the incident's effects, such as isolating endpoints, disabling compromised accounts or blocking malicious traffic, and then remove the cause. NIST's Implementation Examples for RS.MI-01 note that some containment happens automatically through security tools, that responders choose other actions, and that third parties such as ISPs or MSSPs may contain on the organization's behalf. Done means each containment and eradication action is recorded with its owner and time, and the incident lead confirms that the affected scope is contained. Once containment is confirmed, recovery planning passes to the Recover Function, and Detect continues to watch for signs the threat has returned.

How SP 800-61 Rev. 3 rebuilt incident response around the CSF Functions

SP 800-61 Rev. 3 treats all six CSF 2.0 Functions as part of incident response, not only the Functions that handle the incident itself. Govern, Identify and Protect prepare the organization before an incident and feed lessons back afterward, while Detect, Respond and Recover handle discovery, containment, eradication, recovery, reporting and notification. For the Respond Function, this means the response plan is no longer a standalone lifecycle document. Its steps sit inside outcomes that are scored against the Respond Categories: Incident Management (RS.MA), Incident Analysis (RS.AN), Incident Response Reporting and Communication (RS.CO) and Incident Mitigation (RS.MI).

If your team wrote its plan from *SP 800-61 Rev. 2*, the structure you know (preparation, detection and analysis, containment eradication and recovery, post-incident activity) will not map one to one. The practical work is a crosswalk. For each step in your existing plan, record which Respond Category and Subcategory it serves, then check which steps depend on Govern, Identify, Protect, Detect or Recover. Gaps usually appear in three places: escalation and incident lead designation under RS.MA, preservation of incident data and provenance under RS.AN, and the link between containment decisions and the business continuity and disaster recovery plans that RS.MA-01 expects to be started as needed.

Ask whoever maintains your plan to confirm three things before you map it: which roles are named for each Respond Category, which third parties are contracted to act during an incident, and where the plan records lessons that return to Identify and Govern. The current text of Rev. 3 and the Respond Subcategories are published by NIST, and an independent assessor will test your plan against them. Your own counsel and your incident response providers should confirm the reporting and notification obligations that apply to your sector, since those depend on contracts and regulation rather than on the framework.

Who does what when an outside responder joins a response

The organization owns the incident and makes the decisions that carry legal, customer and operational consequences, even when an outside party does much of the technical work. Once an incident is declared, the internal team executes its incident response plan and keeps control of the direction of the response. Its people are the ones who can authorize actions that affect business services and external commitments.

Incident lead: Names one person who coordinates each incident, sets priorities and records decisions, as the Respond outcomes on incident management describe.
Decision makers: Hold authority to approve containment steps that disrupt systems, and to decide when and what to notify.
Legal and communications contacts: Advise on regulatory notification duties, contract obligations and public statements before anything leaves the organization.
Owners of affected systems: Confirm business impact, supply system knowledge and approve changes to production services.
Evidence custodian: Ensures logs, images and timelines are preserved with their provenance so the record survives later review.

Before relying on outside help, confirm in the contract and the plan which internal role can authorize each containment action and each notification.

What to put in writing with an outside responder before an incident

Before an incident, the contract with any outside responder should name who declares one. Under the Respond Function, an incident is handled once it has been declared, and the RS.MA outcomes assume someone has the authority to start the response plan and assign an incident lead. Ask the provider to confirm in writing who on your side may make that call, whether it is your security lead, an on-call manager or a delegate, and what the provider does when the call comes from a third party such as a cloud host or a managed detection service. Also confirm how the outside party is called in, through which channel and to which named contacts, and how fast it must begin work after the call. No response time is supplied here, so treat the figure as something to obtain from the provider and write into the agreement, not something to assume.

The second group of terms covers evidence and containment. Settle who holds preserved incident data, where it is stored, who may copy or export it, and how its provenance is recorded so that chain of custody survives a later review by counsel or a regulator. On containment, the RS.MI outcomes describe security tools containing threats automatically, responders choosing actions, and third parties such as ISPs or MSSPs containing on the organization's behalf. Write down which containment actions the provider may take without approval, such as isolating a host, and which need your sign-off, such as moving a compromised endpoint to a remediation VLAN or blocking a business-critical service. Finally, document how notices to customers, partners and regulators are routed: who drafts them, who approves them, and which clock each contract or regulation starts. Retainers and on-call arrangements move much of this effort into contract terms and standing fees, so the agreement should state what is included at standby and what is billed per engagement. DeployOpen plans and prepares the surrounding plans and records, but it does not issue assessment reports or certifications.

What must exist before an assessor can test the Respond outcomes

An assessor cannot test Respond outcomes against thin air. The items below are the records and capabilities that must exist and be working before anyone can sample them. Each card names what to check and how a reviewer can confirm it in practice.

A current incident response plan

The plan must be dated, approved by leadership and name the incident lead and the decision makers who can declare an incident, pull in outside help and approve external notification. Check that the named people still hold those roles, and that the plan reflects the current systems and cloud accounts. A reviewer will compare the names in the plan against the org chart and the on-call roster, and any gap there is a finding before the Respond outcomes are even reached.

Detection tools that report confirmed incidents

NIST's Implementation Examples for RS.MA-01 describe detection tools that report confirmed incidents automatically to responders. Check the alert routing itself: pick a recent confirmed alert from the SIEM or endpoint console and trace it to the ticket or pager that reached the incident lead. If the path depends on someone reading a dashboard, the outcome is not yet met.

Third-party notification record and contract terms

Keep one register listing each third party the organization notifies during an incident, such as an MSSP, cloud provider, outside responder, insurer, regulator or key customer. For each entry, record the contract clause or legal requirement that sets the notice duty and the contact path. A reviewer can test this by choosing two contracts and confirming that the notice terms match what the plan says will happen.

Preserved incident data with chain of custody

Preservation requires a documented procedure for collecting logs, disk images, memory captures and messages, plus a record of who handled each item and when. Test it by asking for the evidence file from a past incident or a tabletop scenario and checking whether hash values, storage location and access history are logged. Gaps in custody records often weaken the Analysis outcomes even when the technical collection was sound.

An exercise or post-incident review

The plan must have been used, either in a tabletop exercise or in a real incident followed by a written review. Ask for the scenario, the attendees, the decisions taken and the action items that came out of it, then check whether those actions were closed. An exercise with no follow-up shows the plan exists but not that the organization can run it, which is the point an assessor will probe.

Which incident response model fits your organization

This table compares fully in-house response, a retainer with an outside incident response provider, and an MSSP that contains threats under contract. Read each row against your team size, staffed hours and notification pressure, then check the right-hand column before you sign anything. The main takeaway is that outsourcing moves labor, not accountability: the organization still owns the plan, the decisions, the notifications and the evidence.

Model	When it fits	What the organization still owns	What to confirm in the contract
Fully in-house response	Team can staff an on-call rotation covering the hours your incidents can start, has analysts who have handled real intrusions, and faces limited external notification duties	Response plan, incident lead designation, severity decisions, containment approval, regulator and customer notices, evidence preservation and lessons learned	No contract needed, but confirm your own on-call coverage, escalation paths and who may authorize containment at night and on weekends
Retainer with an outside incident response provider	Team is small or lacks 24-hour coverage, but has internal monitoring and a named internal lead who can make decisions while the provider works	Activation decisions, access grants to systems, business continuity calls, notification to regulators and customers, chain of custody for evidence, final root cause sign-off	Activation time and who can trigger it, named responders, data handling and location of evidence, conflict checks, what happens to retained hours, and who writes the final report
MSSP that contains threats under contract	Monitoring is already outsourced, the organization wants containment actions taken without waiting for internal staff, and it accepts that the provider holds privileged access to endpoints or network controls	Scope of pre-approved containment actions, asset criticality ratings, decisions to isolate business-critical systems, regulatory notifications, incident declaration and recovery priorities	Which containment actions are pre-authorized and which need approval, escalation thresholds, log retention and access to raw evidence, provider liability limits, and how incidents are reported back to you

Common questions about the NIST CSF Respond function

Does NIST certify organizations against the CSF Respond function?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. Respond is an outcome area you can align to and evidence, not a certificate you can earn. Any claim of a "NIST CSF certified" Respond function should be treated with caution. If a customer or regulator asks for proof, the usual route is an independent assessment report that describes your Respond outcomes and the evidence behind them, issued by an assessor you choose and who is independent of the work being assessed. The NIST CSF FAQs explain NIST's position on this.

How much does a NIST CSF 2.0 Respond assessment cost?

No fixed figure applies, and no supplied source gives a price for this work, so ask for a written quote built from scope. The main cost drivers are the number of systems and business units in scope, how many of the 13 Respond outcomes already have documented procedures and evidence, the number of third parties your incident plan depends on, and whether you need an independent assessment on top of the preparation work. One-time costs include the gap analysis, plan drafting and tabletop exercises. Recurring costs include retained responders, log retention, and periodic exercises and reviews. Ask each bidder to separate preparation, testing and independent assessment, and to state which items are fixed and which are priced by time.

How long does it take to prepare for the Respond function?

The timeline depends on scope, the maturity of your existing incident response plan, and how many staff can take part. An organization with a tested plan, named incident leads and automated detection feeding its response will move faster than one with an outdated runbook and no agreed escalation path. Scope also matters: a single business unit is far quicker than an enterprise with several third-party responders and regulated notification duties. Ask any partner to show a schedule with milestones for the plan, exercises and evidence collection, and to name the internal roles they need from you in each phase. Confirm the duration in writing rather than relying on a general estimate.

Can we meet the CSF Respond outcomes without an outside firm?

Yes. An organization can build and run its own Respond capability, with its own staff handling incident management, analysis, reporting and mitigation. An outside firm is optional. What matters is that the outcomes are documented, practiced and evidenced. An independent assessor can then review that evidence and report on it, which is a separate step from the work itself. Many teams use an outside responder for surge capacity or specialist forensics, and NIST's implementation examples for RS.MA-01 explicitly include requesting help from an incident response outsourcer. Decide which functions stay in-house before you engage anyone, and write those decisions into your plan.

What does the Respond work need from our internal staff?

It needs named owners who can make decisions under pressure. At minimum, expect to provide an incident lead for each incident, someone who can declare an incident and escalate it, staff who maintain detection tools and feed confirmed incidents into the response process, and people who can approve containment actions on production systems. Legal, communications and privacy staff must own notification decisions, since contracts and regulations set the deadlines. Staff also need time to take part in exercises and to review the post-incident record. Ask a partner to list these roles by name in the scope document, so you can confirm availability before work starts.

How does the CSF Respond function differ from NIST SP 800-61 guidance?

The CSF Respond function is an outcome framework. It lists what your organization should achieve in incident management, analysis, reporting and communication, and mitigation, using 13 outcomes across four Categories. NIST SP 800-61 Rev. 3, published in April 2025, is practical guidance for running incident response, and it was rebuilt around the six CSF 2.0 Functions. The guide says Detect, Respond and Recover help discover, contain, eradicate and recover from incidents, while Govern, Identify and Protect prepare for them and drive improvement. In practice, use the CSF to decide what outcomes to report against, and use SP 800-61 to decide how to achieve them. Note that SP 800-61 is guidance, not an assessable control set.

What evidence should we collect to show Respond outcomes are working?

Collect records that show your response actually happened, not only that a plan exists. Useful evidence includes incident tickets with timestamps, categorization and escalation decisions, the named incident lead, preserved log extracts with chain of custody notes, containment actions and their approvals, notification records, and post-incident reviews with root cause findings. Exercise reports from tabletop tests also help, as they show the plan has been run. Assessors typically sample records like these across a period rather than accepting a single example. Set up your ticketing and logging so these records are created as a matter of course, and confirm with your assessor which sample period and format they expect.

How DeployOpen prepares Respond capability and evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so incident response tooling and records sit where your responders can use them. We prepare systems and evidence for NIST CSF Respond function explained; your organization owns its controls and its incident response decisions.

How we scope

Agree the Respond outcomes in scope, such as incident management, analysis, reporting and mitigation, in writing before work starts.
Confirm which platforms, cloud accounts or networks hold incident data and which third parties must be engaged.
Record the decision owners, escalation paths and notification duties that the written scope must cover.

How we build

Configure self-hosted tooling so detections and confirmed incidents are recorded with timestamps and an assigned incident lead.
Set up evidence collection that preserves incident data and its provenance for later analysis and reporting.
Test containment and mitigation procedures in your environment so responders can show they work before an incident occurs.

How we hand over

Deliver documented runbooks mapped to the Respond outcomes, with owners, steps and the records each step produces.
Provide configuration records, test results and an evidence index that your assessor or internal audit can review.
Train named responders on the handover materials and confirm they can run the procedures without DeployOpen present.

How we support

Offer ongoing support, upgrades and continuous testing of incident response tooling as a retainer, if your organization wants it.
Review runbooks and evidence records after exercises and real incidents, and update them through the agreed change process.
Confirm with your independent assessor which evidence they will accept, since only independent auditors issue reports or certificates.

NIST CSF Respond function explained