Incident Response Playbook

An Incident Response Playbook is a documented, step-by-step procedure for handling a specific type of security incident. Playbooks reduce response time by eliminating decision paralysis during high-stress situations.

Playbook Structure

• Detection: how to identify this incident type (GuardDuty findings, alerts, user reports)
• Severity Assessment: criteria for determining impact and urgency
• Containment: immediate actions to stop the threat from spreading
• Eradication: remove the threat completely (compromised resources, malware, backdoors)
• Recovery: restore normal operations and verify systems are clean
• Lessons Learned: post-incident review to improve defenses and update the playbook

AWS-Specific Playbooks

• Compromised IAM credentials (disable keys, revoke sessions, review CloudTrail)
• Public S3 bucket (block public access, assess exposure, notify stakeholders)
• Compromised EC2 instance (isolate, snapshot, forensic analysis)
• Crypto mining detection (identify source, terminate instances, check billing)

What a Good AWS Playbook Contains

The difference between a playbook and a wiki page is executability at 3 a.m. by whoever is on call. Each step should carry the exact command or console path, the expected output, and the decision rule for the next step. For a compromised-key playbook that means the literal containment command (aws iam update-access-key --access-key-id AKIA... --status Inactive --user-name NAME), the literal investigation query (aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA...), and an explicit persistence checklist: new access keys, new users, new roles, modified trust policies, resources in unused Regions. It also means recording constraints that bite mid-incident, such as lookup-events covering only 90 days at 2 requests per second per Region, so responders know when to pivot to querying the trail in S3. Preconditions belong in the playbook too: none of the investigation steps work if CloudTrail delivery was never configured, which is why every playbook implicitly starts with preparation.

Well-defined trigger mapping closes the loop: each playbook should name the GuardDuty finding types or alert sources that invoke it, and ideally an EventBridge rule routes those findings straight to the on-call channel with the playbook link attached.

How It Goes Wrong in Practice

The most common failure is the untested playbook. It was written eighteen months ago against a different account structure; the role it tells responders to assume no longer exists, the quarantine security group was deleted by a cleanup script, and step four assumes a console layout two redesigns old. The team discovers all of this during a real incident, which converts a runbook into a scavenger hunt. Playbooks are code for humans: they need the same review and testing cadence. GuardDuty can generate sample findings on demand, which makes end-to-end rehearsal (finding, alert, human, playbook, containment) cheap enough to schedule quarterly.

The second failure is the playbook that stops at containment. Deactivating the leaked key is step one, not the outcome. Playbooks that omit the persistence hunt and the eradication verification produce incidents that reopen a week later through the access key the attacker created while they had the chance.

Practical Check: Rehearse the First Command

Pick your compromised-credentials playbook and verify its first two commands run as written (against a test user):

aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive --user-name test-user

aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=test-user --max-items 10

Deactivation is reversible (--status Active restores it), which is exactly why it belongs at the top of the playbook: a responder can act in seconds without fear of destroying anything. If either command fails for the on-call role, you have found a playbook bug for free.

Frequently Asked Questions

Which playbooks should we write first?

The incident types most likely to hit any AWS environment: leaked or abused IAM credentials, a publicly exposed S3 bucket, a compromised EC2 instance, and cryptomining. These cover the bulk of real cloud incidents and exercise the containment primitives every other playbook reuses.

Should playbooks be automated?

Automate the reversible, well-understood steps (isolate instance, deactivate key, snapshot volumes) via EventBridge and Lambda or SSM automation, and keep humans on the judgment calls: severity assessment, eradication scope, customer notification. Full automation of destructive steps tends to produce spectacular self-inflicted outages.

How is a playbook different from an IR plan?

The plan is the organization-level document: roles, escalation, communication, legal obligations. A playbook is the tactical procedure for one incident type. You have one plan and many playbooks, and the plan tells you which playbook to open.