A cloud audit is a systematic, evidence-based review of your cloud accounts against security and compliance baselines, checking identity, configuration, data protection, logging, and network exposure to find where reality diverges from your intended posture. Done well it is not a once-a-year fire drill but a repeatable process that produces findings you can fix and evidence you can hand to an auditor. This guide lays out how to run one.
What a cloud audit covers
The shared responsibility model draws the line: the cloud provider secures the infrastructure, and you secure what you put on it, your configuration, identities, and data. A cloud audit examines your side of that line. A complete one touches several domains:
- Identity and access management (IAM), the highest-leverage area, where over-permissioned roles and stale credentials cause the most damage.
- Resource configuration, such as public storage buckets, open security groups, and unencrypted volumes.
- Data protection, meaning encryption at rest and in transit, and key management.
- Logging and monitoring, so activity is recorded and alertable.
- Network exposure, the internet-facing surface an attacker sees first.
Step 1: Scope and inventory
You cannot audit what you do not know exists, and in the cloud that is a real problem. Shadow accounts, forgotten projects, and resources spun up outside the standard process are exactly where incidents originate.
Start by enumerating every account, subscription, or project across every provider you use. Then inventory the resources within them. Provider tools give you a starting point:
# AWS: list all resources in a region via Resource Groups Tagging API
aws resourcegroupstaggingapi get-resources --region us-east-1
# List all S3 buckets and check public access settings
aws s3api list-buckets
aws s3api get-public-access-block --bucket <bucket-name>
The goal of this step is a defensible answer to "what do we have and who owns it?" Everything after depends on it.
Step 2: Audit identity and access
IAM is where audits find the most serious issues, so give it the most attention.
Check for:
- Over-privileged principals. Roles and users with wildcard permissions or broad administrative access that they do not need. Enforce least privilege.
- Unused credentials. Access keys and accounts that have not been used in 90 days are risk with no benefit. Disable and remove them.
- MFA coverage. Every human with console access, and especially every privileged account, should have MFA enforced.
- Root and break-glass accounts. The root account should have MFA, no access keys, and near-zero routine use.
- Long-lived static keys. Prefer short-lived, federated credentials over stored access keys wherever workloads support it.
Most providers offer a credential report or access analyzer that surfaces these patterns; use it as a starting point and verify by hand where the stakes are high.
Step 3: Check configuration against a benchmark
Do not invent your own definition of "secure configuration." Use an established baseline. The CIS Benchmarks for AWS, Azure, and Google Cloud are the widely accepted standard, and cloud provider tools can score your environment against them automatically.
Common high-impact findings include publicly readable storage buckets, security groups open to 0.0.0.0/0 on sensitive ports, unencrypted databases and volumes, and disabled or misconfigured logging. A Cloud Security Posture Management (CSPM) tool automates this scoring continuously, which is far more useful than a point-in-time manual sweep, because configuration drifts constantly as teams ship changes.
Step 4: Verify logging and monitoring
An audit checks not just that logs exist but that they would actually help during an incident.
Confirm that account-level activity logging is enabled everywhere (CloudTrail on AWS, Activity Logs on Azure, Cloud Audit Logs on Google Cloud), that logs are centralized and retained per your policy, and that they are protected from tampering, ideally written to an append-only or separate-account store. Then check that meaningful alerts exist: root account usage, IAM policy changes, disabled logging, and mass data access should all generate signals someone sees.
Step 5: Do not forget what runs on the cloud
A cloud audit that stops at the account boundary misses a real part of the attack surface: the workloads themselves. Containers with vulnerable base images, functions bundling outdated libraries, and application dependencies with known CVEs are cloud risk too, even though they are not "cloud configuration."
Extend the audit to include the software running in the environment. Scan container images and application dependencies for known vulnerabilities and end-of-life components. An SCA tool such as Safeguard can flag a vulnerable library baked into an image you are about to deploy, closing a gap that configuration-only audits leave open. Our software composition analysis product covers this workload dimension.
Step 6: Report, remediate, and re-audit
Findings are only valuable if they close. Rank each by exploitability and blast radius rather than by raw count, assign a clear owner and deadline, and track remediation to completion. Then treat the audit as continuous: point-in-time reviews are stale the moment a new resource is deployed, so wire the CSPM and dependency scans into an ongoing pipeline and reserve the manual deep-dive for the areas automation cannot judge.
For compliance, keep the evidence. A cloud audit against CIS or a framework like SOC 2 produces artifacts, config snapshots, access reports, remediation records, that auditors will ask for. Collecting them as you go turns the next formal audit from a scramble into an export. Our security academy walks through building this into a repeatable program.
FAQ
What is the difference between a cloud audit and a compliance audit?
A cloud audit is a technical review of your cloud environment's security posture. A compliance audit checks that posture against a specific framework such as SOC 2 or PCI-DSS. A good cloud audit produces much of the evidence a compliance audit requires.
What should I audit first?
Identity and access management. Over-permissioned roles, unused credentials, and missing MFA cause the most serious incidents, so IAM gives you the highest return on audit effort.
Should a cloud audit be manual or automated?
Both. Automated tools (CSPM, credential reports, dependency scanners) provide continuous coverage against benchmarks, while manual review handles context and judgment. Point-in-time-only manual audits go stale as soon as new resources deploy.
Does a cloud audit include the applications running in the cloud?
It should. Vulnerable container images, outdated function dependencies, and application-level CVEs are part of your cloud attack surface, so extend the audit beyond account configuration to scan the workloads themselves.