Cloud incident response is not the same as on premises incident response. The console is different. The data sources are different. The legal exposure is different. The defender who runs the on premises playbook on a cloud incident loses the first 24 hours, which is when the most important decisions get made. Here is how cloud incident response actually works in 2026, and what the defender needs to have ready before the incident.
What makes cloud IR different
Three categories, in roughly that order of operational impact.
1. The speed of the data. Cloud audit logs (CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) record every API call in near real time. The defender can query them with seconds of latency. The on premises equivalent (Windows Event Log forwarding, syslog) records events with minutes to hours of latency. The cloud defender can answer what happened in the last 5 minutes in seconds. The on premises defender cannot.
2. The scope of the data. A single cloud account can produce millions of events per day. The defender has to know which events matter. The defender has to have the queries pre built. The defender has to have the dashboard ready before the incident.
3. The legal exposure. The cloud provider’s terms of service impose a cooperation obligation on the customer. The law enforcement subpoena hits the cloud provider before the customer. The customer who has not preserved the right logs in the right way has lost the evidence before the customer knew the customer needed it.
The cloud IR playbook
Five phases, roughly aligned with the NIST IR framework, adapted for cloud.
1. Preparation. The defender has the cloud audit logs centralised (CloudTrail Lake, Azure Sentinel, GCP Chronicle). The defender has the IAM baseline documented. The defender has the runbooks for the top 10 incident types. The defender has the relationship with the cloud provider support team. The preparation is what the security team does before the incident, the preparation is what the security team has to keep current, and the preparation is what the security team is going to be glad the security team did at 2 AM on a Sunday.
2. Detection and analysis. The defender uses the cloud native detection tools (GuardDuty, Security Command Center, Microsoft Defender for Cloud) to identify the suspicious activity. The defender uses the SIEM to correlate the cloud events with the endpoint events, the identity events, and the network events. The defender has the queries pre built for the top 10 incident types, and the defender is going to use the queries to identify the scope of the incident in the first 30 minutes.
3. Containment. The defender isolates the affected resources (the compromised IAM credentials, the compromised EC2 instances, the compromised S3 buckets). The defender uses the cloud native containment tools (the IAM policy deny, the security group update, the instance stop, the bucket policy update). The containment in the cloud is faster than the containment on premises, and the containment in the cloud is what the defender can do from the laptop without the physical access the defender used to need.
4. Eradication. The defender removes the attacker’s foothold (the backdoor account, the persistent IAM role, the modified Lambda function, the cron job the attacker scheduled). The eradication in the cloud is more thorough than the eradication on premises because the cloud audit log gives the defender the complete list of the changes the attacker made, and the cloud audit log gives the defender the work the defender has to undo.
5. Recovery and post incident. The defender restores the affected systems from the clean backups. The defender rotates all the credentials the attacker had access to. The defender writes the post incident report. The defender updates the runbook. The recovery is what the defender has to do to get back to normal, and the post incident is what the defender has to do to be ready for the next incident.
What the runbook should cover
The top 10 incident types the cloud defender is going to face, in roughly that order of frequency.
1. Compromised IAM credentials. The access key, the long lived credential, the SSO credential, the federated identity. The runbook stands as the credential rotation, the session invalidation, the policy review, and the activity review.
2. Compromised EC2 instance. The web server, the application server, the database server, the jump host. The runbook amounts to the instance isolation, the snapshot for forensics, the credential rotation, and the rebuild from the clean image.
3. Compromised S3 bucket. The data bucket, the backup bucket, the log bucket, the static asset bucket. The runbook stands as the access policy review, the access log review, the data classification review, and the restoration from the immutable backup.
4. Compromised Lambda function. The data processing function, the API trigger function, the scheduled function, the event driven function. The runbook amounts to the function code review, the function execution log review, the IAM role rotation, and the function redeployment.
5. Compromised container. The Kubernetes pod, the Docker container, the serverless container, the Fargate task. The runbook becomes the pod isolation, the image review, the runtime review, and the redeployment from the clean image.
6. Compromised database. The RDS instance, the DynamoDB table, the Aurora cluster, the document database. The runbook stands as the access review, the query review, the data review, and the credential rotation.
7. Compromised network. The VPC, the subnet, the security group, the network ACL. The runbook runs as the rule review, the flow log review, the traffic review, and the rule reset.
8. Compromised KMS key. The encryption key, the data key, the CMK, the customer managed key. The runbook sits as the key rotation, the key policy review, the usage review, and the re encryption of the data.
9. Compromised secret. The Secrets Manager secret, the SSM parameter, the HashiCorp Vault secret. The runbook amounts to the secret rotation, the access review, the usage review, and the cleanup of the leaked secret.
10. Compromised billing. The compromised account used to mine cryptocurrency, the compromised account used to send spam, the compromised account used to run the denial of service. The runbook runs as the billing alert, the usage review, the resource termination, and the account lockdown.
What to do this quarter
Build the centralised log pipeline. The pipeline that centralises the CloudTrail, the Azure Activity Log, the GCP Cloud Audit Logs stands as the pipeline the defender is going to use during the incident. The pipeline is what the security team has to do before the incident, the pipeline is what the security team has to budget for, and the pipeline is what the security team is going to be glad the security team did during the incident.
Write the runbook for the top 3 incident types. The runbook for the compromised IAM credentials, the compromised EC2 instance, the compromised S3 bucket. The runbook is what the security team has been avoiding, the runbook is what the security team has to do, and the runbook is what the security team is going to be glad the security team did at 2 AM on a Sunday.
Run the tabletop exercise against the cloud environment. The tabletop that runs against the cloud runs as the tabletop that is going to find the gaps the tabletop that runs against the on premises environment is going to miss. The tabletop is what the security team has been doing for years, the tabletop is what the security team is going to keep doing, and the tabletop is what the security team is going to be glad the security team did after the next incident.
The bottom line
The patterns the post covers have been showing up in production for long enough that the patterns have names, the failures, the mitigations, the gaps. The work the security team and the engineering team and the operations team are quietly doing today sits as the work that decides whether the practice the post names sits as a tool the team uses or a liability the team is paying for.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
