Defender for Cloud can support a defender for cloud CUI risk assessment by providing security posture findings, workload alerts, regulatory evidence, and remediation tracking that feed a documented organizational risk review. For NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2 practice RA.L2-3.11.1, an SMB must define how often it assesses CUI-related risk, evaluate the operational impact of identified conditions, document results, and track risk-treatment decisions. Defender for Cloud is an important evidence source, but it does not replace the formal risk assessment process or the management decision-making behind it.
What does RA.L2-3.11.1 require an organization to assess?
RA.L2-3.11.1 requires the organization to periodically assess risk to operations, assets, and individuals resulting from systems that process, store, or transmit Controlled Unclassified Information (CUI). The assessment must consider more than technical vulnerabilities. It must determine whether a condition could prevent the customer from performing its mission, disrupt business functions, harm people, damage assets, or affect the organization’s image and reputation.
For an Azure-hosted SMB environment, the scope commonly includes Microsoft 365-connected identities, Azure virtual machines, Azure Storage accounts, Azure SQL databases, Azure Kubernetes Service, Azure Virtual Desktop, backup platforms, managed service provider administration tools, and third-party SaaS applications connected to CUI workflows.
An MSSP analyst should help the customer establish a practical review boundary: identify the systems in the CUI enclave, identify connected systems that can affect that enclave, and record the business processes those systems support. A publicly accessible Azure application may be out of scope for CUI storage, for example, but still create material risk if it shares an identity tenant, network, privileged account, or logging platform with the CUI environment.
How does defender for cloud CUI risk assessment support the control?
Defender for Cloud supports the risk-review workflow by consolidating posture assessments, cloud security recommendations, attack-path analysis, threat alerts, asset context, and regulatory compliance data. These findings help analysts identify conditions that could contribute to a CUI-related risk scenario, such as an exposed storage account, missing endpoint protection on a virtual machine, excessive privileges, weak network segmentation, or unavailable backups.
However, Defender for Cloud findings are not automatically a risk assessment. A recommendation stating that a VM is missing endpoint protection is a technical condition. The formal assessment must connect that condition to likelihood and impact: whether the VM processes CUI, whether an attacker could reach it, what controls reduce exposure, and what operational, financial, contractual, or reputational consequences could follow.
| Defender for Cloud evidence | Risk-review use | Example CUI risk conclusion |
|---|---|---|
| Security recommendations and Secure Score | Identify control gaps and prioritize remediation candidates | Storage account permits public network access, increasing the chance of unauthorized CUI access. |
| Defender for Servers alerts | Identify active threats and recurring attack patterns | Repeated suspicious PowerShell activity on a CUI-processing VM may indicate elevated compromise risk. |
| Attack path analysis | Understand how identity, network, and asset exposures combine | An overprivileged account and internet-facing VM create a path to a CUI database. |
| Regulatory compliance dashboard | Map cloud evidence to customer compliance objectives | Missing logging coverage limits the organization’s ability to detect and investigate CUI incidents. |
| Azure Policy compliance results | Verify configuration standards at scale | Unencrypted or noncompliant resources create unacceptable protection and contractual risk. |
What risks should an Azure CUI review include?
The implementation notes for RA.L2-3.11.1 expect risk assessments to consider technical, human, business, and external sources of risk. The assessment should include vulnerabilities, but it should not stop there. A vulnerability scan or Defender for Cloud recommendation is input to the assessment, not the completed assessment itself.
- Business-process risk: poorly designed approval, document-sharing, procurement, backup, and offboarding processes can expose CUI even when Azure services are configured correctly.
- Human-error risk: administrators may assign excessive roles, send CUI to the wrong recipient, disable logging, or deploy resources outside approved landing zones.
- Malicious-action risk: phishing, credential theft, ransomware, insider misuse, compromised vendor accounts, and cloud-console abuse can affect CUI systems.
- Technology-failure risk: unavailable identity services, failed backups, expired certificates, misconfigured Azure Firewall rules, or failed replication can interrupt CUI operations.
- External-event risk: regional outages, ISP disruption, supply-chain failures, and third-party SaaS downtime may prevent required personnel from accessing CUI systems.
- Reputation and contractual risk: a CUI exposure can damage trust with prime contractors, federal customers, insurers, and business partners even if direct financial loss is limited.
How often should an organization perform the RA.L2-3.11.1 risk review?
The organization must define its review frequency and follow it consistently. For most SMB customers, an annual formal assessment is a reasonable baseline when combined with quarterly risk-review meetings and event-driven reassessments. The customer’s policy should name the owner, cadence, assessment method, approval authority, and triggers that require an out-of-cycle review.
Useful triggers include onboarding a new CUI workload, moving CUI to a new Azure subscription or region, a material architecture change, a high-severity Defender for Cloud alert, a confirmed incident, a major supplier change, acquisition activity, significant business-process changes, or a newly identified threat that materially changes likelihood or impact.
Do not confuse continuous Defender for Cloud monitoring with the required periodic assessment. Continuous monitoring provides current evidence; the documented risk assessment is the management process that evaluates that evidence against defined criteria and records treatment decisions.
How should an MSSP implement the Azure risk-review process step by step?
- Define the CUI system boundary. Build or update a system inventory that identifies Azure subscriptions, resource groups, workloads, data stores, identity providers, administrators, vendors, and integrations that process, store, or transmit CUI.
- Set a documented cadence and trigger criteria. Put the annual formal assessment, quarterly review cadence, and event-driven triggers in the customer’s risk assessment procedure. Assign a business owner, typically an executive or system owner, to accept or reject residual risk.
- Enable relevant Defender for Cloud plans. At minimum, evaluate Defender CSPM and workload protections appropriate to the environment, such as Defender for Servers Plan 2, Defender for Storage, Defender for SQL, Defender for Containers, and Defender for Key Vault. Document why plans are enabled or not applicable.
- Collect Azure posture evidence. Export active Defender for Cloud recommendations, high-severity alerts, attack paths, Secure Score trends, Azure Policy compliance, Microsoft Entra ID privileged-role assignments, and backup or recovery evidence for in-scope systems.
- Translate findings into risk scenarios. Describe the threat source, affected asset, weakness, plausible event, likelihood, impact, existing controls, and residual risk. Avoid writing “Critical Defender finding” as the entire risk statement.
- Score and prioritize risk consistently. Use the customer’s defined likelihood and impact criteria. A simple 1-to-5 scale is acceptable when definitions are documented and consistently applied.
- Select treatment actions. Record whether each risk will be mitigated, accepted, transferred, avoided, or monitored. Link mitigation tasks to a ticket, Azure Policy initiative, change request, or project plan.
- Obtain management review. The customer’s authorized management representative should review material risks, approve accepted residual risks, and confirm resource commitments for remediation.
- Retain evidence. Store the assessment report, Defender exports, meeting notes, risk register, approval records, and remediation status in the compliance evidence repository.
The following Azure Resource Graph query can help an analyst export non-healthy Defender for Cloud assessments for review. Validate the output against the CUI scope before attaching it as assessment evidence.
securityresources
| where type =~ "microsoft.security/assessments"
| extend assessmentName = properties.displayName,
status = tostring(properties.status.code),
severity = tostring(properties.metadata.severity),
resourceId = tostring(properties.resourceDetails.Id)
| where status != "Healthy"
| project subscriptionId, assessmentName, severity, status, resourceId
| order by severity asc, assessmentName ascWhat should the documented risk assessment contain?
A defensible RA.L2-3.11.1 assessment should show the reviewer how the customer moved from cloud findings to business decisions. Include the assessment date, scope, CUI systems reviewed, methodology, risk criteria, threat sources, findings considered, risk scenarios, scores, existing safeguards, residual-risk decisions, remediation owners, due dates, and management approval.
For example, a Defender for Cloud assessment identifying unrestricted public network access on an Azure Storage account should be evaluated in context. If the account stores encrypted CUI exports, uses a private endpoint only in intended design, and the public setting was enabled during a migration, the risk statement should address possible unauthorized access, data disclosure, contractual impact, and the corrective action to disable public access and validate private DNS resolution.
What is the RA.L2-3.11.1 compliance checklist?
- Define and approve a written frequency for CUI-related risk assessments.
- Document annual, quarterly, and event-driven review requirements.
- Maintain an inventory of Azure systems and connected services within the CUI boundary.
- Identify organizational operations, assets, individuals, mission functions, and reputation impacts that could be affected.
- Enable and review appropriate Defender for Cloud plans for in-scope workloads.
- Collect Defender recommendations, alerts, attack paths, Azure Policy results, and supporting cloud evidence.
- Use defined likelihood and impact criteria rather than treating vulnerability severity as risk severity.
- Document risk scenarios, existing controls, residual risk, and treatment decisions.
- Assign remediation owners and target dates for risks requiring mitigation.
- Obtain documented management approval for material risks and risk acceptance decisions.
- Retain assessment reports, exports, meeting records, tickets, and closure evidence.
- Reassess after significant system, threat, business, supplier, or incident changes.
Frequently asked questions about Defender for Cloud and RA.L2-3.11.1
Does Defender for Cloud satisfy RA.L2-3.11.1 by itself?
No. Defender for Cloud produces valuable technical and operational evidence, but RA.L2-3.11.1 requires a documented organizational risk assessment with defined frequency, evaluation criteria, business impact analysis, and management decisions. The platform informs the process; it does not perform risk acceptance for the customer.
What is the difference between a vulnerability assessment and a CUI risk assessment?
A vulnerability assessment identifies weaknesses, such as missing patches, insecure configurations, or exposed services. A CUI risk assessment evaluates what could happen if those weaknesses are exploited, how likely that outcome is, how it affects operations and people, and whether the remaining risk is acceptable. This distinction is especially important because RA.L2-3.11.2 addresses vulnerability scanning separately.
How often should Defender for Cloud findings be reviewed for CMMC Level 2?
Defender findings should be monitored continuously or reviewed operationally at least weekly, depending on the MSSP service model and alert severity. The formal RA.L2-3.11.1 risk assessment should occur at the customer-defined interval, commonly annually, with quarterly management review and event-driven reassessment.
What evidence will a CMMC assessor expect for RA.L2-3.11.1?
Expect to provide the risk assessment policy or procedure, completed risk assessments, the defined cadence, risk register entries, Defender for Cloud reports or exports used as inputs, remediation tickets, management meeting records, and documented approvals or risk acceptances. Assessors will look for evidence that the process occurs at the stated frequency and covers CUI-related systems.
Can Secure Score be used as the organization’s risk score?
No. Secure Score is a posture metric that helps prioritize security improvements. It does not represent the organization’s likelihood-and-impact risk rating because it does not account for CUI sensitivity, business criticality, compensating controls, contractual obligations, or the customer’s risk tolerance.
Build a repeatable Azure evidence package for each customer now, then use the next quarterly service review to turn Defender for Cloud findings into management-approved RA.L2-3.11.1 risk decisions.
