Eradication and recovery

The eradication and recovery requirement means you must remove the incident’s root cause from affected environments and restore systems safely, with validation that the threat is gone and controls are working. Operationalize it by running an eradication task plan, rebuilding or cleaning systems from trusted sources, and documenting proof of actions and post-recovery checks per your incident record ¹.

Key takeaways:

• Eradication is root-cause removal, not “wipe and hope”; you must confirm the attacker’s access path is closed ¹.
• Recovery is controlled restoration plus verification, with heightened monitoring to catch reinfection or persistence ¹.
• Audit readiness depends on evidence: tracked tasks, rebuild decisions, validation results, and change approvals tied to the incident ¹.
• Treat third parties as part of the recovery scope when they host, administer, or integrate affected systems.

Eradication and recovery is the “make it safe again” phase of incident handling. Your examiners and auditors will not accept a claim that systems are restored if you cannot show (1) what you removed, (2) why you believe the root cause is gone, and (3) how you restored operations without reintroducing the same weakness. NIST SP 800-61 frames this requirement plainly: remove the root cause and safely restore affected systems ¹.

For a CCO or GRC lead, the fastest path to operationalizing the eradication and recovery requirement is to turn it into a repeatable checklist with tight governance: clear decision rights (who can authorize rebuilds, credential resets, and production cutover), task tracking with timestamps, and explicit validation criteria. “Safely restore” also implies controlled change: you should be able to show that emergency changes were reviewed, that backups were trustworthy, and that monitoring was elevated during the return to service ¹.

This page is written to help you implement the eradication and recovery requirement quickly: who it applies to, what to do step-by-step, what evidence to retain, and what auditors commonly challenge.

Regulatory text

Regulatory excerpt (requirement-level): “Remove root cause and safely restore affected systems.” ¹

Operator interpretation (what you must do):

1. Identify and eliminate the root cause of the incident in every affected environment (endpoints, servers, identity systems, network controls, cloud resources). Root cause includes technical vulnerabilities, misconfigurations, stolen credentials, malicious persistence, and unsafe administrative paths ¹.
2. Restore service in a controlled way using trusted images, trusted backups, and approved changes, then validate that systems are functioning and the threat is not present ¹.
3. Track eradication tasks and validate post-recovery controls so you can prove actions taken and demonstrate that recovery did not reopen the incident vector ¹.

Plain-English interpretation of the eradication and recovery requirement

Eradication answers: “How did we remove the attacker or malware and close the door they used?” Recovery answers: “How did we bring systems back without restoring the compromise?”

A practical way to interpret the requirement:

• If you cannot explain the root cause, you are not done with eradication.
• If you restored from backups you didn’t validate, you did not “safely restore.”
• If you lack evidence (tickets, logs, approvals, validation results), you will struggle to defend your conclusion that the incident is contained and resolved ¹.

Who it applies to

Entity scope: Any organization using NIST SP 800-61 as incident handling guidance, including critical infrastructure operators and service organizations ¹.

Operational context (where it shows up):

• Internal incident response for corporate IT, product engineering, cloud, and OT where applicable.
• Service organizations that must restore customer-impacting systems and prove control operation.
• Environments with meaningful third-party dependencies: managed service providers, SaaS platforms, data processors, incident response retainers, and cloud hosting providers.

Third-party reality check: If a third party hosts the affected workload, manages identity, provides endpoint tooling, or processes impacted data, your eradication/recovery plan must include them as participants or as constraints. You still own the outcome: root cause removed and safe restoration.

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

Use this as a minimum operational runbook for the eradication and recovery requirement ¹.

1) Establish “eradication complete” criteria

Define objective criteria before you start restoring broadly:

• Known initial access path identified (or bounded with documented hypotheses and compensating actions).
• Persistence mechanisms removed (accounts, tokens, scheduled tasks, startup items, backdoors).
• Vulnerability/misconfiguration corrected, or compensating controls put in place with documented risk acceptance.
• Credentials/keys potentially exposed rotated, with scope documented.

Tip: Put the criteria directly into the incident ticket as acceptance checks. That becomes your audit trail.

2) Build an eradication task plan and track it

Create a task plan that is tied to the incident record and includes:

• Task owner, system scope, action steps, and required validation.
• Sequencing (e.g., rotate privileged credentials before rejoining rebuilt hosts to the domain).
• Change control path (standard, emergency, post-incident review).

This aligns with the recommended control to track eradication tasks and validate post-recovery controls ¹. If you already run a GRC platform or IR case management, make the task plan a structured template. If you use Daydream to manage requirement-to-evidence mapping, map each task and validation result to the eradication and recovery requirement so the evidence stays organized.

3) Choose a restoration strategy: clean, rebuild, or replace

Document the decision and why:

• Rebuild from trusted images for high-risk compromise (common for servers, gold images, cloud instances).
• Clean-in-place only when you can prove removal and integrity to an acceptable level (define “acceptable” in your policy and risk appetite).
• Replace for unmanaged/unsupported assets or where forensic confidence is low.

Auditors focus on whether your strategy was controlled and justified, not whether you picked a specific technical method ¹.

4) Validate backups and restoration sources before cutover

“Safely restore” requires that the recovery source is trustworthy ¹. Operationalize this with explicit checks:

• Backup restore testing results or restore verification notes.
• Malware scanning where feasible.
• Integrity checks for images, repositories, and deployment pipelines used to rebuild.

If you cannot validate older backups, document the risk and choose a safer path (rebuild from known-good images, narrow scope, isolate).

5) Execute recovery in controlled phases

Run recovery in phases to reduce blast radius if the root cause persists:

• Start with a pilot group or low-criticality systems.
• Confirm authentication, logging, and monitoring are functioning.
• Then expand to higher criticality services.

Tie each phase to a clear go/no-go decision with named approvers (incident commander, system owner, security lead).

6) Validate post-recovery controls (required for defensibility)

This is where many teams fail the requirement. You need proof that the environment is not simply “up,” but “up and safe” ¹. Minimum validation set:

• Security controls: EDR/AV active, logging enabled, time sync correct, vulnerability mitigations applied.
• Identity: credential rotations completed, privileged access revalidated, suspicious sessions invalidated.
• Network: firewall rules reviewed for emergency exceptions, remote access paths validated.
• Detection: heightened monitoring in place; alerts reviewed for recurrence indicators.

Capture validation results as artifacts, not as informal chat messages.

7) Monitor for recurrence and document closure rationale

After restoration, maintain heightened monitoring and document what signals you reviewed to conclude eradication held ¹. Also document open items: technical debt, long-term hardening, and control gaps.

Required evidence and artifacts to retain

Keep artifacts tied to the incident record and searchable by system and date. Minimum set aligned to NIST SP 800-61’s expectation to remove root cause and restore safely ¹:

Planning and governance

• Incident record with eradication/recovery scope.
• Eradication task plan with owners, timestamps, and completion status.
• Decision log: rebuild vs clean, backup selection, cutover approvals.
• Emergency change tickets and post-change reviews.

Technical proof

• Patch/misconfiguration remediation evidence (change diffs, config snapshots).
• Credential/key rotation records (what rotated, scope, completion confirmation).
• Rebuild/reimage logs, deployment records, IaC change history.
• Validation checklists with results (control status, monitoring enabled).
• Post-recovery monitoring notes and recurrence checks.

Third-party coordination (if applicable)

• Third-party incident communications, ticket transcripts, and restoration attestations.
• Updated responsibilities matrix (who did what, when).

Daydream fits here as the system to keep requirement-to-evidence mapping clean: one place to store the task plan, validations, and approvals for the eradication and recovery requirement, with consistent naming and retention tags.

Common exam/audit questions and hangups

Expect these lines of questioning ¹:

• “How did you determine the root cause, and what evidence supports it?”
• “Why did you restore from that backup/image, and how did you validate it was not compromised?”
• “Show me proof that persistence was removed (accounts, tokens, scheduled tasks).”
• “What controls did you validate post-recovery, and who signed off?”
• “Which emergency changes were made, and were they reviewed afterward?”
• “How did you ensure third parties did not reintroduce the issue (managed admin access, SaaS integrations, API keys)?”

Hangup to preempt: “We rebuilt everything” is not evidence. Auditors want a traceable record of what you rebuilt, why, and how you confirmed success.

Frequent implementation mistakes and how to avoid them

1. Restoring before credential and access hygiene is complete.
   Fix: rotate compromised credentials/tokens early; document sequencing and approvals.

2. No defined “eradication complete” criteria.
   Fix: write criteria into the IR template; require sign-off before broad cutover ¹.

3. Treating validation as optional.
   Fix: mandate a post-recovery control validation checklist and attach results to the incident record ¹.

4. Losing evidence in chat and email.
   Fix: require all eradication/recovery tasks to be tracked in a system of record and exported for retention.

5. Ignoring third-party dependencies.
   Fix: include third parties in scope reviews; capture their actions as part of your evidence package.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. That does not reduce the operational risk. Weak eradication and recovery commonly leads to repeat incidents, extended outage, and unreliable incident reporting because you cannot confidently state what was removed and when. NIST SP 800-61’s phrasing (“remove root cause and safely restore”) signals a regulator-grade expectation: demonstrable remediation plus safe restoration, not informal “all clear” statements ¹.

30/60/90-day execution plan

Day 0–30: Make it executable

• Publish an “Eradication & Recovery” checklist template inside your incident response process ¹.
• Add an eradication task plan structure to your ticketing/IR tooling (fields: owner, asset, action, validation, approval).
• Define “eradication complete” and “safe to restore” acceptance criteria for common incident types (ransomware, credential theft, web app compromise).
• Align change management: define how emergency changes are recorded and reviewed.

Day 31–60: Make it auditable

• Build an evidence pack template: decision log, task tracking export, validation checklist, change tickets.
• Run a tabletop focused only on eradication/recovery decisions (rebuild vs clean, backup trust, cutover approvals).
• Identify top systems where rebuild is hard (legacy, OT, regulated apps) and pre-stage trusted images or recovery runbooks.

Day 61–90: Make it resilient

• Add post-recovery validation gates into production deployment and access workflows.
• Formalize third-party coordination steps: contact paths, restoration confirmation, credential/key rotation responsibilities.
• Pilot Daydream (or your GRC system) mapping so the eradication and recovery requirement always has a current control description and an evidence index tied to incident records ¹.

Frequently Asked Questions

How do we prove “root cause removed” if we can’t fully attribute the incident?

Document what you know, what you tested, and the compensating controls you applied to close plausible access paths. Auditors accept uncertainty when you show disciplined eradication tasks and validation tied to the incident record ¹.

Is rebuilding always required for eradication and recovery?

NIST SP 800-61 does not mandate a single method; it requires root-cause removal and safe restoration ¹. Rebuild is often the most defensible path for high-confidence eradication, but you can justify other approaches with evidence.

What counts as “safe restoration” in practice?

Safe restoration means restoring from trusted sources and validating controls post-recovery, including logging, endpoint protection, and access controls, then monitoring for recurrence ¹.

How should we handle third parties during recovery?

Treat third parties as part of scope when they host systems, manage admin access, or hold credentials/keys. Capture their restoration actions and confirmations as evidence attached to your incident record.

What evidence do auditors ask for most often?

A tracked eradication task list, rebuild/restore records, credential rotation proof, change approvals, and post-recovery validation results. If you cannot produce these quickly, your eradication and recovery requirement coverage will look weak ¹.

Can we close an incident without post-recovery monitoring?

You can restore service, but closure without a documented monitoring period and recurrence checks is hard to defend. NIST SP 800-61’s “safely restore” expectation implies verification and follow-up, not only system uptime ¹.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. NIST SP 800-61