Risk Assessment is one of the smallest families in NIST 800-171 , but it plays an outsized role in whether the rest of your security program is coherent. It is the family that helps an organization decide which threats matter most, which vulnerabilities require urgent action, which weaknesses can be accepted temporarily, and where limited security resources should go first. Without a functioning risk assessment process, every other control family becomes more reactive. You are patching without context, prioritizing controls without a clear threat model, and making compliance claims without a defensible basis for your decisions.

That is what makes this family so important in a CMMC certification assessment. A C3PAO is not just looking for a vulnerability dashboard or a spreadsheet full of open issues. They are evaluating whether your organization has a repeatable process for identifying risk, assessing the likelihood and impact of threats to CUI systems, scanning for vulnerabilities across the assessment boundary, and remediating those vulnerabilities according to that risk context.

GCC High provides several tools that can inform this family well. Microsoft Defender Vulnerability Management supports endpoint vulnerability visibility. Secure Score highlights security posture gaps across Microsoft 365. Compliance Manager can help identify implementation gaps against frameworks such as NIST 800-171. Defender for Cloud may support Azure-hosted resources where applicable. But none of those tools perform the control for you. Risk Assessment remains heavily dependent on your methodology, your risk register, your prioritization logic, and your remediation discipline.

This is Part 11 of our NIST 800-171 GCC High Configuration Guide. It assumes you already have a functioning Microsoft 365 GCC High tenant, understand the shared responsibility model, and are implementing against NIST SP 800-171  Rev. 2.

Risk Assessment family overview

The Risk Assessment family includes three controls focused on periodically assessing risk to operations, assets, and individuals; scanning for vulnerabilities in systems and applications; and remediating vulnerabilities in accordance with risk assessments.

At a practical level, this family breaks into two implementation groups. One control depends heavily on explicit technical configuration because it requires active vulnerability scanning across the assessment boundary. The other two are shared in the sense that Microsoft provides useful supporting telemetry and scoring mechanisms, but your organization still has to perform the actual analysis, decide what risks matter most, and govern remediation accordingly.

Operationally, the family tends to cluster around three activities: understanding risk, identifying exposure, and acting on the results. That is why this family is often more strategic than it first appears. It is not just about finding vulnerabilities. It is about deciding what those vulnerabilities mean in the context of your actual CUI environment and then proving that the organization responds accordingly.

If Configuration Management defines what the environment should look like, Risk Assessment helps determine where the organization is most exposed and what should be addressed first.

RA controls and CMMC scope

The Risk Assessment family applies across the full CMMC assessment boundary. Any in-scope endpoint, server, cloud workload, application, network device, storage location, or supporting service that stores, processes, or transmits CUI should be considered in the assessment process.

That matters because risk is rarely distributed evenly. In a GCC High environment, a heavily used SharePoint site with CUI, a privileged administrator workstation, an exposed VPN concentrator, and an internal line-of-business application do not all carry the same consequences if compromised. The purpose of this family is not just to collect risks mechanically. It is to analyze those systems in the context of business impact, threat relevance, and operational exposure.

This is also where organizations often discover scoping blind spots. They may perform a reasonable risk assessment on core Microsoft 365 services while ignoring specialized assets, web applications, network appliances, mobile devices, or third-party tools that are still part of the real CMMC boundary. A mature RA implementation therefore has to start with scope discipline. If the boundary is incomplete, the risk assessment will be incomplete too.

How risk assessment works in GCC High

Before walking through the controls, it helps to understand the architecture you are actually using in GCC High.

Microsoft Defender Vulnerability Management is usually the most important technical input for this family. It provides visibility into software weaknesses, exposed devices, security recommendations, and vulnerability trends across onboarded endpoints. For organizations using Defender for Endpoint well, it often becomes the primary operational feed into both scanning and remediation decisions.

Secure Score provides a different kind of input. It is not a risk assessment by itself, but it does surface security posture gaps and improvement actions across Microsoft 365 workloads. Those gaps should not automatically be treated as risks of equal priority, but they are useful inputs into the organization’s analysis.

Compliance Manager can also help identify control gaps in relation to NIST 800-171 and related frameworks. Again, that is not the same thing as performing a risk assessment, but it can help identify issues that should be evaluated and tracked in the risk register.

Defender for Cloud may be relevant where Azure Government resources are in scope. Supplemental tools such as Nessus, Qualys, or web application scanners may also be necessary if the environment includes assets that Defender Vulnerability Management does not adequately cover.

The key point is that GCC High gives you useful evidence sources. It does not make the actual risk decisions for you. The organization still needs a methodology, a review cadence, an ownership model, a risk register, and a remediation framework that turns technical findings into governed decisions.

The two RA controls that depend on both platform inputs and organizational process

3.11.1 Periodically assess risk to operations, assets, and individuals

RA.L2-3.11.1

This control requires the organization to periodically assess the risk to operations, assets, and individuals resulting from the operation of organizational systems and the associated processing, storing, or transmitting of CUI.

This is primarily a governance control. Microsoft provides supporting inputs, but the actual assessment has to be performed by the organization. That means adopting a methodology, defining the scope, identifying relevant threats and vulnerabilities, evaluating likelihood and impact, documenting results, and maintaining those results over time.

For most CMMC environments, a NIST-aligned methodology such as NIST SP 800-30 is the most natural fit. What matters most is not the brand name of the methodology, though. What matters is that the organization can explain how it identifies threats, how it evaluates risk, how it assigns ownership, and how it distinguishes between risks that must be mitigated and risks that are formally accepted.

A strong implementation usually produces a current risk assessment report and a maintained risk register. The risk register should not just list generic issues. It should show the asset or process affected, the threat or vulnerability involved, the business or mission impact, the likelihood, the overall rating, the owner, and the disposition. That disposition matters. Risks should be mitigated, accepted, transferred, or otherwise addressed through a defined decision process rather than left in limbo.

Microsoft Secure Score, Compliance Manager, and Defender Vulnerability Management can all feed this process well. But they are not substitutes for it. One of the most common weaknesses in this family is mistaking a technical dashboard or compliance gap list for a risk assessment. Those tools can inform the analysis, but they do not replace the analysis itself.

This control usually fails when the organization has no formal methodology, no current risk assessment, no maintained risk register, or no evidence that the assessment is updated as the environment changes.

3.11.3 Remediate vulnerabilities in accordance with risk assessments

RA.L2-3.11.3

This control is where the family becomes operational. It requires vulnerabilities to be remediated in accordance with risk assessments, which means the organization is expected to remediate based on priority and context rather than on an ad hoc or purely reactive basis.

That distinction is important. The requirement is not “patch everything immediately.” It is “make remediation decisions according to a defined understanding of risk.” In practice, that usually means having remediation timelines that reflect severity, exploitability, asset importance, CUI relevance, and business impact.

For many organizations, Defender Vulnerability Management becomes the main operational tracking layer here. It can surface exposed devices, weaknesses, recommendations, and remediation activity. Intune update policies and other patching workflows then become part of how those remediation decisions are executed. But the key is that remediation should align with the organization’s defined timelines and prioritization logic, not simply occur whenever capacity becomes available.

That also means exception handling matters. Some vulnerabilities cannot be remediated on the ideal timeline because a patch is unavailable, the asset is operationally sensitive, or remediation would break a critical dependency. Those cases do not automatically violate the control, but they do require a documented risk decision, compensating safeguards where appropriate, ownership, and a review date.

This control often becomes weak when remediation timelines are undefined, critical findings sit open too long without documented exception handling, or vulnerability management and risk assessment operate as disconnected processes. If the organization says it prioritizes risk but patches only by convenience or by whichever issue generates the most noise, the control becomes hard to defend.

The RA control that requires explicit technical implementation

3.11.2 Scan for vulnerabilities periodically and when new vulnerabilities are identified

RA.L2-3.11.2

This control requires vulnerability scanning across organizational systems and applications, both on a defined cadence and in response to new vulnerabilities that affect the environment.

In GCC High, Defender Vulnerability Management is the most natural starting point for this control because it provides continuous assessment for onboarded endpoints. For Windows, macOS, Linux, mobile devices, and other supported assets within Defender coverage, that can satisfy much of the scanning requirement in a practical way.

But that is rarely the whole answer. Most organizations have at least some assets that Defender does not fully cover, such as network devices, web applications, firewalls, VPN appliances, specialized servers, or third-party hosted systems. Those assets still need to be included in the scanning strategy if they are inside the CMMC boundary. That is where supplemental tools often become necessary.

The most important implementation point here is that the scanning strategy must be defined, not assumed. Continuous assessment from Defender Vulnerability Management is useful, but the organization still needs to document how it interprets “periodic” scanning for each asset category, how it handles new critical CVEs, what additional tools it uses for uncovered assets, and how results move into the remediation process.

This is also where ad hoc scanning procedures matter. When a major vulnerability is announced, the organization should not have to invent its response process in real time. There should already be a method for checking whether the affected software exists in the environment, identifying impacted devices or applications, and initiating remediation or temporary safeguards.

This control usually fails when scanning covers only endpoints, scanning frequency is not documented, ad hoc CVE response procedures do not exist, or findings are generated but not actually reviewed.

A practical PowerShell reference for the RA family

Because the Risk Assessment family depends on both governance evidence and technical inputs, PowerShell is most useful for verifying the supporting telemetry rather than proving the entire control. The commands below focus on common evidence points assessors ask for, including Secure Score history, Secure Score improvement actions, managed device visibility, and update policy coverage that supports scanning and remediation.

Export Secure Score history (supports 3.11.1)

This command exports recent Secure Score history so the organization can show how its Microsoft 365 security posture has changed over time.

# Connect to Microsoft Graph (GCC High)
Connect-MgGraph -Environment USGov -Scopes "SecurityEvents.Read.All"

# Export Secure Score history
Get-MgSecuritySecureScore -Top 30 |
    Select-Object CurrentScore,
                  MaxScore,
                  CreatedDateTime,
                  @{N="Percentage";E={[math]::Round(($_.CurrentScore / $_.MaxScore) * 100, 1)}} |
    Export-Csv -Path "RA_3.11.1_SecureScore_History.csv" -NoTypeInformation

This is useful for showing that the organization reviews posture trends rather than looking at a single point-in-time score.

Export Secure Score improvement actions (supports 3.11.1)

This command exports Secure Score improvement actions that may inform the organization’s risk analysis and prioritization process.

# Connect to Microsoft Graph (GCC High)
Connect-MgGraph -Environment USGov -Scopes "SecurityEvents.Read.All"

# Export Secure Score improvement actions
Get-MgSecuritySecureScoreControlProfile -All |
    Select-Object ControlCategory,
                  Title,
                  MaxScore,
                  ImplementationStatus,
                  UserImpact,
                  Rank |
    Sort-Object MaxScore -Descending |
    Export-Csv -Path "RA_3.11.1_SecureScore_Actions.csv" -NoTypeInformation

This does not replace a formal risk assessment, but it can help show which Microsoft 365 security gaps were considered as part of the organization’s broader risk process.

Export managed device inventory and compliance status (supports 3.11.2)

This command exports the managed device population, which helps support vulnerability scanning coverage and scope validation.

# Connect to Microsoft Graph (GCC High)
Connect-MgGraph -Environment USGov -Scopes "DeviceManagementManagedDevices.Read.All"

# Export managed device inventory
Get-MgDeviceManagementManagedDevice -All |
    Select-Object DeviceName,
                  UserPrincipalName,
                  OperatingSystem,
                  OperatingSystemVersion,
                  ComplianceState,
                  ManagementAgent,
                  LastSyncDateTime,
                  IsEncrypted |
    Export-Csv -Path "RA_3.11.2_Device_Inventory.csv" -NoTypeInformation

This is helpful when showing which systems are covered by the scanning program and whether they are actively managed.

Export Windows device update visibility (supports 3.11.3)

This command provides a basic export of Windows device status that can support patching and remediation review.

Get-MgDeviceManagementManagedDevice -All |
    Where-Object { $_.OperatingSystem -eq "Windows" } |
    Select-Object DeviceName,
                  UserPrincipalName,
                  OperatingSystemVersion,
                  ComplianceState,
                  LastSyncDateTime |
    Export-Csv -Path "RA_3.11.3_Windows_Update_Status.csv" -NoTypeInformation

This does not replace full vulnerability remediation evidence, but it helps demonstrate visibility into the managed Windows population supporting patch and remediation workflows.

Export Intune update ring policies (supports 3.11.3)

This command exports Intune device configuration profiles related to Windows Update for Business.

# Connect to Microsoft Graph (GCC High)
Connect-MgGraph -Environment USGov -Scopes "DeviceManagementConfiguration.Read.All"

# Export Windows update-related configuration profiles
Get-MgDeviceManagementDeviceConfiguration -All |
    Where-Object { $_.AdditionalProperties.'@odata.type' -like "*windowsUpdateForBusiness*" } |
    Select-Object DisplayName,
                  Id,
                  LastModifiedDateTime |
    Export-Csv -Path "RA_3.11.3_Update_Ring_Policies.csv" -NoTypeInformation

This helps verify that the organization has defined update policies supporting its remediation timelines.

Export recent device sync status (supports 3.11.2 and 3.11.3)

This command helps identify devices that may not be checking in regularly, which can affect both vulnerability visibility and remediation reliability.

Get-MgDeviceManagementManagedDevice -All |
    Select-Object DeviceName,
                  UserPrincipalName,
                  OperatingSystem,
                  ComplianceState,
                  LastSyncDateTime |
    Sort-Object LastSyncDateTime |
    Export-Csv -Path "RA_Device_LastSync_Status.csv" -NoTypeInformation

Devices that are not syncing consistently may fall out of visibility for scanning, patching, and compliance workflows.

What evidence your C3PAO will usually want to see

For the RA family, assessors usually want evidence that the organization can show both the analysis and the action.

That typically includes the risk assessment methodology, the most recent completed risk assessment, the current risk register, documented risk acceptance records, vulnerability scanning coverage across the CMMC boundary, recent scan outputs or dashboard exports, remediation timelines, remediation tracking evidence, patching or update policies, and examples of exceptions that were formally reviewed rather than ignored.

For 3.11.1 especially, assessors often look for a clear connection between the organization’s stated methodology and the way risks are actually documented. For 3.11.2 and 3.11.3, they usually want to see that findings are not just collected, but prioritized and acted on according to defined expectations.

The strongest evidence packages for this family show an end-to-end story: risks are identified, documented, assigned, tracked, and addressed in a way that reflects the organization’s actual CUI environment.

Common RA findings in real assessments

One of the most common weaknesses in this family is the absence of a true risk assessment. Organizations sometimes have a gap analysis, a list of open tasks, or a consultant spreadsheet, but none of those automatically constitute a documented risk assessment. If the organization cannot show how likelihood, impact, ownership, and disposition were evaluated, the control is weak.

Another recurring issue is incomplete scanning coverage. Defender Vulnerability Management may cover the managed endpoint fleet reasonably well, but web applications, network devices, cloud infrastructure components, or specialized systems remain outside the scanning program. Assessors tend to notice quickly when scanning coverage does not match the actual assessment boundary.

Remediation governance is another common problem. Vulnerabilities may be tracked in a tool, but there are no defined remediation SLAs, no documented exception process, and no evidence that open findings are being prioritized according to business or mission risk. In those cases, the organization has visibility without discipline.

This family also weakens when risk assessment and vulnerability management operate as separate conversations. The risk assessment may identify certain threats as highly relevant to CUI handling, while the remediation process still prioritizes only by raw severity score without considering the environment’s actual context. That disconnect makes it harder to show that vulnerabilities are being remediated in accordance with risk assessments rather than alongside them.

And finally, many organizations struggle to show periodic execution. A risk assessment completed once and left untouched for 18 months is difficult to defend, even if it was good when written. Assessors typically want to see evidence that the organization revisits the assessment and maintains the risk register over time.

How the RA family supports other control families

Risk Assessment is tightly connected to the rest of the framework.

Configuration Management supports RA because secure baselines and controlled configurations give the organization a reference point for identifying weaknesses and exposure. System and Information Integrity overlaps directly with RA because flaw remediation and vulnerability handling are operational expressions of risk-informed security management. Security Assessment depends on RA because the organization’s assessment and monitoring efforts should be informed by what it has determined to be highest risk. Incident Response also feeds back into RA because incidents often reveal new threats, weaknesses, and prioritization needs that should influence future risk decisions. Access Control and the other technical families are strengthened when their implementation reflects the actual threat environment rather than generic assumptions.

That is why this family matters so much despite having only three controls. Risk Assessment is the family that helps turn security activity into security judgment.

Get started

Risk Assessment is where your organization decides whether its security program will be strategic or reactive. The methodology needs to be clear, the risk register needs to stay current, scanning needs to reflect the full assessment boundary, and remediation decisions need to follow defined priorities rather than convenience.

Secureframe Defense connects directly to your GCC High environment and continuously supports the workflows behind the RA family, including vulnerability visibility and scanning support for 3.11.2, remediation tracking aligned to 3.11.3, and supporting evidence from Secure Score, Compliance Manager, and related control data that can inform 3.11.1. When a C3PAO asks how your organization knows which risks matter most and whether vulnerabilities are being remediated accordingly, the goal is not to point to a stale spreadsheet or a disconnected dashboard. The goal is to show a risk process that is current, documented, and actively used.

See how Secureframe Defense automates CMMC evidence collection for the RA family by scheduling a demo today.