CMMC Level 2Implementation GuideJune 11, 2026· 11 min read
How to Actually Implement CMMC Level 2 Risk Assessment: A Practitioner's Guide
Risk Assessment is a three-practice domain that deceptively requires more effort than the practice count suggests. Practice 3.11.1 requires a formal, documented risk assessment. Practice 3.11.2 requires periodic vulnerability scanning. Practice 3.11.3 requires remediating vulnerabilities based on the results of those assessments. Together, they form the foundation of a risk-driven security program rather than a compliance-driven one.
The Difference Between a Risk Assessment and a Vulnerability Scan
These two concepts get conflated constantly, and the confusion leads to CMMC findings. A vulnerability scan is a technical tool output: a list of detected weaknesses in specific systems, scored by severity. A risk assessment is a management-level analysis: what are the threats to our organization, what could they do to us, how likely is it, and what are we doing about it?
Vulnerability scan results are one input to a risk assessment. They tell you about technical exposure. A risk assessment also considers physical security, operational processes, third-party risk, insider threat, and business context that a scanner cannot measure. Both are required. Neither replaces the other.
The risk assessment feeds everything else: Your risk assessment results should directly inform your POA&M (what risks are you actively mitigating?), your security investment decisions (which vulnerabilities get resources first?), and your incident response priorities (which systems and data matter most?). A risk assessment that sits in a folder and influences nothing is a compliance artifact, not a security tool.
Practice 3.11.1 — Periodically Assess Organizational Risk
3.11.1
Conduct formal risk assessments on a defined schedule. Document the methodology, results, and decisions.
This practice requires periodically assessing risk to organizational operations, assets, and individuals resulting from operating systems that process, store, or transmit CUI. The assessment must be documented and must result in actionable risk decisions.
Risk assessment methodology:
Step 1 — Scope the assessment. Define what systems, processes, and data are in scope. This should align with your System Security Plan (SSP) boundary. The scope is not "all of IT" but specifically the environment where CUI exists or flows through
Step 2 — Identify assets. List the systems, data stores, and supporting infrastructure in scope. This is your asset inventory from the CM domain repurposed for risk analysis
Step 3 — Identify threats. For a defense contractor, the relevant threat landscape includes nation-state actors (particularly those targeting the defense industrial base), ransomware groups, phishing and social engineering, insider threats, and supply chain compromises. CISA and the DIB threat intelligence reports are useful sources for current threat context
Step 4 — Identify vulnerabilities. Combine technical vulnerability scan results with process and control gaps identified through your CMMC self-assessment or gap analysis. A missing MFA deployment is a vulnerability just as a missing patch is
Step 5 — Analyze likelihood and impact. For each significant risk, assess how likely it is that a threat will exploit a vulnerability (low/medium/high) and what the impact would be if it did (low/medium/high/critical). A simple 3x3 or 4x4 risk matrix works for most small organizations
Step 6 — Determine risk response. For each identified risk, choose a response: accept (the risk is within tolerance), mitigate (implement controls to reduce it), transfer (cyber insurance), or avoid (stop the activity that creates the risk). Document the decision and rationale
Step 7 — Document and report. Produce a written risk assessment report that captures the methodology, findings, risk ratings, and decisions. Get management sign-off. Update annually or after significant environmental changes
Practical risk matrix for CMMC environments:
Low Impact
Medium Impact
High Impact
High Likelihood
Medium
High
Critical
Medium Likelihood
Low
Medium
High
Low Likelihood
Low
Low
Medium
Common mistake: A risk assessment that lists every possible risk at "High" with no differentiation. If everything is high risk, nothing is high risk — risk ratings lose their meaning and the document becomes useless for prioritization. Real risk assessment requires judgment about likelihood in your specific context, not worst-case scoring across the board.
Practice 3.11.2 — Scan for Vulnerabilities Periodically
3.11.2
Run authenticated vulnerability scans on a defined schedule. Also scan when new vulnerabilities affecting your systems are disclosed.
This practice requires periodic vulnerability scanning of in-scope systems and additional scans triggered by newly disclosed vulnerabilities that affect those systems. Both the periodic and triggered components must be addressed.
How to implement:
Choose a scanning tool. Tenable Nessus (Essentials is free for up to 16 IPs, Professional for larger environments), Qualys, and Microsoft Defender Vulnerability Management are the most common in CMMC environments. All produce scan reports that serve as assessment evidence
Use authenticated scans. Unauthenticated scans identify open ports and services but miss the majority of vulnerabilities. Authenticated scans log in to each system and enumerate installed software, patch levels, and configuration weaknesses. Authenticated scans consistently find 3 to 5 times more vulnerabilities than unauthenticated scans on the same systems
Define your scanning scope. Every system in scope for CMMC must be scanned. Map your asset inventory to your scan targets to verify nothing is missed
Set a scanning cadence. Monthly authenticated scans are the defensible standard for CMMC. Quarterly is the minimum most assessors will accept. Define the cadence in your RA policy and stick to it
Monitor for newly disclosed vulnerabilities. Subscribe to CISA's Known Exploited Vulnerabilities (KEV) catalog notifications and your scanner vendor's vulnerability feed. When a critical vulnerability is disclosed for software in your environment (a Windows zero-day, a new Exchange vulnerability, a critical Cisco patch), trigger an out-of-cycle scan
Store scan reports. Maintain a rolling archive of scan reports. Assessors may ask to see scan history to verify the cadence claim
Common mistake: Running scans without authenticated credentials, then wondering why the scanner only found three vulnerabilities across 40 servers. Unauthenticated scanning is not sufficient. Set up dedicated scan credentials with local administrator rights on Windows systems and root or equivalent on Linux/network devices.
Practice 3.11.3 — Remediate Vulnerabilities Based on Risk
3.11.3
Patch and remediate vulnerabilities on a risk-prioritized schedule. Document what you fixed and when.
Scanning without remediation is one of the most common CMMC gaps. This practice requires that vulnerabilities identified through scanning are remediated according to a risk-based prioritization scheme, and that the remediation is documented.
How to implement:
Define remediation timelines in your RA policy. A defensible standard that aligns with CISA guidance: Critical vulnerabilities (CVSS 9.0 to 10.0) within 15 days, High vulnerabilities (CVSS 7.0 to 8.9) within 30 days, Medium vulnerabilities (CVSS 4.0 to 6.9) within 90 days, Low vulnerabilities (below 4.0) within 180 days or next maintenance window
Apply the CISA KEV override. Regardless of CVSS score, any vulnerability listed in the CISA Known Exploited Vulnerabilities catalog should be treated as critical and remediated within 15 days. KEV-listed vulnerabilities are actively being exploited in the wild. Subscribe to KEV updates at cisa.gov/known-exploited-vulnerabilities-catalog
Use your change management process for remediation. Patching is a change. Critical and high severity patches should go through an expedited change process, not wait for the next monthly maintenance window
Track remediation in your vulnerability management workflow. Your scanner generates findings. Those findings should flow into your ticketing system as remediation tasks with assigned owners, target dates, and closure verification. A scan report showing the same critical vulnerability open across three consecutive monthly scans is a significant finding
Handle exceptions formally. Some vulnerabilities cannot be patched immediately due to vendor support constraints, business impact, or legacy system limitations. These exceptions must be formally documented with a risk acceptance, a compensating control where possible, and a target remediation date
Verify remediation. After patching, re-scan to confirm the vulnerability was actually resolved. Patches occasionally fail silently. A verification scan closes the loop and provides evidence that the remediation worked
Common mistake: Treating vulnerability remediation as an IT task with no connection to the risk assessment. Critical vulnerabilities on systems that handle CUI should trigger management awareness, not just a helpdesk ticket. The risk-based prioritization requirement means the people making patching decisions need to understand which systems are most critical to the business and to CUI protection.
Quick Reference: Tools for RA Implementation
Need
Tool Options
Notes
Vulnerability scanning
Tenable Nessus, Qualys, Microsoft Defender Vulnerability Management, OpenVAS
Nessus Essentials is free for up to 16 IPs; Defender Vulnerability Management is included with Defender for Endpoint Plan 2
Threat intelligence
CISA KEV catalog, CISA Alerts and Advisories, MSISAC Advisories
All free; subscribe to CISA alerts at cisa.gov for proactive notification of critical vulnerabilities
NIST SP 800-30 provides the risk assessment methodology most C3PAOs expect to see referenced
Patch management
Microsoft Intune, WSUS, PDQ Deploy, ManageEngine Patch Manager Plus
Intune handles Windows and third-party patching for Entra-joined devices; WSUS is free for on-premise Windows patching
Vulnerability tracking
Tenable.io, Qualys VMDR, or integrated with your ITSM ticketing system
The key is that findings flow into a tracked workflow with owners and due dates, not just a static report
Risk register documentation
Excel/SharePoint, or purpose-built GRC tools like Drata, Vanta, or Hyperproof
A well-structured Excel risk register is sufficient for most small contractors; GRC platforms add automation at higher cost
The POA&M connection: Vulnerabilities and risks that cannot be remediated immediately must flow into your Plan of Action and Milestones (POA&M). The POA&M is the document that tells assessors: here are the gaps we know about, here is our plan to fix them, and here is when we will fix them. A clean POA&M with realistic timelines and evidence of progress is far better than an assessment that reveals untracked gaps. Risk assessment feeds the POA&M, and the POA&M demonstrates risk management discipline.
How Often Do You Need a Risk Assessment?
NIST 800-171 says "periodically" without specifying a frequency. Annual risk assessments are what most assessors expect. Beyond the annual cadence, risk assessments should be triggered by significant changes: adding new systems or cloud services to the CUI environment, major infrastructure changes, new contractual requirements, significant changes in the threat landscape (such as a major breach of a similar contractor), or after a security incident affecting your organization.
Document your assessment cadence in your RA policy and follow it. An organization that has not conducted a risk assessment in three years, regardless of what the policy says, has a finding.
Need the Policy and Process Documentation?
Our CMMC Level 2 Risk Assessment Policy template covers all three RA practices with formal policy language, a documented risk assessment methodology aligned to NIST SP 800-30, vulnerability scanning requirements, remediation timelines, and fill-in-the-blank sections for your specific tools and risk tolerance levels.
Practice 3.11.1 requires periodic risk assessments but does not specify a fixed frequency. Annual risk assessments are the standard most organizations adopt and what most C3PAO assessors expect. Risk assessments should also be triggered by significant changes to the environment, such as adding new systems to scope, adopting new cloud services, major infrastructure changes, or after a security incident. The assessment cadence should be defined in your Risk Assessment Policy.
Several scanners satisfy practice 3.11.2. Tenable Nessus is the most widely deployed in CMMC environments and has purpose-built CMMC and NIST 800-171 compliance scan templates. Qualys is another enterprise option. For organizations already on Microsoft 365 E5 or Defender for Endpoint Plan 2, Microsoft Defender Vulnerability Management provides continuous vulnerability discovery at no additional tool cost. OpenVAS is a free option for budget-constrained organizations. The scanner matters less than the scanning frequency, scope, and remediation follow-through.
NIST SP 800-171 does not mandate specific patching timelines, but your Risk Assessment Policy should define them. A common and defensible standard: critical vulnerabilities (CVSS 9.0 to 10.0) within 15 days, high (CVSS 7.0 to 8.9) within 30 days, medium (CVSS 4.0 to 6.9) within 90 days, and low (below 4.0) within 180 days. CISA's Known Exploited Vulnerabilities catalog adds urgency regardless of CVSS score. Any KEV-listed vulnerability on an in-scope system should be treated as critical.
No. Vulnerability scanning (3.11.2) and risk assessment (3.11.1) are related but distinct practices. A vulnerability scan identifies technical weaknesses in specific systems. A risk assessment is a broader analysis that examines threats, vulnerabilities, likelihood of exploitation, potential impact, and the existing controls that mitigate those risks. The risk assessment uses vulnerability scan results as one input but also considers operational risks, third-party risks, physical security, and organizational factors that a scanner cannot measure.
A CMMC risk assessment should identify the assets in scope, the threats relevant to those assets, the vulnerabilities that those threats could exploit, the likelihood and potential impact of each risk, the existing controls that reduce each risk, and the residual risk after those controls are applied. Risks that exceed your organization's risk tolerance should feed your Plan of Action and Milestones. The assessment should be documented, reviewed by management, and updated at least annually.