Incident Response · Topic 1 of 5
Incident Response Plan and Testing
Design an AWS incident response plan with phases, roles, ready access, runbooks and Incident Manager, then test it with tabletop exercises and game days.
- 5 min
- The phases are preparation, detection and analysis, containment, eradication and recovery, and post incident activity.
- Separate accounts for logs, security tooling and forensics protect evidence from a compromised workload account.
- Responders should use pre created, least privilege roles with MFA and alerts, not shared keys created during the incident.
What it is
An incident response (IR) plan is the agreed set of people, access, tools and steps used when a security event happens. On AWS the plan has to account for the shared responsibility model: AWS secures the cloud itself, and you respond to events in your accounts, workloads and data.
A good plan is built before the incident and practised, because the middle of an incident is the wrong time to find out that nobody has the right permissions.
How it works
Phases
AWS guidance and the NIST (National Institute of Standards and Technology) incident handling model share the same shape: preparation, detection and analysis, containment, eradication and recovery, and post incident activity. The exam expects you to place an action in the right phase. For example, snapshotting a disk is evidence preservation during containment, and updating a detection rule afterwards is post incident activity.
Preparation: people and process
- Roles and contacts. Name an incident commander, technical responders and a communications lead, and record who decides to isolate a system.
- Alternate contacts. Set the security alternate contact on every account, so AWS notices reach the security team and not a forgotten mailbox.
- Runbooks and playbooks. Write a short, repeatable procedure per scenario, such as exposed access key, compromised instance or public bucket.
- Support plan. Know how to reach AWS Support before you need it, and learn what incident response help AWS offers, such as the AWS Security Incident Response service.
- Classification. Define severity levels so that a low risk finding does not wake the whole company.
Preparation: access and accounts
Responders need access that is ready, tightly controlled and logged.
| Design choice | Why |
|---|---|
| Dedicated security tooling and log archive accounts | Evidence and tools survive the compromise of a workload account |
| Pre created read only investigation role in every account | Analysts can look without changing anything |
| Pre created response role with contain and snapshot permissions | Responders can act fast, but only the allowed actions |
| Break glass access with strong MFA and alerts when used | Emergency access exists, and any use is visible |
| Isolated forensic account or VPC | Disks and memory are analysed away from the production network |
Access should come through federation and short lived roles, not shared long term keys. Alert whenever the break glass role is assumed.
Preparation: tooling
Enable the detective controls first: CloudTrail with data events where needed, VPC flow logs, GuardDuty, Security Hub and Config. Pre build the automation too, such as EventBridge rules that start AWS Systems Manager (SSM) Automation runbooks. Tag resources with an owner and data classification, so responders can tell at once who owns an instance and how sensitive it is.
AWS Systems Manager Incident Manager
Incident Manager manages the human side of response. Check the current AWS documentation for its availability in your account, because the concepts below (contacts, escalation, response plans) are what the exam tests.
| Concept | Purpose |
|---|---|
| Contacts and escalation plans | Who is paged, in what order, and what happens if they do not answer |
| On call schedules | Rotation of responders |
| Response plan | Links a CloudWatch alarm or EventBridge event to a runbook and a chat channel |
| Runbook | An SSM Automation document that performs steps |
| Post incident analysis | A structured review after closing the incident |
Testing the plan
An untested plan is a guess. Use graded exercises.
- Tabletop exercise. The team talks through a scenario and checks roles, decisions and contact lists, with no systems touched.
- Game day. A scheduled, realistic simulation in a test or controlled production account, where responders use the real tools and runbooks.
- Generated findings. GuardDuty can create sample findings for the supported finding types, which exercise your alert and response pipeline without any real attack.
# AWS CLI: create sample GuardDuty findings to test alerting
aws guardduty create-sample-findings \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--finding-types "UnauthorizedAccess:EC2/SSHBruteForce"Sample findings are flagged as samples in their details, so you can tell them from real ones. Check how long detection, escalation and containment took, and fix what was slow. AWS lets you run security assessments on many of its services without prior approval, but simulated distributed denial of service (DDoS) tests follow a separate policy, so check the current AWS rules first.
After the incident
Hold a blameless review. Record the timeline, root cause and what worked, then turn the lessons into new detections, tighter permissions, an SCP or a better runbook.
What to remember for the exam
- The phases are preparation, detection and analysis, containment, eradication and recovery, and post incident activity.
- Separate accounts for logs, security tooling and forensics protect evidence from a compromised workload account.
- Responders should use pre created, least privilege roles with MFA and alerts, not shared keys created during the incident.
- Incident Manager provides contacts, escalation plans, on call schedules, response plans and runbooks.
- Runbooks are SSM Automation documents, which can be started by CloudWatch alarms and EventBridge rules.
- Test with tabletop exercises and game days, and use GuardDuty sample findings to test pipelines.
- Set the security alternate contact so AWS notifications reach the right team.
- Tags and a classification scheme tell responders who owns a resource and how sensitive it is.
When the question is "how do we make sure the team can respond quickly and safely", the answer usually combines pre provisioned least privilege roles, runbooks and a practised exercise.
Common mistakes
Creating access during the incident. Creating users or keys under pressure produces over broad permissions and leftover credentials.
Keeping logs and tools in the affected account. An attacker with administrator rights can delete both.
Skipping the exercise. Plans fail on small details, such as an on call phone number that is out of date.
Automating without limits. A runbook with broad permissions can do more harm than the incident.
Break glass credentials that are not monitored are a standing backdoor, so alert on every use and rotate them after each test.
Check yourself
Where does disk snapshot collection fit in the response phases?
In containment, as evidence preservation done before eradication destroys data.
Which Systems Manager capability handles on call paging and escalation?
Incident Manager, with contacts, escalation plans and response plans.
How can you test an alert pipeline without a real attack?
Use GuardDuty sample findings, ideally in a game day with the real runbooks.
Topic 1 of 5 in Incident Response
Test yourself on Incident Response
The full AWS SCS-C03 question bank has 858 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by AWS. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.