3. Incident Response (14%)

Incident response is where theory meets reality — when a breach happens, the quality of your preparation determines whether you contain it in minutes or discover it months later in a news headline. Detection (Phase 2) tells you something is wrong; incident response tells you what to do about it. Think of the relationship like a hospital's monitoring equipment versus its emergency team: the heart monitor detects the crisis, but the trauma surgeons save the patient. Without a rehearsed response plan, even perfect detection is wasted — your team sees the alert, panics, makes ad-hoc decisions, and destroys forensic evidence in the process. The SCS-C03 separates IR into its own domain because AWS recognizes that designing, testing, and executing incident response requires distinct skills from detection.

The First Principle is that incident response effectiveness is determined before the incident occurs — by the quality of your plans, the readiness of your tools, the automation of your responses, and the rigor of your testing.

Scenario: At 2 AM, GuardDuty generates a HIGH-severity finding: an EC2 instance is communicating with a known command-and-control server. Your on-call engineer has no runbook, no pre-provisioned forensic tools, and no authority to isolate the instance. By the time the security team assembles at 9 AM, the attacker has exfiltrated 50GB of data and established persistence in 3 accounts.

Reflection Question: How does pre-incident preparation — runbooks, automation, pre-provisioned access — change the outcome of the scenario above from "catastrophic breach" to "contained incident"?