A cloud security baseline turns a broad security program into a repeatable review. This checklist helps teams assess AWS, Azure, and Google Cloud environments against the same practical control areas, assign ownership, preserve evidence, and identify changes that require action.
Overview
Cloud providers secure the underlying infrastructure, but customers remain responsible for configuring services, managing identities, protecting data, and monitoring activity according to their architecture and risk profile. The exact control names and console locations vary between AWS, Azure, and Google Cloud, yet the questions a security team should ask are broadly similar.
Use this cloud security baseline checklist as a recurring review rather than a one-time audit. It can support new-account provisioning, monthly configuration checks, quarterly risk reviews, architecture changes, and pre-audit preparation. Record the scope of each review, the date completed, the person responsible, the evidence collected, and the remediation deadline for every exception.
A baseline is not a substitute for threat modeling or provider-specific benchmarks. It is a practical starting point for identifying common exposure paths, including excessive permissions, public storage, missing logs, weak recovery arrangements, and unowned alerts. Teams handling personal data should also connect technical findings to their data protection obligations. For related governance work, see the cloud compliance evidence checklist and the GDPR compliance checklist for cloud startups.
What to track
Track both the control status and the evidence supporting it. A control marked “enabled” without a recent configuration record, test result, or accountable owner is difficult to rely on during an incident or review.
| Control area | Review questions | Useful evidence |
|---|---|---|
| Identity and access | Are administrative accounts protected with strong authentication? Are permissions limited to required tasks? Are unused users, keys, roles, and service principals removed or disabled? | Identity inventory, privileged access list, access review record, authentication settings, and recent changes |
| Network exposure | Which workloads have public addresses? Are inbound rules limited to approved sources and ports? Are management interfaces separated from public application traffic? | Network diagrams, firewall or security group exports, approved exception list, and exposure scan results |
| Encryption and secrets | Is sensitive data encrypted in transit and at rest where appropriate? Are keys managed, rotated, and access-controlled? Are secrets kept out of source code, images, and logs? | Key inventory, secret-store configuration, certificate records, repository scan results, and documented exceptions |
| Logging and monitoring | Are administrative, authentication, network, and application events collected? Are logs protected from unauthorized alteration and retained for a defined period? Does someone investigate meaningful alerts? | Central logging configuration, alert rules, retention settings, sample investigations, and ownership matrix |
| Storage and databases | Are object stores, snapshots, databases, and file shares private by default? Are access policies reviewed? Are test and production data separated? | Resource inventory, access policy review, public exposure results, and data classification records |
| Vulnerability management | Are operating systems, dependencies, container images, and managed services monitored for weaknesses? Are findings prioritized by exposure and business impact? | Scanner output, patch records, image reports, remediation tickets, and accepted-risk approvals |
| Containers and orchestration | Are images built from controlled sources and scanned before deployment? Are workloads running with only the permissions and capabilities they need? Are cluster control planes and workloads separated appropriately? | Build pipeline records, image policies, workload manifests, cluster configuration, and deployment approvals |
| Backups and recovery | Are critical systems backed up automatically? Are backups protected from accidental deletion and unauthorized access? Has restoration been tested against stated recovery objectives? | Backup policy, job results, restore test record, recovery plan, and system owner sign-off |
For each row, use a consistent status such as pass, partial, fail, or not applicable. “Not applicable” should include a short explanation; otherwise, it can conceal an unreviewed service. Add a risk rating, accountable owner, target date, and compensating control when a baseline requirement cannot be met immediately.
Provider-specific implementation should follow the same logic. For example, review account or subscription structure, identity roles, virtual networks, storage permissions, key management, audit logging, security findings, and backup services in each environment. Do not assume that a control enabled in one account, subscription, or project automatically applies everywhere.
Cadence and checkpoints
A useful cadence combines automated checks with human review. Automation can identify drift quickly, while owners are needed to determine whether a change is expected, approved, and safe.
Monthly configuration review
Review newly public resources, privileged identities, inactive credentials, security group or firewall changes, logging failures, unencrypted resources, backup failures, critical vulnerability findings, and unresolved alerts. Compare the current inventory with the previous review so that unexplained additions and removals receive attention.
Quarterly control review
Reconfirm data classifications, business-critical workloads, access assignments, network diagrams, recovery priorities, retention settings, and third-party integrations. Ask service owners to approve their results rather than treating the checklist as an infrastructure-only task. If a provider or product has changed its control names or service behavior, update the mapping in the review record.
Event-driven checkpoints
Run an additional review after creating a new cloud account, project, or subscription; deploying a new internet-facing service; changing an identity model; moving regulated or sensitive data; adopting a managed database or container platform; acquiring a company; or responding to a security incident. These events can alter exposure more quickly than a fixed calendar review.
Keep an evidence folder or compliance workspace with dated exports, screenshots where necessary, configuration reports, tickets, approvals, and test results. A clear evidence trail supports internal accountability and can help with a SOC 2, ISO 27001, or GDPR review. See the cloud incident response plan for guidance on connecting monitoring and recovery controls to incident handling.
How to interpret changes
Not every change represents a security failure. A new public endpoint may be an approved release, and a new privileged role may be required for a defined operational task. The review should establish whether the change was expected, authorized, limited in scope, monitored, and reversible.
Prioritize findings using practical factors:
- Exposure: Is the resource reachable from the public internet, another tenant, or a broad internal network?
- Data sensitivity: Does it process credentials, personal data, production records, or confidential business information?
- Privilege: Could the weakness allow account takeover, broad data access, or control of other workloads?
- Exploitability: Is the issue easy to trigger, automated, or dependent on several conditions?
- Recovery: Can the team detect misuse, revoke access, restore data, and communicate effectively?
Escalate combinations rather than isolated metrics. A publicly reachable management interface, an overly broad administrative role, and incomplete logging create a different level of concern than any one finding alone. Similarly, a backup that exists but has never been restored should not be treated as equivalent to a tested recovery process.
When remediation is delayed, document the reason, interim protection, owner, approval, and expiry or review date. Avoid permanent exceptions with no reassessment. For cloud-specific exposure patterns, use the cloud misconfiguration checklist alongside this baseline.
When to revisit
Revisit this article and your internal checklist at least monthly for active environments and formally every quarter. Refresh the provider-specific implementation whenever AWS, Azure, or Google Cloud changes a relevant service, control name, default setting, logging capability, identity feature, or security recommendation. Also review the checklist when security benchmark revisions or internal control requirements change.
At the next review, start with the previous exception register. Close items only when evidence shows that the risk was reduced, not merely when a ticket was marked complete. Compare inventory, exposure, privileged access, logging coverage, vulnerability backlog, backup success, and restore-test results with the prior period.
To make the process actionable, assign one owner for the baseline and a named owner for each control area. Schedule the next monthly review before closing the current one. Then run a short checkpoint after every material architecture change. This turns a static cloud security checklist into a living control process that can detect configuration drift, preserve useful evidence, and give engineering teams a clear path from finding to remediation.
