Most cloud breaches are not exotic. The 2024 and 2025 reporting from Verizon's DBIR and Mandiant keeps landing on the same few causes: a public storage bucket, an over-privileged role, a security group open to the internet, logging that was never turned on. None of those need a zero-day. They need someone to notice the configuration drifted, which is exactly what a cloud security posture checklist and the discipline behind it, cloud security posture management (CSPM), exist to do.
This checklist is organized into five domains: IAM, Storage, Network, Logging, and Encryption. It maps to the CIS Benchmarks for AWS, Azure, and GCP and calls out provider-specific controls where they differ. Use it as a baseline you verify with automated tooling, then validate with testing, because a green dashboard tells you the config matches the baseline, not that it survives an attacker.
Cloud security posture management is the continuous practice of comparing your cloud configuration against a security baseline and flagging anything that drifts away from it. Rather than auditing once a year, CSPM tools scan your account on a schedule and alert when a bucket goes public, a role gets a wildcard policy, or encryption is disabled on a new database.
The baselines are well defined. The CIS Benchmarks publish prescriptive, provider-specific controls for AWS, Azure, and GCP, and frameworks like NIST and PCI DSS overlay compliance requirements. Tools such as Prowler and ScoutSuite implement these checks directly, emitting a pass or fail per control with the affected resource:
$ prowler aws --compliance cis_3.0_aws --severity high critical
FAIL s3_bucket_level_public_access_block acme-prod-assets Block Public Access is not enabled
FAIL iam_policy_no_administrative_privileges AdminPowerUsers policy grants Action: "*" Resource: "*"
PASS cloudtrail_multi_region_enabled organization-trail multi-region trail is enabledThe reason posture management exists at all is drift. A locked-down account on Monday can have a public bucket, a wildcard role, and an open security group by Friday because three teams shipped changes nobody reviewed together. CSPM turns that from an annual surprise into a same-day alert. For how this fits into testing, see what to expect from a cloud penetration test.
IAM comes first because identity is the perimeter in cloud. There is no firewall between an attacker with valid credentials and your data, so the strength of your access model sets the blast radius of any compromise. Enforce least privilege ruthlessly: no wildcard * actions or resources, no long-lived access keys where short-lived tokens work, MFA on every human account, and especially on root and Global Administrator.
Audit the privileged tier specifically. In AWS, lock down root and stop iam:PassRole sprawl; in Azure, limit Global Administrator and watch service-principal credentials; in GCP, strip the broad Editor role from default service accounts. A few one-line checks surface the worst offenders fast, and the output is the audit evidence:
$ aws iam list-entities-for-policy \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess \
--query 'PolicyUsers[].UserName' --output text
break-glass legacy-jenkins intern-sandbox <- two of these should not have admin
$ az role assignment list --all --query "[?roleDefinitionName=='Owner'].principalName" -o tsv
backup-automation-sp <- a non-human Owner worth questioningThe IAM privilege-escalation paths covered in our AWS penetration testing guide are exactly what tight IAM hygiene closes off.
The other four domains follow the same least-exposure principle. Storage: block public access at the account level, deny anonymous reads, keep SAS and signed-URL expiry short. Network: default to deny, restrict security groups and NSGs to known sources, avoid 0.0.0.0/0 on management ports (22, 3389, database ports), segment with private subnets. Logging: enable full audit trails (CloudTrail, Azure Activity and Diagnostic logs, GCP Cloud Audit Logs), protect them from tampering, ship them somewhere central. Encryption: encrypt at rest with managed keys, enforce TLS in transit, rotate keys on a schedule, and scope key policies tightly.
Spot-check the high-risk items directly rather than trusting console toggles. The fastest storage check is anonymous access from outside the account:
$ aws ec2 describe-security-groups \
--filters "Name=ip-permission.cidr,Values=0.0.0.0/0" \
--query 'SecurityGroups[].[GroupId,IpPermissions[].FromPort]' --output text
sg-0a1b2c3d 22 3389 <- SSH and RDP open to the world
$ aws s3 ls s3://acme-prod-assets --no-sign-request
2026-05-29 09:14:02 188204 backup-2026-05.sql.gz <- a public database dumpThe checklist visual below groups every concrete control by domain. Treat it as the items to verify, not a one-time gate. Continuous verification is the point, the same argument behind continuous penetration testing.
A posture scanner measures static configuration, not exploitability, so a fully green dashboard can sit on top of a critical chain. The scanner flags a public bucket and a wildcard policy, but it cannot tell you that a scoped-looking role chains through iam:PassRole into a Lambda that runs as admin, or that an SSRF in your app can replay against the metadata endpoint to steal a token the scanner rated as fine. Config and exploitability are different measurements.
On a recent engagement, the client's CSPM dashboard was fully green the week we found an SSRF that reached an IMDSv1 instance and handed us role credentials that read every bucket in the account. Nothing in the config was technically wrong by the scanner's rules; the attack lived in the gaps between controls. The findings table below is that report excerpt, and it is the argument for pairing every posture scan with active testing. Three checks separate a checklist that prevents breaches from one that just passes audits: prove logging is tamper-resistant and centralized (an attacker disables CloudTrail before doing anything noisy), confirm encryption keys are actually scoped (a KMS key with a permissive policy is encryption in name only, since anyone who can call Decrypt holds the data), and test that network segmentation holds under a stolen credential rather than just on paper. Map provider-specific depth through the GCP penetration testing guide and the Azure penetration testing guide.
Run an open-source CSPM scanner rather than checking by hand, on a schedule, and treat new failures as alerts. Prowler runs hundreds of checks across AWS, Azure, and GCP mapped to CIS, NIST, and PCI; ScoutSuite produces a multi-cloud HTML report; CloudSploit offers a second set of detections:
prowler aws --compliance cis_3.0_aws --severity high critical
prowler azure --subscription-ids <sub-id>
scout gcp --user-account --report-dir ./gcp-postureRemediation should be config that cannot drift back, not a ticket. For the most common failures, that means account-level controls: AWS account Block Public Access, an SCP denying public-bucket policies, GCP public access prevention, and an Azure Policy denying public blob access. The AWS account-wide control is one call:
aws s3control put-public-access-block --account-id 111122223333 \
--public-access-block-configuration \
BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=trueAutomation catches drift, but it cannot tell you whether a control actually stops an attacker. A bucket can be private and still leak through an SSRF-stolen token; a role can look scoped and still chain into escalation. That gap is why posture management and penetration testing are complementary, and why running offense continuously through agentic pentesting closes the loop between what your checklist says and what an adversary can actually do.