The short answer
Cloud incident response depends almost entirely on preparation: centralised immutable logging, break-glass access that does not rely on the compromised environment, and rehearsed runbooks. When an incident occurs, contain first by revoking credentials and isolating resources, preserve evidence through snapshots before terminating anything, then investigate.
Key takeaways
- Logs must be centralised and immutable before the incident, not after
- Contain by revoking sessions, not only by deleting keys
- Snapshot before you terminate — terminated instances take evidence with them
- A runbook nobody has rehearsed will not be followed under pressure
Part of our guide to Cloud security: the configuration is the attack surface.
Cloud incident response differs from traditional response in one decisive way: nearly everything depends on decisions made before the incident. You cannot retrieve logs you never enabled, and you cannot investigate an instance somebody already terminated.
Prepare these four things
Centralised, immutable logging. Audit logs from every account written to a dedicated account the source accounts cannot modify. If an attacker with administrative access can delete the logs, you have no reliable record of what happened. Set retention deliberately — many investigations need to look back further than thirty days.
Break-glass access. A path into the environment that does not depend on the systems that may be compromised. If your only administrative route is federated through an identity provider and that provider is the thing under attack, you are locked out during the incident. Store the credentials securely offline, alert loudly on their use, and test them periodically.
Runbooks. Written procedures for the common cases: compromised credential, exposed data store, suspicious compute, ransomware. Under pressure people follow what is written, and only if they have seen it before.
Contact paths. Who declares an incident, who talks to customers, who talks to regulators, and what the deadlines are. Several regimes require notification within tight windows, and working that out during the event is too late.
Contain before you investigate
The instinct is to understand what happened. Contain first.
For a compromised credential: attach a deny-all policy to the principal, then revoke active sessions. Deleting an access key does not invalidate temporary credentials already issued from it — sessions can remain valid for hours. Revoke by session policy or by rotating the underlying role trust.
For a compromised instance: isolate it with a restrictive security group rather than terminating it. Remove it from load balancer targets. Keep it running — memory contents and running processes are evidence.
For exposed data: close the exposure, then determine from access logs whether anything was actually retrieved. This distinction usually drives the notification obligation, and it is only answerable if object-level logging was enabled beforehand.
Preserve evidence
Before changing or terminating anything: snapshot volumes, capture memory if you can, and export the relevant log ranges to somewhere outside the affected account.
The common and irreversible mistake is terminating a compromised instance to stop the bleeding. It stops the bleeding and destroys the evidence, and the question that follows — what did they access — becomes unanswerable.
Investigate
Work from the audit log. Establish the initial access, what the credential or instance did, whether privilege was escalated, whether persistence was established, and what data was reachable versus actually accessed.
Check for persistence specifically: new IAM users or roles, modified trust policies, new access keys on existing users, unfamiliar Lambda functions or scheduled tasks. Attackers who gain administrative access commonly create a second way back in before doing anything noisy.
Afterwards
Rotate every credential that could plausibly have been exposed, not only the one you know about. Close the initial access path. Then add the guardrail that would have prevented it — because an incident you learn nothing structural from is an incident you will have again.
Rehearse. A tabletop exercise once or twice a year finds the gaps cheaply: the runbook that references a decommissioned system, the on-call engineer without the permissions to contain anything, the break-glass credential nobody can locate.
