You do not need an expensive tool or a week of consulting to get a baseline read on your cloud security posture. With 30 minutes and access to your cloud console or CLI, you can check the six areas that matter most and identify whether you have critical gaps that need immediate attention.
This checklist is not a substitute for a comprehensive architecture review. It will not catch subtle design flaws or complex trust relationship issues. But it will tell you whether the fundamentals are in place, and it will surface the high-severity misconfigurations that attackers exploit first. Think of this as triage: identify the most dangerous issues so you can prioritize your time and budget effectively.
Check 1: MFA Enforcement (5 Minutes)
Start with identity because it is the most common initial access vector in cloud breaches. In AWS, open the IAM Credential Report (`aws iam generate-credential-report` then `aws iam get-credential-report`) and check two things: is MFA enabled for the root account, and is MFA enabled for every IAM user with console access? Any console user without MFA is a breach waiting to happen. Pay special attention to the root account: it should have a hardware MFA token, and there should be no access keys associated with it.
In Azure, check Entra ID's MFA registration report under Security > Authentication Methods. Look for users with the "Registered" status as "No" and cross-reference with users who have privileged roles (Global Administrator, Security Administrator, etc.). In GCP, check 2-Step Verification enforcement in the Google Admin console under Security > 2-Step Verification. Ensure it is enforced for all users in the organization, not just recommended.
If you find users without MFA, especially administrators, this is your highest-priority finding. MFA blocks over 99% of account compromise attacks. Fix this before moving to the next check if possible.
Check 2: Service Account Permissions and Access Key Age (5 Minutes)
Service accounts and long-lived access keys are the second most common compromise vector. In AWS, pull the credential report and sort by `access_key_1_last_rotated`. Any key older than 90 days is overdue for rotation. Any key older than 365 days is a critical finding. Then check for IAM users or roles with `AdministratorAccess` or `*:*` policies attached. In a well-governed environment, only a break-glass role should have full administrative permissions.
In GCP, list service account keys with `gcloud iam service-accounts keys list` for each service account and check the creation date. Also check whether any service accounts still have the default Editor role, which grants write access to almost every resource in the project. In Azure, review app registrations and their client secrets: check expiration dates and whether any secrets are shared across multiple applications.
The goal is not to inventory every permission in 5 minutes. The goal is to find the outliers: the admin-level service account key that was created two years ago and has never been rotated, or the service account with project-level Editor that is used by a single application. These are the credentials attackers target first.
Check 3: Security Group Rules and Public-Facing Resources (10 Minutes)
This check takes the most time because it requires reviewing network rules and identifying public exposure. In AWS, query security groups for rules allowing inbound traffic from 0.0.0.0/0 or ::/0 on any port other than 80 and 443: `aws ec2 describe-security-groups --query "SecurityGroups[?IpPermissions[?IpRanges[?CidrIp=='0.0.0.0/0']]]"`. Any security group allowing SSH (22), RDP (3389), database ports (3306, 5432, 1433, 27017), or all ports from the internet is a critical finding.
Next, identify public-facing resources. In AWS, check for EC2 instances with public IP addresses that are not behind a load balancer, RDS instances with public accessibility enabled, and Elasticsearch/OpenSearch domains with public endpoints. In Azure, check for VMs with public IPs, SQL databases with public endpoint enabled, and storage accounts with public blob access. In GCP, check for compute instances with external IPs and Cloud SQL instances with public IPs.
Document everything you find that is publicly accessible and ask: does this need to be publicly accessible? In our experience, at least 30% of publicly exposed cloud resources do not need public access and are exposed only because it was the path of least resistance during deployment.
Check 4: Logging and Encryption Coverage (10 Minutes)
Spend the remaining time on two foundational controls. For logging, verify that your cloud audit trail is active and storing logs durably. In AWS, run `aws cloudtrail describe-trails` and confirm at least one trail is active, is multi-region, and is writing to an S3 bucket. Check whether the S3 bucket has versioning and MFA Delete enabled to prevent log tampering. In Azure, check that Diagnostic Settings are configured at the subscription level. In GCP, confirm Admin Activity audit logs are present (they should be by default).
For encryption, check whether encryption at rest is enforced across your primary data stores. In AWS, verify that the account-level EBS encryption default is enabled (`aws ec2 get-ebs-encryption-by-default`), that S3 bucket default encryption is set on all buckets, and that RDS instances use encryption. In Azure, check that storage account encryption is enabled (it should be by default) and that SQL TDE is active. In GCP, encryption at rest is enabled by default for most services.
If you find gaps in logging or encryption, these are high-priority fixes. Missing logging means you cannot detect or investigate incidents. Missing encryption means a compromised storage volume or backup exposes data in plaintext. Both are common compliance failures as well.