To assess risk in the cloud, use the same method as anywhere else: identify what you are protecting, the threats and weaknesses that apply, how likely harm is and how bad it would be, then decide what to do. What changes in the cloud is who controls each layer, so you must map responsibilities first.
What does a risk assessment actually consist of?
NIST SP 800-30 Revision 1 is the standard reference. It defines risk as a function of the likelihood of a threat event occurring and the potential adverse impact if it does. Its assessment process has four steps: prepare for the assessment, conduct it, communicate the results, and maintain the assessment over time. The conduct step breaks into tasks: identify threat sources and events, identify vulnerabilities and predisposing conditions, determine the likelihood of occurrence, determine the magnitude of impact, and determine risk. NIST places assessment inside a larger cycle of framing, assessing, responding to and monitoring risk.
None of that changes because a workload moved to a cloud provider. What changes are the inputs.
Who is responsible for what?
CISA's Cloud Security Technical Reference Architecture, a multi-agency document, explains that it covers the shared risk model for cloud service adoption, how to build a cloud environment, and how to monitor one through cloud security posture management. The words "shared risk" matter. A provider secures the underlying facilities and services. You remain responsible for how you configure and use them, for your identities, your data and your code. The exact split depends on the service type, so read the provider's own documentation for each service you use.
A practical step: for every service in scope, write who handles patching, configuration, identity, logging and data protection. Gaps in that table are your first findings.
What are the typical cloud weaknesses?
Based on how cloud environments work, rather than on any statistic, the usual areas to examine are identity and access settings that grant more than needed, storage and network settings that expose more than intended, secrets stored in code or images, logging that is off or not kept, and software dependencies that carry known vulnerabilities into workloads. These are categories to check, not a complete list.
A constructed example
A company runs a customer portal on managed containers with a managed database. The assessment starts with a one page responsibility table. The provider handles the physical hosts and the database engine patching. The company handles container images, application code, access rules and backups. The team lists threats such as stolen credentials and a vulnerable dependency, then scores each for likelihood and impact on a simple three level scale. The highest rated item is an administrator role that every developer can assume, with no logging of use. The fix is not exotic: split the role, require MFA, turn on and retain audit logs. The residual risk is recorded with an owner and a review date.
How to check or apply this
- Define scope: which accounts, services and data are in the assessment.
- Inventory assets and classify the data each holds.
- Write a responsibility table per service: provider versus you.
- List threat sources and events relevant to those assets.
- Identify vulnerabilities and predisposing conditions: configuration, identity, dependencies, process.
- Rate likelihood and impact using a scale you define once and apply consistently.
- Decide per risk: reduce, accept, transfer or avoid, with an owner and a date.
- Communicate results to the people who can fund the fixes, and schedule reassessment, since cloud configurations change daily.
Safeguard's SBOM and dependency scanning, reachability analysis and compliance automation can supply evidence for the dependency and control parts of the assessment.
Quick check
Is the cloud provider responsible for my risk?
Only part of it. The provider secures its own layers. You are responsible for your configuration, identities, data and code, and the split varies by service.
How often should a cloud risk assessment be repeated?
NIST includes maintaining the assessment as a step. Reassess on a schedule and after material changes, because cloud configurations change frequently.
Sources
- NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments
- CISA: Cloud Security Technical Reference Architecture
Last reviewed: 18 October 2026.
