Most cloud breaches are not the result of a sophisticated exploit. They are the result of a misconfiguration someone meant to fix, an access key that never got rotated, or a storage bucket that was public for testing and stayed that way. Misconfiguration is consistently the leading cause of cloud security incidents, which means most of what you need to get right is achievable without a research team or a big budget. You just need to work through the list.
This is a practical checklist for AWS, GCP, and Azure environments. It is written for the person who owns cloud infrastructure and needs to know what "secure" actually requires, not a vendor's marketing definition of it.
Identity and access management
- Multi-factor authentication on every account with console or API access. Passwords alone are not a control anymore. This applies to root or organization admin accounts especially, since a compromised root credential gives an attacker full control of the environment.
- No standing root or global admin credentials in daily use. Root (AWS), Owner (GCP), or Global Administrator (Azure) accounts should be locked down, used rarely, and logged when they are. Day-to-day work should run through scoped roles.
- Least-privilege IAM policies, not wildcard permissions. A policy that grants
*:*on a resource because it was faster to write during a deploy is a liability that outlives the deploy. Review IAM policies for overly broad grants on a schedule, not just when something breaks. - Access keys and service account credentials on a rotation schedule. Long-lived keys that never expire are a common finding in posture reviews. Where possible, use short-lived credentials or workload identity instead of static keys at all.
- Federated or single sign-on for human users. Centralizing authentication through an identity provider makes offboarding actually work. A departed employee's local cloud console password is easy to forget about.
Network configuration
- No storage buckets or databases open to the public by default. S3 buckets, Azure Blob containers, and GCS buckets set to public read are the single most common misconfiguration found in cloud environments, and one of the easiest for an attacker to find with automated scanning.
- Security groups and firewall rules scoped to specific sources, not 0.0.0.0/0. An open SSH or RDP port to the entire internet is an invitation, not a convenience. Restrict management ports to known IP ranges or a VPN.
- Private subnets for anything that does not need to face the internet. Databases, internal APIs, and backend services should sit behind a load balancer or bastion, not directly exposed.
- VPC flow logs or equivalent network logging enabled. You cannot investigate what you did not log. Flow logs are inexpensive to turn on and often the difference between confirming a breach and speculating about one.
Data protection
- Encryption at rest enabled on storage, databases, and disks. All three major providers make this close to a one-line configuration change. There is rarely a good reason to skip it.
- Encryption in transit enforced, not just available. TLS should be required, not optional, on every endpoint that handles customer or business data.
- Key management through a managed KMS, with defined ownership. Know who can access encryption keys and audit that access. Customer-managed keys give you more control than provider-managed defaults, but only if someone is actually managing them.
- Backups that are tested, not just scheduled. A backup you have never restored from is a hypothesis, not a control. Ransomware and accidental deletion are both real risks, and untested backups fail you at the worst possible moment.
Logging and monitoring
- CloudTrail, Cloud Audit Logs, or Azure Activity Log enabled and centralized. These are the record of who did what, and they need to be turned on before an incident, not after.
- Log retention long enough to support an investigation. Thirty days is rarely enough. Most compliance frameworks and reasonable investigations expect closer to a year.
- Alerting on high-risk events. Root login, IAM policy changes, security group modifications, and disabled logging should all trigger an alert, not just a log entry nobody reads.
- A defined process for reviewing alerts. Monitoring that nobody looks at is not monitoring. Assign ownership, even if it is one person checking a dashboard weekly.
Configuration management
- Infrastructure as code where practical. Manual console changes are how drift and one-off misconfigurations accumulate. Terraform, CloudFormation, or equivalent tooling gives you a reviewable, repeatable record of what your environment actually looks like.
- Automated posture scanning against a benchmark. AWS Security Hub, GCP Security Command Center, Azure Security Center, or a third-party CSPM tool checked against CIS benchmarks will catch drift between deliberate reviews.
- A documented patching and update cadence for anything you manage. Managed services shift some of this burden to the provider, but self-managed compute, containers, and dependencies are still your responsibility.
- Regular manual review, not just automated scanning. Automated tools catch known patterns. They miss context, like a permission that is technically scoped correctly but no longer matches how the team actually works.
Where this checklist tends to break down
Every item on this list is well documented by the cloud providers themselves. The gap is rarely knowledge, it is time and prioritization. Environments accumulate exceptions over months of shipping under deadline pressure, and by the time someone goes looking, the drift between the intended configuration and the actual one can be significant.
This is what a cloud security assessment is built to catch. A structured posture review across AWS, GCP, or Azure walks through exactly this kind of checklist against your live environment, flags the gaps in order of actual risk, and gives you a prioritized remediation plan instead of a generic scan report. For teams that are also working toward a framework like SOC 2, the same misconfigurations that create breach risk are usually the ones an auditor will flag, so closing them early pays off twice. If that is where you are headed, our compliance readiness work picks up from there.
If you want a second set of eyes on your cloud environment, or you are not sure which of these items apply to your setup, get in touch and we will walk through it together.