Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Cloud account compromise response checklist
Updated
Preserve cloud audit logs first — they can roll off. Review IAM changes and new resources, hunt cryptomining and data staging, rotate keys and roles, then evict the actor across the tenant. This page is not legal advice.
Operational guidance, last verified 7 September 2026 against CISA AA26-237A A Tale of Two SOCs: Insights From Two Red Team Assessments (25 August 2026 — a cybersecurity advisory with cloud-compromise mitigations, not a statute), NIST SP 800-61r2 Computer Security Incident Handling Guide (containment, then eradication, then recovery — guidance, not a statute), the AWS Security Incident Response Technical Guide and AWS CloudTrail security best practices (CloudTrail Event history is 90 days of management events and is not a permanent record), Microsoft's Incident response overview for Azure (aligned with NIST SP 800-61; collect Activity Logs, Entra ID logs, and NSG flow logs), and Google Cloud Audit Logs (Admin Activity default-on; Data Access opt-in). Pointers to each provider's audit-log documentation are equal and are not a ranking of clouds. This page does not start a notification clock and is not a substitute for counsel, your insurer, or a retained DFIR firm. Not legal advice.
Preserve cloud logs first — this is not a statute
Audience: the incident commander facing a compromised cloud tenant (console, API, IAM identity, or federated role), and counsel, the insurer, and DFIR on the out-of-band bridge. The we've-been-breached page on this site is the first-moves hub. The preserve-evidence page on this site is the capture order. The was-data-stolen page on this site is the access-is-not-exfiltration map. The who-to-call page on this site is the contact order. This page is the cloud-account-compromise runbook: preserve audit logs before they rotate off, hunt IAM persistence and new resources, check for cryptomining and data staging, rotate keys and roles, then evict the actor across the tenant. It does not rank cloud providers, DFIR firms, or logging products, does not name any as better than another, and does not start a notification clock.
CISA AA26-237A (25 August 2026, last verified still listed on 7 September 2026) treats cloud environments as an underestimated risk and asks organizations to establish procedures for detecting, remediating, and revoking access and refresh tokens after a cloud compromise, and to mitigate long-lived IAM user credentials. NIST SP 800-61r2 sequences containment, then eradication, then recovery — guidance, not a statute. Provider audit-log windows are finite: AWS CloudTrail Event history is 90 days of management events and is not a permanent record; Azure Activity Logs and Entra ID logs you have not exported still age out of the hot store you actually query; Google Cloud Data Access audit logs are opt-in and are the row you need for object-read exfil questions. Last verified 7 September 2026. Not legal advice.
- Preserve logs first. Copy or freeze the control-plane trail, identity audit, object-access logs, and egress or flow logs into a store the actor cannot delete, before you disable the identity that still has DeleteTrail / purge-log rights. Logs can roll off. This product does not preserve CloudTrail.
- Do not tip the actor. No in-band 'we see you', no public status page, no mass key rotation from a possibly compromised cloud identity. CISA: actors watch the response.
- IAM persistence survives a password change. New users, roles, access keys, trust policies, federation, and resource-based policies are the hunt. CISA AA26-237A: long-lived static IAM user credentials and missing token-revocation procedures are how cloud access outlives on-prem eviction.
- The credential-compromise-checklist page on this site is the revoke-rotate-hunt for the identity that minted the cloud keys. The repository-compromise-checklist page on this site is the access-and-token audit, planted-commit hunt, and secret-rotation runbook. The cicd-compromise-checklist page on this site is the freeze-and-audit runbook when a pipeline minted cloud keys.
- This page does not rank clouds, does not interpret YOUR policy, does not start a notification clock, and is not legal advice.
What to do now
Walk top to bottom. Unknowns belong on the list. Last verified 7 September 2026. Not legal advice.
- Declare the incident. Name one commander. Open an out-of-band bridge the actor cannot see (phone, a clean conference). The who-to-call page on this site is the contact order.
- Preserve cloud logs now: control-plane audit, identity sign-in and audit, object-access or data-access logs if they exist, flow or egress logs, DNS, and billing. Copy them to a store the compromised identity cannot write. Do not disable logging to 'reduce noise.' The preserve-evidence page on this site is the capture list.
- Inventory IAM changes since first-access (or since the oldest log you still have): new users, roles, groups, policies, access keys, service principals, workload identities, federation, and trust relationships. Unexplained items are persistence until proven otherwise.
- Inventory new resources: compute, storage, functions, snapshots, images, queues, secrets, and regions or subscriptions you did not know you had. Cryptomining and staging often look like a new instance, a new bucket, or a new region.
- Rotate keys, console passwords, service-principal secrets, and role credentials at the issuer, then revoke the old values. A disabled user with a live access key is not containment. This product does not rotate cloud keys.
- Evict the actor across the tenant: revoke sessions and tokens, disable unexplained identities, detach unexplained policies, close unexplained security groups and firewall rules, and lock the log store. This product does not evict an actor.
- Use egress and flow logs, plus object-access logs, to ask whether data left. Access is not exfiltration. The was-data-stolen page on this site is that map. Missing egress logs are a gap, not a finding of no theft.
- Page counsel and the insurer if YOUR plan or policy requires prompt notice. A compromised cloud tenant can still be a notification question. This page does not start a clock.
Preserve-cloud-logs-first — they roll off
Cloud audit logs are the memory of the control plane. Unlike RAM on a laptop, they do not die when you power off a VM — they die when retention expires, when a trail is deleted, when Data Access was never enabled, or when the actor empties the bucket. AWS CloudTrail security best practices state that Event history is 90 days of management events, is not a permanent record, and does not cover every event type; a trail to object storage is the ongoing record, and log-file integrity validation is what lets you assert the file has not changed. Azure's incident-response overview treats comprehensive logging (Entra ID, Activity Logs, NSG flow logs, resource diagnostics) as essential for timelines, and tells responders to export evidence to immutable storage. Google Cloud Audit Logs answer 'who did what, where, and when': Admin Activity is default-on; Data Access is opt-in and is the row that records reads of user data. Last verified 7 September 2026. Not legal advice.
| Log class | Why it rolls off | What 'preserved' looks like |
|---|---|---|
| Control-plane audit (API / admin activity) | Console Event history and default activity logs are a hot window, not an archive. A deleted trail, a disabled diagnostic setting, or a 90-day rollover is how the window disappears. | Exported copy in a store the compromised identity cannot delete, with the account or subscription, region, and retention you still hold recorded. Integrity validation or hashes if YOUR procedure names them. |
| Identity sign-in and audit | IdP and cloud-identity sign-in logs rotate on THEIR retention. Token-issue and privilege-change rows are the ones you need to evict the actor later. | Sign-in, audit, token issue, role assignment, and federation-change export covering first-access through now. CISA AA26-237A: procedures for remediating and revoking access and refresh tokens. |
| Object-access / data-access | Often opt-in and high volume. If it was never enabled, you cannot reconstruct GetObject / blob-read / object-get after the fact. That gap is a gap. | Whatever data-access log exists, exported. If it does not exist, write that down. The was-data-stolen page on this site treats missing object-access as a limit, not a clean bill. |
| Egress / flow / DNS | VPC or VNet flow logs, firewall allows and denies, DNS query logs, and NAT gateway records sample, rotate, and miss cloud-to-cloud copies on a path you did not instrument. | Flow and DNS for the window, plus any packet capture you already had. Absence of a flow is not proof of no theft if the path was not logged. |
| Billing, config, snapshots | Billing is a delayed signal of cryptomining and unexpected regions. Config history and snapshots disappear if the actor deletes the resource first. | Billing export, config timeline, and snapshots of volumes you can still snapshot. AWS IR guidance: copy logs, resources, and snapshots into a dedicated response account. This product does not take those snapshots. |
IAM and persistence hunt
Containment for a compromised cloud tenant is not 'reset the console password and hope.' CISA AA26-237A records long-lived static IAM user credentials that never expired, missing Conditional Access for workload identities, and the absence of a token-revocation procedure as the reasons cloud access outlived on-prem eviction. Walk the rows. Unexplained is persistence until an owner claims it. Last verified 7 September 2026. Not legal advice.
| Hunt | What 'done' looks like | If you skip it |
|---|---|---|
| Users, groups, and console identities | Every human and break-glass identity created or modified in the window is listed, owner-claimed, or disabled. MFA state recorded. Recovery emails and phones checked. | The actor's console user stays live after you rotate the password you know about. |
| Access keys, service principals, workload identities | Every access key, client secret, certificate, and workload identity created or last-used in the window is inventoried. Unused and unexplained keys disabled. CISA AA26-237A: identify and audit existing access keys; disable unused ones; mitigate long-lived IAM user credentials. | A disabled user with a live access key is still the actor. This product does not rotate cloud keys. |
| Roles, policies, and trust | New roles, inline and attached policies, resource-based policies, and trust relationships (including federation and cross-account or cross-tenant trusts) are listed. Unexplained privilege is detached. | A trust the actor planted still assumes into the tenant after you evict the user. |
| Federation, SSO, and tokens | SSO apps, SAML / OIDC trusts, refresh tokens, and API tokens issued in the window are revoked. CISA AA26-237A: establish procedures for detecting, remediating, and revoking access and refresh tokens in a cloud compromise. | On-prem eviction with a live cloud refresh token is how the actor walks back in. |
| Logging and detection tampering | Trails, diagnostic settings, sinks, and alert rules created, stopped, or deleted in the window are listed. Logging that was turned off is turned back on after the export exists. | You hunt in a trail the actor already emptied. Preserve first, then lock the log store. |
New resources, cryptomining, and data staging
A compromised cloud tenant is a place the actor can run compute and park data. Cryptomining is unexpected compute, often in a region you do not use, billed to you. Data staging is a bucket, share, snapshot, or queue the actor filled before egress. Neither is a notification determination. Last verified 7 September 2026. Not legal advice.
| Look for | What it can mean | Limit |
|---|---|---|
| New compute, functions, containers, or GPU instances | Persistence, cryptomining, or a build box for the next stage. Check regions, subscriptions, and projects you do not normally use. Billing spikes lag the launch. | A legitimate autoscaling event looks similar. Owner-claim it. This product does not detect cryptomining. |
| New storage, snapshots, images, and queues | Staging for exfiltration, or a copy of a volume the actor imaged. Snapshots in another account or region are a copy you may still hold. | A snapshot is not proof the data left the cloud. Cloud-to-cloud copy can skip YOUR internet egress. The was-data-stolen page on this site is that map. |
| New security groups, firewall rules, public IPs, and peering | An ingress or egress path the actor opened. 0.0.0.0/0 on a port you did not need is a finding to close after you have the log of who opened it. | Closing the rule before you export the change log is how you lose the who. Preserve, then lock down. |
| New secrets, keys, and KMS grants | A key the actor minted to keep access after you rotate the one you know. Grants that let another account decrypt. | Deleting the key before you know what it encrypted is how recovery dies. Rotate, then revoke. Do not shred the only copy of production data to feel busy. |
Provider audit-log pointers — not a ranking
Each major cloud publishes its own audit-log and incident-response documentation. The rows below are pointers so a responder can find the current doc. They are not a comparison, not a recommendation of which cloud to run, and not a finding that one provider's log is 'enough.' Use the doc for the cloud you actually run. If you run more than one, do the hunt in each. Last verified 7 September 2026. Not legal advice.
- The order of the rows is alphabetical by common short name, not a ranking. This page does not rank clouds.
- Follow the current provider doc, not a screenshot of this table. Last verified 7 September 2026 is how you can see we have not re-checked yet.
- CISA's Cloud Security Technical Reference Architecture (version 2, 21 June 2022) remains listed on CISA.gov and is marked archived as of 7 September 2026 — historical CSPM and shared-responsibility guidance, not the current cloud-compromise advisory. AA26-237A is the current CISA cloud-compromise pointer this page cites.
| Provider doc (pointer) | What it is | Limit this page will not paper over |
|---|---|---|
| AWS Security Incident Response Technical Guide, and CloudTrail security best practices | AWS's customer IR guide (prepare, operate, post-incident) and CloudTrail's own security best practices. Event history: 90 days of management events, not a permanent record, not every event type. A trail to object storage is the ongoing record. Log-file integrity validation is the forensic assert. | Management events without data events will not show object-level reads. This page does not operate YOUR trail. This product does not preserve CloudTrail. |
| Microsoft — Incident response overview for Azure | Azure-specific IR considerations aligned with NIST SP 800-61 phases. Collect Microsoft Entra ID sign-in and audit logs, Azure Activity Logs, NSG flow logs, and resource diagnostic logs. Preserve evidence: VM snapshots, immutable storage, packet capture, memory dumps. | Activity Logs are control plane. Object-level reads live in resource diagnostics you may never have enabled. This product does not snapshot an Azure VM. |
| Google Cloud Audit Logs overview | Admin Activity, Data Access, System Event, and Policy Denied audit logs that answer who did what, where, and when. Admin Activity is default-on. Data Access is opt-in and high volume; it is the row that records reads of user-provided data. | If Data Access was never enabled, you cannot reconstruct object reads after the fact. Write the gap down. This product does not enable Data Access for you. |
Egress logs and whether data left
A compromised cloud tenant is not, by itself, a finding that data was stolen. Access is not exfiltration. Egress logs, flow logs, and object-access logs are how you ask whether a copy left a boundary you can name. Cloud-to-cloud copies, a snapshot shared to another account, and a path you did not instrument will not appear on the internet egress you watch. Missing logs are a gap, not proof of no theft. The was-data-stolen page on this site is the evidence-to-conclusion map. Counsel maps YOUR notification duty. Last verified 7 September 2026. Not legal advice.
- Export flow, firewall, NAT, and DNS logs for the window before they rotate. Correlate with IAM and object-access events.
- A GetObject or blob-read is access. Bytes leaving to an actor-controlled prefix, another account, or a region you do not use is the later claim.
- This product does not determine exfiltration and does not start a notification clock.
Evict the actor and lock down
NIST SP 800-61r2 sequences containment, then eradication, then recovery. In a cloud tenant, containment is isolating the path and freezing logs; eradication is revoking the identities, keys, trusts, and resources the actor planted; recovery is returning production to a known-good state without restoring the persistence. CISA AA26-237A: revoke access and refresh tokens; disable unused keys; do not leave long-lived IAM user credentials as the standing access. Last verified 7 September 2026. Not legal advice.
- Revoke sessions, refresh tokens, and API tokens for every identity in the blast radius, not only the one you first saw. This product does not evict an actor.
- Disable unexplained users, keys, and service principals. Detach unexplained policies and trusts. Close unexplained network openings.
- Lock the log store and the billing account so the actor cannot delete the evidence or spin new spend. Then recover from known-good infrastructure-as-code or images — after the forensic copy exists.
- Do not wipe the tenant to 'start clean' before the export exists. Isolate, do not destroy. The never-delete-after-breach page on this site is that prohibition list.
Where this shows up in ShipReady Metrics
The signed-in app does not preserve CloudTrail, Azure Activity Logs, or Cloud Audit Logs, does not rotate cloud keys, does not snapshot volumes, and does not evict an actor from a tenant. It does not rank clouds. Cloud Health is a posture score (Cost Efficiency, Security Posture, Reliability, Architecture Maturity) that lights up when a cloud connector — AWS, Azure, GCP, or Supabase — syncs; it is not an incident-response runbook and not a detector that YOUR account is compromised. Security findings is where open vulnerabilities and connector-ingested cloud and code-scanning findings land. The cyber risk register lives under Security — a risk you can record, not a cloud-compromise detector. If you already have a session: signed-in app → Compliance → CRA reporting tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness for findings the org has classified as CRA-in-scope. That ladder is not a cloud-account runbook, it does not start a clock for you, and it is not a determination that CRA applies. A named human still submits. None of those surfaces preserves a trail or rotates a key.
Primary sources (last verified 7 September 2026)
Every operational claim on this page is taken from one of these. If a later revision of a source changes the advice, the date above is how you can see we have not re-checked yet.
CISA AA26-237A, A Tale of Two SOCs: Insights From Two Red Team Assessments (25 August 2026), remains the current CISA advisory this page cites for cloud-compromise mitigations — revoke access and refresh tokens, mitigate long-lived IAM user credentials, identify and audit access keys, monitor sign-in logs — a cybersecurity advisory, not a statute, last verified still current on 7 September 2026. CISA's Cloud Security Technical Reference Architecture (version 2, 21 June 2022) remains listed and is marked archived as of 7 September 2026; it is historical shared-responsibility and CSPM guidance, not the current compromise advisory. NIST SP 800-61r2 remains the current final Computer Security Incident Handling Guide this cluster cites for containment then eradication then recovery. AWS Security Incident Response Technical Guide is AWS's customer IR overview; AWS CloudTrail security best practices document the 90-day Event history limit, the trail-to-object-storage ongoing record, and log-file integrity validation. Microsoft, Incident response overview for Azure (article updated 20 July 2026, last verified 7 September 2026), is Azure-specific IR aligned with NIST SP 800-61, including Activity Logs, Entra ID logs, NSG flow logs, and evidence preservation. Google Cloud Audit Logs overview is the customer audit-log model (Admin Activity default-on; Data Access opt-in). Those three provider docs are pointers, not a ranking. CISA's Federal Government Cybersecurity Incident and Vulnerability Response Playbooks remain the general IR playbook this cluster cites.
Frequently asked questions
What should we do first if a cloud account is compromised?
Preserve cloud audit logs first — control-plane, identity, object-access, and egress — because those windows roll off and the actor may delete the trail. Then hunt IAM persistence and new resources, check for cryptomining and data staging, rotate keys and roles at the issuer, and evict the actor across the tenant. Do not tip the actor. CISA AA26-237A, NIST SP 800-61r2, and the provider audit-log docs in the resources are the primary sources. Not legal advice.
Why preserve logs before rotating keys?
Because the identity you are about to disable may be the only one that can still read or export the trail, and because CloudTrail Event history, Azure Activity Logs, and opt-in Data Access logs expire or were never on. AWS CloudTrail security best practices: Event history is 90 days of management events and is not a permanent record. Copy the logs to a store the compromised identity cannot delete, then rotate and revoke. This product does not preserve CloudTrail. Not legal advice.
Does ShipReady Metrics preserve CloudTrail, rotate cloud keys, or evict an actor?
No. The signed-in app does not preserve CloudTrail, Azure Activity Logs, or Cloud Audit Logs, does not rotate cloud keys, does not snapshot volumes, and does not evict an actor. It does have a Cloud Health posture score (Cost Efficiency, Security Posture, Reliability, Architecture Maturity) that lights up when a cloud connector syncs, Security findings ingest from connected cloud and code-scanning sources, a cyber risk register, and Compliance → CRA reporting (the Article 14 24-hour / 72-hour / 14-day ladder from recorded awareness). None of those is a cloud-compromise runbook. Not legal advice.
Is this legal advice?
No. It is operational guidance distilled from CISA AA26-237A, NIST SP 800-61r2, the AWS Security Incident Response Technical Guide and CloudTrail security best practices, Microsoft's Incident response overview for Azure, and Google Cloud Audit Logs. Whether a notification duty has started, whether a cloud GetObject was 'unauthorised access' under a named statute, and what you may say externally are questions for counsel on YOUR facts. This page does not rank clouds and does not start a notification clock.
Do we have to pick a cloud to follow this checklist?
No. The checklist is provider-neutral. AWS CloudTrail, Azure Activity Logs, and Google Cloud Audit Logs are pointers to each provider's current audit-log documentation so you can find the export path you actually have. The order of those pointers is not a ranking. If you run more than one cloud, do the preserve-hunt-rotate-evict loop in each tenant. Not legal advice.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.