Cloud Misconfiguration Checklist: A Practical Security Review for AWS, Azure, and Google Cloud

Overview

Cloud environments change continuously. A new deployment, temporary troubleshooting rule, inherited permission, or unmanaged resource can weaken an otherwise sound security design. The purpose of a cloud configuration review is not to inspect every setting manually. It is to identify high-impact deviations from an approved baseline, confirm that important controls are working, and create an evidence trail for follow-up.

This checklist is designed as a repeatable workflow rather than a one-time audit. Apply it to production first, then extend it to development, testing, shared services, and disaster recovery accounts or subscriptions. Record the cloud provider, account or project, resource, finding, severity, owner, target date, and remediation status for every issue.

Use your provider's current guidance alongside this checklist. The AWS Security Pillar, Microsoft Azure security guidance, and Google Cloud infrastructure security guidance can help translate general controls into platform-specific settings.

What to track

1. Identity and access management

• ☐ Confirm that human users authenticate through a central identity provider where practical, with multi-factor authentication required for administrative access.
• ☐ Review users, groups, roles, service principals, and workload identities for excessive or unused permissions.
• ☐ Check for standing administrative access and replace it with time-limited or approval-based elevation where the platform supports it.
• ☐ Remove terminated users, stale access keys, unused service accounts, and permissions left from completed projects.
• ☐ Confirm that production access is separated from ordinary development access and that break-glass accounts are protected and monitored.

For a deeper review, use the least privilege IAM review checklist for AWS, Azure, and Google Cloud. Track both the number of privileged identities and the age of the oldest unused credential; a rising count or aging credential should trigger investigation.

2. Storage and data exposure

• ☐ Identify object storage containers, databases, file shares, snapshots, and disks that allow public or anonymous access.
• ☐ Check resource policies as well as identity policies. An apparently restrictive user role can still be bypassed by an overly broad resource policy.
• ☐ Confirm encryption is enabled for stored data and that key access is limited to the people and workloads that need it.
• ☐ Review cross-account, cross-subscription, and cross-project sharing for business justification and an expiry or review date.
• ☐ Compare retention settings with approved data retention requirements, particularly for personal, confidential, and regulated data.

Do not treat encryption as a substitute for access control. A correctly encrypted bucket or database can still expose data if an unintended identity can request decryption or read the resource. For retention and backup considerations, see the data retention policy checklist.

3. Network boundaries and public exposure

• ☐ Inventory internet-facing load balancers, virtual machines, containers, APIs, databases, and management interfaces.
• ☐ Check firewall rules, security groups, network security groups, and access control lists for broad sources such as any IPv4 or IPv6 address.
• ☐ Remove unused inbound ports and restrict administrative protocols to approved networks, private connectivity, or a controlled access service.
• ☐ Confirm databases and internal services do not have a public route unless that exposure is deliberate, documented, and protected.
• ☐ Review egress rules where sensitive workloads need to limit outbound destinations or prevent data exfiltration.

For each public endpoint, record its purpose, owner, authentication method, data handled, and expected exposure. An endpoint without a current owner is a useful remediation priority even if no immediate vulnerability is known.

4. Logging, monitoring, and detection

• ☐ Confirm that control-plane activity, authentication events, privileged actions, and important data access events are logged.
• ☐ Send security-relevant logs to a separate account, subscription, or project where ordinary administrators cannot easily alter or delete them.
• ☐ Check log retention, time synchronization, alert routing, and access to the monitoring platform.
• ☐ Test alerts for suspicious sign-ins, privilege changes, public exposure, disabled logging, and unusual data access.
• ☐ Verify that someone owns alert triage outside business hours if the service requires continuous monitoring.

A log that is collected but never reviewed provides limited protection. Use the cloud logging and audit trail checklist to connect logging decisions to incident response requirements.

5. Secrets and software delivery

• ☐ Search repositories, build logs, images, scripts, and configuration files for passwords, tokens, private keys, and connection strings.
• ☐ Store secrets in a managed secret store rather than source code, plain-text environment files, or general-purpose object storage.
• ☐ Review secret access policies, rotation settings, emergency revocation procedures, and recent access activity.
• ☐ Ensure deployment pipelines use short-lived identities and cannot freely modify unrelated production resources.
• ☐ Scan infrastructure-as-code before deployment and require review for changes to identity, networking, encryption, and public exposure.

When a secret is exposed, treat it as compromised until proven otherwise. Revoke or rotate it, investigate use, and document the response rather than simply deleting the visible value.

6. Backups and recovery

• ☐ Confirm that critical workloads have defined backup coverage, recovery objectives, and an accountable owner.
• ☐ Check whether backups and snapshots are encrypted and protected from ordinary production administrators.
• ☐ Review immutability, deletion protection, retention, and cross-region or cross-account copies where appropriate.
• ☐ Perform restore tests and record the actual recovery time, missing dependencies, and corrective actions.

A backup policy is incomplete without a tested restore. The cloud backup security checklist provides a separate review for encryption, immutability, access control, and recovery testing.

7. Configuration ownership and compliance context

• ☐ Tag or otherwise identify resource owner, environment, application, data classification, and retirement date.
• ☐ Compare actual settings with the approved cloud security baseline and document exceptions.
• ☐ Map important resources to the data they process so privacy, retention, and cross-border transfer decisions remain visible.
• ☐ Confirm that infrastructure changes are reviewed, traceable, and reversible.

Cloud security and data protection compliance overlap here. A public storage resource is a technical issue, but the impact depends on the data inside it, the people affected, and the organization's obligations. Keep configuration findings connected to system inventories and processing records where relevant.

Cadence and checkpoints

Use automated checks continuously, but schedule human review on a predictable cadence:

• Every deployment: scan infrastructure-as-code, review high-risk changes, and block known critical misconfigurations before release.
• Monthly: review privileged access, public exposure, firewall changes, secrets, failed alerts, and newly created resources.
• Quarterly: perform a broader cloud security audit checklist across all accounts, subscriptions, projects, environments, and backup locations. Reconfirm owners and test at least one recovery or incident workflow.
• After a major change: repeat the review after an acquisition, migration, identity provider change, new region, new data type, or material architecture change.

Keep a dated record of each review. Useful fields include the number of open findings by severity, average remediation age, public resources without an owner, privileged identities, unencrypted or improperly retained resources, and failed control checks. Trends are often more informative than a single snapshot.

How to interpret changes

Prioritize findings by realistic impact and exposure, not by the number of alerts. A critical finding typically combines sensitive data or a high-value system with public reachability, excessive privilege, weak authentication, or an easy path to compromise. A high finding may be internally reachable or require additional conditions but still deserves prompt action. Medium findings should have an owner and deadline; low findings can be grouped into planned hardening work.

Look for patterns:

• A sudden increase in public resources may indicate an automation or deployment change rather than isolated user error.
• Repeated findings in the same team may point to missing templates, inadequate pipeline checks, or unclear ownership.
• A declining finding count with growing remediation age may indicate that teams are closing easy alerts while difficult risks remain.
• Changes in data classification or application purpose may require updated retention, access, logging, or privacy assessments.

Every exception should state why the configuration is needed, what compensating controls exist, who approved it, and when it expires. Avoid permanent exceptions without periodic reapproval.

When to revisit

Make this cloud misconfiguration checklist part of normal operations rather than an annual scramble. Review it monthly for fast-changing environments and at least quarterly for a broader governance checkpoint. Revisit it immediately after a security incident, near miss, cloud account compromise, major provider feature change, or finding that reveals a weakness in your baseline.

To make the next review practical, finish each session with three actions: assign an owner to every unresolved high-risk finding, update the baseline or automation rule that would prevent recurrence, and schedule a date to verify the fix. Keep provider documentation links and internal control references current as platforms evolve. Teams that treat configuration review as a recurring feedback loop are better positioned to reduce exposure without slowing every infrastructure change.