This playbook template gives a SOC team a ready-to-adapt structure for handling security incidents end to end. It follows the NIST SP 800-61 incident response lifecycle so that every responder works from a shared mental model and a repeatable sequence of actions. Each phase below pairs a short statement of intent with a concrete checklist you can lift directly into your own runbook. Replace the bracketed placeholders with your organisation specific tools, contacts and thresholds before you put it into production. Treat this as a living document and revise it after every major incident and tabletop exercise.
Roles and Responsibilities
Before an incident occurs, every person who may be pulled into a response must know their lane. Ambiguity about who can authorise containment or speak to the press costs precious time during a live event. Define the roles below and name primary and backup holders for each, then publish the list where on-call staff can reach it within seconds.
Keep the roster current. People change teams, leave the company, or are simply unreachable, so review assignments at least quarterly and validate contact details during tabletop exercises.
- ▸Name an Incident Commander who owns decisions and the overall timeline, with at least one named backup.
- ▸Assign a Lead Analyst responsible for technical investigation and evidence handling.
- ▸Designate a Communications Lead who manages internal updates, customer notices and any regulator contact.
- ▸Identify a Scribe to maintain the incident timeline and decision log in real time.
- ▸Confirm who holds authority to approve disruptive containment actions such as isolating production hosts.
- ▸Document escalation contacts for legal, HR, executive leadership and external IR retainer.
- ▸Record an out-of-band contact method (signal group, phone tree) usable if corporate email or chat is compromised.
Phase 1 - Preparation
Preparation is the work you do before anything goes wrong, and it is the single largest determinant of how well a response runs. The goal is to ensure that tooling, access, logging and people are ready so that the team is reacting to the incident rather than to its own gaps.
Audit these items on a recurring schedule, not just once. Logging silently breaks, credentials expire and new systems arrive without coverage.
- ▸Verify centralised logging is enabled and retained for at least 90 days across endpoints, identity, network and cloud.
- ▸Confirm EDR or equivalent telemetry is deployed and reporting on every in-scope asset.
- ▸Maintain an up-to-date asset and network diagram so responders can locate systems quickly.
- ▸Pre-stage break-glass credentials and ensure responders have the access they need to investigate.
- ▸Keep an offline copy of contact lists, this playbook and vendor support details.
- ▸Establish and test backups, confirming you can actually restore critical systems within target timeframes.
- ▸Run tabletop exercises at least twice a year and capture gaps as remediation actions.
Phase 2 - Detection and Analysis
This phase turns a signal into a confirmed, scoped incident. The objective is to determine whether an event is a true incident, establish its severity, and understand what is affected before you take disruptive action. Rushing to containment without analysis risks tipping off an attacker or destroying evidence.
Assign a severity level early using a documented matrix so that the response effort matches the business impact, and revise that severity as new facts emerge.
- ▸Triage the alert and validate it is a genuine incident rather than a false positive.
- ▸Assign an initial severity using your severity matrix (for example SEV1 through SEV4).
- ▸Open a dedicated incident channel and ticket, and start the timeline log immediately.
- ▸Identify affected hosts, accounts, data and the likely initial access vector.
- ▸Preserve volatile evidence (memory, running processes, network connections) before changes are made.
- ▸Capture indicators of compromise (hashes, IPs, domains, user agents) into a shared tracker.
- ▸Map observed activity to MITRE ATT&CK techniques to anticipate likely next steps.
- ▸Notify the Incident Commander and escalate per the communication plan once severity is confirmed.
Phase 3 - Containment
Containment limits the damage and stops the spread while you prepare to remove the threat. Distinguish short-term containment (immediate moves to stop bleeding) from long-term containment (sustainable changes that hold while you eradicate). Always weigh the value of preserving evidence against the urgency of stopping harm, and record who authorised each disruptive action.
Coordinate containment so you do not alert an active adversary prematurely or knock out a system that you still need for evidence.
- ▸Isolate affected hosts from the network while keeping them powered on for forensics where possible.
- ▸Disable or reset compromised accounts and revoke active sessions and tokens.
- ▸Block known-malicious indicators at the firewall, proxy, DNS and email gateway.
- ▸Rotate credentials, API keys and secrets that may have been exposed.
- ▸Preserve forensic images or snapshots before making changes to affected systems.
- ▸Confirm containment held by monitoring for re-connection attempts or lateral movement.
- ▸Document the time and approver for every containment action in the incident log.
Phase 4 - Eradication
Eradication removes the root cause and any attacker footholds from the environment. The goal is to ensure that when systems come back, the adversary cannot simply walk back in. This means eliminating malware, closing the exploited vulnerability, and hunting for persistence mechanisms the attacker may have planted.
Do not declare eradication complete based on a single cleaned host. Attackers commonly establish multiple persistence points, so verify across the whole affected scope.
- ▸Identify and document the root cause and the full scope of compromise.
- ▸Remove malware, web shells, scheduled tasks and other attacker artifacts.
- ▸Patch or remediate the vulnerability or misconfiguration that enabled initial access.
- ▸Hunt for persistence: new accounts, modified services, registry run keys, cron jobs and rogue OAuth grants.
- ▸Reset credentials broadly, including service accounts and any domain-level secrets if identity was touched.
- ▸Validate the environment with a fresh scan and threat hunt before moving to recovery.
- ▸Rebuild from known-good images rather than cleaning in place when integrity is in doubt.
Phase 5 - Recovery
Recovery returns affected systems to normal operation in a controlled, monitored way. The objective is to restore business function with confidence that the threat is gone and that any return of malicious activity will be caught immediately. Bring systems back in stages and watch them closely.
Define clear, agreed criteria for declaring the incident closed so the decision is objective rather than a matter of fatigue or pressure.
- ▸Restore systems from validated clean backups or freshly rebuilt images.
- ▸Confirm patches and hardening are in place before reconnecting systems to production.
- ▸Reconnect in stages and apply enhanced monitoring to recovered assets.
- ▸Validate that business services are functioning correctly with system owners.
- ▸Watch for signs of attacker return for a defined heightened-monitoring period.
- ▸Confirm all containment artifacts (blocks, isolations) are intentionally retained or removed.
- ▸Obtain Incident Commander sign-off against the documented closure criteria.
Phase 6 - Post-Incident and Lessons Learned
The post-incident phase converts a painful event into durable improvement. The goal is a blameless review that identifies what happened, how the response performed, and which concrete changes will reduce the chance or impact of a repeat. Hold the review while memories are fresh, ideally within two weeks of closure.
Track resulting actions to completion. A lessons-learned report with no owned, deadlined follow-ups simply guarantees the same incident again.
- ▸Schedule a blameless post-incident review with all key participants.
- ▸Reconstruct a clear timeline from the incident log and supporting evidence.
- ▸Assess detection and response performance against time-to-detect and time-to-contain targets.
- ▸Identify root causes and contributing factors across people, process and technology.
- ▸Record specific remediation actions, each with a named owner and due date.
- ▸Update detections, playbooks and documentation based on what was learned.
- ▸Capture metrics and share an executive summary with leadership.
- ▸Verify completion of all follow-up actions in a later review cycle.
Communication and Escalation
Clear communication keeps responders aligned and stakeholders informed without leaking sensitive detail. The goal is to define who is told what, when and through which channel, so that updates are timely and consistent. Poor communication during an incident erodes trust faster than the technical impact itself.
Pre-draft notification templates and know your regulatory clocks in advance. Many breach-notification regimes impose tight deadlines that are difficult to meet if you start writing from scratch mid-incident.
- ▸Define an internal update cadence (for example every 30 or 60 minutes for SEV1).
- ▸Use an out-of-band channel if email or chat may be compromised.
- ▸Maintain pre-approved templates for staff, customer and regulator notifications.
- ▸Know your legal and regulatory notification deadlines (for example GDPR 72 hours).
- ▸Route all external and media statements through Communications and Legal only.
- ▸Brief executive stakeholders with concise, decision-focused updates.
- ▸Log every external communication and the time it was sent.