Cloud Breach Response Checklist
A leaked key, an abused role, crypto-miners in regions you never use. A provider-neutral checklist with AWS, Azure and Google Cloud examples: contain the identity, revoke live sessions, snapshot before you terminate, preserve the logs, sweep every region and decide on data access.
Template & sample only — a structured starting point with sample content, not legal, audit, certification or investment advice.Customise it with your own details for free; exporting the generated document is part of Pro.
A provider-neutral response checklist for a cloud account compromise — leaked keys, abused roles, crypto-mining, data taken from storage — with AWS, Azure and Google Cloud examples for every step. Work top to bottom: declare, contain the identity, preserve evidence, sweep every region, decide on data access, recover and notify. Mark each step, add owners and notes, and the page builds an incident record you can hand to counsel and the post-incident review.
Your context
1. Declare and organise (first hour)
Get the clock, the people and the provider moving before anyone starts deleting things.
Declare an incident, name an incident commander and record the time you became awareNIST SP 800-61r3material
List every cloud account, subscription and project the compromised identity could reach
Open an out-of-band incident channel; assume the attacker can read cloud-hosted chat and ticket tools tied to the compromised tenant
Open a security case with the cloud provider support team
Brief legal counsel and the insurer (if you have cyber cover) early
2. Contain the identity
Take the attacker's access away without destroying the evidence of what they did.
Disable the exposed credential: deactivate the AWS access key, remove the Azure app secret or certificate, disable the Google Cloud service-account keymaterial
Revoke sessions the attacker already holds, not just the keyAWS IAMmaterial
Add a temporary guardrail above the account: an organisation-level deny (AWS SCP, Azure Policy deny, Google Cloud organisation policy) for the regions or services you never use
Secure the top-level accounts: AWS root user, Azure Global Administrators, Google Cloud organisation admins — MFA confirmed, recent activity reviewedmaterial
Rotate in the safe order: create the replacement, verify it works, update every consumer, then delete the old credential
3. Preserve evidence
Cloud evidence ages out on a timer and disappears when you terminate things. Capture first, clean up second.
Export the control-plane logs for the full exposure window to protected storage nowNIST SP 800-61r3material
Snapshot disks of attacker-created or compromised instances before stopping or terminating themmaterial
Isolate instead of terminate: move compromised instances to a quarantine security group / NSG / firewall rule that blocks all traffic except your forensics access
Capture resource configuration as it is now: IAM policies, trust policies, bucket and container policies, network rules
Record hashes, who copied what and when, and where it is stored (chain of custody)ISO/IEC 27037
4. Find everything the attacker created — in every region
Crypto-miners and persistence are deliberately placed where you do not look.
Inventory compute in ALL regions, including ones you never use: instances, spot requests, launch templates, auto-scaling groups, containers, serverless functionsmaterial
Find identities and credentials the attacker created: IAM users, access keys, roles, policies; Azure app registrations, service principals and added secrets; Google Cloud service accounts and keysmaterial
Check for external trust: new cross-account role trusts, identity providers, federated credentials, or resource policies granting another account access
Review billing for anomalies: spend by region and service, quota-increase requests, marketplace subscriptions, reserved or savings commitments you did not buy
Check the organisation level: new accounts or subscriptions, changes to the organisation, disabled logging or security services
5. Decide whether data was accessed
The notification decision turns on this. Be honest about what your logs can and cannot prove.
Check object-level access to storage: S3 server access logs or CloudTrail data events, Azure Storage diagnostic logs, Google Cloud Storage Data Access audit logsmaterial
Check for exposure changes: buckets or containers made public, snapshots or images shared to other accounts, database snapshots exported
Check reads of secrets stores and key services: AWS Secrets Manager and KMS, Azure Key Vault, Google Cloud Secret Manager and KMS
Classify any data that may have been accessed (personal data, customer data, regulated data) and hand counsel a written summary
6. Eradicate and recover
Remove attacker resources and identities after evidence is captured, and confirm in every region that nothing restarts
Rotate every secret reachable from the compromised identity: other keys, database passwords, API tokens in environment variables or parameter storesmaterial
Rebuild changed resources from known-good infrastructure-as-code rather than editing them back by hand
Ask the provider about adjusting charges for fraudulent usage, with the case number and evidence of remediation
7. Notify, learn and harden
Counsel decides notification duties (regulators, customers, contracts) against the recorded awareness timeGDPR Art. 33material
Close the logging gaps this incident exposed (data events, flow logs, longer retention, central log archive)
Prevent the repeat: secret scanning with push protection, no long-lived keys for humans, region deny guardrails, cost anomaly alerts
Hold a blameless post-incident review within two weeks and track actions to closureNIST CSF 2.0 ID.IM
What this template gives you
- Seven phases: declare and organise, contain the identity, preserve evidence, find everything in every region, decide on data access, eradicate and recover, notify and harden.
- Each step is provider-neutral, with the AWS, Azure and Google Cloud equivalent named in the guidance.
- Covers the steps most often missed: sessions that outlive a disabled key, logs that age out after 90 days, instances terminated before anyone took a snapshot, and miners in unused regions.
- Sample values show a fictional company mid-incident. Replace them with your own and the page builds an incident record for counsel and the post-incident review.
Frequently asked questions
What should I do first when a cloud account is compromised?
Declare an incident and record the time you became aware, then take the attacker's access away without destroying evidence: deactivate the exposed key, revoke sessions they already hold, and secure the root or global administrator accounts. Open a security case with the provider. Only then start terminating resources, and only after you have snapshots and an export of the logs.
Is disabling the access key enough?
Often not. On AWS, temporary credentials the attacker created with the key can keep working after the key is deactivated, so attach an explicit deny policy to the user and use "Revoke active sessions" on any role they used. On Azure, revoking sign-in sessions stops refresh tokens, but access tokens already issued can work until they expire. Always check the logs after containment to confirm the calls stopped.
How long do cloud providers keep audit logs by default?
Without extra configuration, AWS CloudTrail event history covers 90 days of management events, Azure Activity Log is kept for 90 days, and Google Cloud keeps Admin Activity audit logs for 400 days but Data Access audit logs (which are mostly off by default) for 30 days. Object-level storage access logs are off by default on all three. Use the Cloud Logging Gap Checker to see what that means for your next incident.
Why check regions we never use?
Attackers who get a working key commonly launch crypto-mining instances in regions the owner does not watch, because nobody looks at the console there and quota is often available. Inventory every enabled region by script, and consider an organisation-level policy that denies the regions you do not use.
Is this a finished document I can rely on?
No. Every tool in this suite is a template with sample content. It gives you a structured, editable starting point and generates a document from your own answers, but it is not legal, audit, certification, investment or professional advice. Review and adapt the output, and have it checked by the appropriate specialist before you rely on it.
Who can use it?
Anyone. Using it and customising it with your own details is free, and your work is saved in your own browser. Exporting the generated document (Word, PDF, Markdown, CSV) is part of any PlayCISO paid plan.
More free security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.