For Azure Policy vs Defender for Cloud risk evidence, save both products’ dated outputs, but do not treat either as your complete RA.L2-3.11.1 risk assessment. Azure Policy proves whether required governance and configuration rules were met; Defender for Cloud provides findings, recommendations, alerts, and exposure information that can inform risk decisions. Your audit-ready package must also include a defined assessment frequency, a documented risk assessment, assigned owners, treatment decisions, and proof that leadership reviewed the results.
For NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2 practice RA.L2-3.11.1, the assessor is looking for more than a vulnerability report. The requirement is to periodically assess risk to operations, assets, individuals, mission, reputation, and systems that process, store, or transmit CUI. Azure-generated findings are strong inputs, but your company must document what those findings mean to the business and what it decided to do about them.
What evidence taxonomy should you use for RA.L2-3.11.1?
Use a simple evidence taxonomy: artifact → source → owner → cadence. This keeps a small business from collecting piles of screenshots that nobody can explain six months later. Every artifact should answer four questions: What is it? Where did it come from? Who is responsible for reviewing it? How often is it collected or approved?
- Risk assessment record: The primary RA.L2-3.11.1 artifact. It identifies systems handling CUI, threat sources, business impacts, likelihood, risk ratings, and treatment decisions. Source: your risk register or assessment workbook. Owner: business owner or designated security coordinator. Cadence: at least annually and after material changes.
- Defined assessment frequency: A short policy statement or risk-management procedure that says when formal risk assessments occur and what events trigger an out-of-cycle assessment. Source: approved policy or procedure. Owner: company owner, operations manager, or compliance lead. Cadence: review annually.
- Azure Policy compliance export: Evidence of compliant and noncompliant resources against assigned initiatives and policies. Source: Azure Policy portal, Azure Resource Graph, or Azure CLI export. Owner: Azure administrator. Cadence: monthly, plus a snapshot used in each formal assessment.
- Defender for Cloud recommendations and alerts: Security recommendations, secure score trends, attack-path information if licensed, and relevant security alerts. Source: Microsoft Defender for Cloud. Owner: Azure administrator or outsourced IT provider. Cadence: monthly review and at assessment time.
- Risk treatment evidence: Tickets, exception approvals, remediation records, accepted-risk approvals, and compensating-control descriptions. Source: ticketing system, change log, or signed risk register. Owner: the person assigned the action. Cadence: update until closed.
- Management review evidence: Meeting notes, email approval, or signature showing that leadership reviewed significant risks and accepted, funded, transferred, or remediated them. Source: meeting record or approval workflow. Owner: company owner or executive sponsor. Cadence: after every formal assessment.
A practical rule for Azure Policy evidence and Defender for Cloud evidence is this: preserve the underlying export, then preserve the business decision made from it. A recommendation that a storage account permits public access is not, by itself, a risk assessment. The risk assessment explains whether that storage account is in the CUI boundary, whether it contains sensitive engineering data, the likely impact of disclosure, the planned corrective action, and who accepted any remaining risk.
Azure Policy vs Defender for Cloud risk evidence: what should the inventory include?
| Artifact to retain | Azure or business source | What it proves | Owner | Collection cadence |
|---|---|---|---|---|
| Risk assessment procedure with annual and change-triggered frequency | Approved policy repository or controlled SharePoint library | The organization defined how often risk is assessed | Owner or operations manager | Annual review |
| In-scope CUI system inventory | Azure Resource Graph export, CMDB, architecture diagram | Which subscriptions, resource groups, VMs, storage accounts, and users support CUI processing | Azure administrator | Quarterly and before assessment |
| Azure Policy compliance-state export | Azure Policy Insights: Microsoft.PolicyInsights/policyStates |
Configuration compliance and exceptions at a stated point in time | Azure administrator | Monthly |
| Assigned policy and initiative export | Azure Policy assignments and definitions | Which governance requirements applied to the CUI environment | Azure administrator | At assessment and after policy changes |
| Defender for Cloud recommendations export | Microsoft Defender for Cloud recommendations | Identified security weaknesses and remediation status | Azure administrator or MSP | Monthly |
| Relevant Defender security alerts | Microsoft Defender for Cloud alert records or connected Microsoft Sentinel workspace | Whether suspected malicious activity affected systems in scope | Azure administrator or incident-response provider | Monthly review; retain when generated |
| Risk register and treatment plan | Controlled spreadsheet, GRC tool, or ticketing platform | Likelihood, impact, business consequence, decision, due date, and accountable owner | Business owner | Annual assessment and monthly updates |
| Leadership review and risk acceptance record | Signed PDF, approval workflow, or meeting minutes | Management reviewed material operational and reputation risks | Company owner | Each assessment |
Consider a 65-person manufacturer that produces machined aircraft brackets and assemblies. Its engineering team stores controlled drawings in SharePoint and uses an Azure-hosted virtual machine for a production-planning application. A Defender recommendation showing that the VM lacks endpoint protection is useful evidence, but the risk register should translate it into operational terms: ransomware could delay production scheduling, affect delivery commitments, expose CUI drawings, and damage customer trust. The resulting record should identify the system owner, risk score, remediation due date, and whether the company owner approved temporary risk acceptance.
How can you automate collection without relying on screenshots?
Automate recurring exports, but keep the formal risk assessment human-reviewed. Screenshots are fragile because they may omit scope, dates, filters, and resource names. A scheduled export can create repeatable JSON or CSV records, while your assessment record documents the business analysis required by RA.L2-3.11.1.
The Azure CLI example below captures Azure Policy compliance states and Defender for Cloud assessments for one subscription. Run it from an Azure Automation runbook, an Azure DevOps pipeline with a protected service connection, or a secured administrator workstation. The identity running it should have read-only access sufficient for Policy Insights and Defender for Cloud data.
#!/bin/bash
SUBSCRIPTION_ID="11111111-2222-3333-4444-555555555555"
EXPORT_DATE=$(date -u +"%Y-%m-%dT%H%M%SZ")
EXPORT_DIR="./risk-evidence/${EXPORT_DATE}"
mkdir -p "$EXPORT_DIR"
az account set --subscription "$SUBSCRIPTION_ID"
az policy state list \
--all \
--subscription "$SUBSCRIPTION_ID" \
--output json \
> "$EXPORT_DIR/azure-policy-compliance.json"
az security assessment list \
--subscription "$SUBSCRIPTION_ID" \
--output json \
> "$EXPORT_DIR/defender-for-cloud-assessments.json"
az policy assignment list \
--subscription "$SUBSCRIPTION_ID" \
--output json \
> "$EXPORT_DIR/policy-assignments.json"
sha256sum "$EXPORT_DIR"/*.json \
> "$EXPORT_DIR/SHA256SUMS.txt"For ongoing monitoring, configure Defender for Cloud continuous export to a Log Analytics workspace, Event Hub, or Storage Account. Use it to preserve recommendations and alerts over time, but do not assume continuous export replaces a periodic risk assessment. It provides evidence inputs and trends; the company still needs a dated assessment that evaluates likelihood and impact.
For a 28-person aerospace component supplier, an outsourced IT provider can run the export monthly and place it in a controlled evidence folder. The owner can then review only the exceptions: new high-severity Defender recommendations, noncompliant CUI resources, unresolved alerts, and overdue risk treatments. This is manageable without hiring a full-time security employee.
Where should you store evidence and how long should you retain it?
Store evidence in a controlled repository that is backed up, access-restricted, and separate from ordinary working files. A SharePoint document library with versioning, restricted membership, retention labels, and multifactor-authenticated access is often adequate for a small company. Azure Blob Storage can also work if you use private access, encryption, lifecycle rules, and a documented access process.
- Create a folder structure by assessment period, such as
Compliance/RA.L2-3.11.1/2026-Annual-Assessment/. - Keep raw Azure exports in a
01-Raw-Exportsfolder and do not edit them after collection. - Keep the risk register, assessment narrative, treatment plan, and management approval in
02-Assessment-and-Decisions. - Keep remediation tickets, exception approvals, and closure evidence in
03-Treatment-Evidence. - Record the subscription ID, export date and time, collector identity, query or script version, and SHA-256 hash with each automated collection.
- Do not place CUI in filenames, screenshots, or exported notes unless the repository is authorized and protected for CUI handling.
NIST SP 800-171 does not set one universal retention period for RA.L2-3.11.1 evidence. Set a written retention period based on customer contracts, legal obligations, and your assessment schedule. As a practical baseline, retain at least three completed assessment cycles and all evidence supporting any open risk, accepted risk, incident, or customer requirement. Do not delete an older assessment merely because a newer one exists if the older record explains an unresolved decision.
How do you package the evidence so an auditor can follow it?
Give the assessor one index document rather than a large unorganized archive. The index should identify the assessment period, CUI systems in scope, assessment frequency, evidence location, responsible owner, and the date management reviewed the result. Link each significant risk to the specific Azure Policy export, Defender recommendation, alert, ticket, or approval that supports it.
- Start with the approved risk-assessment procedure and highlight the required annual frequency and change triggers.
- Include a one-page scope statement listing the Azure subscriptions, resource groups, applications, and data flows involving CUI.
- Provide the formal risk assessment with likelihood, impact, operational consequence, treatment choice, and accountable owner for each material risk.
- Attach dated Azure Policy compliance exports and Defender for Cloud recommendation exports as supporting inputs, not as the assessment itself.
- Include open remediation tickets, approved exceptions, and evidence that closed actions were verified.
- End with leadership approval, meeting minutes, or a signed acceptance record dated after the assessment review.
This approach shows the distinction assessors expect: Azure tooling identified technical conditions, while the business evaluated their effect on operations, assets, individuals, mission, and reputation. It also makes Azure Policy versus Defender risk evidence understandable to a reviewer who does not have access to your Azure tenant.
Next step: create one RA.L2-3.11.1 evidence folder this week, export your current Azure Policy and Defender for Cloud results, and schedule a short owner review to turn the findings into a dated risk assessment.
