Recovery is not proof of eradication
Service restoration can be necessary before every investigative question is resolved. Eradication addresses root cause or persistence; recovery restores a usable service. Both require evidence, owner confirmation, rollback readiness, and a monitoring plan. Credential resets, token invalidation, configuration correction, vulnerability remediation, rebuilds, and clean-up actions solve different problems.
Eradication checklist
- Identify suspected root cause, persistence paths, affected identities, and affected assets.
- Remove or disable known malicious mechanisms where evidence supports the action.
- Reset credentials and invalidate sessions or tokens where the incident scope requires it.
- Apply relevant vulnerability, configuration, or access-control remediation.
- Choose rebuild versus clean based on evidence, supportability, and approved procedures.
Recovery checklist
- Restore in a documented sequence with business-owner confirmation.
- Validate versions, configurations, service behavior, and monitoring coverage.
- Retain rollback options and identify dependencies that can reintroduce the condition.
- Set a monitoring window and recurrence triggers.
False recovery
A restarted service, changed password, or closed ticket does not establish that persistence is gone, every node was remediated, or the original cause is understood. Record unresolved questions and re-open scope when monitoring shows related activity.