Incident Response in Practice: Building and Running Your First Playbook

Incident response is one of those skills that sounds abstract until you need it. When a real breach is happening — or you suspect one is — clarity of process is what determines whether you contain the incident or let it spiral. Playbooks are that clarity in written form.

The NIST Incident Response Lifecycle

The NIST SP 800-61 framework defines four phases:

1. Preparation — Establish capabilities before incidents happen
2. Detection and Analysis — Identify and understand the incident
3. Containment, Eradication, and Recovery — Stop the damage, remove the threat, restore operations
4. Post-Incident Activity — Learn from it

I'll walk through each phase with concrete, actionable steps.

Phase 1: Preparation

Preparation is everything you do before an incident occurs. Most organizations invest too little here and pay for it during actual incidents.

Asset inventory: You cannot detect anomalies without knowing what normal looks like, and you cannot respond effectively without knowing what systems you have. Maintain an up-to-date inventory: all servers (IP, OS, purpose, owner), network devices, endpoints, cloud resources, third-party services.

Communication plan: Who needs to be notified when an incident occurs? In what order? Legal? Executive leadership? Customers? Regulators? Define this in advance — during an incident is the wrong time to figure out escalation paths.

Contact list: Security team phone numbers, ISP contacts, law enforcement contacts, legal counsel, forensics vendors. Stored offline — your primary communication channels may be compromised.

Tooling: Your incident responders need tools already installed, tested, and documented before an incident. Forensic tools, log aggregation, network capture capabilities, disk imaging tools.

Practice: Run tabletop exercises. Present your team with a scenario (ransomware infection, credential theft, insider threat) and walk through your response. Gaps in your process are much less costly to find in a tabletop than in a real incident.

Phase 2: Detection and Analysis

Detection sources: Incidents are detected through many channels — SIEM alerts, endpoint detection tools (EDR), user reports, third-party notification, threat intelligence feeds. All of these should feed a central logging and alerting system.

Initial triage: When a potential incident is flagged, the first question is: is this real? Many alerts are false positives. Investigate enough to determine:

• What happened?
• Which systems are affected?
• Is this still happening?
• What is the potential impact?

Evidence collection: Begin preserving evidence immediately. Memory contents are volatile — capture before isolating a system. Log files may roll over — preserve them now. Document everything with timestamps.

Incident classification: Categorize by type (malware infection, unauthorized access, data breach, DDoS, insider threat) and severity. Severity determines response urgency and escalation requirements.

A Concrete Playbook: Suspected Account Compromise

Here's a playbook I developed for a common scenario — a user account showing signs of compromise:

Trigger: SIEM alert — successful login from an unusual geographic location, followed by large data access.

Step 1 — Verify (15 minutes)

• Confirm the alert is real: check source IP geolocation, compare to user's normal login locations
• Contact the user via phone (not email — the email may be compromised): "Did you log in from [country] in the last two hours?"
• If user says no: escalate to confirmed compromise. If yes: investigate further before escalating.

Step 2 — Contain (immediate upon confirmation)

• Disable the compromised account
• Invalidate all active sessions (force re-authentication)
• Block the source IP at the perimeter firewall
• Preserve current logs before any changes

Step 3 — Investigate

• Review all activity from the compromised account in the past 30 days
• Identify what data was accessed
• Determine initial compromise vector: phishing, credential reuse, brute force?
• Check for persistence mechanisms: new email rules, forwarding addresses, OAuth app grants

Step 4 — Eradicate

• If credential reuse: force password reset, check if same credentials used elsewhere in the org
• If phishing: identify the phishing email, check if other users received it, quarantine
• Remove any persistence mechanisms found

Step 5 — Recover

• Re-enable account with new credentials
• Enforce MFA if not already in place
• Monitor account activity closely for 30 days

Step 6 — Post-incident

• Document timeline of events
• Root cause analysis
• Update detection rules if the initial alert could be improved
• Review similar accounts for same indicators of compromise

Containment Strategies

Containment decisions involve tradeoffs between minimizing damage and preserving investigation capability.

Network isolation: Disconnect affected systems from the network. Stops ongoing exfiltration and lateral movement. Downside: may alert the attacker and destroy forensic evidence of their activity.

Account suspension: Disable compromised accounts without removing them. Stops access without destroying audit trails.

Honeypot traffic: Rather than immediately containing, route attacker traffic to a monitored honeypot environment. Allows you to observe attacker TTPs (tactics, techniques, procedures) while keeping them away from real systems.

Kill switch: For ransomware incidents specifically — if you have a network-level kill switch that can isolate affected segments in seconds, use it.

Forensic Evidence Preservation

Evidence handling is critical, especially if law enforcement will be involved.

Memory forensics: Capture memory before powering down or isolating the system. Tools: Volatility, WinPmem. Memory contains running processes, network connections, encryption keys, and attacker tools that won't be present on disk.

Disk imaging: Use write blockers when imaging drives. Chain of custody documentation is essential if evidence will be used in legal proceedings.

Log preservation: Archive logs to write-once storage immediately. Log aggregation systems with immutable storage (S3 with Object Lock, for example) help here.

Timeline construction: Build a chronological timeline of events using multiple log sources. Host logs, network logs, application logs, authentication logs — cross-correlate to reconstruct attacker activity.

Learning from Incidents

Post-incident reviews are where organizations actually improve. The goal isn't blame assignment — it's process improvement.

Questions to answer:

• What was the initial indicator and why was it (or wasn't it) detected?
• What could have reduced the attacker's dwell time?
• Did our containment actions work as expected?
• What gaps in tooling, process, or knowledge did the incident reveal?

Document findings and track remediation items with owners and deadlines. An incident that doesn't produce process improvements was doubly costly — you paid for the breach and learned nothing.

Incident response is a skill you build over time, through exercises, through real incidents, and through honest post-mortems. Start building your playbooks now, before you need them.