Incident Response Playbook: Template and Worked Example

An incident response playbook is a short, scenario-specific procedure that tells the on-call responder what to check, what to contain, who to call and what to record for one type of incident, such as a leaked cloud key or a ransomware alert. It sits under your incident response plan, which defines roles, severity levels and who may take a system offline, and it should be executable by a competent engineer who has never seen that incident before. Good playbooks are short, name real commands and consoles, make decision points explicit, and get tested before they are needed.

Key takeaways

• Write one incident response plan and a small number of playbooks for the incidents you are most likely to have. Five well-tested playbooks beat twenty untested ones.
• A playbook step must be executable as written: a command, a console path or a named person. "Contain the affected systems" is not a step.
• Preserve evidence before you change anything you cannot change back. Deactivate rather than delete; snapshot before you rebuild.
• Contain in one coordinated move. Partial containment tells the attacker you have noticed and gives them time to dig in.
• Assume your normal tools may be compromised or down. Keep playbooks, contact lists and a communication channel reachable without SSO.
• Notification deadlines start when you become aware, not when you finish investigating. Put the clocks in the playbook.

Plan, playbook, runbook

These three words get used interchangeably, which is how teams end up with a forty-page policy and nothing to follow at 3 a.m.

Playbooks call runbooks. The ransomware playbook says "isolate affected hosts (runbook: EDR network containment)"; the runbook says which console, which button and what the host status should change to.

Phases, briefly

The lifecycle most teams learned comes from NIST SP 800-61 Rev. 2: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. SANS splits the same work into six steps (preparation, identification, containment, eradication, recovery, lessons learned). NIST's Rev. 3, published in April 2025, reframes incident response around the CSF 2.0 functions so that it is treated as part of everyday risk management rather than a separate discipline. That framing is useful for program design. Inside an incident, the sequence is unchanged: confirm, contain, preserve, remove, recover, learn.

Roles during an incident

In a small team one person can hold two roles. The one combination that fails reliably is incident commander plus hands-on responder: the person deep in a terminal stops coordinating, and nobody notices the second compromised account.

Severity levels

Define severity by impact and confidence, and attach a response to each level. A reasonable starting scale:

Upgrade quickly and downgrade slowly. Declaring SEV1 and standing down after an hour costs a little sleep. Treating a real SEV1 as a SEV3 overnight can cost the company.

The playbook template

Keep playbooks in version control next to the code they protect, in a format that renders anywhere and prints. A skeleton:

id: PB-CLOUD-KEY
title: Leaked or abused cloud access key
owner: platform-security
last_tested: 2026-09-12   # tabletop
trigger:
  - Secret scanner alert for a cloud key in a repo, log or ticket
  - Provider notice that a key was found publicly
  - Threat detection alert for API calls from an unusual network or region
triage:
  - Is the key active, and what can it do?
  - Has it been used from anywhere we do not recognize?
  - Did that use touch data, identities or create resources?
severity_rules:
  - Unknown use plus data access or IAM changes: SEV1
  - Unknown use, no data access: SEV2
  - No use since exposure: SEV3
contain: [deactivate key, revoke issued sessions, block persistence]
preserve: [CloudTrail for the window, snapshots of affected instances]
eradicate: [remove created identities and resources, fix the leak source]
recover: [replace with role or OIDC, add guardrail]
contacts: [incident commander rota, cloud account owner, legal]

The last_tested field is not decoration. A playbook nobody has walked through since the last re-organization usually references a console that moved, a person who left and a log that is no longer retained.

Worked example: a leaked AWS access key

This is the playbook most engineering teams should write first. Keys leak through commits, CI logs, screenshots and laptops, and the first attacker use is often automated: crypto-mining instances in regions you never use, spam through SES, or new IAM users for persistence.

1. Triage: what is this key and has it been used?

KEY=AKIAEXAMPLEEXAMPLE
 
aws iam get-access-key-last-used --access-key-id "$KEY"
 
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue="$KEY" \
  --max-items 50 \
  --query 'Events[].[EventTime,EventName,EventSource]' --output table

lookup-events only covers management events from the last 90 days, one region at a time. For the full picture, query your organization trail in Athena, or in CloudTrail Lake if you already use it. Remember that temporary credentials minted from the key show up with different key IDs (starting ASIA), so search by the user's ARN as well:

SELECT eventtime, awsregion, eventsource, eventname, sourceipaddress, errorcode
FROM cloudtrail_logs
WHERE useridentity.arn = 'arn:aws:iam::111122223333:user/ci-deployer'
  AND eventtime > '2026-10-01T00:00:00Z'
ORDER BY eventtime;

Look specifically for CreateUser, CreateAccessKey, CreateLoginProfile, AttachUserPolicy, PutUserPolicy, UpdateAssumeRolePolicy, RunInstances in regions you do not use, and anything touching secrets or data stores.

2. Preserve before you change

Make sure the organization trail is delivering to a bucket the compromised identity cannot write to, ideally with S3 Object Lock. Snapshot the EBS volumes of any instance the attacker launched or touched before you terminate it. Write down the key ID, user, timestamps and source IPs in the incident log.

3. Contain in one move

aws iam update-access-key --user-name ci-deployer --access-key-id "$KEY" --status Inactive

Deactivate, do not delete. Deactivation is reversible, keeps the key ID tied to the evidence, and has the same effect on the attacker.

Deactivating the key does not end sessions the attacker already created with GetSessionToken or AssumeRole. Attach an explicit deny for anything issued before now, which is what the console's "revoke active sessions" does for roles:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": { "DateLessThan": { "aws:TokenIssueTime": "2026-10-04T10:15:00Z" } }
    }
  ]
}

Then disable whatever persistence triage found: new users' keys and console passwords, new roles' trust policies. Do this as one coordinated batch. If you remove one backdoor at a time over an afternoon, an attacker who is watching will add another.

4. Eradicate and find the source

Delete attacker-created users, keys, roles, functions and instances (after snapshots). Then answer how the key leaked: a commit, a CI log, a pasted config, a stolen laptop. If you cannot answer that, assume the same source has leaked other credentials and widen the rotation.

5. Recover and prevent

Replace the long-lived key with a role or OIDC federation, so there is no key to leak next time. Add an SCP that denies regions you do not use. Make sure S3 data events are logged for sensitive buckets; they are not recorded by default, and without them you cannot answer "was the data read?", which is the question legal will ask first.

Decision points to write down

• If data access on buckets holding personal data is confirmed or cannot be ruled out, SEV1, legal joins, and the notification clock is running.
• If the attacker created IAM identities, assume full account compromise until every identity is reviewed.
• If the key belonged to CI, switch to the supply chain playbook as well: every other secret on that runner is suspect.

The other playbooks to write first

The compromised account playbook connects directly to phishing defense, and the ransomware playbook to the controls in our ransomware prevention guide, especially immutable backups.

Not every incident starts with a security tool. A miner on a compromised server often surfaces first as a host stuck at full CPU, a disk filling with logs, or a process nobody recognizes. Basic host monitoring with alerting that reaches a human (Prometheus with Alertmanager, Netdata, or for self-hosted Linux fleets our own Trinetra, which sends threshold alerts to Telegram and other channels) is part of detection, not just operations.

Communication and notification clocks

Many obligations run from when you become aware of a breach, not when the investigation ends. Put the relevant ones in the playbook so nobody has to look them up mid-incident, and have counsel confirm which apply to you.

Internal updates go out on a fixed cadence even when nothing has changed, because silence gets filled with rumor. A template that fits in a chat message:

[SEV2] Leaked CI access key, update 3, 11:40 UTC
Status: contained. Key deactivated 10:15, old sessions denied 10:22.
Impact: attacker launched instances in an unused region (snapshotted, terminated). No data access found so far.
Next: finish IAM review, confirm leak source (CI log suspected).
Next update: 12:10 UTC. IC: (name). Channel: #inc-2026-10-04

Making playbooks usable under pressure

Reachable when everything else is down. If your playbooks live in a wiki behind SSO and the incident is an identity provider compromise, you have no playbooks. Keep an offline copy and a printed contact sheet, and agree on an out-of-band channel (a separate chat workspace, a phone bridge) in case email or chat is compromised.

Specific enough to follow cold. Compare "contain the host" with "In the EDR console, open the host, choose network containment, and confirm the status shows contained before moving on." The second can be followed by the newest person on the rota.

Break-glass access tested in advance. Emergency admin accounts, hardware keys in a safe, and a documented procedure to use them. Test them in the tabletop, not during the incident.

Exercised. Tabletops do not need to be elaborate. Pick one playbook, describe the first alert, and have the on-call engineer walk through it step by step while someone runs the actual commands against a test account. Note every place someone hesitates. Each hesitation is an edit to the playbook.

Maintained. Update after every incident and every tabletop, when tooling changes, and when people change roles. Give every playbook an owner and a last_tested date, and treat an old date as a finding.

Measuring the program

Keep the list short:

• Time to detect, from first malicious activity to the alert that started the response.
• Time to contain, from alert to the attacker losing access.
• Playbook coverage, the share of incidents where a playbook existed and was used.
• Action item closure from post-incident reviews. Reviews whose actions never ship are theater.

Detection time depends heavily on what you collect and alert on; our SIEM and SOC guide covers that side.

What goes wrong in production

• Evidence destroyed by the fix. A responder terminates the miner instances or reimages the laptop before anyone snapshots it, and the question "how did they get in?" becomes unanswerable.
• The attacker is tipped off. One account disabled at 10:00, another at 14:00, and the attacker uses the gap to create three more. Scope first, then contain everything at once.
• Communication through a compromised channel. The team discusses containment in the email system the attacker is reading. Move to the out-of-band channel as soon as identity or messaging compromise is plausible.
• Logs you assumed you had. Data events were never enabled, retention was a week, or the attacker deleted the only copy. Find this out in a tabletop, not in an incident.
• Time zone confusion. Logs in UTC, chat in local time, the provider's console in a third zone. Agree on UTC for the incident log from the first entry.
• The all-clear comes too early. The obvious backdoor is gone, a quieter one is not. Keep heightened monitoring on affected systems for a defined period after recovery, and only then close.
• No one owns the follow-up. The post-incident review produces good actions that never get scheduled. Assign owners and dates, and review them like any other engineering commitment.

Frequently Asked Questions

What is an incident response playbook?

An incident response playbook is a short, scenario-specific procedure for one type of incident, such as a leaked cloud key, a compromised account or a ransomware alert. It tells the responder what to check, how to contain it, who to call and what to record, with real commands and console paths. It sits under the incident response plan, which defines roles, severity levels and decision authority.

What should an incident response playbook include?

A trigger that says when to use it, triage questions that set severity, containment steps in order, evidence to preserve before anything is changed, eradication and recovery steps, decision points that escalate or switch to another playbook, and the people and notification deadlines involved. It should also record an owner and the date it was last tested. If a step cannot be executed by an engineer who has never seen this incident, it is not specific enough.

What is the difference between an incident response plan and a playbook?

The plan is the organization-wide policy: who is on the response team, how severity is defined, who can make decisions such as taking a system offline, and how communication works. A playbook is the procedure for one scenario inside that plan. Most teams need one plan and a handful of playbooks for the incidents they are most likely to face.

What are the phases of incident response?

The classic lifecycle from NIST SP 800-61 Rev. 2 is preparation, detection and analysis, containment, eradication and recovery, and post-incident activity; SANS splits the same work into six steps. NIST's Rev. 3, published in 2025, maps incident response onto the CSF 2.0 functions instead, but the practical sequence inside an incident is unchanged. Contain first, preserve evidence, remove the attacker, recover, then learn.

How often should incident response playbooks be tested?

Run a tabletop exercise for your highest-risk playbooks at least twice a year, and review every playbook after any real incident or major infrastructure change. Short, frequent exercises that walk one playbook end to end find more problems than an annual all-day simulation. Check that commands still work, contact details are current and the documents are reachable when single sign-on is down.

Who should be on an incident response team?

At minimum an incident commander who coordinates and decides, a technical lead who directs the investigation, a scribe who keeps the timeline, and a communications lead for internal and external updates. Legal or privacy counsel joins whenever personal data or regulated systems may be involved. In small teams one person can hold two roles, but the incident commander should not be the person typing commands.

Need help with incident response?

We run production systems, so incident response is something we practice rather than describe: playbooks that match your actual stack, tabletop exercises with real commands, and the logging you need to answer what happened. If we built it, we're on the pager for it.

• Cybersecurity and compliance
• Cloud architecture and infrastructure
• Talk to an engineer