Illustrated by Jeff Prymowicz
Every check we run, what proves it, and who owns the fix.
A cloud environment rarely becomes risky because a team ignored security outright. More often, the estate changes faster than the operating habits around it. Accounts multiply, permissions drift, and a new service goes live on a Friday while the team is already working through the next priority. Evidence needed to explain the decision then sits across tools and tickets.
The assessment should produce a usable view of the present state: running services, access paths, and conditions that could lead to harm. This checklist turns that view into work people can finish. It contains 65 checks for AWS, Azure, and Google Cloud, with a verification approach, evidence to retain, and a suggested owner for the fix. Use it as a first pass, for audit preparation, or in a working session with an assessor. Start with the environment that exists today, rather than an old architecture diagram.
Get the Working Checklist
The working checklist is available without a form. It mirrors the on-page table and adds status, notes, due date, exception approval, and retest fields. Those fields matter because a finding without an owner or follow-up date tends to remain open in practice.
Download the working Google Sheet: Cloud Security Assessment Checklist v1.0
What the Assessment Covers
A cloud security assessment examines cloud assets, controls, architecture, and the operating practices around them. The output identifies gaps, documents why they matter, and orders the remediation work so a team can act. It is not a sweep through settings to generate a score.
An assessment and an audit have different jobs. An audit asks whether the available evidence meets a stated requirement. The assessment looks directly at the environment: account structure, identity paths, public exposure, logging, encryption, and the routines that keep controls in place after the first review. A penetration test has a separate purpose: it tests whether an attacker can turn a weakness into a usable path through a defined environment. The three can sit within one security program, but they do not answer the same question.
At Cloud Security Partners, we start with the estate and the business risk tied to it. A configuration report may identify a public storage policy. The next questions are more useful: does it expose production data, has someone accepted the exception, and will the team detect the next policy change before it becomes another finding?
Using the Checklist
Set the scope before opening the provider-specific checks. List the accounts, subscriptions, projects, regions, applications, and data stores that matter. Flag systems that are internet-facing, handle sensitive data, or grant administrative access. A focused first pass is more useful than a review that tries to cover every corner and never reaches a conclusion.
Then use the AWS, Azure, or Google Cloud column that fits your environment. The instructions are starting points, not a claim that every organization uses the same services. Capture evidence as you work: a policy export, configuration screenshot, ticket, test result, or concise written decision. Mark a check N/A when it does not apply, and explain the reason. The explanation will be needed when the scope is reviewed later.
Assign an owner and a status for each finding. Critical findings usually present a direct attack path or data exposure and require immediate attention. High findings point to a material control failure. Medium findings belong in the plan too, particularly when several point to the same operating weakness. Use the due date, exception approval, and retest fields to make the decision visible. A discussion in a meeting is not a resolution.
Finally, group related fixes before opening a long run of tickets. One adjustment to a deployment role or identity baseline can close several rows. In the same way, one weak process can generate dozens of findings. That pattern is often where the meaningful work begins.
Keep the assessment practical. A finding should give the owner enough context to decide what to change without asking the assessment team to repeat the review. If a risk is accepted, record the scope of the exception, who approved it, and when it will be reconsidered. That record is as useful as the technical evidence when a different engineer returns to the work months later.
The Checklist, by Domain
The published page should show the full 65-row table as HTML, grouped under the nine domains below. On mobile, the table should scroll horizontally; it should not become a screenshot or embedded spreadsheet. The companion Sheet is the editable version.
Scope & Governance
Establish the shape of the estate first: accounts, subscriptions, projects, regions, owners, criticality, required tags, and recorded exceptions. An owner should be able to explain what the resource supports, where it runs, and how it would be restored. Without a reliable ownership picture, a team cannot secure or recover the resource with confidence. This domain also finds orphaned resources and regions that expanded beyond the intended footprint.
Identity & Access
Cloud incidents often become costly through identity. Examine MFA, federation, long-lived keys, privileged roles, external trust, workload identities, and break-glass access. Review root, tenant, and organization administrator accounts separately. Their use should be rare, protected, and visible in monitoring.
Data Protection
Look at encryption at rest and in transit, public storage, database access, key-management roles, secret handling, backups, and restoration testing. Encryption alone does not settle this part of the assessment. A bucket may be encrypted and still have a permissive policy; a backup that has never been restored remains an assumption.
Network Security
Identify every public endpoint, then decide whether it needs to be public. Treat “reachable from the internet” as a deliberate design choice, not a default state. Remove unrestricted management access, narrow broad firewall rules, segment sensitive workloads, use private access paths where appropriate, control egress, and watch for changes to the public surface. Public services also need edge protections such as DDoS coverage, web application firewall rules, and sensible rate limits.
Workload Security
Review images, patching, container scans, workload identities, serverless permissions, runtime monitoring, and secret exposure. Managed cloud services reduce some operating-system work, but they also make it easier to lose sight of what runs by default and what a deployment has changed. Teams still need to know what code is running, what it can access, and how suspicious behavior will be noticed.
Logging & Monitoring
A security team cannot respond to events outside its view. Check that audit logs cover each account and region, reach a protected destination, stay available for the required period, and produce alerts that someone will use. Look closely at identity and policy changes, public exposure, disabled logging, and high-severity findings that are still open.
Incident Response
Maintain cloud-specific runbooks and test identity or workload containment. A useful runbook names the account or role a responder needs, the first containment action, and the evidence to preserve. Confirm that responders can read the logs during an incident, and preserve evidence without granting broad access to it. Discovering that a responder cannot reach the logging account during a live compromise is not a workable plan.
Secure Delivery & Infrastructure as Code
Infrastructure as code reduces repeatable configuration mistakes when the pipeline is protected as carefully as the workloads it deploys. Review branch protection, peer review, IaC scans, deployment identities, production approvals, drift, secret handling, and artifact integrity. The aim is to stop the same finding from returning with the next deployment.
Resilience & Third Parties
Close with recovery and outside access. Review vendor identities, connected services, recovery objectives, backup protection, deletion safeguards, DNS and certificate ownership, and continuity planning for a provider outage. These checks may not draw the same attention as a public database, but they shape the damage from an ordinary failure.
Framework Mapping
The checklist provides a domain-level crosswalk to CIS Benchmarks, NIST SP 800-53 Rev. 5, ISO/IEC 27001:2022 Annex A, SOC 2 Trust Services Criteria, and PCI DSS v4.0. Use it to connect technical evidence to the framework that applies to your organization. It is not a substitute for scope: control applicability still depends on your systems, data, contracts, and regulatory obligations.
A framework mapping gives a finding useful context. It should not become a paper exercise. If a control appears only in a policy document and no one can demonstrate it in the environment, the assessment should record that gap.
The crosswalk gives different teams a common way to discuss the work. Engineering sees the configuration issue; risk owners see the business exposure; compliance teams trace the related requirement. Each view serves a purpose, but none replaces the others. The underlying evidence remains the basis for the decision.
The Assessment Questionnaire
Before the review, bring together the people who can answer a few direct questions. Which accounts and regions are in scope? Which applications and data stores are business-critical? What identity provider governs normal access? Where do cloud and workload logs go? Which frameworks, customer commitments, or audit dates are driving the work? How is infrastructure deployed? When was the last restoration test? Which vendors and external identities can reach cloud data or workloads?
This is not administrative busywork. The answers direct the team to the highest-value areas and keep an engineer from guessing who owns a database, a policy exception, or a production account.
Ask for access and artifacts early. Delays rarely come from the check itself; they come from waiting for a diagram, a log owner, an exception record, or approval to examine a production account. A short kickoff that names the contacts and expected evidence keeps the review moving without expanding its scope.
What We Do With the Results
Scope
We confirm the estate, priorities, data, and decision makers before testing begins. Clear scope keeps a team from spending a week on a low-risk sandbox while a production identity path remains unclear.
Evidence Gathering
We collect configuration exports, identity coverage, diagrams, logging details, deployment evidence, and approved exceptions that show how the environment works now. Good evidence lets another person examine the material and reach the same conclusion.
Testing and Validation
We pair manual review with automated checks. For high-risk findings, we validate the actual impact within an approved scope. That avoids treating every configuration issue as either exploitable or harmless without evidence.
Findings and Severity
Each finding should state the affected resources, condition, evidence, risk, and practical fix. The point is not to hand a team a stack of warnings. It is to provide a sequence of decisions they can act on.
Remediation and Retest
The team assigns owners, agrees on timing, records approved exceptions, and verifies that the fix worked. A retest matters because a closed ticket can leave the underlying access path, deployment pattern, or missing alert in place.
Retesting should look at the condition that produced the finding, not only the ticket status. For example, a permission change may appear correct in one account while a similar role remains open elsewhere. The work is complete when the risk is addressed in the intended scope and the evidence reflects the current state.
Where Tools Help and Where Judgment Remains
Cloud-native asset inventory, configuration, logging, and threat-detection services save time. AWS Config, Security Hub, GuardDuty, Microsoft Defender for Cloud, Azure Policy, Security Command Center, and related tools are useful inputs. They are good at locating configuration states and surfacing conditions worth review. They cannot decide which accounts carry the most risk, whether an exception is justified, whether a role fits the architecture, or whether a team can complete the remediation. Somebody still has to make those calls.
Frequently asked questions
How often should we work through this checklist?
Make this checklist part of the annual baseline. Return to the relevant checks after a major architecture change, when a new account or region is introduced, ahead of a compliance deadline, or after a critical vulnerability class affects your services. Systems with greater exposure may need a shorter review cycle.
Can we run this ourselves, or do we need an external assessor?
Many teams can complete a substantial portion of the checklist internally. Bring in an external assessor when independent judgment matters, a material attack path needs validation, identity or cross-account design is hard to untangle, or the findings need to become a prioritized work plan.
How long does it take to work through?
A focused single-account review can take a few days. A multi-account or multi-cloud assessment takes longer, especially when identity, logging, data flows, and evidence are owned by different teams. The technical review may move quickly once access is in place; coordination is often the slower part.
Who needs to be involved from our side?
The right group is usually small: cloud engineering, identity, the owner of logging and detection, the application or data owners in scope, and the person authorized to approve risk exceptions. A large committee is unnecessary. What matters is having people who can answer the questions and make decisions.
Does this still apply if we only use one cloud provider?
Yes. Work from the provider column that applies to your environment, mark the other columns N/A, and keep the nine-domain structure. One provider does not remove the underlying concerns: identity, data, public exposure, logging, recovery, and deployment practices still require review.
Need an assessment team?
The final scope reflects the number of accounts, resources, and environments, along with testing depth, the compliance driver, and the reporting required. A focused engagement can give a small team its first clear set of fixes. A larger estate may call for a broader assessment and a retest plan.
Cloud Security Partners can review the details, explain the decisions that matter, and help engineers close the gaps. Use Get Started to scope the work, or Contact Us to discuss the environment first.
.
About the Author
Peter Karman is a Senior Principal AI Engineer at DryRun Security. He builds agentic, LLM-powered code-review systems that review PRs, ground findings in evidence, and alert of potential security issues. With 17+ years across infrastructure, networking, and software engineering, he designs dependable review pipelines, grounds findings in evidence, and instruments the process so performance meets real-world cost and latency constraints. He previously led engineering and AppSec initiatives as a Principal Engineer at companies like Leafly and AnyRoad.
Cloud Security Partners partnered with DryRun Security for this blog. DryRun Security is the industry’s first AI-native, agentic code security intelligence solution. Powered by their proprietary Contextual Security Analysis engine, they secure software built for the future by helping security and developer teams quiet noise, gain insights, and surface risks that pattern-based scanning tools inherently miss.
Stay in the loop.
Subscribe for the latest in AI, Security, Cloud, and more—straight to your inbox.
