What Is a Cloud Security Audit?
A cloud security audit is a structured assessment of cloud controls, configurations, identities, processes, and evidence against defined criteria. Its goal is to determine whether controls are appropriately designed, implemented, and operating as intended, and whether the organization can support those conclusions with evidence. Those criteria may come from internal policy, the CIS Benchmarks, the NIST Cybersecurity Framework, the CSA Cloud Controls Matrix, contractual obligations, or a formal assurance program such as SOC 2 or ISO 27001. An internal audit can tell you how ready you are and where the gaps sit, but a formal compliance opinion, attestation, or certification depends on the applicable program and a qualified external assessor. In short, an audit answers three questions: are the right controls in place, do they work, and can you prove it.
Read More: What Is a Cloud Security Scan?
Cloud Security Audit vs Cloud Security Scan: What Is the Difference?
These terms get used interchangeably, but they are different, and the distinction keeps a program honest. A cloud security scan is an automated technical assessment: a tool connects to your environment and detects vulnerabilities, misconfigurations, and exposed resources, often in minutes. A cloud security audit is the broader assurance process. It can combine automated evidence collection and configuration assessment with documentation review, interviews, sampling, control testing, walkthroughs, and auditor judgment. The scan is one input to the audit, not a replacement for it. Automated evidence tooling can organize and collect evidence, but it does not issue a compliance opinion on its own. Put simply, the scan tells you what is exposed right now, and the audit tells you whether your controls and processes are sound enough to keep it that way.
Who Should Perform a Cloud Security Audit?
The choice comes down to the assurance objective, the independence you need, and the skills you have in-house.
- Run it internally for self-improvement and audit readiness. Your own team knows the environment deeply, an internal review costs less, and internal audits remain a legitimate part of a management system such as ISO 27001.
- Engage an external assessor when the objective requires independent attestation, certification, or customer and regulatory independence. A SOC 2 report is produced through an independent CPA examination, and ISO 27001 certification involves an accredited certification process.
- Match the assessor model to the framework. The frameworks do not share one universal external-audit model, so confirm what the specific program requires rather than assuming every standard works the same way.
- Combine both in practice. Many teams run frequent internal reviews to stay ready and bring in a third party for the formal, attestable audit.
How Do You Prepare for a Cloud Security Audit?
Preparation decides whether an audit runs smoothly or drags. Handle these before you start.
- Define the scope and objectives, deciding which accounts, services, and data are in scope and whether the audit targets a specific program or a general posture review.
- Choose the criteria to audit against, whether that is a compliance program’s requirements or a self-selected baseline such as the CIS Benchmarks or the NIST Cybersecurity Framework.
- Engage stakeholders early, bringing in the IT, security, and management owners who can grant access and answer questions, plus legal where a customer or regulator is involved.
- Clarify the shared responsibility boundary for each service model, reviewing your providers’ own attestations so you audit your controls and not the parts the provider already assures.
- Gather documentation and evidence up front so the audit reviews reality rather than waiting on requests.
Cloud Security Audit Checklist at a Glance
Here is the full checklist in one view. Each domain is expanded below, with the specific controls to verify and the evidence that proves they work.
| Audit domain | What to verify | Evidence |
|---|---|---|
| Asset inventory and scope | Every account, resource, and owner is known and in scope | Inventory export, hierarchy, diagrams |
| Identity and access | Least privilege, MFA, human and workload identities | IAM exports, access-review records |
| Secrets and credentials | No hardcoded or stale static secrets | Secret-store inventory, key-age report |
| Data protection | Encryption mode, key ownership, data lifecycle | Key policies, classification, retention |
| Logging and detection | Coverage, routing, tested alerts, tamper resistance | Coverage map, alert tests, triage tickets |
| Network security | No broad public exposure, segmentation, egress control | Firewall exports, segmentation diagram |
| Configuration and posture | Baseline, drift, exceptions, guardrails | Posture report, exception register |
| Change management and IaC | Reviewed, controlled, detectable changes | IaC repos, approvals, drift reports |
| Vulnerability management | Prioritized by exposure, patched to SLA | Scan reports, SLA metrics, retest |
| Workloads and containers | Hardened VMs, containers, Kubernetes, serverless | RBAC exports, container scans |
| Backup and recovery | Immutable, isolated, tested restores | Backup policy, restore-test result |
| Incident response | Cloud-specific, tested playbooks | IR plan, tabletop records |
| Third-party assurance | Provider and vendor controls confirmed | SOC/ISO reports, responsibility matrix |
| Data classification and governance | Ownership, classification, policy traceability | Owner matrix, risk and exception registers |
The Cloud Security Audit Checklist: What to Review
Work through each domain in turn, confirm the controls actually operate, and collect the evidence that proves it. The order matters: scope first, because an incomplete inventory invalidates everything after it.
1. Cloud Asset Inventory and Audit Scope
Scope comes first, because an audit of an incomplete inventory is an incomplete audit. Enumerate every AWS account, Azure subscription and management group, and Google Cloud organization, folder, and project in scope, along with regions, VPCs and VNets, compute, containers and registries, Kubernetes clusters, serverless services, databases, storage, public IPs, DNS zones, secret stores, and identity directories. Confirm each resource has an owner, that in-scope and out-of-scope decisions are documented, that internet-facing resources and regulated-data locations are known, and that architecture diagrams match reality. Pay attention to old, test, and orphaned resources, which are exactly what attackers find first. Evidence to collect: an asset-inventory export, the account and project hierarchy, network diagrams, a public-facing asset list, an ownership and tag report, and the in-scope rationale.
2. Identity and Access Management (IAM)
Identity is where most cloud incidents escalate, so audit both human and workload identities. For people, check least privilege, enforced MFA, privileged and root or global-admin accounts, SSO and federation, the joiner-mover-leaver process, dormant accounts, session duration, and emergency break-glass identities. For workloads, review AWS roles, Azure managed identities and service principals, and Google Cloud service accounts for long-lived keys, excessive permissions, cross-account or cross-tenant trust, and service accounts owned by teams that have left. Do not settle for a policy that says reviews happen; ask for evidence of the last completed access review, who ran it, and which access it removed. Evidence to collect: IAM exports, a privileged and workload-identity inventory, an MFA report, federation and trust configuration, the break-glass procedure, and completed access-review records with deprovisioning samples.
3. Secrets and Credential Management
Static secrets are durable keys attackers reuse, so audit how yours are stored and rotated. Look for hardcoded passwords and API keys in source code, container images, and CI/CD pipelines, plus cloud access keys, service-account keys, and personal developer credentials that outlive their purpose. Confirm a centralized secrets manager is used where appropriate, that short-lived, federated, or workload identities are preferred over static keys, that rotation and lifecycle exist, that secrets are not written to logs, and that repository and image scanning catches committed secrets. Verify access to secrets follows least privilege and that emergency rotation is documented. Evidence to collect: a secret-store inventory, a key and credential age report, a static-access-key inventory, leaked-secret scan results, the rotation policy with samples, and pipeline secret configuration.
4. Data Protection and Encryption
Because many cloud services encrypt by default, the audit should verify that the encryption mode, key ownership, and key policy meet your requirements, not simply that an encrypted flag is set. Confirm encryption at rest for storage, databases, snapshots, and backups, TLS in transit on sensitive paths, and that customer-managed keys are used where policy requires, with key administrators separated from key users and no broad cross-account key access. Extend the review to the data lifecycle: classification, residency, retention, and secure deletion, plus data-loss-prevention controls where required. Evidence to collect: a data-classification scheme, a data-location inventory, a key inventory and key policies, rotation records, TLS configuration exports, retention schedules, and deletion-policy evidence.
5. Logging, Monitoring, Detection, and Audit Trails
Logs enabled is not the same as detection working, so audit the whole chain. Confirm coverage of control-plane, identity, network, data, and workload logs; centralization to an approved destination; protection so monitored identities cannot alter or delete records; and retention that meets policy. Then check detection logic mapped to high-risk events such as privilege escalation, new public storage, root or global-admin use, logging being disabled, and key-policy or trust-policy changes; routing so each alert reaches a named owner; and testing so you know the alerts actually fire. A log nobody can alter and nobody reads is not much of a control. Evidence to collect: a log-source coverage map, retention settings, the central log destination, sample alert rules, test-alert records, triage tickets, and the access policy for the log archive.
6. Network Security
Examine what the outside world can reach and how far an intruder could move. Review security groups, Azure Network Security Groups, and firewall rules for anything open to 0.0.0.0/0 on management ports like SSH (22) or RDP (3389), and confirm databases and caches are not publicly reachable. Administrative access should not be broadly internet-exposed; it should use an approved controlled-access method such as a bastion, VPN, AWS Systems Manager Session Manager, Azure Bastion, just-in-time access, a zero-trust network access (ZTNA) service, or an identity-aware proxy. Check east-west segmentation between production, development, sensitive-data tiers, and management planes, and review egress controls that slow exfiltration. Evidence to collect: firewall and security-group exports, a segmentation diagram, an internet-facing endpoint inventory, egress policy, and evidence of the approved admin-access method.
7. Configuration and Posture Management
Misconfiguration is a leading source of cloud exposure, so audit configuration against a named baseline rather than by feel. Measure settings for storage, compute, identity, and network services against the CIS Benchmarks or provider standards, and flag drift from the approved state; our guide to common cloud misconfigurations lists the specific settings. Ask which baseline applies, how exceptions are recorded and whether they are time-limited, whether findings map to owners, and whether console or manual changes are detected. Confirm organization-level guardrails such as AWS service control policies, Azure Policy, and Google Organization Policy are in place, while remembering that automated posture tooling does not catch everything. Evidence to collect: a posture report with the benchmark version, an exception register, control and policy assignments, drift findings, and samples of remediated findings.
8. Change Management, Infrastructure as Code, and CI/CD
How changes reach production decides whether your other controls hold. Audit whether infrastructure changes are defined as code where practical, with pull-request review, approval requirements, protected branches, and security scanning of Infrastructure as Code and policy-as-code in the pipeline. Check deployment identities, secrets handling in pipelines, rollback capability, and how emergency or manual changes are approved and expire. One nuance matters: not using Infrastructure as Code is not automatically a finding, since some resources are legitimately managed by hand. The real question is whether manual changes are controlled, documented, reviewed, and detectable, and whether production has drifted from the code that is supposed to define it. Evidence to collect: IaC repositories, pull-request and approval samples, IaC scan output, change tickets, emergency-change records, pipeline configuration, and production-drift reports.
9. Vulnerability and Patch Management
Confirm the program that keeps workloads current is real and prioritized well. Check that virtual machines, container images, and dependencies are scanned across development, registries, and runtime, that unsupported or end-of-life software is tracked, and that patches meet a defined service-level agreement. Crucially, prioritize by exposure and context, not raw severity alone: ask whether the vulnerable component is reachable, whether the workload is internet-facing, whether the identity holds sensitive permissions, and whether exploitation is known, because not every vulnerable package is exploitable. A vulnerability assessment feeds this domain of the audit. Evidence to collect: recent scan reports, the patch policy and SLA-performance metrics, an exception register, an unsupported-software inventory, and a trace of a critical finding from detection through retest to closure.
10. Cloud Workloads, Containers, Kubernetes, and Serverless
Modern workloads bring their own audit surface. For virtual machines, check hardened images, end-of-life operating systems, unnecessary services, and instance-metadata protections. For containers and registries, review trusted registries and image provenance, base-image hygiene, root or privileged containers, host mounts, and excessive Linux capabilities, remembering that running as root inside a container increases risk but is not automatically root on the host. For Kubernetes, audit RBAC and cluster-admin assignments, public API-server exposure, workload identity, network policies, admission controls, and audit logging. For serverless, review execution-role least privilege, secrets handling, public triggers, runtime versions, and environment variables. Evidence to collect: cluster RBAC exports, container scan reports, registry policy, workload-identity mappings, serverless IAM, and a public-endpoint inventory.
11. Backup and Disaster Recovery
Backups only count if they are protected and proven to restore. Audit backup frequency, encryption, and access, and check for immutability and isolation, such as keeping copies in a separate account or project so ransomware cannot reach both production and its backups. Confirm deletion protection, retention, and separation of backup administration from day-to-day admin. Rather than requiring a fixed pattern, verify that the resilience architecture, redundancy, and recovery procedures meet the approved recovery-time and recovery-point objectives and business-continuity goals, and that restores are actually tested rather than assumed. Evidence to collect: the backup policy and inventory, the access and immutability configuration, the date and result of the last restore test, documented recovery-time and recovery-point approval, and disaster-recovery exercise records.
12. Incident Response
An audit checks whether you could handle a cloud incident, not just prevent one. Confirm the incident response plan includes cloud-specific playbooks for compromised cloud credentials, exposed object storage, leaked service-account keys, IAM privilege escalation, a compromised container or Kubernetes workload, disabled logging, and cryptomining or resource abuse. Check that responders have cloud forensics access and can preserve snapshots and evidence, that key and token revocation is defined, that there is a provider escalation path, and that legal and privacy notification is understood. Verify roles are assigned and that the plan is tested through tabletop exercises rather than left on a shelf. Evidence to collect: the IR plan, the cloud-specific playbooks, the date and outcome of the last exercise, escalation contacts, and a sample post-incident review.
13. Third-Party and Cloud Service Provider Assurance
You do not audit the provider’s data centers; you audit what assurance they supply and what stays your responsibility. Review your providers’ assurance reports, such as their SOC 2 or ISO certifications, confirm the shared-responsibility documents, and check that the evidence actually satisfies your requirements. Extend the review to subprocessors, SaaS integrations, marketplace applications, vendor identities and external support access, data residency, breach-notification terms, and offboarding. The goal is to confirm which controls the provider assures, which remain yours, and whether any control falls into the gap between the two. Evidence to collect: provider SOC and ISO reports, vendor risk assessments, the contract or security addendum, a subprocessor inventory, a third-party access list, and the shared-responsibility matrix.
14. Data Classification and Governance
Finish with the governance that ties the technical controls together, kept security-focused rather than sprawling into general GRC. Confirm sensitive data is classified so controls match its value, that ownership is assigned for key systems and data, and that security policies exist with review dates. Check that a risk register captures accepted risks and approved exceptions, and that policies trace to the technical controls that implement them, so a stated requirement can be shown to be real rather than aspirational. Verify the shared-responsibility boundary is understood for each service model in use. Evidence to collect: a data-classification scheme, an asset-and-owner matrix, the risk and exception registers, current policies with approval dates, and a shared-responsibility mapping for the services in scope.
Cloud Security Audit Checklist
0/14
What Makes Audit Evidence Defensible?
An audit stands or falls on its evidence, and not all evidence is equal. Defensible evidence is relevant to the control, scoped to the audited environment, timestamped, attributable to a source or system, complete enough to support the conclusion, protected from unauthorized change where required, and retained according to your evidence policy. It also helps to distinguish three levels of proof. Policy evidence shows design intent: a written MFA policy proves you meant to require it. Configuration evidence shows implementation: a current MFA-enrollment report proves it is switched on. Operating-effectiveness evidence shows it worked over time: a completed access review plus the privileges it removed proves the control actually ran. A mature audit, and any SOC 2 or ISO program, cares about all three, while a quick internal review may focus on the first two. Knowing which level a finding rests on is what separates a defensible conclusion from a hopeful one.
What Are the Challenges of Auditing Multi-Cloud Environments?
Many organizations operate across multiple cloud providers, accounts, subscriptions, projects, or SaaS platforms, and auditing across them is harder than auditing one.
- Identity models differ. AWS roles, Azure managed identities, and Google Cloud service accounts each work differently, so the same control has to be verified separately on each.
- Logging and policy engines differ. Different log formats, severity labels, and policy tools make one consistent picture hard to assemble.
- Configuration spreads thin. Settings correct on one provider are easy to forget on another, so drift hides in the cloud you check least often.
- Ownership fragments across teams and platforms, and the shared-responsibility line shifts per provider and service.
The way through is to define a common control baseline, map each provider’s implementation to the same control objective, normalize inventory and ownership, keep provider-native evidence, and centralize tracking where practical.
Which Frameworks Should a Cloud Security Audit Map To?
The criteria you audit against define what secure means for your organization, and the distinctions between them matter. SOC 2 is an independent attestation report, ISO 27001 is a certifiable standard, PCI DSS is a payment-card security standard, and GDPR is a regulation with the force of law. Treating a standard as a regulation, or an attestation as a certification, is a common and avoidable error.
| Framework / Program | Type | Audit relevance |
|---|---|---|
| CIS Benchmarks | Secure configuration guidance | Provider and service baseline checks |
| CSA Cloud Controls Matrix (CCM) v4.1 | Cloud control framework | Cloud control domains and responsibility mapping |
| CSA STAR | Cloud assurance registry and program | Provider assurance and self or third-party assessment |
| SOC 2 | Independent attestation report | Trust Services Criteria control examination |
| ISO/IEC 27001 | Certifiable ISMS standard | Information security management system |
| ISO/IEC 27017 | Cloud security guidance standard | Cloud-specific security controls and guidance |
| ISO/IEC 27018 | Privacy code of practice | Protection of PII in public-cloud processing |
| PCI DSS | Payment-card security standard | Cardholder-data environment |
| HIPAA Security Rule | US regulatory requirements | Safeguards for electronic protected health information |
| NIST CSF 2.0 | Cybersecurity risk-management framework | Govern, Identify, Protect, Detect, Respond, Recover |
| NIST SP 800-53 Rev. 5 | Security and privacy control catalog | Federal and high-assurance control baselines |
| FedRAMP | US government cloud authorization program | Cloud-service authorization for federal use |
| GDPR | EU regulation | Personal-data protection and privacy requirements |
For source material, see the CIS Benchmarks, the CSA Cloud Controls Matrix v4.1, the NIST Cybersecurity Framework 2.0 with its six functions of govern, identify, protect, detect, respond, and recover, NIST SP 800-53 Rev. 5, the PCI DSS standard, and the FedRAMP program.
What Evidence Should You Collect from AWS, Azure, and Google Cloud?
Evidence lives in different places on each provider. This maps common audit domains to where you collect the proof across the three major clouds.
| Domain | AWS examples | Azure examples | Google Cloud examples |
|---|---|---|---|
| Identity | IAM, Identity Center, Access Analyzer | Entra ID, PIM, Conditional Access | Cloud IAM, service accounts |
| Logging | CloudTrail, Config | Activity Logs, diagnostic settings | Cloud Audit Logs |
| Posture | Security Hub, Config | Defender for Cloud, Azure Policy | Security Command Center, Organization Policy |
| Keys | KMS | Key Vault | Cloud KMS |
| Network | Security Groups, NACLs, VPC | NSGs, Azure Firewall, VNets | VPC firewall policies |
| Audit evidence | Audit Manager | Compliance exports, Defender | SCC findings, policy exports |
These native services collect and organize strong evidence, but a provider service alone does not prove compliance; it supports the audit.
Which Tools Help You Run a Cloud Security Audit?
Tools do not replace the auditor’s judgment, but they automate the heavy lifting of evidence collection and configuration review. Provider-native options include AWS Config and Security Hub CSPM for configuration and control evidence. AWS Audit Manager can automate evidence collection for existing configured customers, although AWS placed the service in maintenance mode and stopped new account setup on April 30, 2026. Microsoft Defender for Cloud provides posture and regulatory-compliance evidence for Azure and multicloud environments, while Google Cloud Security Command Center provides findings and inventory for Google Cloud. Open-source auditors like Prowler and ScoutSuite run framework-aligned checks, though their exact AWS, Azure, and GCP coverage varies by tool and version, so confirm support for the providers you use. Cloud Security Posture Management (CSPM) tools give continuous coverage between formal audits. Across all of them, automated tooling can collect, organize, and map evidence, but it does not issue a formal compliance opinion by itself. ScanTitan’s Cloud Vulnerability Scanner is designed to assess supported AWS, Azure, and Google Cloud resources from a unified workflow, surfacing supported misconfigurations, exposed resources, identity risks, and vulnerability findings with contextual evidence and remediation guidance where available. Its output can support audit preparation and technical evidence collection, but it does not replace auditor judgment, certification, or formal attestation.
How Do You Report and Remediate Audit Findings?
The audit is only useful if its findings drive change, so treat each finding as a record, not a note. A well-formed finding names the affected resource, the control requirement, the observation and its evidence, the risk and its context, a severity, the root cause, the remediation, an owner, and a due date. Track it through a clear lifecycle: open, assigned, then remediation or documented risk acceptance, then retest, then closed with evidence.
- Score and contextualize each finding so the riskiest, most exposed issues rise first, not just the highest raw severity.
- Assign an owner and a due date, because a finding without either tends to stay a finding.
- Handle risk acceptance properly: it does not make a finding disappear, so document it, have the right risk owner approve it, time-limit it, and review it later.
- Retest after remediation and record the closure evidence, then look for recurring trends that point to a root cause worth fixing once.
How Often Should You Run a Cloud Security Audit?
There is no universal annual rule across the frameworks people cite, so be precise. Audit cadence depends on the assurance program, contractual obligations, risk profile, regulatory requirements, scope, and pace of change. Some attestation and certification programs run on annual cycles, while others require periodic or ongoing assessment without prescribing one universal cloud-audit frequency. Sensible triggers for a fresh audit include a major architecture change, a new cloud provider, a new regulated workload, a merger or acquisition, a material IAM redesign, and a security incident. Two nuances are worth stating clearly. PCI DSS requires applicable vulnerability scans at least once every three months and after significant changes, but that is a scanning requirement, not the cadence for a full cloud security audit. And HIPAA does not fix an annual risk-analysis frequency; HHS guidance ties it to the environment and ongoing risk management. Between audits, keep continuous vulnerability scanning, posture monitoring, access reviews, and drift detection running so problems surface early rather than at audit time.
Frequently Asked Questions
What is a cloud security audit checklist?
It is a structured list of the domains and controls to review when auditing a cloud environment. A complete checklist covers asset inventory, identity and access, secrets, data protection, logging and detection, network, configuration, change management, vulnerability management, workloads and containers, backup and recovery, incident response, third-party assurance, and governance, each mapped to defined criteria and backed by evidence.
What is the difference between a cloud security audit and a cloud security scan?
A scan is an automated technical assessment. An audit is the broader assurance process that combines technical evidence with control testing, documentation, interviews, sampling, and judgment. The scan is one input to the audit, not a substitute for it.
Should a cloud security audit be internal or third-party?
It depends on the objective, the independence required, and whether a certification or attestation is involved. Internal audits suit self-improvement and readiness, while an external assessor is needed when the assurance program or your customers and regulators require independence, as with a SOC 2 report or ISO 27001 certification.
How often should you run a cloud security audit?
There is no single universal frequency. Cadence depends on the assurance program, contractual and regulatory requirements, risk, scope, and pace of change. Beyond any program schedule, audit after major changes, incidents, and new regulated workloads, and use continuous posture monitoring in between.
Which frameworks apply to cloud security audits?
It depends on your industry and data. Common ones include the CIS Benchmarks, the CSA Cloud Controls Matrix v4.1, SOC 2, ISO 27001 with the 27017 and 27018 extensions, PCI DSS, HIPAA, NIST CSF 2.0 and SP 800-53, FedRAMP, and GDPR.
What evidence should a cloud security audit collect?
Configuration exports, identity reports, access-review records, logging and alert tests, vulnerability reports, key-management evidence, backup restore tests, incident-response exercise records, change and IaC records, provider assurance reports, exceptions, and proof of remediation.
Does a cloud security scan prove compliance?
No. It can provide technical findings and evidence that support an audit, but formal compliance depends on the applicable criteria, the full control environment, and, where required, an independent assessor.
Reviewed by Obaida Al-Sulaiman, Information Security Manager, ScanTitan. CISSP, GXPN, GCIH, GWAPT, CISA, CEH, ISO 27001 Lead Auditor. Obaida leads offensive and defensive security assessments across ScanTitan’s vulnerability scanning, malware, and attack surface work.
