Eradication and recovery

Restore service without restoring the compromise

Eradication addresses the causes and surviving access involved in an incident. Recovery returns affected services to an acceptable, trustworthy operating state. The activities can overlap, but they answer different questions: what must be removed or corrected, and what evidence shows the service is ready to operate again?

Deleting the first suspicious file is rarely sufficient evidence of eradication. The actor may have created an account, changed a scheduled task, obtained a token, altered an application grant, or reached another system. Investigation findings should determine the cleanup scope rather than the location of the first alert.

Build a recovery plan from the evidence

Consider a fictional portal server where an unauthorized component was installed through a vulnerable application. The team isolates the server and preserves relevant evidence. It then identifies the vulnerable version, the component's execution history, the permissions available to the service, and any secrets the service could access.

The recovery plan might include rebuilding from a trusted source, correcting the vulnerable application, replacing exposed credentials, and reviewing connected resources. A backup can help restore data, but its date and contents matter. Restoring a backup containing the unauthorized component recreates the problem; restoring an earlier backup without addressing the vulnerability leaves the original access route open.

Backups and restore testing therefore support recovery alongside configuration integrity, identity management, and application maintenance. A successful restore command establishes only one step of the process, not the security of the restored service.

Define readiness conditions

Before returning the portal to users, the team specifies checks: the corrected version is running, the approved configuration is present, unauthorized access paths have been reviewed, required business functions pass testing, and monitoring captures the activity that mattered in the incident.

Not every uncertainty can be eliminated. Record unresolved questions and decide who accepts the associated risk. A missing historical log may prevent a definitive conclusion about data access; that limitation should remain visible even if technical recovery succeeds.

Coordinate with service owners because restored access affects real workflows. Staged restoration can reveal problems before full use resumes. Keep a fallback plan and a responsible person available if the service behaves unexpectedly.

Learn from the recovery

After restoration, review whether suspicious behavior returns and whether the original conditions recur. Agree on the monitoring period and the evidence that would trigger renewed investigation. Quiet dashboards are useful only when the relevant telemetry is functioning.

For practice, write five readiness conditions for the portal scenario and identify how each will be verified. Include one technical check, one identity check, one user-facing test, and one evidence limitation. Incident reporting and handover should explain the remaining risk, while Incident response connects the lessons to preparation for the next event.

Related concepts

• Disaster recovery
• Lessons learned