Runbooks, playbooks, and severity
Lesson 1 of 3 in Designing the Response.
Detection taught you to see. This domain is about what happens in the ninety minutes after you see it — and it is the domain where good engineers lose marks, because the questions are rarely about a service. They are about order. Capture or contain first? Terminate or isolate? Who gets woken up, and at what point does the legal team need to know?
Underneath every one of those questions sits the same seven-phase spine, the incident response lifecycle. Read it as a loop, not a line: you prepare, you detect, you analyse, you contain, you eradicate, you recover, and you learn — and what you learn becomes next quarter’s preparation. The exam leans on three properties of that loop. Preparation is a phase, which is why "create an IAM role for the responder" is a wrong answer during an incident. Analysis sits between detection and containment, which is why acting on an unvalidated finding is a wrong answer too. And learning closes the loop, which is why a question that ends "…and prevent recurrence" is asking for a control, not a cleanup.
The incident response lifecycle — a loop, and the exam knows where you are standing on it
- Prepare
Responder roles deployed, forensics account standing, runbooks written and tested, logging already on, Shield Advanced already subscribed. Everything that is expensive to invent under pressure.
- Detect
A finding, an alarm, a customer report, a bill spike. Detection is Content Domain 1 — GuardDuty, Security Hub, CloudWatch alarms, Config rules.
- Analyse — is it real, and how far does it reach?
Validate the finding, confirm the resource and the principal, read the surrounding CloudTrail, then scope it. This phase is where a finding becomes an incident, or does not.
- Contain
Stop the spread without destroying what you need to understand it: isolate, deny, revoke. Evidence capture happens here or just before — never after.
- Eradicate
Remove the attacker’s persistence and close the entry point. Containment holds the line; eradication removes the cause.
- Recover
Rebuild from known-good material, restore data from before the compromise, verify, and return to service with monitoring on.
- Learn
Post-incident analysis: timeline, root cause, what the detectors missed, which runbook step was wrong. Output is a backlog of controls and runbook edits.
Now the two words the exam uses as if they were interchangeable, and is not. A Runbook is prescribed steps: numbered, deterministic, safe to hand to the person on call at 03:00 who has never seen this failure. "Snapshot the volume, replace the security group with sg-quarantine, record the snapshot id in the ticket." It is the kind of document that can become code — and on AWS it literally does, as a Systems Manager Automation document.
A Playbook is decision guidance: the branching, judgement-carrying document for a class of incident. "Compromised IAM credentials" is a playbook. It names who decides, what the decision criteria are, which runbooks to invoke at each branch, when to notify legal and communications, and what makes this a severity 1 rather than a severity 3. It cannot be fully automated, because its value is in the choices.
Teams that only write runbooks end up executing confidently in the wrong direction. Teams that only write playbooks end up improvising every command under stress. You want both: playbooks that decide, runbooks that act.
| Runbook | Playbook | |
|---|---|---|
Answers | "How do I do this?" | "What should we do, and who decides?" |
Shape | Linear, numbered, deterministic steps | Branching decision tree with criteria and owners |
Scope | One task — isolate an instance, rotate a key, snapshot a volume | One incident class — credential compromise, data exposure, DDoS, crypto-mining |
Automatable | Yes — this is the half that becomes a Systems Manager Automation document | Partly — Step Functions can carry the branches, but human approval stays human |
Authored by | The engineers who own the resource | Security leadership with legal, comms, and engineering |
Failure mode | Correct execution of the wrong response | Confident decisions that nobody knows how to carry out |
Lives in | Version control, and an Automation document in each account | The wiki, attached to the response plan and linked from the OpsItem |
Severity is the dial that makes every other decision cheap. It is not a feeling — it is a published table with thresholds, and the point of publishing it is that nobody negotiates severity during the incident. Three inputs drive it: confidentiality impact (what data is exposed, and whose), integrity and availability impact (what stopped working, for how many), and scope (one instance, one account, or the organization). Regulatory exposure is a multiplier, not an input — personal data in scope raises the floor regardless of technical blast radius.
Severity then drives the things an exam question cares about: who is engaged, how fast, how often you communicate, and how much authority the responder has. At the top rung the responder can isolate production without asking. At the bottom they open a ticket. Write that authority down in advance, or your severity 1 spends its first hour looking for someone to approve a security group change.
A severity ladder — widest at the bottom, loudest at the top
- SEV4 — informational — queue it
A low-severity finding with no evidence of exploitation: an unencrypted non-production volume, a stale access key, a Config rule gone non-compliant. No engagement. It becomes a ticket with an SLA, and it is the volume tier — most of what detection produces lands here, which is why automated suppression and ticket routing matter more than paging.
- SEV3 — contained anomaly — business hours
Something real happened but the blast radius is one non-production resource and the control held. Engage the owning team during business hours, follow the runbook, record it. The exam signal is "no evidence of data access" plus "single resource" — that combination is rarely a page.
- SEV2 — active in production — page the on-call
An attacker or malware is active on a production resource, or a production credential is being used in a way its owner did not intend. Page the on-call responder immediately, open the incident record, start the clock on communications. The responder has standing authority to contain. Most GuardDuty high-severity findings against production land here.
- SEV1 — organizational — engage everyone, now
Confirmed data exfiltration, root or management-account credential misuse, ransomware, or any incident crossing account boundaries. Engage the full response plan: security leadership, legal, communications, and the executive on call, with a documented regulatory clock running. Containment authority is pre-granted and broad. This is the tier your break-glass path and your forensics account exist for.
Systems Manager OpsCenter — the incident’s record of work
OpsCenter is the central list of operational items across your accounts and Regions. Each item is an OpsItem: a title, a severity and category, the related AWS resources, and — the part that matters here — associated Automation runbooks you can launch from the OpsItem itself, with their output recorded against it. OpsItems can be created by hand, from a CloudWatch alarm, from an EventBridge rule, or from a Security Hub finding, which makes OpsCenter the natural landing surface for "a detector fired and a human now owns it". It earns that place because it closes the gap between the finding and the work: investigation notes, the resources touched, and the runbook executions all hang off one id you can cite afterwards — and the exam guide names it among the tools for building response plans and runbooks.
Incident Manager — the on-call and engagement half
Systems Manager Incident Manager owns the part OpsCenter does not: who gets woken up. You define contacts with contact channels (SMS, voice, email) and their own engagement plans with built-in delays, escalation plans that walk tiers until somebody acknowledges, and response plans that bind an impact level (1 = critical through 5 = low), a chat channel, the contacts to engage, and the runbooks to start — so one triggered response plan creates the incident record, pages the right humans, and launches the first runbook together. It also carries structured post-incident analysis against a template, which is the "learn" phase with a schema. Pair them mentally: OpsCenter = the work item; Incident Manager = the people and the clock.
SageMaker AI notebooks — the investigation surface the exam guide names
The SCS-C03 exam guide lists Amazon SageMaker AI notebooks under response plans and runbooks, which surprises people until you see what a notebook is in this context: a repeatable, reviewable investigation. The cells query CloudTrail through Athena, pull GuardDuty and Detective data through the APIs, join them against your asset inventory, and chart the result — and because the notebook is a file, it is version-controlled, peer-reviewed, parameterised for the next incident, and attachable to the incident record as exactly what the responder ran. Compare that with a responder pasting ad-hoc CLI into a terminal, where the analysis dies with the shell session. Run it from the forensics account against read-only cross-account roles so the investigation never needs write access to the environment it is examining.
Key terms: Incident response lifecycle, Runbook, Playbook, Severity classification, Systems Manager OpsCenter, Systems Manager Incident Manager
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.