Introduction: Why Cloud Security Audit is Essential
The accelerated migration of sensitive workloads to the cloud has fundamentally altered the risk landscape for organizations. In this context, cloud security audit is no longer an optional approach: it is an operational and regulatory imperative. It allows you to evaluate the effectiveness of controls in place, identify compliance gaps, and reduce exposure to threats.
This guide is intended for IT Audit Managers, Cloud Security Engineers, and CISOs seeking a structured methodology aligned with recognized industry frameworks: CSA CCM, NIST SP 800-53, ISO 27001, and ISO 27017.
Guide Scope
This guide covers ten critical domains of cloud security, each with a detailed control list including objectives, testing steps, expected evidence, and framework references.
What a Cloud Security Audit Entails
A cloud security audit goes far beyond a simple technical scan. It consists of a thorough analysis of technical configurations, administrative policies, and operational procedures, both on the Cloud Service Provider (CSP) side and on the client side.
The central concept is the Shared Responsibility Model: each party — CSP and client organization — assumes distinct security obligations depending on the service model used (IaaS, PaaS, SaaS). The audit aims precisely to verify that these obligations are effectively fulfilled.
| Model | CSP Responsibility | Client Responsibility |
|---|---|---|
| IaaS | Physical infrastructure, hypervisor, networking | OS, middleware, applications, data, IAM |
| PaaS | Infrastructure + runtime + OS | Applications, data, configurations, IAM |
| SaaS | Complete infrastructure + application | Data, user access, security configurations |
Methodology: Steps for a Structured Cloud Audit
Define Scope and Objectives
Identify the cloud services in scope (IaaS, PaaS, SaaS), the business units included, and compliance objectives (GDPR, HIPAA, PCI DSS, etc.).
Analyze the Shared Responsibility Model
Documely document which security tasks fall to the CSP and which fall to the organization. This matrix will serve as a reference throughout the audit.
Conduct a Cloud Risk Assessment
Evaluate cloud-specific threats: misconfigurations, unsecured APIs, account compromise, lateral movement. Use a formalized risk register.
Select Audit Frameworks
Align your approach with recognized standards: CSA CCM v4, NIST SP 800-53 Rev5, ISO 27017, CIS Benchmarks. This choice structures your controls.
Execute Control Tests
Conduct technical inspections (configuration review, log analysis), stakeholder interviews, and practical tests to validate control effectiveness.
1# Example: Verification of MFA policies on Azure AD via Microsoft Graph2Connect-MgGraph -Scopes "Policy.Read.All"3Get-MgPolicyAuthenticationMethodPolicy | Select-Object -ExpandProperty AuthenticationMethodConfigurationsCollect and Document Evidence
Gather configuration screenshots, log exports, documented policies, and automated tool reports. Each control must be supported by timestamped evidence.
Draft Report and Recommendations
Produce a detailed report with findings classified by criticality (Critical, High, Medium, Low) and prioritized remediation recommendations.
Establish Continuous Monitoring
Point-in-time audit is insufficient. Establish a continuous cloud security posture monitoring (CSPM) program to detect configuration drift in real-time.
Complete Checklist: 10 Critical Cloud Audit Domains
Domain 1 — Governance and Risk Management
Governance is the foundation of any cloud security strategy. Without formalized and approved policies, teams operate without clear direction, creating inconsistencies and uncontrolled risks.
| Control Domain | Risk | Objective | Framework |
|---|---|---|---|
| Cloud Security Policy | Inconsistent practices | Formalized policy approved annually | CSA CCM GRC-01 |
| Shared Responsibility Matrix | Role ambiguity | Clear definition of CSP/client responsibilities | CSA CCM GRC-02 |
| Cloud Risk Assessment | Unidentified threats | Regular assessments with mitigation plans | NIST SP 800-53 RA-3 |
| Compliance Monitoring | GDPR/HIPAA non-compliance | Active automated compliance scanning | CSA CCM GRC-03 |
| Asset Inventory | Shadow IT | Accurate inventory of all cloud resources | CIS Control 1 |
| Security Awareness Training | Human error | Cloud-specific modules with completion tracking | ISO 27001 A.7.2.2 |
| Strategic Alignment | Misaligned cloud initiatives | Integration into enterprise security strategy | CSA CCM GRC-04 |
| Internal Audit Program | Undetected failures | Cloud included in annual audit plan | CSA CCM GRC-05 |
| Exception Management | Unauthorized exceptions | Formalized process with approval and expiration | NIST SP 800-53 AC-1 |
| CSP Audit | Unsecured CSP infrastructure | Review CSP's SOC 2 Type II report + CUECs | CSA CCM GRC-06 |
Practical Advice
When reviewing your CSP's SOC 2 Type II report, pay special attention to Complementary User Entity Controls (CUECs). These are controls the CSP expects from you to make its own control system complete. Their non-implementation constitutes an often-overlooked security gap.
Domain 2 — Identity and Access Management (IAM)
IAM represents the first line of defense in a cloud environment. The compromise of privileged identities remains one of the most exploited attack vectors.
| Control Domain | Risk | Objective | Framework |
|---|---|---|---|
| Multi-Factor Authentication (MFA) | Credential theft | MFA mandatory for console and API | CSA CCM IAM-02 |
| Least Privilege | Excessive permissions | No wildcard * in IAM policies | NIST SP 800-53 AC-6 |
| Privileged Accounts | Administration abuse | Dedicated admin accounts, separate from personal accounts | CSA CCM IAM-01 |
| Just-In-Time (JIT) Access | Permanent attack surface | PIM/PAM configured for temporary elevation | CSA CCM IAM-04 |
| Access Reviews | Obsolete rights | Quarterly documented reviews | ISO 27001 A.9.2.5 |
| API Key Management | Hardcoded keys | Regular rotation, absence from source code | CSA CCM IAM-06 |
| Service Account Security | Compromised accounts | Minimal permissions, behavioral monitoring | CSA CCM IAM-09 |
| Identity Federation (SSO) | Fragmented management | Corporate IdP integration, no local account bypass | CSA CCM IAM-08 |
| Root Account Protection | Complete compromise | Root MFA active, no root API keys active | CIS Benchmark 1.1 |
| Password Policy | Brute force | Complexity and rotation enforced via IAM policy | NIST SP 800-53 IA-5 |
1# Verification of users without MFA in AWS via AWS CLI2aws iam generate-credential-report3aws iam get-credential-report --query 'Content' --output text | base64 -d | grep -v ',true,' | cut -d',' -f1Attention
The presence of active API keys on the AWS root account constitutes a critical vulnerability. This point must be addressed with absolute priority during any AWS cloud audit.
Domain 3 — Network Security
Cloud network security relies on defense-in-depth architecture: segmentation, traffic filtering, intrusion detection, and communication encryption.
| Control Domain | Risk | Objective | Framework |
|---|---|---|---|
| Security Groups / Firewall Rules | Unrestricted access | Deny-all by default policy, no 0.0.0.0/0 on sensitive ports | CSA CCM IVS-06 |
| VPC Segmentation | Lateral movement | Isolation by subnets and dedicated VPCs | ISO 27017 |
| Web Application Firewall (WAF) | SQLi, XSS | WAF attached to public Load Balancers | CSA CCM IVS-08 |
| DDoS Protection | Unavailability | AWS Shield / Azure DDoS Protection enabled | CSA CCM IVS-03 |
| IDS/IPS | Undetected malicious activity | Deployment and review of threat alerts | CSA CCM IVS-07 |
| Private Connectivity | Internet exposure | VPC Endpoints / Private Links for internal services | CSA CCM IVS-04 |
| VPC Flow Logs | Lack of visibility | Flow Logs active on all subnets | CSA CCM IVS-01 |
| VPN / Direct Connect | Unsecured hybrid connections | Tunnel encryption and monitoring | NIST SP 800-53 SC-8 |
| Load Balancer Security | Obsolete TLS | Secured listeners, TLS 1.2+ minimum | CSA CCM IVS-02 |
| Egress Filtering | C2/malware | Restriction of outbound traffic to known destinations | CSA CCM IVS-05 |
Domain 4 — Data Security and Encryption
Data protection is at the heart of any cloud security program. It revolves around encryption, classification, and data loss prevention.
| Control Domain | Risk | Objective | Framework |
|---|---|---|---|
| Encryption at Rest | Exposure if storage compromised | S3/EBS/RDS encryption with KMS | CSA CCM DSI-01 |
| Encryption in Transit | Data interception | TLS 1.2+ enforced, HTTPS mandatory | CSA CCM DSI-02 |
| Key Management (KMS) | Unauthorized key access | Strict policies, automatic rotation | NIST SP 800-53 SC-12 |
| Data Classification | Inadequate protection | Classification policy + resource tagging | CSA CCM DSI-03 |
| DLP (Data Loss Prevention) | Data exfiltration | DLP tool configured, active alerts | CSA CCM DSI-04 |
| Public Bucket Prevention | Accidental exposure | Block Public Access enabled by default | CIS Benchmark 2.1.1 |
| Database Backups | Data loss / ransomware | Regular encrypted backups | CSA CCM BCR-02 |
| Retention and Deletion | Non-compliance | Lifecycle policies configured | ISO 27001 A.8.2.3 |
| Snapshot Security | Unauthorized access | Restricted permissions, verified encryption | CSA CCM DSI-05 |
| Secrets Management | Secrets in code | AWS Secrets Manager / Azure Key Vault used | CSA CCM EKM-03 |
1// Example of restrictive KMS policy (AWS)2{3 "Version": "2012-10-17",4 "Statement": [5 {6 "Sid": "RestrictKeyUsage",7 "Effect": "Allow",8 "Principal": {9 "AWS": "arn:aws:iam::123456789012:role/DataEncryptionRole"10 },11 "Action": [12 "kms:Encrypt",13 "kms:Decrypt",14 "kms:GenerateDataKey"15 ],16 "Resource": "*"17 }18 ]19}Domain 5 — Vulnerability and Patch Management
Vulnerability management in a dynamic cloud environment requires an automated and continuous approach, integrated into the development pipeline.
| Control Domain | Risk | Objective | Framework |
|---|---|---|---|
| Vulnerability Scanning | Undetected flaws | Regular scans of cloud instances | CSA CCM TVM-01 |
| Patch Management Policy | Exploitation of known flaws | Formal process with criticality-based timelines | NIST SP 800-53 SI-2 |
| Automated Patching | Manual delays | AWS Systems Manager / Azure Update Manager | CSA CCM TVM-02 |
| Golden Images | Outdated OS images | Hardened, scanned images before deployment | CIS Control 5 |
| Container Image Scanning | Container vulnerabilities | ECR/ACR scanning active, critical findings blocking | CSA CCM TVM-03 |
| Penetration Testing | Uncovered complex vectors | Annual pentest with tracked remediation | PCI DSS 11.3 |
| SCA (Software Composition Analysis) | Vulnerable third-party libraries | Tools like Snyk or Dependabot integrated | CSA CCM TVM-04 |
| Zero-Day Response Plan | Inability to respond quickly | Documented and tested procedure | NIST SP 800-53 SI-5 |
| Remediation Timelines | Unpatched critical vulnerabilities | SLA by criticality level (e.g., Critical < 24h) | CSA CCM TVM-05 |
| Configuration Drift Monitoring | Degraded posture | AWS Config / Azure Policy with drift alerts | CSA CCM TVM-06 |
Important
Define strict remediation SLAs based on CVSS criticality: vulnerabilities with CVSS score ≥ 9.0 (Critical) must be patched within 24 to 72 hours. Any exception requires formal approval and a compensatory mitigation plan.
Domain 6 — Logging and Monitoring
A robust logging program is essential for incident detection, forensic investigation, and compliance demonstration.
| Control Domain | Risk | Objective | Framework |
|---|---|---|---|
| Centralized Logging | Fragmented logs | Aggregation in central SIEM with integrity control | CSA CCM LOG-01 |
| Audit Log Enablement | Lack of visibility | CloudTrail / Activity Logs globally enabled | NIST SP 800-53 AU-2 |
| Log Retention Policy | Loss of forensic data | Retention compliant with regulatory obligations | ISO 27001 A.12.4.2 |
| Real-Time Alerts | Late response | Alert rules for critical events sent to SOC | CSA CCM LOG-02 |
| Log Access Control | Attacker falsification | Restrictive IAM on log buckets + MFA | CSA CCM LOG-03 |
| Privileged Action Monitoring | Undetected admin abuse | Alerts on admin logins and sensitive API calls | CSA CCM LOG-04 |
| Network Traffic Analysis | Undetected exfiltration | Automated flow log analysis + threat detection | CSA CCM LOG-05 |
| Application Logging | Investigation incapability | Authentication, error, and security event logs | OWASP Logging Guide |
| Log Integrity Protection | Deletion by attackers | S3 Object Lock (WORM) or Azure Immutable Storage | NIST SP 800-53 AU-9 |
| NTP Synchronization | Inconsistent timestamps | NTP synchronized on all instances | ISO 27001 A.12.4.4 |
1# Verification that CloudTrail is active across all AWS regions2aws cloudtrail describe-trails --include-shadow-trails \3 --query 'trailList[?IsMultiRegionTrail==`true` && IncludeGlobalServiceEvents==`true`].[Name,HomeRegion,LogFileValidationEnabled]'Domain 7 — Incident Response and Business Continuity
The ability to respond effectively to a cloud security incident is conditioned by preparation, exercises, and automation.
| Control Domain | Risk | Objective | Framework |
|---|---|---|---|
| Incident Response Plan (IRP) | Chaotic response | IRP documented with cloud-specific scenarios | CSA CCM IRM-01 |
| Incident Response Team | Unclear responsibilities | IR roster with current contacts | NIST SP 800-61 |
| Tabletop Exercises | Ineffective response | Regular exercises with documented lessons learned | CSA CCM IRM-02 |
| Automated Response | Manual slowness | Playbooks with Lambda / Logic Apps for known threats | CSA CCM IRM-03 |
| Forensic Preparation | Evidence collection impossible | Snapshot procedures and forensic tools available | CSA CCM IRM-04 |
| Business Continuity Plan (BCP) | Extended unavailability | BCP covering multi-region failover | CSA CCM BCR-01 |
| Disaster Recovery Testing | Failed DR mechanisms | Annual DR tests with validated RTO/RPO | ISO 27001 A.17.1.3 |
| Backup Integrity Tests | Unusable backups | Regular documented restore tests | CSA CCM BCR-03 |
| Crisis Communication Plan | Misinformation | Plan with regulator and stakeholder contacts | NIST SP 800-53 CP-2 |
| Post-Incident Review | Error recurrence | Lessons learned session after each major incident | CSA CCM IRM-05 |
Automated Incident Response
Integrating automated playbooks (AWS Lambda, Azure Logic Apps) dramatically reduces response time (MTTR) for recurring threats like isolating a compromised instance or revoking an exposed API key.
Domain 8 — Application Security and DevSecOps
Integrating security into the software development lifecycle (DevSecOps) is essential to detect and fix vulnerabilities before they reach production.
| Control Domain | Risk | Objective | Framework |
|---|---|---|---|
| Secure SDLC Policy | Security as afterthought | Security gates integrated into CI/CD pipeline | CSA CCM AIS-01 |
| SAST (Static Analysis) | Source code vulnerabilities | Automated SAST on every commit | CSA CCM AIS-02 |
| DAST (Dynamic Analysis) | Runtime vulnerabilities | DAST on staging/production | OWASP ASVS |
| SCA (Software Composition Analysis) | Vulnerable open-source libraries | Snyk / Dependabot integrated into pipeline | CSA CCM AIS-03 |
| IaC Scanning | Misconfigured infrastructure via code | Checkov / tfsec on Terraform/CloudFormation templates | CSA CCM AIS-04 |
| Secrets in Code Prevention | Exposed credentials in Git | Pre-commit hooks (git-secrets, truffleHog) | NIST SP 800-53 SA-11 |
| Container Security | Compromised runtime | Falco or equivalent for runtime security | CSA CCM AIS-05 |
| API Security | Sensitive data exposure | OAuth/JWT, rate limiting, API Gateway configured | OWASP API Security Top 10 |
| Environment Isolation | Dev errors impacting Prod | Network and IAM segregation Dev/Staging/Prod | ISO 27001 A.12.1.4 |
| Deployment Authorization | Unauthorized changes to Prod | Multi-party approval in CI/CD workflow | CSA CCM AIS-06 |
1# Example of GitHub Actions pipeline with SAST and IaC scanning2name: Security Pipeline3on: [push, pull_request]4jobs:5 sast:6 runs-on: ubuntu-latest7 steps:8 - uses: actions/checkout@v49 - name: Run Semgrep SAST10 uses: semgrep/semgrep-action@v111 with:12 config: p/owasp-top-ten13 iac-scan:14 runs-on: ubuntu-latest15 steps:16 - uses: actions/checkout@v417 - name: Run Checkov IaC Scan18 uses: bridgecrewio/checkov-action@master19 with:20 directory: ./terraform21 framework: terraformDomain 9 — Third-Party Risks and Supply Chain
Your cloud environment's security depends on your suppliers' security posture. Third-party risk is often underestimated until the first incident.
| Control Domain | Risk | Objective | Framework |
|---|---|---|---|
| Vendor Risk Assessment | Supplier flaws | Security questionnaires before onboarding | CSA CCM STA-01 |
| Contractual Requirements | Lack of legal recourse | Security clauses + audit rights in contracts | ISO 27001 A.15.1.2 |
| Third-Party Access Control | Excessive vendor access | Temporary IAM roles, vendor activity logs | CSA CCM STA-02 |
| Software Supply Chain Security | Compromised components | Code signing, integrity verification of updates | NIST SP 800-161 |
| Vendor Compliance Monitoring | Degraded posture over time | Annual review of SOC 2 and ISO certifications | CSA CCM STA-03 |
| Exit Strategy | Vendor lock-in | Documented exit plan with data export capabilities | CSA CCM STA-04 |
| Fourth-Party Risk | Sub-supplier risks | Review of vendor's sub-processor list | GDPR Article 28 |
| Vendor Incident Notification | Unreported breaches | 72-hour notification clauses in contracts | CSA CCM STA-05 |
| SaaS Application Security | Misconfigured M365/Salesforce | Audit of SaaS security baselines, MFA, sharing | CSA CCM STA-06 |
| MSP Supervision | Unauthorized modifications | MSP activity logs + change management compliance | CSA CCM STA-07 |
Attention
Managing fourth-party risk (your suppliers' suppliers) is required by the GDPR Article 28. Ensure your contracts require sub-processors to notify you of additional sub-processors.
Domain 10 — Compliance and Legal Aspects
The legal and compliance component of a cloud audit encompasses data sovereignty, cross-border transfers, and ability to respond to legal requests.
| Control Domain | Risk | Objective | Framework |
|---|---|---|---|
| Data Sovereignty and Residency | Data in non-compliant jurisdictions | Verification of cloud regions used | GDPR / CSA CCM UEM-01 |
| Privacy Impact Assessment (PIA) | Risks to personal data | PIA conducted before any new personal data project | ISO 29134 |
| Regulatory Mapping | Missing controls | Control/requirement mapping matrix for PCI, HIPAA | CSA CCM GRC-07 |
| e-Discovery Readiness | Data production incapability | e-discovery procedures and tools available | CSA CCM UEM-02 |
| SLA Monitoring | CSP non-compliance with commitments | Monthly uptime reports, service credit claims | CSA CCM UEM-03 |
| Records Retention Policy | Illegal deletion or excessive storage | Retention schedule with automated deletion | NIST SP 800-53 MP-6 |
| DPO Oversight | Lack of independent oversight | DPO sign-off on cloud projects involving personal data | GDPR Article 37 |
| Legal Review of Cloud Contracts | Unfavorable clauses | Legal counsel validation before signature | CSA CCM UEM-04 |
| Cross-Border Data Transfers | Illegal transfers | Standard Contractual Clauses (SCCs) in place | GDPR Article 46 |
| Log Admissibility in Court | Inadmissible logs | Chain-of-custody procedures + log integrity | ISO 27037 |
Summary and Recommendations for IT Teams
Implementing this checklist represents a significant but structuring investment. Here are the recommended priorities for organizations beginning or maturing their cloud audit program:
- Short term (0-3 months): Enable MFA on all accounts, fix public buckets, enable audit logs, and establish the shared responsibility matrix.
- Medium term (3-6 months): Deploy a CSPM, implement JIT access via PIM/PAM, integrate SAST/SCA into CI/CD pipelines, and formalize IRP.
- Long term (6-12 months): Automate incident response, conduct comprehensive penetration testing, formalize third-party risk assessments, and align with CSA CCM v4.
Reference Resources
To deepen each domain, consult official resources: CSA Cloud Controls Matrix v4, NIST SP 800-53 Rev5, CIS Benchmarks, OWASP API Security Top 10, and ISO/IEC 27017:2015.
