RS.MI-02 Incident eradication: requirements and evidence

RS.MI-02 incident eradication: what the requirement asks

If you are the compliance lead, engineer or buyer responsible for showing that an incident was fully cleaned up, RS.MI-02 is the CSF 2.0 Subcategory that asks for it. It sits in the Incident Mitigation (RS.MI) Category of the RESPOND Function and expects that incidents are eradicated, meaning the attacker's presence, access and artifacts are removed from the affected environment. Containment stops the bleeding, but eradication is what removes the foothold. A backdoor, a persistence mechanism, a stolen credential still in use or a malicious scheduled task left behind will let the same intruder return after the incident is closed, often with more knowledge of the environment than before.

RS.MI-02 sits alongside RS.MI-01 incident containment in the same Category, and the two are meant to work as a sequence: contain first, then eradicate. The identifier is unchanged from CSF 1.1, where the same outcome was numbered RS.MI-2, so mappings and assessments built on the earlier version carry over at the same identifier. NIST's Implementation Examples describe three patterns: security technologies and features of other technologies that eradicate automatically, responders who choose eradication actions, and third parties such as an MSSP that eradicate on the organization's behalf. Most programs use a mix of all three, which is why ownership needs to be written down before an incident occurs.

Eradication is hard to prove for three reasons. The steps are often undocumented, carried out from memory or from chat messages during the incident. They are split across tools, with an EDR agent removing one file, a responder resetting an account and a provider deleting a cloud role, none of which share a record. And once the work is done, nobody can show which hosts were checked, when and against what. A practical first check is to ask whether your team could produce, for the last significant incident, a single list of every eradication action, who performed it, the tool that logged it and the verification step that confirmed the threat was gone. If that list cannot be built, RS.MI-02 is not yet evidenced, whatever the policy says.

Which systems, teams and third parties RS.MI-02 covers

Eradication scope follows the incident scope set under the incident management (RS.MA) and incident analysis (RS.AN) Categories, so the same asset list should drive containment, eradication and recovery. The cards below cover the places malicious artifacts persist, the people who perform eradication and the third parties that may act for the organization.

Endpoints and user devices

Workstations and laptops are the most common place where malware, persistence mechanisms and stolen credential caches survive a first cleanup. Eradication here means removing scheduled tasks, services, autorun entries, browser extensions and dropped binaries, then confirming with fleet queries that none return on any host. Check that the endpoint inventory is current, because an unmanaged device that was never scanned will not appear in the eradication scope.

Servers and workloads

Servers often hold the same malicious artifacts as endpoints, plus web shells, altered configurations and backdoored services that run with higher privileges. Eradication must cover every host that the attacker reached, not only the one that raised the alert. Confirm how the team identifies those hosts from logs, network connections and lateral movement evidence, and record the decision so auditors can trace why a system was included or excluded.

Cloud workloads and control planes

Cloud eradication includes compute instances, container images, serverless functions and the control plane settings that let an attacker return, such as new access keys, altered security groups and rogue automation roles. Removing an infected instance without rotating the credentials it used leaves the intrusion in place. Ask whether your cloud accounts have a documented procedure for reviewing and revoking these resources.

Identity systems and credentials

Attackers commonly keep access through directory accounts, service principals, OAuth grants and privileged group memberships rather than through malware. Eradication should reset or revoke compromised credentials, remove unauthorized persistence in the identity provider and review recent changes to administrative roles. Confirm who has authority to disable accounts during an active incident, because delayed credential action is a frequent reason eradication appears complete when it is not.

SaaS tenants and integrations

Email, collaboration and business applications can hold forwarding rules, mailbox delegations, connected apps and API tokens that persist after endpoints are clean. These artifacts sit outside the usual host-based tooling, so they often fall outside the eradication scope unless someone names them. Check each SaaS tenant that the affected users or systems touched and confirm that the owner of each tenant is part of the response.

Responders, MSSPs and on-call roles

Eradication is performed by named internal responders, by automatic actions in security tools, or by a managed security service provider acting for the organization. Each actor needs written authority, access and a clear hand-off so that no step is assumed to belong to someone else. Confirm the contract terms that allow an MSSP to take eradication actions, the escalation path for out-of-hours work and which decisions remain with the organization's own staff.

Who performs eradication: three paths the outcome can take

Under this path, security technologies and features of other technologies remove the malicious element without a person choosing the action each time. Examples include an endpoint agent quarantining or deleting a flagged file, a mail gateway removing a malicious attachment, or a platform feature terminating a process that matches a defined rule. The organization still has to show that these rules were designed, tested and tuned for its environment, because automation can remove legitimate software just as quickly as malware.

Rule ownership: Name who approves the detection and response rules, and keep a dated record of each change and its reason.
Test evidence: Show that the automated action worked on a known sample or controlled test, not only that the product is installed.
Exception handling: Document how false positives are reversed and who may override an automatic action.
Action logs: Keep the vendor or platform log entries that show what was removed, from which host and at what time.
Coverage gaps: Record which systems lack the agent or feature, such as unmanaged devices or appliances, and how they are covered.

Before relying on this path, confirm with the product owner which eradication actions are fully automatic, which only alert, and which need approval, because these differences shape the evidence you must keep.

How an assessor tests RS.MI-02 incident eradication

This table compares what an assessor samples, asks for and typically finds when testing whether incidents are eradicated under RS.MI-02. Read each row as a test step paired with the evidence it needs, then check your own records against the same questions before an assessment begins. The main takeaway is that eradication is only credible when the incident record shows what was removed, how it was verified and who acted, including any work a third party did.

Test area	Evidence the assessor requests	Common findings
Sampling of closed incidents	A population list of incidents closed in the period, with a sample selected across severities and incident types	Samples drawn only from easy, low-severity cases, leaving complex incidents untested
Walkthrough of eradication decisions	Interviews with responders on how they chose removal actions, such as deleting malware, rebuilding hosts or resetting credentials	Responders describe a process the written procedure does not reflect
Review of eradication actions against the incident record	Ticket or case entries listing each eradication step, the affected assets and the time it was completed	Incidents closed with a summary line but no itemized eradication actions
Verification of eradication	Post-eradication scans, hash checks, persistence reviews or log queries showing the threat no longer runs	Incidents closed without documented verification after removal
Automatic eradication rules	Rule configurations from security tools, change records for those rules and logs showing rule executions	Automatic actions enabled but not logged, or rules changed with no approval record
Eradication steps outside the record	Chat transcripts, runbook versions and shift handover notes reconciled against the case record	Eradication steps that exist only in chat or in a responder's memory
Review of MSSP reports	Contract terms for eradication authority, the provider's incident reports and the organization's acceptance of each report	Third-party eradication actions the organization cannot see or has not reviewed
Independence of the conclusion	Assessor workpapers and the final report, prepared by the independent assessor	Internal teams drafting conclusions about their own outcome; only the assessor decides whether the outcome is met

Implementing RS.MI-02 in a sequence the evidence can follow

This sequence turns eradication from an ad hoc response into a set of decisions, actions and records that an assessor can trace from an incident back to the rule that authorized the work. The organization owns each decision, and the implementation partner prepares the systems, runbooks and logging that make those decisions visible.

Define eradication actions by incident category
Start by listing the incident categories your response plan already recognizes, such as malware on an endpoint, credential misuse or a compromised cloud workload. For each category, record which eradication actions are permitted, such as removing a persistence mechanism, deleting a malicious file or disabling an account, and which require approval before they run. Name the role that approves each action and the role that may act without approval. Your leadership and incident response owners make these decisions. The output is a signed eradication matrix that responders and tools can both reference.
Configure automatic eradication with logging
Where your security tools support automatic eradication, such as quarantining a known malicious file or terminating a process that matches a confirmed detection rule, configure only the actions your matrix allows for that category. Confirm each capability with the vendor, because support differs by product and version. Send every automatic action to a central log that records the time, the tool, the target, the rule that triggered it and the outcome. The output is a tested configuration and a log sample showing each automatic eradication action can be traced.
Write runbooks for manual eradication
For actions that responders perform by hand, write a runbook for each incident category that sets out the steps, the tools to use and the conditions that stop the procedure and trigger escalation. Each runbook should end with verification checks that confirm the threat is gone, such as re-running a hunt across the affected group of systems or confirming that a persistence location no longer holds the artifact. Open-source endpoint tools can support these checks. Osquery can query running processes, open network connections and file hashes across hosts, and Velociraptor can run hunts across a group of systems. The output is a set of versioned runbooks that name the verification query or hunt for each step.
Set MSSP eradication authority in writing
If a managed security service provider performs any eradication for you, the contract or statement of work should state which actions the provider may take without asking first, which require your approval, how it must report each action and how quickly it must notify your team. Confirm these terms with your legal and procurement teams, since they set obligations on both sides. Make sure the provider's actions appear in the same log as your automatic and manual actions. The output is a signed authority schedule that matches the eradication matrix from the first step.
Preserve evidence before eradicating
Before any eradication action removes or changes a file, process or account, confirm that the relevant evidence has been captured under your evidence handling procedure. Record what was collected, its hash and who collected it. Case management platforms such as DFIR-IRIS can keep evidence entries with SHA-256 verification and chain of custody alongside the case. This step prevents the eradication from destroying the material your root cause analysis depends on. The output is an evidence entry linked to the incident before the eradication action appears in the log.
Create an eradication record for each incident
For every incident that involved eradication, create one eradication record that lists the actions taken, whether each was automatic, manual or performed by a third party, the approver for any action that required approval and the log entries that show each action. Link the record to the incident case so that the case timeline includes the eradication steps. The output is a record that an assessor can follow from the detection to the action to the approval without relying on memory or verbal accounts.
Verify eradication before closing the incident
Before an incident is closed, run the post-eradication verification named in the relevant runbook and record the result, including the query or hunt used, the date, the scope covered and the person who reviewed the output. If verification finds the threat still present, reopen the eradication step rather than closing the case. Your incident commander decides closure. The output is a verification entry attached to the eradication record, so every closed incident has a documented check that eradication succeeded.

Evidence that satisfies RS.MI-02 and how to keep it current

RS.MI-02 asks whether incidents are eradicated, so an assessor will look for a written procedure, proof that eradication happened for real incidents, and proof that lessons were fed back. The cards below list the five artifacts that usually carry that proof and how to keep each one current between assessments.

Eradication procedure and approval matrix

This is the written procedure that says how each type of incident is eradicated, who decides between automatic and manual actions, and who approves destructive steps such as reimaging a host or disabling an account. Check that the matrix names an owner for each eradication path, that it covers the three ways NIST describes eradication (security tools, responders, and third parties), and that it matches what responders actually do. Review it after every significant incident and whenever tooling changes. Record the review date and approver on the document itself.

Automated eradication rule configurations and logs

Where security tools eradicate without a person in the loop, the assessor will want the rule configuration and the log of each action it took. Export the rule set under version control so every change has an author and a reason, and keep the action logs long enough to match your incident retention policy. Confirm that each automated action can be traced back to the rule that triggered it. Test a sample rule periodically in a non-production environment and keep the test record.

Closed-incident records with verification

Each closed incident should show every eradication action taken, the time it was taken, who took it, and the check that confirmed the threat was gone. DFIR-IRIS keeps each case as one record of assets, IOCs, tasks and evidence with a full audit trail, so the eradication steps sit next to the indicators they removed. Verification can be backed by osquery, which can schedule queries across a fleet to confirm that a malicious process, kernel module, network connection or file hash is no longer present. Store the query results with the case. Reports generated from case data can serve as the assessor's sample.

Fleet hunt results for eradication checks

After a manual eradication, responders often need to prove that the same artifact is gone from every affected system, not only the one that alerted. Velociraptor hunts collect defined artifacts across a group of endpoints and keep a notebook per hunt for the combined results, and offline machines are collected when they reconnect. Keep the hunt definition, the target scope, and the final notebook with the incident record. Confirm that hunts ran against machines that were offline during the first pass. Velociraptor is licensed AGPL-3.0-only, so confirm your license obligations with counsel before you distribute or modify it.

MSSP contract terms and eradication reports

When a managed security service provider eradicates on your behalf, the contract and its reports become part of your evidence. Check that the contract states what the provider may do without approval, how fast it must notify you, what it reports after each eradication, and who keeps the logs. Collect the provider's eradication reports and reconcile them against your own incident records. Review the terms at each renewal and when the provider's scope changes. Ask the provider to confirm which of its evidence it can export in a usable format.

What RS.MI-02 incident eradication costs to meet

This table lists the cost components of meeting RS.MI-02, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote so that open-source tooling savings are not mistaken for total savings.

Cost component	Who is paid or who does the work	One-time or recurring	Main cost drivers
Tooling or licenses	Vendor or subscription provider for any commercial add-ons; open-source tools carry no license fee	Recurring if commercial components are used; one-time for installation	Number of endpoints and sites, retention needs, whether a commercial EDR or SOAR is kept alongside open-source tools
Engineering to configure eradication actions and integrations	Implementation partner or internal platform engineers	One-time, with recurring change work	Count of automated eradication actions, number of SIEM, EDR and ticketing integrations, and how many eradication paths are approved
Responder runbooks and training	Internal incident response team, with the implementation partner or trainers if contracted	One-time to write, recurring to refresh and train new staff	Number of responders, number of eradication scenarios, staff turnover, and tabletop exercise frequency
Evidence upkeep	Internal security operations staff	Recurring	Volume of DFIR-IRIS cases, scheduled osquery queries, Velociraptor hunts and notebooks, and how long records must be kept
MSSP scope for eradication	Managed security service provider under contract	Recurring under the service agreement	Which eradication actions the provider may take, service hours, escalation terms, and whether the provider keeps its own records
External testing or review	Independent tester or assessor, not the implementation partner for the same evidence	Recurring, usually tied to audit or test cycles	Scope of the eradication test, number of systems in scope, and whether results are needed for a report
Auditor sampling effort	Internal staff preparing samples, and the independent auditor or certification body performing the test	Recurring each assessment cycle	Number of incidents or systems the auditor samples, quality of case records, and how quickly evidence can be produced

Who does what: your team, an implementation partner and the auditor

Your organization owns RS.MI-02. Eradication is a risk decision as much as a technical action: someone accountable must decide when a malware family is removed automatically, when a responder must choose a manual eradication path, and when a system is rebuilt rather than cleaned. Under CSF 2.0, that accountability sits with leadership and the incident response function, and no vendor or partner can take it over.

Eradication decisions: Define which eradication actions security tools may take without approval, such as quarantining a file or killing a process, and which require a responder or incident commander to sign off.
Approval matrix: Document who approves destructive actions, such as reimaging a production server or resetting privileged accounts, and who is told afterward.
MSSP oversight: If a managed security service provider eradicates on your behalf, keep your own record of its actions, review its tickets and confirm your contract gives you the logs and timelines you need.
Attestations of your own practice: Your leaders can attest internally that the process runs and that exceptions are recorded. That is management assurance, not an external report.
Evidence ownership: Keep case records, tool logs and approval records in systems you control so they remain available after any vendor relationship ends.

Before you sign any engagement, confirm in writing which eradication decisions stay with your staff and which tasks a partner or MSSP performs.

Where RS.MI-02 usually falls short and how to close each gap

Eradication is often done but not provable. The gaps below recur across organizations that run automatic tools, responders and managed providers side by side, and each one leaves no record an assessor can test. Each card names the artifact that closes it.

Eradication decided but never verified

Responders often mark a threat as removed once the malicious process is killed or the file is deleted, without checking whether persistence mechanisms, scheduled tasks or credentials remain. RS.MI-02 asks for incidents to be eradicated, so the record must show the check, not just the action. Close the gap with a post-eradication verification step in the case workflow, recorded with the query or scan that confirmed the result. Confirm who signs off before the case moves to recovery.

Automatic actions without readable logs

Security tools may remove malware or block a hash automatically, but the action often lives only in the vendor console with no exportable record. An assessor testing the Implementation Example for automatic eradication will ask which tool acted, on what object, and when. Confirm that each tool forwards its action logs to a central store with timestamps and identifiers, and keep a sample export as evidence. Test that the logs survive a tool outage.

Responder steps undocumented

Manual eradication decisions, such as choosing between reimaging a host and cleaning it in place, are frequently made in chat or from memory. RS.MI-02 covers responders choosing eradication actions, so the reasoning and each command run must be captured. Require every eradication step to be logged to the case with the operator, the action and the justification. Review a sample of closed cases to confirm the steps can be reconstructed without asking the responder.

Managed provider eradication without reports

When an MSSP removes a threat on the organization's behalf, the organization often receives only a closure ticket. The third-party Implementation Example for RS.MI-02 expects the organization to know what was eradicated and how. Put a written reporting obligation in the service agreement, covering the actions taken, affected assets, verification results and time of completion. Confirm the report is stored in the organization's own case system, not only the provider's portal.

Incidents closed before fleet-wide checks

Teams often clear the host where the alert fired and close the case, leaving the same artifact on other endpoints. Eradication is not complete until the indicator has been searched across the fleet. Use a fleet query such as an osquery scheduled query for running processes, file hashes and open connections, or a Velociraptor hunt across the affected group, and attach the results to the case. Confirm that offline machines are scheduled to collect when they return.

Eradication records split across tools

Alerts sit in the SIEM, host actions in the EDR, forensic results in a collection tool and decisions in email, so no one can show the full eradication history. RS.MI-02 evidence is far easier to assess when one case holds the assets, indicators, tasks and evidence. Consider DFIR-IRIS as a single case record that links the alert sources and keeps an audit trail, and define which system is the authoritative record. Check that exports from every source are attached with hashes or identifiers.

Questions buyers ask about RS.MI-02 before hiring outside help

What does it cost to meet RS.MI-02 and what drives the price?

No single figure applies, because the cost depends on which eradication path your organization uses and how much of it is already in place. The main components are the time of your own responders, any licensed security tooling you add or extend, the work of an implementation partner to deploy and configure systems, and any fees paid to a managed security service provider for eradication work. The biggest drivers are the number of endpoints and systems in scope, how many eradication actions you want automated versus performed by responders, and how much evidence the assessor will expect. Ask any partner for a written, fixed scope that lists deliverables, responsibilities and assumptions, since that scope is the basis for any quote.

How long does RS.MI-02 work take to complete?

The duration depends on the current state of your detection and response tooling, the size of the environment and how many eradication paths need to be built. Work usually runs in phases: confirming which tools already remove malicious files, processes or access, defining who decides on eradication actions, testing those actions on a sample of systems and then rolling them out. Timelines also slip when change approvals, maintenance windows or access to production systems are slow, so ask a partner to name those dependencies in the written plan. Treat any timeline offered before a scope review as provisional.

What does the work need from our own staff?

Your staff owns the decisions and the outcome, so they need to take part throughout. Security operations and incident response staff must define which eradication actions are approved, under what conditions and who signs off on them. IT operations staff must confirm change control, system ownership and rollback steps, and your asset owners must confirm which systems are in scope. Expect a partner to ask for access to existing logs, tickets, runbooks and past incident records so the work starts from real practice rather than assumptions.

Can a small security team meet RS.MI-02 in-house?

A small team can meet RS.MI-02 in-house if it has clear eradication procedures, tools that can act on confirmed threats and enough time to test and maintain them. The harder parts are usually building repeatable playbooks, keeping them current and having staff available to respond outside business hours. Many small teams keep the decisions and approvals internal, then bring in a partner for a short, fixed-scope build of tooling and documentation. Whichever path you choose, confirm that someone in the organization can run and review the process without the partner present.

Does NIST certify that our RS.MI-02 implementation meets the subcategory?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. Any claim that a vendor, partner or product has certified your RS.MI-02 implementation should be treated with caution. If a customer or regulator asks for independent evidence, the relevant option is an assessment by a qualified independent assessor, whose report comes from that assessor, not from NIST or your implementation partner.

Can an MSSP satisfy RS.MI-02 on its own?

No. NIST's implementation examples for RS.MI-02 include eradication performed by a third party such as a managed security service provider, but the organization still owns the outcome. Your contract with the provider should define which systems it may act on, which actions require your approval, how quickly it must act, and what evidence it returns to you. You also need your own process to verify that eradication succeeded and to decide what happens when the provider's actions conflict with your business needs.

Which parts of RS.MI-02 are worth outsourcing and which should we keep?

Outsource work that needs specialist build effort or is hard to staff continuously, such as deploying forensic collection tooling, configuring automated eradication and documenting playbooks. Keep decisions that carry business or legal risk in-house, including approving eradication on production systems, deciding when to isolate a business-critical service and authorizing disclosure. Many organizations also keep ownership of evidence records and post-incident review. Set these boundaries in writing before work starts so the partner's deliverables match what your team will actually run.

How can open-source tools support evidence for RS.MI-02?

Open-source tools can produce records that show eradication happened and was verified, though they do not replace your decisions. For example, DFIR-IRIS keeps each case as one record of assets, indicators of compromise, tasks and evidence with a full audit trail, which helps show who acted and when. Velociraptor collects forensic artifacts from endpoints and runs hunts across groups of systems, and osquery can run scheduled queries across a fleet to confirm that malicious processes or network connections are gone. Confirm with each tool's documentation how it fits your environment, and keep the approvals and verification results in the same case record.

How DeployOpen works on this

DeployOpen works on RS.MI-02 Incident eradication as implementation and evidence preparation inside your own infrastructure. We set up the open-source tooling that supports eradication, while your organization keeps ownership of its response decisions and controls.

How we scope

Agree in writing which eradication paths apply: automatic by security tools, manual by your responders, or by an MSSP.
Confirm which hosts, cases and tools fall within the engagement, and which remain with your internal teams.
Define the deliverables, timelines and roles before work starts, since most engagements are fixed-scope.
Ask for the scope to name the evidence artifacts you expect, such as case records and eradication actions.

How we build

Deploy self-hosted case management in your environment so each incident keeps one record of assets, indicators and tasks.
Configure fleet-wide query and forensic collection tooling so responders can confirm removal across affected systems.
Test eradication workflows in a controlled setting, including a private cyber range where your organization agrees to use one.
Harden the platforms and integrations against your own access and logging requirements before handover.

How we hand over

Document the eradication procedures, responder roles and escalation paths that your team will operate day to day.
Show how each eradication action is recorded with timestamps, evidence hashes and an audit trail in the tooling.
Map the delivered evidence to IR-4 and Annex A control 5.26 so your assessor can trace it, confirming the mapping with your auditor.
Walk your responders and MSSP through the handover so the evidence process runs without outside help.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the initial implementation is complete.
Review eradication evidence samples before an assessment so gaps can be fixed while the scope is still open.
Remember that only an independent auditor or certification body issues reports or certificates; DeployOpen prepares the evidence.
Ask your auditor which evidence formats and sample sizes they expect, and confirm them before the engagement starts.