When should recovery begin after containment?¶

Recovery should begin when the immediate threat is sufficiently controlled and the evidence needed to understand the incident has been preserved proportionately.

Avoid this assumption: Services should be restored as soon as alerts stop. Premature recovery may reconnect compromised systems, destroy volatile evidence or allow the attacker back in.

Confirm the containment objective and whether it was achieved.

Identify which accounts, devices, services and access routes remain at risk.

Preserve the affected systems, logs, sessions, malware evidence, audit records and responder actions before rebuilding or reconnecting.

Ensure that essential provider preservation requests and organisational holds have been made.

Define what must be cleaned, rebuilt, reset, replaced or monitored.

Use trusted sources for software, credentials, configuration and backups.

Do not restore from an unverified backup simply because it predates the visible incident.

Record the recovery plan, authorisation, sequence, dependencies and rollback options.

Restore critical services in a controlled order and monitor for renewed access, alerts or unusual activity.

Record every system brought back online, the time, configuration and validation performed.

Keep recovery records separate from the original incident evidence.

Where uncertainty remains about persistence, identity systems or administrative control, seek specialist advice before wider reconnection.

Do not declare recovery complete solely because systems are functioning.

Define who has authority to approve reconnection and what evidence or validation they require before each stage proceeds.

Operational takeaway¶

Begin recovery only after proportionate preservation and verified containment, then restore systems in a controlled, documented sequence with monitoring for renewed compromise.