Ops guide

Incident response: containment-first playbook

Contain, preserve, eradicate, recover, learn. A calm workflow teams can follow without destroying evidence.

Difficulty: starter Time: ~25 min Updated: 2025-12-30

Mindset: calm beats clever

A good incident response (IR) playbook makes people calmer. Calm teams preserve evidence, contain damage, and recover faster. Panic teams delete logs, reboot everything, and lose the story.

Triage: what happened and how bad is it?

Start by collecting a few high-signal facts. Don’t try to answer everything immediately.

Triage checklist

  • What systems are affected? (endpoints, servers, accounts, backups)
  • What is the impact? (data exposure, downtime, privilege levels)
  • Is the attacker still active? (new logins, running processes, beaconing)
  • What is the time window? (first alert, last known good)

Containment first

Containment limits harm. It can be network-level (isolate a host), account-level (disable sessions), or application-level (turn off a compromised feature). Pick the least destructive action that stops the bleeding.

Containment options

  • Isolate impacted endpoints from the network (preserve power state if needed).
  • Reset and rotate compromised credentials and session tokens.
  • Disable exposed services temporarily (admin panels, vulnerable plugins).
  • Increase monitoring and logging during the active window.

Don’t destroy the scene

Wiping, mass reboots, or “cleanup scripts” can erase the evidence you need to understand what happened.

Preserve evidence

Preserve logs, snapshots, and timelines. Even a small set of preserved evidence can be the difference between “we fixed it” and “they’re still inside”.

Evidence minimum

  • Central logs (auth, web, system, EDR, VPN) for the incident window.
  • Account and session history (new devices, token creations).
  • Disk/memory captures where justified and lawful.
  • Hashes of suspicious binaries and a copy of relevant configuration.

Eradication and recovery

Once you have containment and evidence, eradicate the cause: patch the vulnerability, remove persistence, rotate keys, and fix risky configuration. Then recover services from known-good images/backups.

Recovery checklist

  • Patch and harden the root cause (not only symptoms).
  • Rebuild compromised systems from known-good images when possible.
  • Validate backups are clean before restoring.
  • Monitor for re-entry (new admin accounts, unusual outbound traffic).

Communications

In incidents, communication is part of security. Define who can say what, to whom, and through which channel. Keep a clear internal log of decisions.

  • Internal: operations timeline, ownership, and action log.
  • External: customers/partners/legal as required by policy and law.
  • Media/social: only if needed, with controlled messaging.

Lessons learned

After recovery, capture what would have made the incident smaller. Then implement it.

Post-incident improvements

  • Fix patch SLAs and monitoring gaps.
  • Improve backups and restore testing.
  • Add MFA and least privilege where missing.
  • Run a tabletop exercise with the updated playbook.

Templates

INCIDENT ID:
START TIME (UTC):
DETECTION SOURCE:
AFFECTED SYSTEMS:
IMPACT SUMMARY:
CONTAINMENT ACTIONS:
EVIDENCE PRESERVED:
ROOT CAUSE:
ERADICATION STEPS:
RECOVERY STEPS:
POST-INCIDENT ACTION ITEMS:

References

  • NIST incident response lifecycle concepts.
  • Log retention and evidence handling basics.
  • Backup integrity and restore testing practices.

Scope note

This guide focuses on defensive hardening and incident readiness. Guidance about hiding wrongdoing, destroying evidence, or evading lawful investigation is intentionally not provided.