Prepare repeatable cloud incident procedures, preserve evidence, contain safely, eradicate causes, and restore trusted operation.
Define roles, access, evidence paths, automation guardrails, communications, exercises, and recovery criteria before an incident.
Triage findings, preserve volatile evidence, contain with reversible actions, determine scope and root cause, and recover with validation.
Cloud incident response is an operating capability, not a document opened after an alert. Preparation must establish authority, access, evidence locations, communication paths, automation boundaries, recovery criteria, and exercises before credentials or workloads are compromised. During an event, prefer actions that preserve evidence and remain reversible unless immediate safety or business harm requires stronger containment.
Use the sequence prepare → detect and analyze → contain → eradicate → recover → learn, but expect controlled overlap. Evidence collection can continue while containment begins. Recovery design can inform containment. Communication, decision logging, legal obligations, and business ownership run across every stage.
| Objective | Required judgment | Proof |
|---|---|---|
| 2.1 Design and test an incident response plan | Establish roles, access, evidence, playbooks, automation, communications, exercises, and recovery gates | A realistic exercise produces timed decisions, retained evidence, and corrective actions |
| 2.2 Respond to security incidents | Triage, preserve, scope, contain, eradicate, restore, and verify without unnecessary destruction | A decision log connects evidence to each action and validates trusted recovery |
Define who can declare an incident, isolate a resource, assume an emergency role, preserve data, engage legal or privacy teams, notify stakeholders, and approve return to service. Use a dedicated security tooling or incident response account where practical. Pre-create cross-account roles with tightly scoped trust, short sessions, MFA or other strong conditions for humans, and logged use. Avoid designing emergency access that depends on the same identity system or network path the incident might disable.
Inventory evidence before an event: organization CloudTrail, AWS Config history, GuardDuty and Security Hub findings, VPC and DNS records, workload logs, snapshots, backups, object versions, identity data, and application telemetry. Record retention, ownership, encryption, query access, and expected gaps. Decide which volatile evidence can be collected safely and which containment actions would destroy it.
Playbooks should encode decision points, not pretend every incident is identical. Define input evidence, allowed actions, approval gates, stop conditions, idempotency, rollback, and audit output. Automation through EventBridge, Lambda, Step Functions, Systems Manager, or service-native controls can reduce delay, but high-impact or ambiguous actions need human approval. A failed automation must be observable and must not repeatedly damage resources.
Validate the alert before accepting its narrative. Identify the affected principal, account, Region, resource, data, time window, and first reliable event. Build a timeline from authoritative sources and distinguish confirmed facts, hypotheses, and unknowns. Scope laterally: related sessions, roles, keys, resources, network paths, persistence mechanisms, accounts, Regions, and downstream systems.
Containment should reduce attacker capability while retaining investigative value. Examples include applying a quarantine security group, restricting a role or session path, disabling a specific credential, changing a resource policy, blocking a known indicator, or isolating an account through an approved organization control. Evaluate blast radius, attacker awareness, dependency failure, and rollback. Deleting a workload or broadly disabling identity can destroy evidence and interrupt critical services without removing the root cause.
Eradication removes persistence and the enabling weakness: compromised keys, unsafe trust policies, vulnerable images, malicious automation, exposed secrets, permissive network paths, or an unpatched component. Recovery uses known-good artifacts and configuration, restores required data, rotates affected trust material, reconnects dependencies deliberately, and increases monitoring. Do not declare recovery because an instance is running; validate integrity, expected behavior, access boundaries, telemetry, and business acceptance.
| Situation | Strong action | Weak shortcut |
|---|---|---|
| Suspected compromised EC2 workload | Preserve relevant evidence, apply reversible isolation, investigate identity and network activity | Terminate immediately without evidence or scope |
| Exposed access key | Determine use and blast radius, disable or restrict it, preserve events, rotate dependencies | Rotate the key and close the incident |
| Malicious role session | Restrict the role or resources, revoke where supported, investigate trust and session issuance | Delete unrelated users or widen explicit denies indefinitely |
| Public data exposure | Stop exposure safely, preserve configuration and access evidence, assess data and obligations | Make the bucket private and assume no access occurred |
| Automated containment | Use bounded, idempotent action with approval and rollback where impact is material | Let one unverified finding terminate production resources |
Keep original records immutable and work from controlled copies. Record who collected evidence, when, by what method, from which account and Region, and how integrity is checked. Cloud metadata, API records, snapshots, and centralized logs often provide stronger reconstruction than logging into a suspect system and changing it interactively. Investigation requirements vary by legal, regulatory, contractual, and organizational context; the incident team must involve the appropriate authority rather than inventing a universal chain-of-custody claim.
Correlate principal and session information carefully. A role session name, source identity, session tags, user agent, network origin, and the role's trust policy may be needed to connect an action to its issuance path. Determine whether the activity used a long-term key, web identity, SAML, service role, instance profile, task role, or chained role. Scope permissions at the time of the event, not only the repaired configuration.
GuardDuty reports credential use from an unusual location during a production deployment. The same role is used by automation, and executives request immediate deletion of the affected resources.
