RS.MI-02: Incidents are eradicated

RS.MI-02 requires you to fully remove an incident’s cause and attacker foothold from affected environments, not just restore service. Operationalize it by defining “eradication complete” criteria, running a repeatable eradication playbook (contain → remove → harden → validate), and retaining evidence that the threat cannot re-establish persistence. ¹

Key takeaways:

• Eradication means eliminating root cause and persistence mechanisms, then proving it with verification steps and artifacts. ¹
• Your incident process needs explicit exit criteria, owner accountability, and evidence collection mapped to RS.MI-02. ²
• Audit readiness depends on logs, change records, and post-eradication validation, not a closed ticket note. ¹

“Incidents are eradicated” sounds straightforward until you have to defend it to an auditor, your board, or a customer after an intrusion. RS.MI-02 is a requirement-level expectation that your response does more than stop the bleeding. You must remove the adversary’s access, eliminate malicious artifacts, address the exploited weakness, and validate the environment is clean. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate RS.MI-02 into an operational control with: (1) a clear definition of eradication, (2) documented steps responders follow every time, (3) measurable “done” criteria, and (4) evidence that stands on its own months later. Evidence is the usual failure point. Teams often do the work but cannot show what was removed, what was changed, and how they confirmed the attacker could not come back through the same path.

This page gives you a practical implementation blueprint: who owns eradication, what must happen during and after an incident, what artifacts to retain, what auditors ask, and how to roll it out with a 30/60/90-day plan aligned to NIST CSF 2.0. ¹

Regulatory text

Requirement (excerpt): “Incidents are eradicated.” ¹

What the operator must do

You must run incident handling through an eradication phase where you remove the threat and the conditions that allowed it to exist. Concretely, that means you define and execute actions that:

• Remove malicious code, tools, accounts, persistence mechanisms, and unauthorized configurations.
• Eliminate or mitigate the exploited vulnerability or control failure (technical and procedural).
• Validate eradication with repeatable checks (not assumptions), then document results and residual risk. ¹

A practical interpretation for audit purposes: an incident is not “closed” until you can show what was eradicated, how you eradicated it, and how you confirmed it did not remain. ²

Plain-English interpretation (what RS.MI-02 really means)

Eradication is the “make it safe to operate again” step. Containment limits damage. Recovery restores service. Eradication removes the attacker’s foothold and fixes the weakness they used so the same compromise does not recur immediately.

For most organizations, RS.MI-02 breaks into four decisions you must make explicit:

1. What counts as eradication for each incident type? Ransomware, BEC, web shell, insider data theft, cloud token compromise, and third-party remote access abuse each require different eradication actions.
2. Who can declare eradication complete? This should be a named role with authority (often IR Lead with Security Engineering sign-off).
3. What verification is mandatory? “We reimaged the laptop” is not enough if the identity plane is still compromised.
4. What evidence is required? If it isn’t recorded, it didn’t happen from an assurance perspective.

Who it applies to

Entity scope

RS.MI-02 applies to any organization running a cybersecurity program and using NIST CSF 2.0 as a framework for governance, assurance, or customer commitments. ¹

Operational context (where it shows up in real life)

You will operationalize RS.MI-02 across:

• Security incident response (SOC/IR): eradication tasks, verification, closure gates.
• IT operations / platform teams: patching, rebuilds, configuration baselines, EDR deployment, identity hardening.
• Identity and access management: credential resets, token revocation, privileged access cleanup.
• Cloud and application owners: key rotation, pipeline integrity, secrets management, WAF/app fixes.
• Third-party access management: disabling vendor accounts, rotating shared credentials, re-issuing VPN certs, reviewing remote management tooling.

What you actually need to do (step-by-step)

Use this as a requirement-to-runbook implementation checklist.

1) Define “eradication complete” criteria (policy + runbooks)

Create a short standard that applies to all incidents, then add incident-type variants.

Minimum eradication exit criteria (baseline):

• Initial infection vector is identified or documented as unknown with compensating controls and risk acceptance.
• All known malicious artifacts are removed or isolated (files, services, scheduled tasks, registry keys, containers, images, IAM entities).
• Persistence mechanisms are removed (backdoors, unauthorized accounts, OAuth apps, API keys, SSH keys).
• Compromised credentials and tokens are rotated/revoked, and session invalidation steps are executed where applicable.
• Vulnerability/control gap remediations are implemented or tracked with defined due dates and owners.
• Verification checks pass and are documented (see Step 5). ¹

Deliverable: an “Eradication & Validation Standard” referenced by the Incident Response Plan. ¹

2) Assign control ownership and RACI

Make RS.MI-02 a controlled process, not an informal practice.

Recommended ownership model:

• Control owner: Head of Incident Response or SOC Manager.
• Accountable executive: CISO (or delegated security executive).
• Key partners: IT Ops, IAM, Cloud Ops, Application Engineering, Legal/Privacy for notification decisions. ²

Deliverable: RACI matrix embedded in IR plan and on-call procedures.

3) Build eradication playbooks per incident class

Start with your top incident patterns and create short, checklisted runbooks. Each playbook should include:

• Common persistence locations and what to check.
• Minimum credential and key rotation requirements.
• System rebuild vs clean guidance (when you must rebuild).
• Required change tickets and approvals.
• Verification steps and evidence list.

If you lack maturity, begin with three playbooks: endpoint malware, compromised identity, and cloud workload compromise. ¹

4) Integrate eradication into change management and ticketing

Eradication work often fails audits because it happens “out of band.”

Operational requirements:

• Every eradication action that changes production has a change record (even if expedited/emergency).
• The incident ticket links to change tickets, forensic case notes, EDR actions, and IAM actions.
• Closure requires completion of eradication checklist fields (do not rely on free-text). ²

5) Validate eradication (prove a negative with practical checks)

You cannot prove a system is perfectly clean, but you can show a reasonable, documented validation process.

Minimum validation set (adapt to your environment):

• EDR or endpoint scan results and quarantine/remediation logs on affected endpoints.
• Review for re-creation of persistence artifacts after reboot and after credential rotation.
• SIEM queries for known IOCs/IOAs post-eradication window; document query logic and results.
• IAM review: no unexpected privileged accounts, no new MFA bypass methods, no suspicious OAuth grants, no stale sessions.
• Vulnerability scan or configuration compliance evidence showing the exploited issue is addressed (or tracked as an exception with compensating controls). ¹

6) Close the loop: root cause, lessons learned, and backlog control

Eradication that does not drive systemic fixes becomes recurring incidents.

Required operational practices:

• Document root cause (technical and process) and map remediations to owners.
• Track remediation items in a backlog with dates, priority, and risk acceptance where needed.
• Run a post-incident review and capture “what would have prevented this” controls (logging gaps, segmentation, MFA, email hardening, third-party access controls). ¹

7) Make evidence collection recurring and auditable

Treat RS.MI-02 like a control with recurring evidence, not a one-off narrative.

One pragmatic approach: map RS.MI-02 to a control statement, procedure, control owner, and an evidence checklist that is automatically attached to each incident record. This is also where Daydream fits naturally: it helps you map RS.MI-02 to a named control owner and a repeatable evidence request workflow so incident teams produce audit-ready artifacts as part of closure, not as a scramble later. ²

Required evidence and artifacts to retain

Retain artifacts in a consistent “incident package” structure. Auditors want traceability and completeness.

Evidence category	What to retain	What it proves
Incident record	Incident ticket with timeline, scope, affected assets, decision log	Governance and execution trail
Eradication checklist	Completed checklist with timestamps, owners, and references	Eradication steps were performed
Forensic notes	Case notes, triage findings, indicators, hypotheses, conclusions	Basis for eradication decisions
EDR artifacts	Alerts, isolation actions, remediation logs, scan outputs	Threat removal actions and outcomes
IAM artifacts	Account disablement logs, password resets, key/token revocation records, privileged access reviews	Removal of identity footholds
Change records	Emergency changes, patches, rebuilds, config changes, approvals	Controlled remediation
Validation results	SIEM queries, hunt notes, IOC sweeps, vuln scan outputs, config compliance checks	Post-action verification
Exceptions	Risk acceptance memos, compensating controls, due dates	Managed residual risk

Common exam/audit questions and hangups

Expect these questions and prepare short, evidence-backed answers:

• “Define eradication in your program.” Provide your exit criteria and how it differs from containment and recovery. ¹
• “Show me an incident where you eradicated.” Produce the incident package: checklist, logs, change tickets, and validation results.
• “Who can declare eradication complete?” Show the RACI and the sign-off field in the incident record.
• “How do you prevent re-entry?” Show credential rotation, vulnerability remediation, and monitoring queries post-eradication. ¹
• Hangup: teams close incidents based on service restoration. Fix by adding an eradication gate to closure workflow. ²

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating reimaging as universal eradication.
   Avoidance: require identity and access plane checks for any incident that involved credentials, tokens, email rules, or OAuth grants. ¹

2. Mistake: No documented exit criteria.
   Avoidance: publish an “eradication complete” definition with minimum required steps and verification per incident class. ¹

3. Mistake: Evidence scattered across tools with no linkage.
   Avoidance: enforce ticket hygiene: the incident record must link to EDR events, SIEM queries, change records, and IAM actions. ²

4. Mistake: Root cause left as “phishing happened.”
   Avoidance: require a technical root cause statement (what control failed, what misconfiguration existed, what detection gap existed) and track corrective actions. ¹

5. Mistake: Third-party access not included in eradication scope.
   Avoidance: add a checklist branch for third-party accounts, remote tooling, shared credentials, and integration tokens.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so you should not assume a specific regulator’s penalty theory. Practically, failing RS.MI-02 increases repeat-incident risk, extends attacker dwell time, and creates credibility problems during customer security reviews because you cannot demonstrate that threats were fully removed. ¹

Practical 30/60/90-day execution plan

Use time-boxed phases to ship the control without boiling the ocean.

First 30 days (foundation)

• Name the RS.MI-02 control owner and approve a one-page eradication standard with exit criteria. ¹
• Add an eradication checklist to your incident ticket template with mandatory fields and closure gate.
• Define the incident package folder structure and minimum evidence list.

By 60 days (operationalization)

• Publish eradication playbooks for your most common incident types and train on-call responders.
• Integrate emergency change management steps into the IR workflow so eradication actions have change records.
• Implement a validation checklist: required SIEM queries, EDR verification, IAM review steps. ¹

By 90 days (audit readiness)

• Run a tabletop focused on eradication decisions and evidence capture; adjust checklists based on gaps found.
• Sample recent incidents and perform an internal “eradication evidence review” to confirm packages are complete.
• Stand up recurring reporting: incidents closed without eradication sign-off, overdue remediation items, and exceptions with risk acceptance. ²

Frequently Asked Questions

What’s the difference between containment, eradication, and recovery for RS.MI-02?

Containment stops spread and limits impact. Eradication removes the attacker’s foothold and fixes the exploited weakness. Recovery restores normal operations, but closure should require eradication evidence, not just restored uptime. ¹

Can we close an incident if we can’t identify the initial access vector?

You can, but treat it as a documented exception with compensating controls and a clear validation plan. Your evidence should show what you did remove (accounts, persistence, malware) and what added monitoring or hardening you put in place. ¹

What evidence is most persuasive to auditors for eradication?

Linked artifacts: EDR remediation logs, IAM revocation/rotation records, change tickets for patches or rebuilds, and documented validation queries with results. A narrative without tool evidence rarely holds up. ¹

Who should have authority to declare “eradication complete”?

Assign a specific role in your IR governance, commonly the Incident Response Lead with sign-off from the system owner or Security Engineering for material changes. Document it in the IR plan and enforce it in the ticket workflow. ²

How do third parties fit into eradication?

Treat third-party access as a potential persistence path. Include steps to disable vendor accounts, rotate shared credentials, revoke integration tokens, and confirm remote tooling is approved and logged.

We have many tools. How do we keep RS.MI-02 evidence from becoming a scavenger hunt?

Standardize an “incident package” checklist and require responders to attach or link artifacts before closure. Tools can vary; the evidence categories should not. Daydream can help by turning RS.MI-02 into a mapped control with recurring evidence requests tied to incident closure. ²

Footnotes

1. NIST CSWP 29

2. NIST CSF 1.1 to 2.0 Core Transition Changes