Cloud Security Risk Assessment Guide

What a cloud security risk assessment covers

A cloud security risk assessment evaluates the security posture of an organization's cloud infrastructure — identifying misconfigurations, access control weaknesses, data protection gaps, and cloud-specific threats — then quantifies the resulting business risk. It is not the same exercise as a traditional on-premises risk assessment applied to cloud resources. The differences are structural, not cosmetic.

Four factors make cloud assessments fundamentally different from on-prem:

• The shared responsibility model. In cloud environments, the provider secures the infrastructure layer and you secure everything you build on top of it. Where that line falls varies by service type (IaaS vs PaaS vs SaaS) and by provider (AWS, Azure, and GCP each define it differently). Misunderstanding where provider responsibility ends and yours begins is the single most common source of cloud security gaps.
• Dynamic infrastructure. Cloud infrastructure changes hourly — new instances, modified security groups, changed IAM policies, new storage buckets. A point-in-time assessment captures a snapshot that may be obsolete within days. Cloud assessment methodology must account for this velocity.
• IAM complexity. In traditional environments, access control is largely network-based — firewalls, VLANs, segmentation. In cloud, identity is the new perimeter. IAM policies, service accounts, cross-account roles, and federation configurations create an access control surface that is orders of magnitude more complex than network ACLs.
• Data sprawl. Cloud makes it easy to create storage resources — S3 buckets, database instances, data lakes, message queues — faster than security teams can track them. Sensitive data ends up in locations the security team doesn't know about, governed by permissions the security team didn't approve.

The scope of a cloud security risk assessment covers five domains:

• Identity and access management — IAM policies, service accounts, cross-account roles, federation, privilege escalation paths
• Network security — security groups, NACLs, VPC configuration, peering, transit gateways, exposure to the public internet
• Data protection — encryption at rest and in transit, key management, storage bucket permissions, data classification, sensitive data discovery
• Workload security — container configurations, VM hardening, serverless function permissions, image scanning, runtime protection
• Logging and monitoring — CloudTrail/Activity Log/Audit Log configuration, SIEM integration, alert coverage, incident response readiness

For the general framework that applies to both cloud and on-prem environments, see our security risk assessment guide. This page focuses on the cloud-specific methodology, tools, and deliverables.

The shared responsibility gap

Every major cloud provider publishes a shared responsibility model. The problem is that most organizations assume the provider covers more than it actually does. This assumption gap — not a technology failure — is the root cause of most cloud security incidents.

AWS, Azure, and GCP each define shared responsibility differently, and the line shifts depending on the service type:

• IaaS (EC2, Azure VMs, Compute Engine) — the provider secures the physical host, hypervisor, and network fabric. You own the operating system, applications, IAM configuration, network security groups, and data encryption. This is the most responsibility on the customer side.
• PaaS (Lambda, Azure Functions, Cloud Run) — the provider additionally manages the runtime environment and OS patching. You still own IAM policies, application code, function permissions, and data handling. The attack surface is smaller but the IAM complexity is often higher.
• SaaS (S3, Azure Blob, Cloud Storage) — the provider manages everything except your data, access policies, and configuration. The customer's responsibility is narrower but the misconfiguration surface is deceptively large — a single S3 bucket policy error has caused more breaches than most malware campaigns.

The most common blind spots in the shared responsibility gap:

• IAM policy sprawl. Organizations create IAM policies incrementally and rarely audit them holistically. Over time, policies accumulate permissions far beyond what's needed — overprivileged service accounts, unused cross-account roles, stale federation configurations. The provider doesn't manage your IAM policies; that's entirely your domain.
• Storage bucket permissions. Default bucket configurations vary by provider and have changed over time. Organizations that created buckets years ago may be running with permissions that pre-date current security defaults. Public bucket exposure remains one of the most common cloud security findings.
• Encryption key management. Providers offer managed encryption (AWS KMS, Azure Key Vault, GCP Cloud KMS), but customers must configure it correctly — specifying which keys encrypt which resources, managing key rotation, and controlling who has access to key material. Default encryption is often provider-managed keys; regulated environments typically require customer-managed keys, which adds operational complexity.
• Logging configuration. CloudTrail, Azure Activity Log, and GCP Audit Logs are not fully enabled by default in all configurations. Data event logging (API calls to S3, Lambda invocations) is typically off by default and must be explicitly enabled — and it generates costs. Organizations that skip this configuration lose visibility into the exact events that matter most for incident detection and response.

For automated, continuous checking of cloud configuration against security benchmarks, see our guide to cloud security posture management (CSPM).

Cloud risk assessment methodology: step by step

A cloud security risk assessment follows five phases. Each phase builds on the previous one — skip a phase and the downstream findings are unreliable.

1. Asset discovery and classification

You cannot assess what you haven't inventoried. Cloud asset discovery must cover every account, subscription, and project across every cloud provider the organization uses — including the ones the security team doesn't know about.

Multi-account sprawl is the first challenge. Enterprise organizations routinely have dozens to hundreds of cloud accounts, often created by individual teams without central governance. Shadow IT compounds the problem — departments spinning up cloud resources outside the approved procurement process. The discovery phase must enumerate all accounts, classify them by business function and data sensitivity, and identify orphaned or unmanaged accounts that have fallen outside governance.

Within each account, asset discovery catalogs compute instances, storage resources, databases, network configurations, IAM entities, and serverless functions. Classification assigns data sensitivity labels to each resource — which ones hold PII, PHI, PCI data, intellectual property, or other regulated information. Without classification, risk scoring is meaningless because you can't quantify the impact of a compromise without knowing what data is at stake.

For a deeper look at how to discover and classify sensitive data across cloud environments, see our sensitive data discovery guide.

2. Configuration and posture analysis

Once you know what exists, you assess how it's configured. Configuration analysis checks every cloud resource against established security benchmarks — primarily the CIS Benchmarks for AWS, Azure, and GCP, which provide hundreds of specific configuration checks organized by service and severity.

Manual configuration review at scale is not feasible. An enterprise AWS account may have thousands of security groups, hundreds of IAM policies, and dozens of S3 bucket configurations. This is where CSPM tooling becomes essential — it automates the configuration scan, maps findings to CIS benchmarks and compliance frameworks, and surfaces deviations that require remediation.

Configuration analysis should cover cloud-native security controls as well: VPC flow logs, WAF rules, GuardDuty/Defender/SCC alerts, encryption configurations, and backup policies. Each cloud provider offers its own security services; the assessment must verify they're enabled, correctly configured, and actually generating useful findings.

For a comparison of the tools that automate this phase, see our best CSPM tools 2026 guide.

3. Identity and access review

IAM is the most complex and highest-risk domain in any cloud assessment. In cloud environments, identity has replaced the network as the primary security boundary — and IAM policies are harder to audit than firewall rules.

The review should cover:

• Human IAM policies. Which users have which permissions? Are permissions assigned directly to users (brittle and hard to audit) or through roles and groups (scalable and auditable)? Are there users with administrative access who don't need it?
• Service accounts and machine identities. Service accounts often accumulate more permissions than any human user — and they run unattended. Map every service account, its permissions, when it was last used, and whether its access is scoped to what the service actually requires.
• Cross-account roles. AWS cross-account roles, Azure service principals with access to multiple subscriptions, and GCP service accounts with cross-project permissions create access paths that bypass per-account controls. Map these explicitly — they're common lateral movement paths.
• Privilege escalation paths. Some permission combinations allow a user to escalate their own privileges — creating new policies, assuming higher-privilege roles, or modifying trust relationships. These paths are not obvious from reading individual policies; they emerge from the interaction between policies across the account.

The output of the IAM review is a privilege escalation map — a visual or tabular representation of which identities can reach which resources through which paths, including indirect paths via role assumption and policy chaining.

4. Threat modeling for cloud architectures

Cloud-specific threat modeling extends traditional threat modeling to account for the attack patterns that are unique to — or significantly different in — cloud environments. The MITRE ATT&CK Cloud Matrix provides a structured taxonomy of cloud-specific tactics and techniques.

Key cloud-specific threats to model:

• Credential theft and API key exposure. Cloud APIs are the control plane — stolen credentials give attackers programmatic access to create, modify, and delete resources. API keys committed to public repositories, leaked in log files, or stolen from developer workstations are the most common initial access vector in cloud breaches.
• API abuse and cloud control-plane attacks. Once inside a cloud environment, attackers use the cloud API itself as the attack tool — creating new resources, modifying security groups, exfiltrating data through legitimate API calls that don't trigger traditional security controls.
• Lateral movement via IAM. In traditional environments, lateral movement means pivoting between servers on the network. In cloud, lateral movement often happens through IAM — assuming roles, leveraging service accounts, exploiting cross-account trust relationships. The movement is identity-based, not network-based.
• Data exfiltration through cloud-native channels. S3 bucket replication, database snapshots shared to external accounts, storage transfer services — cloud-native data movement features are also data exfiltration channels that bypass network-level DLP.

5. Risk quantification and prioritization

The final phase translates technical findings into business risk — quantified in dollars so that executives and boards can make informed investment decisions. Without quantification, a cloud assessment produces a list of technical findings with severity labels that mean different things to different audiences.

FAIR-based risk quantification (Factor Analysis of Information Risk) provides the methodology: for each finding, estimate the frequency of threat events and the magnitude of loss if the finding is exploited. The result is an annualized loss expectancy in dollars — the expected cost of leaving the risk unaddressed for one year.

This quantification transforms the remediation conversation. Instead of "this finding is critical severity — fix it first," the conversation becomes "this misconfiguration exposes $2.4M in annualized loss expectancy — here's the remediation cost and the ROI of fixing it." Boards and CFOs respond to the second framing; they struggle with the first.

For the quantification methodology in depth, see our guide to cyber risk quantification. For the underlying formula and worked examples, see the annual loss expectancy calculator.

Cloud security assessment tools

The tooling landscape for cloud security assessment includes cloud-native services, third-party CSPM platforms, and unified risk quantification platforms. Each category serves a different layer of the assessment.

Cloud-native tools (Security Hub, Defender, SCC) are strong first layers for single-cloud environments — they're often free or included with existing licensing and provide baseline posture visibility. For multi-cloud environments or deeper assessment requirements, third-party CSPM platforms provide the cross-cloud normalization and advanced correlation that cloud-native tools lack.

For runtime workload protection — the detection layer that configuration scanning can't replace — see our guide to cloud workload protection platforms (CWPP).

What a cloud assessment should deliver

A cloud security risk assessment is only useful if its deliverables drive action. Too many assessments produce 200-page PDF reports that no one reads. The deliverables below are designed to be actionable across technical, management, and executive audiences.

• Cloud risk register. A structured catalog of every finding: the specific misconfiguration or vulnerability, the affected cloud resource (account, region, service, resource ARN/ID), a risk score (ideally dollar-quantified), and the recommended remediation. The risk register is the primary working document for the remediation team.
• Shared responsibility gap analysis. A mapping of what the cloud provider covers vs what the organization is responsible for — with explicit identification of the gaps where the organization's current controls don't fully cover its side of the shared responsibility model. This is the deliverable that prevents the most common class of cloud security failures.
• IAM privilege escalation map. A visual or tabular representation of identity access paths across the cloud environment — showing which identities can reach which resources through which paths, including indirect access via role assumption, policy chaining, and cross-account trust. Attackers think in access paths; this deliverable forces defenders to think the same way.
• Data flow diagram with classification. A map of where sensitive data lives, how it moves between services, who and what has access to it, and what classification applies to each data store. Sensitive data in locations the security team didn't know about is one of the most consistently impactful findings in cloud assessments.
• Remediation roadmap with SLAs by risk tier. Findings grouped into risk tiers (critical, high, medium, low) with remediation SLAs for each tier — for example: critical findings remediated within 48 hours, high within two weeks, medium within 30 days. The roadmap assigns ownership to specific teams and tracks remediation progress against the SLA commitments.
• Executive summary with dollar-quantified risk exposure. A one-to-three-page summary written for boards and C-suites: total risk exposure in dollars, the top five findings by dollar impact, remediation cost estimates, and the ROI of the recommended investments. This is the deliverable that unlocks budget. Without it, assessment findings compete for attention with every other initiative the leadership team is evaluating.

Common cloud assessment mistakes

Mistake: assessing one account and assuming the rest match

Enterprise organizations run dozens to hundreds of cloud accounts. Assessing the primary production account and extrapolating to the rest is a common shortcut — and a dangerous one. Development, staging, sandbox, and acquired-company accounts routinely have weaker security configurations than the primary account. Attackers know this; they target the weakest account and pivot laterally. The assessment must cover every account, or explicitly document which accounts were excluded and why the risk of exclusion was accepted.

Mistake: skipping identity review in favor of network scanning

Teams with on-prem assessment experience default to network-centric assessments — port scanning, vulnerability scanning, network segmentation review. These are necessary but insufficient in cloud environments where identity is the primary security boundary. An IAM policy that allows s3:* on * resources is a more exploitable finding than an open port in most cloud architectures. The identity and access review must be a first-class phase of the assessment, not an afterthought appended to the network scan results.

Mistake: using on-prem assessment checklists for cloud

Generic cybersecurity assessment checklists (even well-regarded frameworks like NIST 800-53) were designed for environments with physical servers, on-premises networks, and traditional perimeter architectures. Applying them directly to cloud infrastructure produces assessments that check irrelevant controls (physical access to data center) while missing cloud-specific risks (IAM policy sprawl, storage bucket exposure, serverless function permissions). Use cloud-specific benchmarks — CIS Benchmarks for AWS/Azure/GCP, the CSA Cloud Controls Matrix, and provider-native security best practices — as the primary assessment framework.

Mistake: point-in-time assessment without continuous monitoring

A cloud security assessment captures the posture at a moment in time. In cloud environments that change daily, yesterday's assessment may not reflect today's configuration. The assessment is necessary — it establishes the baseline, identifies systemic issues, and creates the remediation roadmap. But it must be paired with continuous posture monitoring (CSPM) — a capability our strategic oversight engagements build into the operating cadence — that catches configuration drift between formal assessments. Without continuous monitoring, the assessment is a snapshot that degrades in accuracy every day after delivery. For the tooling that makes this continuous, see our guide to risk-based vulnerability management.