Cloud Security Audit: AWS, Azure and Google Cloud Under Control

1. Introduction

Cloud security auditing has become a necessity for any company operating in AWS, Azure or Google Cloud: the cloud is secure, but the configuration rarely is. An open S3 bucket, an overly permissive IAM policy or a poorly segmented network can expose customer data without anyone noticing. In this article we explain what a cloud security audit consists of, what is reviewed and what deliverables your company should receive.

The incidents of 2025-2026 confirm it: most cloud breaches are not caused by platform vulnerabilities but by misconfigurations. A cloud security audit detects these failures before attackers do, and it is also a requirement for certifications such as ISO 27001 or the Spanish ENS when the infrastructure lives in the cloud.

In this article we review the layered audit methodology — IAM, data, network, logging and compliance — with examples of real commands in the three providers, the recommended frequency and the expected deliverables. By the end, you will know exactly what to ask your cybersecurity services provider.

2. What Is a Cloud Security Audit and Why Do Configurations Fail?

A cloud security audit is a systematic process that evaluates the configuration, permissions and usage of a cloud provider’s infrastructure (AWS, Azure or Google Cloud) against best practices and regulatory requirements, identifying concrete risks and proposing prioritized remediations.

The shared responsibility model explains everything: the provider secures the cloud, but the customer is responsible for what is inside — identities, data, networks and configurations. The most common failures detected in real audits include buckets with public access, access keys embedded in code, roles with excessive permissions, disabled logging and unsegmented VPCs.

The model has a practical consequence: the provider protects the physical platform, the hypervisor and the network fabric, but everything the customer configures — identities, permissions, buckets, databases, firewalls, monitoring — is customer responsibility. The same service works perfectly in a compliant architecture or a vulnerable one, depending on who created it. A single account with an administrator role shared by five employees, an open storage bucket or a production database without backups are all customer-side decisions that no provider will fix automatically.

Layer	Typical risk	Impact
IAM / identities	Excessive permissions, keys not rotated	Credential compromise
Data / storage	Public buckets, encryption disabled	Massive data leakage
Network	Open ports, no segmentation	Unauthorized access
Logging	CloudTrail/Audit off	No forensic visibility

Fig. 1 – Typical layers of a cloud security audit and their main risks.

3. IAM Audit: The Foundation of Cloud Security

Identity and access management is the most critical layer. The audit reviews the principle of least privilege, roles instead of long-lived keys, credential rotation and mandatory MFA:

# AWS: identify users, roles and permissions
aws iam list-users --output table
aws iam list-access-keys --user-name ana --output table
aws iam get-account-authorization-details --output json | jq '.UserDetailList[].AttachedManagedPolicies'

# Azure: review roles and global administrators
az ad signed-in-user show
az role assignment list --all --output table

# Google Cloud: project IAM
gcloud projects get-iam-policy my-project --flatten="bindings[].members" --format="table(bindings.role,bindings.members)"

Fig. 2 – IAM audit commands in the three major cloud providers.

A classic finding: users with “AdministratorAccess” or “Owner” access when they only need permissions limited to one service. The cloud security audit quantifies this risk and proposes policy redesigns with concrete examples.

The practical checks the auditor performs in this layer:

MFA enabled on all human accounts and enforced for administrative roles.
Service accounts and access keys: how many exist, when they were last rotated and whether they appear in code repositories.
Break-glass accounts: whether they exist, who controls them and whether their use is monitored.
Role design: whether permissions follow the least-privilege principle or roles accumulate from previous projects.
In Azure, whether Privileged Identity Management (PIM) limits privileged roles to temporary activation.

Tools such as AWS IAM Access Analyzer, Azure AD Identity Protection and Google Cloud IAM recommender already identify most of these issues automatically; the audit validates them against the business context and quantifies the real risk.

4. Data Audit: Buckets, Databases and Encryption

Storage is where the most famous leaks happen. The audit reviews public policies, encryption at rest and in transit, and lifecycle rules:

# AWS: detect buckets with public access
aws s3api get-bucket-acl --bucket my-bucket
aws s3api get-bucket-policy-status --bucket my-bucket

# Azure: review anonymous access on blobs
az storage account list --query "[].{name:name,allowBlobPublicAccess:allowBlobPublicAccess}" -o table

# Google Cloud: public policies on buckets
gsutil iam get gs://my-bucket

Fig. 3 – Commands to detect exposed cloud storage.

The cloud security audit also covers encryption review (SSE-S3/KMS, SSE with customer-managed keys), object versioning and deletion lock — essential controls against ransomware and accidental deletion.

In this layer the auditor also verifies: default encryption keys versus customer-managed keys (CMEK), encryption in transit enforced on load balancers and API gateways, object versioning and deletion lock as protection against ransomware, database snapshots and their retention policy, and signed URLs with long expiration periods that publish private data.

5. Network, Logging and Compliance Audit

In the network layer, security groups, firewall rules (including 0.0.0.0/0), peerings and environment segmentation are reviewed. In the logging layer, that activity logs are enabled and centralized:

# AWS: security groups with access from any IP
aws ec2 describe-security-groups --query 'SecurityGroups[].IpPermissions[]' --output json

# Azure: enable network diagnostics
az monitor diagnostic-settings list --resource my-vm

# Google Cloud: enable audit logging
gcloud services enable cloudaudit.googleapis.com

Fig. 4 – Verifying network rules and logging in cloud providers.

In the network layer the checklist includes: security groups and firewall rules that allow 0.0.0.0/0 for administrative ports, peering connections that are no longer used, production and test environments without separation, disabled flow logs and traffic analysis, and services exposed to the internet that should be internal. In Google Cloud the same checks apply to VPC firewall rules and the Identity-Aware Proxy (IAP) configuration.

The compliance part compares the configuration with the applicable framework: CIS Benchmarks, ISO 27001, ENS (if applicable) and GDPR for personal data. Open-source tools such as ScoutSuite, Prowler (AWS) or CloudSploit automate much of the initial sweep, which the auditor complements with manual review.

CIS Benchmarks define the hardened baseline for each provider: hundreds of configuration items, from password policies to disabled default accounts, and they are the common language between auditors and engineers. The cloud security audit should report the percentage of compliance with the applicable benchmark, the specific controls that fail and the remediation for each one. Beyond CIS, the audit maps the configuration to the regulatory framework: ISO 27001 Annex A controls, the ENS if applicable, and GDPR requirements for personal data, including data residency and processing agreements (DPA).

Automated Tools: Prowler, ScoutSuite, CloudSploit and CSPM

Open-source tools automate the first sweep and guarantee that the audit does not depend on the auditor’s memory. Prowler is the reference for AWS and also supports Azure and Google Cloud, with hundreds of checks mapped to CIS Benchmarks; ScoutSuite provides a readable multi-cloud view of the configuration; CloudSploit covers misconfigurations and exposed services. The automated phase runs with read-only permissions on a dedicated account, so nothing is ever changed by the audit.

# Automated cloud security assessment with open-source tools
prowler aws -M csv -o prowler_report.csv       # AWS: 300+ CIS checks
prowler azure -M csv -o azure_report.csv      # Azure: same methodology
prowler gcp -M csv -o gcp_report.csv          # Google Cloud
scoutsuite aws --report-dir ./scoutsuite      # Complementary multi-cloud view

Commercial CSPM platforms (AWS Security Hub, Microsoft Defender for Cloud, Google Security Command Center, and independent products such as Wiz or Orca) add continuous monitoring that runs daily instead of once a year. The audit validates the alerts these platforms generate, discards false positives and focuses on findings with real business impact. A cloud security audit without an automated baseline is incomplete; one that only automates is equally incomplete, because context — who uses what, and what really matters — requires a human auditor.

How Much Does a Cloud Security Audit Cost and How Often Should It Be Done?

As a reference in 2026, a complete cloud security audit of a small or medium environment — a few accounts, under 200 resources — costs between 4,000 and 10,000 EUR in Europe, while a complex multi-account organization can reach 20,000-40,000 EUR including remediation workshops. The price depends mainly on the number of accounts, the services in use and the depth of the compliance mapping.

Frequency is as important as depth: at least an annual audit, plus a quick review after every major architecture change, migration or new integration. Many organizations combine both: an annual full audit with executive report, and quarterly automated scans with the CSPM platform that keep the baseline visible in between. If your company stores personal data under GDPR or handles regulated information, treat the audit as part of compliance, not as an optional expense.

6. Methodology, Deliverables and Frequency

A professional cloud security audit follows a clear process: resource inventory, configuration collection (with the minimum permissions needed by the auditor), automated + manual analysis, finding validation (discarding false positives) and final report.

The report must include: executive summary for management, asset inventory, findings matrix by severity (critical/high/medium/low), evidence for each one, business risk and a prioritized remediation plan with estimated effort. The recommended frequency is at least annual, and after significant architecture changes; many companies opt for quarterly automated audits with continuous scanning.

7. Conclusion

The cloud security audit turns “we trust the cloud” into “we have verified that our configuration is secure”. In 2026, with automated attacks scanning the internet for open buckets and backdoors, this review is not optional for any company with infrastructure in AWS, Azure or Google Cloud.

At Jaymon Security we perform complete cloud security audits for companies of all sizes, with an executive report and remediation plan. Learn more at jaymonsecurity.com or in the official AWS Well-Architected and Microsoft Azure Well-Architected guides.

Need help with Cloud security audit?

At Jaymon Security, we help organizations protect their systems. From security audits to SIEM/SOC implementation, our expert team designs custom solutions.