Cloud security assessment: what it covers, and why IAM comes first

A cloud security assessment is a structured review of how your cloud accounts, workloads, and services are configured, who can reach them, and how an attacker would move through them if they got a foothold. It covers identity and access management, network exposure, data storage, logging and detection, workload configuration, and the way your CI/CD pipeline pushes code into production. The point is not a checklist for its own sake. The point is to find the paths an attacker would actually take and to rank them by how much damage they enable.

We put identity and access management first because in cloud environments identity is the perimeter. There is no firewall that separates inside from outside in the way there was on a data center network. An over-permissioned role, a stale access key, or a misconfigured trust relationship lets an attacker reach data and workloads directly, often without touching a single network control. Most serious cloud breaches we read about trace back to credentials and permissions, not to a clever exploit of a patched service. So we start where the risk concentrates. This post explains what a full assessment covers, how we run it, what you receive, and how it connects to the frameworks regulated companies have to satisfy.

What a cloud security assessment actually covers

A complete assessment looks at the cloud control plane and the workloads that run on top of it. The control plane is where identity, policy, networking, and account structure live. The workload layer is your applications, containers, functions, and databases. Both matter, and weaknesses in one usually compound weaknesses in the other. We assess them together so the findings reflect real attack paths rather than isolated misconfigurations.

• Identity and access management, including human users, service accounts, roles, trust policies, key rotation, and the gap between permissions granted and permissions actually used.
• Network exposure, covering security groups, public IP assignment, load balancer rules, VPC peering, and any service unintentionally reachable from the internet.
• Data storage and protection, looking at object storage permissions, database access controls, encryption at rest and in transit, and whether sensitive data sits in places it should not.
• Logging, monitoring, and detection, checking whether control plane and data plane events are captured, retained, and actually feeding something that would catch an intrusion.
• Workload configuration, including container images, serverless functions, virtual machine hardening, secrets handling, and the privileges each workload runs with.
• CI/CD and infrastructure as code, where pipeline credentials, build systems, and Terraform or CloudFormation state often hold more access than the workloads they deploy.

Why identity comes first

In a traditional network, you had to cross a boundary to reach an asset. In the cloud, the boundary is a policy decision. An identity with the right permissions can read a storage bucket, assume another role, or spin up compute from anywhere with an API call. That changes the order of work. We map identity before we map the network, because the identity graph tells us what an attacker gains the moment they compromise any single credential.

The hardest problems are rarely a single bad policy. They are chains. A developer role can assume a deployment role, the deployment role can write to a function, the function runs with a role that can read the production database. None of those steps looks alarming on its own. Together they let an attacker walk from a low-value foothold to your most sensitive data. We trace these chains by hand and with tooling, then we show you the shortest path to each crown-jewel asset. If you want a deeper treatment of why identity quietly accumulates risk, we wrote about that in the quiet risk hiding in cloud IAM.

Most cloud breaches do not start at the perimeter. They start with a valid credential and permissions that were never reviewed.

The components of IAM we examine

Identity work splits into a few concrete areas. We look at each one for the gap between what is configured and what the business actually needs, because that gap is where attackers live. Over-provisioning is the default state of most cloud accounts, since it is faster to grant broad access than to scope it correctly, and almost nobody goes back to tighten it later.

• Human identities and federation, including whether single sign-on is enforced, whether multi-factor authentication is required everywhere, and whether anyone still logs in with long-lived local credentials.
• Service identities and roles, where we measure the difference between permissions granted and permissions used over the trailing 90 days to find roles that can be safely narrowed.
• Trust and assumption policies, because a role that any account or any principal can assume is a direct path in, and these are easy to create and hard to notice.
• Access keys and secrets, looking for keys that are old, unused, embedded in code, or stored in places that get backed up and shared without anyone thinking about it.
• Privilege escalation paths, where a seemingly limited identity can grant itself more access by editing its own policy, passing a role, or invoking a service that runs with higher privilege.
• Break-glass and root account handling, since the most powerful identities are often the least monitored and the rarely used ones tend to keep weak protection.

How we run the assessment step by step

We work in a fixed sequence so nothing important gets skipped and so the findings build on each other. Scoping comes first, then read-only access, then analysis, then validation, then reporting. We do not need to break anything to assess it, and for production environments we keep all testing non-destructive unless you explicitly ask us to validate exploitation in a controlled window.

• We scope the engagement with you, agreeing which accounts, regions, and workloads are in play, what the crown-jewel assets are, and what the rules of engagement allow.
• We take read-only access through a dedicated audit role, then pull the full configuration of identity, networking, storage, logging, and workloads across every account in scope.
• We build the identity and network graph, mapping who can reach what, and we identify the shortest paths from low-privilege footholds to sensitive data.
• We validate the most serious findings, confirming that a path is real rather than theoretical, and we document the exact steps so your team can reproduce and verify the fix.
• We rank everything by exploitability and business impact, not by raw severity scores, so you know what to fix this week versus this quarter.
• We deliver the report and walk your engineering and security teams through it, then we retest the fixes you make so you have evidence the risk is closed.

What you actually receive

The deliverable is a report your engineers can act on and your auditors can read. We avoid the generic scanner export that lists 4,000 low-severity items and helps no one. Every finding includes what it is, where it is, how an attacker uses it, what it leads to, and the specific change that fixes it. Where the fix is a policy or an infrastructure-as-code change, we give you the corrected configuration, not a vague recommendation.

• A prioritized findings report that ranks issues by real exploitability and business impact, with the attack paths drawn out so the reasoning is visible.
• Concrete remediation guidance for each finding, including corrected IAM policies and infrastructure-as-code snippets where that is the right fix.
• An identity and network exposure map that shows how access flows through your environment, which is often the first time teams see the full picture.
• An executive summary written for leadership that states the top risks in plain language and ties them to business consequences and regulatory exposure.
• A retest of remediated findings so you hold evidence that each issue is actually closed, which matters for both internal sign-off and external audit.
• A reusable baseline that your team can compare future changes against, so the assessment improves your ongoing posture rather than being a one-time snapshot.

Assessment versus penetration test versus automated scanning

These three things get conflated, and the confusion leads people to buy the wrong one. An automated scanner checks configurations against known rules and runs continuously. A cloud security assessment is a deeper, human-led review of configuration and identity that finds the chains a scanner cannot reason about. A penetration test simulates an active attacker trying to reach a goal. You usually want more than one, and the right mix depends on your maturity. We covered the broader distinction in PTaaS versus pentest versus automated scanning and in why a scan is not a pentest.

• Automated scanning is cheap, fast, and continuous, but it reports against rules and misses multi-step paths and business context, so it generates volume without priority.
• A cloud security assessment is human-led and reasons about identity chains and blast radius, which is the part scanners cannot do, but it is a point-in-time view.
• A penetration test proves whether a path is exploitable end to end and is the right tool when you need evidence that a control holds under attack.
• The strongest programs run continuous scanning for drift, a periodic assessment for depth, and targeted penetration testing against the highest-value systems.

How often you should assess

Cloud environments change every day. A configuration that was clean last quarter drifts as teams ship features, add services, and grant access under deadline pressure. We recommend a full assessment at least annually, plus a focused review after any major architectural change such as a new account structure, a migration to containers, or the introduction of a new data store. If you deploy frequently, continuous monitoring fills the gap between assessments by catching drift as it happens.

Regulated companies often have a cadence forced on them anyway. A SOC 2 audit window, an ISO 27001 surveillance audit, or a DORA-driven testing requirement all create natural points to assess. We would rather you tie the assessment to a real risk event than to a calendar date alone, but a calendar floor is better than waiting for an incident to tell you the timing.

Common mistakes and red flags

We see the same patterns across most environments we review. They are rarely exotic. They are the predictable result of speed beating discipline, and they are fixable once you can see them clearly.

• Wildcard permissions in IAM policies, where a role is granted action and resource access far beyond what it uses, usually because scoping it correctly took more time than anyone had.
• Public storage buckets and databases reachable from the internet, often created for a quick test and then forgotten, holding data nobody remembers putting there.
• Long-lived access keys with no rotation, embedded in scripts or CI configuration, which become the single most valuable thing an attacker can steal.
• Logging that exists but goes nowhere, so events are captured and then never reviewed, which means an intrusion can run for weeks without anyone noticing.
• CI/CD pipelines that hold more privilege than the workloads they deploy, turning the build system into the softest and most powerful target in the environment.
• Treating a clean scanner report as proof of security, when the scanner never reasoned about the identity chain that leads straight to your customer data.

Cost and effort

The effort scales with the number of accounts, the diversity of services, and how much identity sprawl has accumulated. A single well-organized account takes far less time than a sprawling estate of dozens of accounts with inconsistent structure. The honest driver of cost is complexity, not headcount or a price list. We scope every engagement before we quote it, and we tell you where the time will go. If you want a sense of how security testing engagements get priced more broadly, our write-up on what penetration testing costs explains the same logic that applies here.

The cheapest assessment is the one that finds the issue before an attacker does. The expensive version is the incident response, the regulatory notification, and the lost trust that follow a breach. We frame the spend that way because that is the actual comparison, not assessment cost against zero.

How this ties to compliance

A cloud security assessment maps cleanly onto the frameworks regulated companies have to satisfy. It is not the whole of compliance, but it produces a large share of the technical evidence those frameworks demand. ISO/IEC 27001:2022 organizes its 93 Annex A controls across four themes, and many of the technological controls are exactly what an assessment evaluates, from access control to logging to secure configuration. We connect findings to the relevant control so the work counts twice, once for security and once for the audit. Our ISO 27001 certification guide goes through that in detail.

• For SOC 2, the assessment generates evidence against the Trust Services Criteria, particularly the security and availability criteria, which auditors expect you to demonstrate with real configuration and not just policy documents. See our SOC 2 readiness guidance.
• For DORA, in force since January 2025, the regulation expects financial entities to test ICT systems and manage ICT risk, and a cloud assessment feeds directly into that testing obligation. Our DORA compliance checklist lays out the requirements.
• For NIS2, Directive (EU) 2022/2555, the assessment supports the risk management and security measure obligations placed on essential and important entities, which we cover in NIS2 explained.
• For organizations running AI workloads in the cloud, the same identity and data exposure questions apply with extra force, since model endpoints and training data create new sensitive targets, a topic we examine in securing LLM applications.

A cloud security assessment gives you an honest map of where an attacker would go and what they would reach, ranked by what it would cost you. We start with identity because identity is where the risk concentrates, then we work outward to network, data, workloads, and pipelines. If you want to see how this fits into our broader application and cloud security work, our cloud security assessment page lays out the engagement model. When you are ready to scope your environment, book a scoping call and we will tell you where the time will go before you commit to anything.