Cloud Security Assessment: AWS, Azure, and GCP Hardening Checklist for 2026

TL;DR — Most cloud breaches in 2026 still trace to the same root causes: over-permissioned IAM principals, publicly exposed storage buckets, flat networks with no segmentation, missing or unmonitored audit logs, secrets hardcoded in source, unscanned container images, and infrastructure-as-code templates that deploy known misconfigurations on every terraform apply. This post is a practitioner-grade hardening checklist for AWS, Azure, and Google Cloud Platform, grounded in CIS Benchmarks v3.0/v4.0, CSA Cloud Controls Matrix v4, NIST SP 800-53 Rev 5, ISO/IEC 27017:2015, and the AWS Well-Architected Framework (Security Pillar). Every section includes real CLI commands you can run today to find the gaps, and a standards mapping so your compliance team can trace each control to the framework they care about. No fabricated case studies, no marketing percentages — just the checklist. For a scoped assessment of your cloud estate, see our Security & Risk Assessment service.

Why cloud security assessments still matter#

Cloud providers operate on a shared-responsibility model. The provider secures the infrastructure of the cloud; you secure everything in it — identity policies, storage permissions, network rules, logging configuration, secrets, workloads, and the IaC that deploys all of the above. Every major cloud breach disclosure in 2024-2026 fell on the customer side of that line. The misconfiguration was in the customer's account, not the provider's platform.

A cloud security assessment is a systematic, evidence-based review of your cloud tenant configuration against a recognised baseline. The most widely adopted baselines are:

• CIS Benchmarks — prescriptive, per-service configuration guides for AWS (v3.0), Azure (v3.0), and GCP (v4.0). Each recommendation has a rationale, an audit procedure, and a remediation procedure.
• CSA Cloud Controls Matrix (CCM) v4 — a controls framework purpose-built for cloud, mapping to ISO 27001/27002, NIST, PCI DSS, SOC 2, and regional regulations.
• NIST SP 800-53 Rev 5 — the US federal control catalogue, adopted globally as a comprehensive baseline. The AC (Access Control), AU (Audit and Accountability), SC (System and Communications Protection), and IA (Identification and Authentication) families are the ones cloud assessments hit hardest.
• ISO/IEC 27017:2015 — cloud-specific guidance extending ISO 27002 controls with cloud service customer and cloud service provider implementation notes.
• AWS Well-Architected Framework, Security Pillar — AWS's own opinionated guidance on identity, detective controls, infrastructure protection, data protection, and incident response.

The checklist below covers the seven domains where misconfigurations are most common and most consequential.

1. IAM misconfigurations#

Identity and access management is the perimeter of the cloud. Every action in every cloud provider is an API call, and every API call is authorised (or not) by the IAM layer. Get IAM wrong and nothing else matters — the attacker inherits whatever permissions the compromised principal has.

What to check#

• Overly permissive policies. Any principal with *:*, Action: "*", or equivalent broad permissions. In AWS, this means policies granting "Effect": "Allow", "Action": "*", "Resource": "*". In Azure, role assignments with Owner or Contributor at the subscription or management-group scope. In GCP, bindings with roles/editor or roles/owner at the organisation or folder level.
• Unused credentials. Access keys, service account keys, and service principals that have not been used in 90+ days. Dormant credentials are the attacker's preferred lateral-movement path.
• MFA enforcement. Every human identity — root/global-admin accounts especially — must have MFA enforced, not just enabled.
• Cross-account / cross-tenant trust. IAM roles or policies that grant access to external AWS accounts, Azure tenants, or GCP projects. Each trust relationship is an attack surface.
• Service account key sprawl. GCP service account keys and AWS access keys downloaded to developer workstations, CI/CD runners, or committed to repositories.

CLI audit commands#

AWS — find IAM users without MFA:

aws iam generate-credential-report --output text
aws iam get-credential-report --query 'Content' --output text \
  | base64 --decode | cut -d',' -f1,4,8 \
  | grep -i 'false'

AWS — list policies granting full admin:

aws iam list-policies --scope Local --query \
  'Policies[?DefaultVersionId!=`null`].{Name:PolicyName,Arn:Arn}' \
  --output table
# Then for each policy:
aws iam get-policy-version --policy-arn <ARN> \
  --version-id <VersionId> \
  --query 'PolicyVersion.Document'
# Look for "Action": "*" with "Resource": "*"

Azure — list role assignments with Owner at subscription scope:

az role assignment list --role "Owner" \
  --scope "/subscriptions/<sub-id>" \
  --output table

GCP — list IAM bindings with primitive roles at org level:

gcloud organizations get-iam-policy <ORG_ID> \
  --format='table(bindings.role,bindings.members)' \
  --filter='bindings.role:(roles/owner OR roles/editor)'

Standards mapping#

Control	Framework
AC-2, AC-3, AC-6 (Least Privilege)	NIST SP 800-53 Rev 5
IAM-01 through IAM-16	CSA CCM v4
CIS AWS 1.x, CIS Azure 1.x, CIS GCP 1.x	CIS Benchmarks
SEC01, SEC02	AWS Well-Architected (Security Pillar)
A.9.2, A.9.4 (CLD.9.5.1, CLD.9.5.2)	ISO/IEC 27017

2. Storage exposure — S3, Blob Storage, GCS#

Public storage buckets remain one of the most reliably exploitable misconfigurations. Despite years of vendor defaults shifting toward "block public access," legacy buckets, IaC templates that predate those defaults, and explicit policy overrides continue to expose sensitive data.

What to check#

• Public access settings. AWS S3 Block Public Access at the account level and per bucket. Azure storage account "Allow Blob public access" setting. GCP uniform bucket-level access and allUsers / allAuthenticatedUsers bindings.
• Bucket policies and ACLs. Policies granting access to "Principal": "*" (AWS), anonymous access (Azure), or allUsers (GCP).
• Encryption at rest. Whether server-side encryption is enabled and whether customer-managed keys (CMK) are in use where required by policy.
• Versioning and lifecycle. Whether versioning is enabled for data-integrity and ransomware-recovery scenarios. Whether lifecycle policies prevent indefinite data retention.
• Access logging. Whether server access logging or data-access audit logs are enabled for the bucket.

CLI audit commands#

AWS — check account-level S3 Block Public Access:

aws s3control get-public-access-block \
  --account-id $(aws sts get-caller-identity --query Account --output text)

AWS — find buckets without default encryption:

for bucket in $(aws s3api list-buckets --query 'Buckets[].Name' --output text); do
  echo -n "$bucket: "
  aws s3api get-bucket-encryption --bucket "$bucket" 2>&1 \
    | grep -q 'ServerSideEncryptionConfiguration' \
    && echo "ENCRYPTED" || echo "NOT ENCRYPTED"
done

Azure — list storage accounts with public blob access enabled:

az storage account list \
  --query "[?allowBlobPublicAccess==\`true\`].{Name:name,RG:resourceGroup}" \
  --output table

GCP — find buckets with allUsers or allAuthenticatedUsers bindings:

for bucket in $(gcloud storage buckets list --format='value(name)'); do
  gcloud storage buckets get-iam-policy "gs://$bucket" \
    --format=json 2>/dev/null \
    | grep -q 'allUsers\|allAuthenticatedUsers' \
    && echo "PUBLIC: $bucket"
done

Standards mapping#

Control	Framework
SC-28 (Protection of Information at Rest), SC-12 (Cryptographic Key Management)	NIST SP 800-53 Rev 5
DSP-01 through DSP-19	CSA CCM v4
CIS AWS 2.1.x, CIS Azure 3.x, CIS GCP 5.x	CIS Benchmarks
SEC07, SEC08	AWS Well-Architected (Security Pillar)
A.10.1 (CLD.10.1.1)	ISO/IEC 27017

3. Network segmentation#

A flat cloud network — where every workload can reach every other workload on every port — is the cloud equivalent of a building with no internal doors. Once an attacker compromises a single workload, lateral movement is trivial.

What to check#

• Default VPC / default security groups. Whether workloads are deployed into the provider-created default VPC/VNet with permissive default rules.
• Overly permissive security groups / NSGs / firewall rules. Rules allowing 0.0.0.0/0 inbound on management ports (SSH/22, RDP/3389) or on all ports.
• VPC Flow Logs / NSG Flow Logs / VPC Flow Logs (GCP). Whether flow logging is enabled for forensic and anomaly-detection purposes.
• Private endpoints vs. public endpoints. Whether managed services (databases, key vaults, storage) are accessed over private endpoints or over the public internet.
• Network segmentation between tiers. Whether web, application, and data tiers are in separate subnets with security groups restricting inter-tier traffic to only the required ports and protocols.

CLI audit commands#

AWS — find security groups allowing 0.0.0.0/0 on SSH:

aws ec2 describe-security-groups \
  --filters "Name=ip-permission.from-port,Values=22" \
             "Name=ip-permission.to-port,Values=22" \
             "Name=ip-permission.cidr,Values=0.0.0.0/0" \
  --query 'SecurityGroups[].{ID:GroupId,Name:GroupName}' \
  --output table

AWS — check VPC Flow Logs are enabled:

for vpc in $(aws ec2 describe-vpcs --query 'Vpcs[].VpcId' --output text); do
  echo -n "$vpc: "
  aws ec2 describe-flow-logs \
    --filter "Name=resource-id,Values=$vpc" \
    --query 'FlowLogs[0].FlowLogStatus' --output text
done

Azure — find NSG rules allowing inbound SSH from any source:

az network nsg list --query '[].name' -o tsv | while read nsg; do
  az network nsg rule list --nsg-name "$nsg" \
    --resource-group <RG> \
    --query "[?access=='Allow' && direction=='Inbound' \
      && destinationPortRange=='22' \
      && sourceAddressPrefix=='*'].{NSG:'$nsg',Rule:name}" \
    --output table
done

GCP — find firewall rules allowing 0.0.0.0/0 on SSH:

gcloud compute firewall-rules list \
  --filter="sourceRanges=0.0.0.0/0 AND allowed[].ports=22 AND direction=INGRESS" \
  --format="table(name,network,sourceRanges,allowed[].ports)"

Standards mapping#

Control	Framework
SC-7 (Boundary Protection), SC-7(5) (Deny by Default)	NIST SP 800-53 Rev 5
IVS-01 through IVS-13	CSA CCM v4
CIS AWS 5.x, CIS Azure 6.x, CIS GCP 3.x	CIS Benchmarks
SEC05, SEC06	AWS Well-Architected (Security Pillar)
A.13.1 (CLD.13.1.4)	ISO/IEC 27017

4. Logging and monitoring gaps#

You cannot detect what you do not log. You cannot investigate what you did not retain. Logging gaps are not a theoretical weakness — they are the specific reason post-breach investigations produce "we cannot determine the full scope of the compromise" statements.

What to check#

• Cloud-native audit logging. AWS CloudTrail (management events and data events), Azure Activity Log and Diagnostic Settings, GCP Cloud Audit Logs (Admin Activity, Data Access, System Event, Policy Denied).
• Multi-region / all-region coverage. Whether audit logs capture events in every region, not just the regions you think you use. Attackers spin up resources in regions you are not monitoring.
• Log retention. Whether logs are retained for at least 365 days (CIS recommendation) and whether they are stored in immutable, tamper-evident storage.
• Alerting on critical events. Whether alerts fire on root/global-admin sign-in, IAM policy changes, security-group changes, CloudTrail/audit-log disablement, and console sign-in without MFA.
• Centralised log aggregation. Whether logs from all accounts, subscriptions, and projects flow to a central, protected location.

CLI audit commands#

AWS — verify CloudTrail is enabled and multi-region:

aws cloudtrail describe-trails \
  --query 'trailList[].{Name:Name,IsMultiRegion:IsMultiRegionTrail,IsLogging:HasCustomEventSelectors}' \
  --output table

aws cloudtrail get-trail-status --name <trail-name> \
  --query '{IsLogging:IsLogging,LatestDeliveryTime:LatestDeliveryTime}'

AWS — check CloudTrail log file validation:

aws cloudtrail describe-trails \
  --query 'trailList[].{Name:Name,LogFileValidation:LogFileValidationEnabled}' \
  --output table

Azure — check Diagnostic Settings for the subscription Activity Log:

az monitor diagnostic-settings subscription list \
  --subscription <sub-id> \
  --query '[].{Name:name,Logs:logs[].categoryGroup}' \
  --output table

GCP — check Data Access audit logs are enabled:

gcloud projects get-iam-policy <PROJECT_ID> \
  --format=json | jq '.auditConfigs'

Standards mapping#

Control	Framework
AU-2, AU-3, AU-6, AU-9, AU-11	NIST SP 800-53 Rev 5
LOG-01 through LOG-13	CSA CCM v4
CIS AWS 3.x, CIS Azure 5.x, CIS GCP 2.x	CIS Benchmarks
SEC04	AWS Well-Architected (Security Pillar)
A.12.4 (CLD.12.4.5)	ISO/IEC 27017

5. Secrets management#

Hardcoded secrets — API keys, database passwords, service account credentials, TLS private keys — in source code, environment variables, CI/CD configuration, or container images are the single most common initial-access vector in cloud compromises that do not involve phishing. Every secrets-scanning tool finds them; every attacker with repository access finds them first.

What to check#

• Secrets in source control. Run a secrets scanner (e.g., trufflehog, gitleaks, detect-secrets) against the full git history, not just the current HEAD.
• Secrets in environment variables. Whether application configuration pulls secrets from a vault (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault) or from plaintext environment variables.
• Secrets rotation. Whether credentials have an automated rotation schedule. IAM access keys older than 90 days, database passwords that have never been rotated, and API keys with no expiration date are all findings.
• Vault access policies. Whether the secrets vault itself follows least privilege — only the specific service identity that needs a secret can read it.
• Secrets in container images. Whether docker history or image-layer inspection reveals embedded credentials.

CLI audit commands#

AWS — find IAM access keys older than 90 days:

aws iam generate-credential-report > /dev/null 2>&1
sleep 5
aws iam get-credential-report --query 'Content' --output text \
  | base64 --decode \
  | awk -F',' 'NR>1 && $9=="true" { print $1, $10 }' \
  | while read user date; do
      age=$(( ($(date +%s) - $(date -d "$date" +%s)) / 86400 ))
      [ "$age" -gt 90 ] && echo "STALE KEY: $user ($age days)"
    done

Azure — list Key Vault secrets approaching expiry:

az keyvault secret list --vault-name <vault-name> \
  --query "[?attributes.expires!=null].{Name:name,Expires:attributes.expires}" \
  --output table

GCP — list service account keys and their creation dates:

for sa in $(gcloud iam service-accounts list --format='value(email)'); do
  echo "=== $sa ==="
  gcloud iam service-accounts keys list \
    --iam-account="$sa" \
    --format='table(name.basename(),validAfterTime,validBeforeTime,keyType)'
done

Git repository — scan full history for secrets:

# Using trufflehog (install: pip install trufflehog)
trufflehog git file://. --since-commit HEAD~500 --only-verified

# Using gitleaks (install: brew install gitleaks / go install)
gitleaks detect --source=. --verbose

Standards mapping#

Control	Framework
IA-5 (Authenticator Management), SC-12, SC-28	NIST SP 800-53 Rev 5
IAM-02, IAM-14, DSP-11	CSA CCM v4
CIS AWS 1.12-1.14, CIS Azure 8.x, CIS GCP 1.x	CIS Benchmarks
SEC02, SEC08	AWS Well-Architected (Security Pillar)
A.10.1 (CLD.10.1.1), A.9.2	ISO/IEC 27017

6. Container and workload security#

Containers — on EKS, AKS, GKE, ECS, or self-managed Kubernetes — are the dominant deployment model for cloud workloads in 2026. The attack surface spans the image supply chain, the runtime configuration, the orchestrator itself, and the node OS beneath it.

What to check#

• Base image provenance. Whether container images are built from known, maintained base images or from unvetted public images. Whether images are pulled from a private registry with vulnerability scanning enabled.
• Image vulnerability scanning. Whether images are scanned for known CVEs before deployment and whether a policy blocks deployment of images with critical/high findings.
• Runtime privileges. Whether containers run as root, whether they have privileged: true, hostNetwork: true, hostPID: true, or elevated Linux capabilities.
• Pod security standards. Whether Kubernetes clusters enforce Pod Security Standards (Restricted baseline) or equivalent policies via admission controllers.
• Network policies. Whether Kubernetes NetworkPolicies restrict pod-to-pod traffic to only what is required.
• Secrets in pods. Whether Kubernetes Secrets are stored encrypted at rest (etcd encryption) and whether workloads use a secrets-store CSI driver rather than mounting Secrets as environment variables.

CLI audit commands#

AWS EKS — check if secrets encryption is enabled:

aws eks describe-cluster --name <cluster-name> \
  --query 'cluster.encryptionConfig[].resources' \
  --output text
# Should return "secrets"

Kubernetes — find pods running as root or privileged:

kubectl get pods --all-namespaces -o json \
  | jq -r '
    .items[] |
    select(
      .spec.containers[]? |
      (.securityContext.runAsUser == 0) or
      (.securityContext.privileged == true)
    ) |
    "\(.metadata.namespace)/\(.metadata.name)"
  '

Kubernetes — find pods without resource limits:

kubectl get pods --all-namespaces -o json \
  | jq -r '
    .items[] |
    select(.spec.containers[] | .resources.limits == null) |
    "\(.metadata.namespace)/\(.metadata.name)"
  '

Azure AKS — check if Azure Policy add-on is enabled:

az aks show --name <cluster-name> \
  --resource-group <rg> \
  --query 'addonProfiles.azurepolicy.enabled'

GCP GKE — check if Workload Identity is enabled:

gcloud container clusters describe <cluster-name> \
  --zone <zone> \
  --format='value(workloadIdentityConfig.workloadPool)'
# Non-empty means Workload Identity is enabled

Standards mapping#

Control	Framework
CM-7 (Least Functionality), SI-3, SI-7	NIST SP 800-53 Rev 5
IVS-04, IVS-09, DSP-17	CSA CCM v4
CIS EKS 1.x, CIS AKS 1.x, CIS GKE 1.x	CIS Benchmarks
SEC06	AWS Well-Architected (Security Pillar)
A.12.6 (CLD.12.6.1)	ISO/IEC 27017

7. Infrastructure-as-Code scanning#

If your cloud infrastructure is deployed via Terraform, CloudFormation, Bicep, Pulumi, or CDK, then your security posture is defined in code — and that code can be scanned for misconfigurations before it ever reaches a cloud API. IaC scanning is the cloud equivalent of static application security testing (SAST): it shifts the detection left, where the fix is a PR comment rather than a production incident.

What to check#

• Pre-commit / CI pipeline scanning. Whether IaC templates are scanned for misconfigurations in CI before merge. Tools: checkov, tfsec / trivy config, KICS, Bridgecrew.
• Policy-as-code enforcement. Whether guardrails (e.g., OPA/Rego, AWS Service Control Policies, Azure Policy, GCP Organisation Policies) prevent deployment of non-compliant resources even if the IaC scan is skipped.
• Drift detection. Whether the actual cloud state is compared to the declared IaC state on a regular cadence. Drift — manual changes made outside the IaC pipeline — is a misconfiguration vector that IaC scanning alone misses.
• Module provenance. Whether Terraform modules or Pulumi components are pulled from trusted, version-pinned registries or from arbitrary public sources.

CLI audit commands#

Terraform — scan with checkov:

# Install: pip install checkov
checkov -d . --framework terraform \
  --check CKV_AWS_18,CKV_AWS_19,CKV_AWS_21,CKV_AWS_145 \
  --compact
# CKV_AWS_18: S3 access logging
# CKV_AWS_19: S3 SSE
# CKV_AWS_21: S3 versioning
# CKV_AWS_145: S3 KMS encryption

Terraform — scan with trivy:

trivy config . --severity HIGH,CRITICAL --format table

CloudFormation — scan with cfn-lint + checkov:

cfn-lint template.yaml
checkov -f template.yaml --framework cloudformation

Detect Terraform state drift:

terraform plan -detailed-exitcode
# Exit code 0 = no changes (no drift)
# Exit code 2 = changes detected (drift present)

Standards mapping#

Control	Framework
CM-2 (Baseline Configuration), CM-3 (Configuration Change Control), SA-11	NIST SP 800-53 Rev 5
IVS-04, CCC-01, CCC-02	CSA CCM v4
CIS AWS 1.x (general), CIS Azure 1.x	CIS Benchmarks
SEC01, OPS01	AWS Well-Architected (Security Pillar + Operational Excellence)
A.14.2 (CLD.14.2.1)	ISO/IEC 27017

Putting it together: the assessment workflow#

A structured cloud security assessment follows a repeatable workflow:

1. Scope definition. Enumerate accounts, subscriptions, and projects in scope. Identify the compliance frameworks the organisation must align with.
2. Automated baseline scan. Run CIS Benchmark scanners (Prowler for AWS, ScoutSuite for multi-cloud, Steampipe for SQL-based queries) to generate a quantitative gap analysis.
3. Manual configuration review. Validate automated findings, check for false positives, and investigate areas automated tools miss — trust relationships, custom IAM policies, application-layer secrets exposure, IaC pipeline configuration.
4. Evidence collection. Screenshot or export the CLI output for every finding. Every finding must be reproducible.
5. Risk-rated findings report. Each finding mapped to the relevant CIS control, CSA CCM domain, NIST control family, and/or ISO 27017 clause. Severity rated by exploitability and blast radius, not by theoretical risk alone.
6. Remediation guidance. Specific, actionable remediation steps — not "improve your IAM posture" but "remove "Action": "*" from policy ARN arn:aws:iam::123456789012:policy/LegacyAdmin and replace with the minimum permissions documented in the application's IAM requirements."
7. Revalidation. Re-run the automated scan after remediation to confirm closure.

Quick-start: Prowler for AWS#

# Install
pip install prowler

# Run full CIS Benchmark assessment
prowler aws --compliance cis_3.0_aws

# Run specific checks only
prowler aws -c s3_bucket_public_access iam_root_mfa_enabled \
  cloudtrail_multi_region_enabled

# Output to HTML report
prowler aws --compliance cis_3.0_aws -M html

Quick-start: ScoutSuite for multi-cloud#

# Install
pip install scoutsuite

# AWS
scout aws

# Azure
scout azure --cli

# GCP
scout gcp --user-account

The assessment is the beginning, not the end#

A findings report that sits in a shared drive is not security. The value of a cloud security assessment is realised only when findings are remediated, controls are automated, and the assessment is repeated on a cadence — quarterly at minimum, continuously if your IaC pipeline and policy-as-code guardrails are mature enough.

The domains above — IAM, storage, networking, logging, secrets, containers, IaC — are not independent. A misconfigured IAM role that grants access to an unencrypted S3 bucket in a flat network with no logging and credentials baked into a container image deployed by unscanned Terraform is not seven findings. It is one kill chain.

Assess the estate, fix the gaps, automate the guardrails, reassess. That cycle — grounded in CIS, CSA CCM, NIST 800-53, ISO 27017, and the Well-Architected Framework — is what separates organisations that get breached from organisations that do not.

For a scoped cloud security assessment of your AWS, Azure, or GCP environment, see our Security & Risk Assessment service.

FAQ#

How often should a cloud security assessment be performed?

At minimum, quarterly. Ideally, the automated-scan component runs continuously in CI/CD and on a daily or weekly schedule, with a manual deep-dive review quarterly or after any major architectural change. CIS Benchmarks and CSA CCM both expect periodic reassessment, not one-time compliance.

Can automated tools replace a manual assessment?

Automated tools (Prowler, ScoutSuite, Steampipe, cloud-native services like AWS Security Hub, Azure Defender for Cloud, GCP Security Command Centre) are essential for baseline coverage and continuous monitoring. They cannot replace manual review for custom IAM policies, trust-relationship analysis, application-layer secrets exposure, IaC pipeline design, and the judgment calls that turn a list of findings into a prioritised remediation plan.

We use a single cloud provider. Does this checklist still apply?

Yes. Every section is structured per-provider. Focus on the CLI commands and CIS Benchmark references for your provider. The framework mappings (NIST, CSA CCM, ISO 27017) are cloud-agnostic and apply regardless.

What is the difference between a cloud security assessment and a penetration test?

A cloud security assessment reviews configuration against a recognised baseline — it answers "is this environment configured securely?" A cloud penetration test attempts to exploit misconfigurations and vulnerabilities to demonstrate real-world impact — it answers "what can an attacker actually do?" The two are complementary: the assessment finds the gaps, the pen test proves which gaps are exploitable and chains them into attack paths.

Our cloud provider says we passed their compliance check. Are we secure?

Cloud-provider compliance dashboards (AWS Security Hub, Azure Secure Score, GCP Security Command Centre) are useful triage tools that measure configuration against a subset of their own recommendations. They do not cover cross-account trust analysis, IaC pipeline security, secrets in source control, container runtime configuration, or the custom IAM policies specific to your application. Passing a provider's built-in check is a starting point, not an attestation of security.

Where do CIS Benchmarks, CSA CCM, and NIST 800-53 overlap?

Extensively. CIS Benchmarks provide the prescriptive per-service configuration checks. CSA CCM provides the cloud-specific control domains. NIST 800-53 provides the comprehensive control catalogue. A well-structured findings report maps each finding to all three: the CIS check that flagged it, the CSA CCM domain it falls under, and the NIST control family it traces to. This triple mapping satisfies compliance teams anchored on any one of the three frameworks.