A cloud security checklist is a repeatable list of controls you confirm before launch and reverify on a schedule. The essentials are multifactor authentication on every account, least privilege roles, default encryption, blocked public storage, private networking, central audit logging, automated vulnerability scanning and tested backups. Check each item, record the evidence and rerun the list quarterly.
Guidance is easy to agree with and hard to apply. People nod to enforce least privilege and then ship a role with full administrator rights because a deadline is near. A checklist closes that gap. It turns principles into yes or no questions that an engineer, auditor or manager can answer with evidence.If you prefer narrative guidance first, our companion piece on cloud security best practices covers the reasoning behind many of these measures. Come back here when you are ready to audit.
How to Use This Cloud Security Checklist
Follow four rules so the list produces results rather than paperwork:
Assign an owner to each item. An unowned control is an unchecked control.
Capture evidence. A screenshot, a policy export or a query result beats a verbal "yes."
Automate where possible. Anything you check manually more than twice should become a policy or an alert.
Record exceptions. If a control cannot be met, document the risk, the compensating control and an expiry date.
The thirty items below are written to apply to AWS, Microsoft Azure and Google Cloud, with provider examples where useful.
Phase 1Foundation Checks Before Anything Is Deployed
These cloud security measures protect the account itself. Fix them first, because a weak foundation undermines everything built on top.
1. Root and global administrator accounts are locked down. These accounts use a hardware security key, a shared mailbox that is monitored and are never used for daily tasks. TestReview the last sign in time for the root account; it should be rare and explained.
2. Multifactor authentication is mandatory for all human users. Prefer phishing/resistant factors such as passkeys or security keys. TestRun the provider's credential report and confirm no console user lacks a second factor.
3. Accounts follow a multiaccount or multiproject structure. Separate production, development, logging and security tooling. TestConfirm no production workload shares an account with experiments.
4. Organization level guardrails exist. Service control policies, Azure Policy or organization policy constraints block dangerous actions, such as disabling logging, regardless of local permissions. TestAttempt a prohibited action in a sandbox and confirm it fails.
5. Billing and security contacts are current. Providers send abuse and compromise notices to these addresses. TestSend a test message and confirm it reaches a monitored group.
Phase 2Identity and Access Checks
6. Roles follow least privilege. Permissions are scoped to specific actions and resources, with no wildcard administrator on workloads. TestUse the access analyser tools to list unused or overly broad permissions.
7. Workloads use temporary credentials. Instance roles, managed identities and workload identity federation replace stored keys. TestSearch for active long lived access keys and justify or remove each.
8. Privileged access is timebound and approved. Justintime elevation is required for administrator roles. TestCheck that standing membership in privileged groups is limited to emergency accounts.
9. Joiner, mover and leaver processes are enforced. Departing staff lose access the same day. TestCompare the HR leavers list with active identities.
10. Service accounts are inventoried and owned. Every nonhuman identity has an owner, a purpose and a rotation or expiry plan. TestList service accounts with no recent activity.
11. Application authorization is tested separately. Cloud IAM does not stop a logged in user from opening someone else's record. Verify that your applications prevent horizontal access, as described in our article on broken object level authorization and vertical escalation, covered in broken function level authorization.
Phase 3Data Protection Checks
12. Data is classified and tagged. Stores holding regulated or confidential data are labelled. TestSample ten storage resources and confirm each has a classification tag.
13. Encryption at rest is enabled by default. Object storage, volumes, databases, snapshots and backups are encrypted. TestQuery configuration for any unencrypted resource; the answer should be none.
14. Encryption in transit is enforced. TLS 1.2 or higher is required and plain HTTP is rejected. TestRun a TLS scan against public endpoints and confirm legacy protocols are disabled.
15. Keys are managed, rotated and separated. People who administer keys differ from those who use them. TestReview key policies and confirm rotation is on.
16. Secrets live in a secrets manager. Nothing sensitive appears in repositories, images or environment files. TestRun a secret scanner against code and build artifacts.
17. Public access to storage is blocked at the account level. Exceptions go through approval. TestEnumerate buckets or containers with public read and confirm each is intentional.
18. Backups are immutable, separated and restoretested. Copies live in a different account with deletion protection. TestPerform a restore drill and record the time taken.
Phase 4Network and Perimeter Checks
19. Workloads are segmented by sensitivity. Databases sit in private subnets with no direct internet route. TestReview routing tables for unexpected internet gateways.
20. Management ports are not open to the internet. SSH and RDP are reached through bastion or session services. TestScan your public address space for ports 22 and 3389.
21. Firewall rules default to deny. Cloud firewall configuration permits only required sources and ports and unused rules are removed. TestCompare flow logs with rules and prune anything idle for ninety days.
22. Public web applications and APIs sit behind a web application firewall. Rules are tuned, not left at defaults. TestReview blocked versus allowed request ratios and false positives monthly.
23. Private connectivity is used for managed services. Private endpoints keep traffic off the public internet. TestConfirm database and storage traffic resolves to private addresses from inside the network.
Phase 5Workload and Application Checks
24. Images are minimal, scanned and rebuilt regularly. TestVerify the pipeline fails builds containing critical known vulnerabilities.
25. Instance metadata is hardened. The newer tokenbased metadata service is required. TestQuery configuration for instances still allowing the legacy version.
26. Infrastructure code is scanned before deployment. Templates are checked for open storage, wideopen rules and disabled logging. TestConfirm the scan is a required step in the pipeline.
27. Design reviews include a threat model. New architectures are examined for trust boundaries and attack paths before launch. A practical starting point is our guide to threat modeling. TestEach new service has a dated threat model on file.
28. Code changes are reviewed for security. Reviewers check input handling, authorization and secret use. Our secure code review guide offers a repeatable method. TestSample recent pull requests for evidence of security review.
Phase 6Detection and Response Checks
29. Audit logging is everywhere and protected. CloudTrail, Activity Log or Cloud Audit Logs cover every account and region and are stored in a separate, writeprotected location. TestConfirm no region or project lacks logging and that log deletion is blocked.
30. Alerts and a response plan exist and are rehearsed. High signal alerts cover root signing, logging changes, new privileged keys and public exposure and the team has practised the playbook. TestRun a tabletop exercise at least twice a year and record lessons learned.
How to Prioritise When Many Items Fail
Your first run will probably show failures and that is normal. The goal is to fix the right things in the right order rather than chase a perfect score on day one.Rank by exposure first. A weakness reachable from the internet, such as public storage, an open management port or an access key leaked in a repository, outranks an internal misconfiguration that requires an attacker to already be inside.
Then rank by blast radius. Ask what an attacker could reach if this one control failed. An overly broad administrator role or a shared service account touches far more than a single mislabelled database, so it deserves earlier attention.Then consider effort. Some of the highest value fixes are also the cheapest, enabling default encryption, blocking public access at the account level and turning on multifactor authentication usually take hours, not weeks. Do those immediately while longer projects such as network redesign are planned.
A simple three tier model works well:
Fix now (within days)items that expose data or credentials to the internet, plus any gap in logging or multifactor authentication.
Fix soon (within a month)excessive permissions, unrotated keys, unscanned images and missing guardrails.
Plan and schedule structural improvements such as segmentation changes, private connectivity and restore drill automation.
What Good Evidence Looks Like
Auditors, customers and your own leadership will ask how you know a control works. Build a small evidence pack for each checklist item so answers are fast and consistent. A useful record contains:
The control statement, written as a yes or no question.
The owner and the date of the last check.
The method used, such as a console export, a query, an automated policy result or a scan report.
The result, including any exceptions and their expiry dates.
The next review date.
Store these records in a controlled location with the same protections you apply to other sensitive operational documents. Where possible, generate them automatically from your posture tooling so they never go stale. Over time the pack becomes valuable for compliance conversations, because it shows not only that controls exist but that they are checked regularly and that failures are corrected.Controls fail when staff do not understand them. Invest in structured application security training for developers and give engineers safe places to practise attacks.
Turning Findings Into Fixes Without Slowing Delivery
Security checks lose support when they feel like roadblocks. Three habits keep the checklist helpful:
Shift checks left. Put infrastructure scanning and policy validation inside the deployment pipeline so developers see problems minutes after writing them, not weeks later in an audit.
Offer paved roads. Provide preapproved templates for common patterns, such as a private database with encryption, logging and backups already configured. Teams choose the secure path because it is also the fastest.
Measure and share progress. Track the percentage of checklist items passing, time to remediate and the number of exceptions. Publishing the trend creates healthy accountability without blame.
Common Checklist Mistakes to Avoid
Treating it as a onetime exercise. Cloud environments drift daily. A list completed at launch and never reopened gives false comfort.
Checking settings but not behaviour. A policy may exist and still be bypassed. Test by attempting the prohibited action.
Ignoring the application layer. Infrastructure controls cannot catch broken business logic. Pair this list with application testing, including API penetration testing for the interfaces your cloud services expose and the habits summarised in our web security best practices article.
Conclusion
A cloud security checklist works because it replaces good intentions with verifiable facts. The thirty controls above move from account foundations through identity, data, network, workload and detection layers, each with a test you can run today. Start by assigning owners and fixing the items that fail, beginning with multifactor authentication, public storage and logging. Then automate the checks, schedule the reviews and rehearse your response. Done consistently, this discipline turns scattered cloud security measures into a dependable, auditable program that improves with every review cycle.More learning paths are available on the AppSecMaster home page.
Frequently Asked Questions (FAQs)
What should a cloud security checklist include?
A solid checklist covers account foundations, identity and access, data protection, network controls, workload hardening, logging and detection and recovery. Each item should be specific enough to answer yes or no, have a named owner and include a way to collect evidence such as a configuration export or scan result.
How often should I run through a cloud security checklist?
Automate the highest risk checks to run continuously, review operational items such as unused keys and vulnerability findings weekly or monthly and perform full owner signoffs quarterly. Run the entire list again after major architecture changes, new provider adoption, mergers or security incidents.
Can one checklist cover AWS, Azure and Google Cloud?
Yes, for the principles. Multifactor authentication, least privilege, encryption, logging and segmentation apply everywhere. Only the service names and exact settings differ. Use a provider neutral list for governance, then add short provider specific appendices with the relevant tools and benchmark references.
Who should own cloud security checklist items?
Ownership should sit with the team that controls the resource. Platform engineers typically own network and account guardrails, developers own application and workload items, data owners own classification and retention and the security team owns detection, standards and independent verification of the results.
Is a checklist enough to be secure?
No. A checklist ensures baseline controls are present, but it cannot anticipate every attack path. Combine it with threat modeling, code review, penetration testing, continuous monitoring and incident drills. Think of the checklist as the floor of your security program, not the ceiling.
