Risk Assessment (RA)

Risk Assessment (RA) is one of 14 security control families in NIST SP 800-171 Revision 2 that forms the foundation for CMMC Level 2 certification. The RA family contains 3 security requirements (3.11.1 through 3.11.3) that establish your organization’s approach to identifying, analyzing, and managing cybersecurity risks to systems processing Controlled Unclassified Information (CUI).

Unlike many control families, Risk Assessment contains 1 Basic Security Requirement (3.11.1) and 2 Derived Security Requirements (3.11.2 and 3.11.3). This means every organization handling CUI must implement all three RA requirements to achieve CMMC Level 2 compliance.

The Risk Assessment family is foundational because it drives decision-making across your entire security program. Risk assessments determine which security controls to implement, how to prioritize remediation efforts, and where to allocate limited security resources for maximum protection.

Why Risk Assessment Matters for CMMC

Risk Assessment is worth 9 total points in the DoD CMMC Scoring Methodology:

• 3.11.1 (Risk Assessment): 3 points
• 3.11.2 (Vulnerability Scanning): 5 points
• 3.11.3 (Vulnerability Remediation): 1 point

The 5-point value assigned to vulnerability scanning (3.11.2) places it on par with critical requirements like Multi-Factor Authentication (IA.L2-3.5.3) and encryption requirements (SC.L2-3.13.8, SC.L2-3.13.16). This reflects DoD’s recognition that vulnerability management is fundamental to protecting CUI.

Without effective risk assessment and vulnerability management, organizations cannot make informed decisions about security investments, prioritize remediation efforts, or demonstrate due diligence in protecting sensitive federal information.

The 3 Risk Assessment Requirements

3.11.1: Periodically Assess Risk to Organizational Operations

Requirement: Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.

What This Means

Organizations must conduct regular, comprehensive risk assessments that evaluate threats and vulnerabilities affecting systems processing CUI. Risk assessments consider how security risks impact organizational operations, assets, reputation, and the individuals involved.

Risk Assessment Components:

Risk assessments evaluate four key elements:

1. Threats: Potential circumstances or events that could adversely impact operations—including cyberattacks, natural disasters, insider threats, supply chain compromises, and human error
2. Vulnerabilities: Weaknesses in security controls that threats could exploit—such as unpatched software, misconfigured firewalls, weak passwords, or inadequate physical security
3. Likelihood: Probability that a threat will exploit a vulnerability—informed by threat intelligence, historical incident data, and current security posture
4. Impact: Consequences if a threat successfully exploits a vulnerability—including mission disruption, financial loss, reputational damage, regulatory penalties, or harm to individuals

Assessment Scope:

Risk assessments must evaluate risks to:

• Organizational operations: Impact on mission, functions, and critical business processes
• Organizational assets: Systems, data, facilities, and equipment processing, storing, or transmitting CUI
• Individuals: Employees, contractors, partners, and customers affected by security incidents
• Organizational reputation: Public perception, customer confidence, and regulatory standing

Assessment Types:

Organizations can conduct risk assessments at multiple levels:

• Organization-level: Enterprise-wide risks affecting overall security posture
• Mission/Business process level: Risks to specific operations or workflows involving CUI
• System-level: Risks to individual information systems or applications
• Any phase of system development lifecycle: Risks during design, development, implementation, operation, or disposal

NIST SP 800-30 provides comprehensive guidance on conducting risk assessments using structured methodologies.

Implementation Approach

Risk Assessment Frequency:

NIST 800-171 requires “periodic” risk assessments without specifying exact frequency. Organizations should conduct risk assessments:

• At least annually (industry best practice and common compliance interpretation)
• When significant changes occur: New systems deployed, major architecture changes, mergers/acquisitions, significant security incidents
• When threat landscape evolves: New attack vectors emerge, threat intelligence indicates elevated risk, industry-wide vulnerabilities discovered
• Before major decisions: Contract bids involving new CUI types, cloud service provider selection, third-party integrations

Risk Assessment Process:

1. System Characterization: Identify all systems processing, storing, or transmitting CUI; document system boundaries, data flows, and interconnections
2. Threat Identification: Research relevant threat actors, attack vectors, and threat intelligence specific to your industry and threat environment
3. Vulnerability Identification: Leverage vulnerability scanning (3.11.2), penetration testing, security assessments, and configuration reviews to identify weaknesses
4. Risk Analysis: Evaluate likelihood and impact for each threat-vulnerability pair using qualitative (Low/Moderate/High) or quantitative (numeric probability and cost) methods
5. Risk Determination: Calculate overall risk levels considering both likelihood and impact
6. Risk Prioritization: Rank risks to guide remediation efforts and resource allocation
7. Risk Response: Determine appropriate responses—mitigate, accept, avoid, or transfer risks based on organizational risk tolerance
8. Documentation: Record assessment methodology, findings, risk scores, and recommended controls in formal risk assessment report

External Risk Considerations:

Risk assessments must consider risks from external parties:

• Cloud service providers: Assess CSP security controls, data location, access controls, incident response capabilities
• Third-party vendors: Evaluate vendor security postures, data sharing arrangements, supply chain risks
• Subcontractors: Assess subcontractor compliance with NIST 800-171 and ability to protect CUI
• Outsourcing entities: Review security controls of organizations processing CUI on your behalf

Integration with Security Program:

Risk assessment findings should inform:

• Security control selection: Choose controls that address highest-priority risks
• POA&M prioritization: Focus remediation efforts on vulnerabilities with highest risk scores
• Budget allocation: Invest security resources in areas with greatest risk reduction potential
• System security plan updates: Document how selected controls mitigate identified risks
• Incident response planning: Prepare for threats most likely to impact operations

Assessment Tips

Documentation Requirements:

• Maintain formal risk assessment reports with dates, assessors, methodology, and findings
• Document threat sources consulted (CISA alerts, vendor advisories, threat intelligence feeds)
• Record risk scores and rationale for risk acceptance decisions
• Update risk register as new risks identified through scanning or monitoring

Common Pitfalls to Avoid:

• Generic risk assessments not tailored to your specific systems and threat environment
• Focusing only on technical risks while ignoring physical, administrative, and supply chain risks
• Conducting one-time assessment and never updating as systems and threats evolve
• Failing to act on assessment findings—risk assessments without remediation provide no value

---

3.11.2: Scan for Vulnerabilities Periodically and When New Vulnerabilities Identified

Requirement: Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.

What This Means

Organizations must deploy and operate vulnerability scanning tools that automatically identify security weaknesses in systems, applications, and infrastructure. Scans must occur on regular schedules AND whenever new vulnerabilities are discovered that could affect your environment.

Vulnerability scanning is the technical implementation of ongoing risk identification—it discovers the specific weaknesses that threats could exploit to compromise CUI.

Understanding Vulnerability Scanning

What Gets Scanned:

Vulnerability scans must cover ALL systems within the CMMC assessment scope:

• Servers: Windows/Linux servers, database servers, web servers, file servers
• Workstations: Employee laptops and desktops that access CUI
• Network devices: Firewalls, routers, switches, wireless access points
• Applications: Web applications, databases, custom software, commercial applications
• Cloud infrastructure: Virtual machines, containers, serverless functions, cloud storage
• Mobile devices: Smartphones and tablets accessing CUI (if in scope)

What Scans Detect:

Vulnerability scans identify:

• Missing security patches: Unpatched operating systems, applications, firmware
• Configuration weaknesses: Default passwords, unnecessary services, weak encryption
• Known vulnerabilities: CVE-listed vulnerabilities affecting installed software versions
• Open ports and services: Unnecessary network services exposing attack surface
• Compliance violations: Deviations from security baselines and hardening standards
• End-of-life software: Unsupported software versions no longer receiving security updates

Scanning Methodologies:

Organizations should employ multiple scanning approaches:

• Authenticated (credentialed) scans: Scans using admin credentials to examine internal system configurations—more thorough and recommended for CMMC
• Unauthenticated scans: External scans simulating attacker reconnaissance—useful for perimeter security testing
• Network-based scans: Scan network infrastructure and services
• Agent-based scans: Software agents on endpoints provide detailed internal vulnerability data
• Application scanning: Static analysis (SAST), dynamic analysis (DAST), and interactive testing for custom applications

Scanning Frequency Requirements

Periodic Scanning:

NIST 800-171 requires “periodic” scanning without mandating specific frequency. Industry best practices recommend:

• At minimum: Weekly scans of all in-scope systems
• Better practice: Every 72 hours (3 days) for critical systems and internet-facing assets
• Optimal: Continuous scanning using agent-based tools that provide real-time vulnerability discovery

Many organizations implement tiered scanning:

• External/DMZ systems: Weekly or every 72 hours (higher risk)
• Internal CUI systems: Weekly or bi-weekly
• Other internal systems: Monthly
• Workstations: Weekly or continuous agent-based scanning

Event-Triggered Scanning:

Organizations must scan immediately when:

• New vulnerabilities announced: Vendor security bulletins, CISA alerts, CVE publications affecting your software stack
• Major changes deployed: New systems, applications, or infrastructure added to environment
• Significant incidents: After security incidents to identify additional vulnerabilities or attack vectors
• Patches applied: Post-patch validation scans to confirm vulnerabilities remediated
• Configuration changes: After firewall rule changes, security policy updates, or access control modifications

Scanning Tools:

Common vulnerability scanners include:

• Nessus: Industry-standard commercial scanner
• Qualys: Cloud-based vulnerability management platform
• Rapid7 InsightVM: Comprehensive vulnerability and risk analytics
• OpenVAS: Open-source alternative for budget-conscious organizations
• Microsoft Defender for Endpoint: Built-in scanning for Microsoft environments

Tools should support:

• SCAP (Security Content Automation Protocol): Standardized vulnerability data format
• CVE (Common Vulnerabilities and Exposures): Standard vulnerability naming
• OVAL (Open Vulnerability Assessment Language): Standardized vulnerability testing
• CVSS (Common Vulnerability Scoring System): Standardized vulnerability severity ratings

Implementation Considerations

Scan Configuration:

Properly configured scans are essential:

• Update vulnerability definitions: Keep scanner databases current (ideally within 24 hours of new CVE releases)
• Credential configuration: Provide appropriate credentials for authenticated scanning
• Scan scheduling: Schedule scans during maintenance windows to minimize impact
• Scope definition: Ensure all CUI systems included in scan scope
• Exclusions: Document any scan exclusions with technical justification (fragile systems, production constraints)

Handling Scan Results:

Organizations must:

• Review scan reports: Designate personnel responsible for analyzing vulnerability scan results
• Validate findings: Investigate and confirm true positives vs. false positives
• Document in POA&M: Add confirmed vulnerabilities to Plan of Action and Milestones (3.12.2)
• Prioritize remediation: Use risk assessment (3.11.1) and CVSS scores to prioritize vulnerability remediation (3.11.3)
• Track remediation: Monitor vulnerability resolution progress through POA&M management
• Rescan after remediation: Validate that patches and fixes successfully eliminated vulnerabilities

Special Considerations:

Remote/mobile devices: Organizations with remote workers face scanning challenges. Options include VPN-required scanning, agent-based tools providing results when devices connect, or “representative system” scanning of baseline configurations.

Critical production systems: Some systems cannot tolerate disruptive scans. Document compensating controls like isolated test environment scanning, manual configuration reviews, or scheduled maintenance window scanning.

Custom applications: Commercial scanners may not effectively test custom software. Consider supplemental approaches like static code analysis, dynamic application security testing, or penetration testing.

Assessment Tips

Evidence for Assessors:

• Vulnerability scanning policy documenting frequency and procedures
• Scan schedules showing regular scanning cadence
• Recent scan reports with dates, systems scanned, and findings
• Screenshots of scanner configurations showing credential usage and scope
• POA&M entries for identified vulnerabilities
• Remediation tracking showing closed vulnerabilities
• Rescan reports validating successful remediation

---

3.11.3: Remediate Vulnerabilities in Accordance with Risk Assessments

Requirement: Remediate vulnerabilities in accordance with risk assessments.

What This Means

Discovered vulnerabilities must be fixed based on risk-based prioritization. Organizations cannot remediate all vulnerabilities simultaneously, so risk assessments guide which vulnerabilities receive immediate attention and which can be scheduled for later remediation.

This requirement closes the loop: scanning identifies vulnerabilities (3.11.2), risk assessment evaluates severity (3.11.1), and remediation eliminates the weaknesses (3.11.3).

Understanding Risk-Based Remediation

Remediation Prioritization:

Organizations prioritize vulnerability remediation based on:

• Vulnerability severity: CVSS scores (Critical, High, Moderate, Low)
• Asset criticality: Systems processing CUI receive higher priority than non-CUI systems
• Exploitability: Vulnerabilities with known exploits require faster remediation
• Threat intelligence: Vulnerabilities actively exploited in the wild demand immediate action
• Compensating controls: Existing security controls may reduce urgency for some vulnerabilities
• Operational impact: Critical production systems may require scheduled maintenance windows

Risk-Based Remediation Timelines:

While NIST 800-171 doesn’t mandate specific remediation timelines, industry best practices recommend:

Critical vulnerabilities (CVSS 9.0-10.0):

• Systems processing CUI: 30 days maximum
• Internet-facing systems: 7-14 days or immediately if actively exploited
• Internal systems: 30 days

High vulnerabilities (CVSS 7.0-8.9):

• Systems processing CUI: 90 days maximum
• Internet-facing systems: 30 days
• Internal systems: 90 days

Moderate vulnerabilities (CVSS 4.0-6.9):

• All systems: 180 days maximum
• May be addressed in regular patch cycles

Low vulnerabilities (CVSS 0.1-3.9):

• All systems: As resources permit
• May be accepted if remediation costs exceed risk

These timelines should be documented in your vulnerability management policy and tracked through your POA&M process.

Remediation Methods

Primary Remediation:

The preferred remediation approach is patching—applying vendor-supplied security updates that eliminate the vulnerability:

• Deploy patches during scheduled maintenance windows
• Test patches in non-production environments before production deployment
• Document patch deployment through change management procedures
• Validate successful remediation through rescanning

Alternative Remediation:

When patching isn’t immediately feasible, organizations can implement compensating controls:

• Configuration changes: Disable vulnerable services, restrict access, enable additional logging
• Network segmentation: Isolate vulnerable systems from CUI environments
• Access controls: Limit who can access vulnerable systems
• Enhanced monitoring: Deploy additional detection capabilities to identify exploitation attempts
• Firewall rules: Block network access to vulnerable services
• Web application firewalls: Virtually patch web application vulnerabilities

Risk Acceptance:

Some vulnerabilities may be accepted without remediation when:

• Remediation cost exceeds risk (e.g., replacing expensive equipment for low-severity vulnerability)
• Remediation breaks critical business functionality
• Compensating controls provide equivalent protection
• System scheduled for replacement in near term

Risk acceptance requires:

• Formal documentation: Written justification and approval from authorizing official
• Compensating controls: Implementation of alternative security measures
• Ongoing monitoring: Regular reassessment of accepted risks
• POA&M tracking: Document as accepted risk with justification

Integration with Other Requirements

Vulnerability remediation connects to multiple NIST 800-171 requirements:

System and Information Integrity (SI.L2-3.14.1): Identify, report, and correct system flaws in timely manner—overlaps with vulnerability remediation timelines

Configuration Management (CM.L2-3.4.8): Apply least functionality by disabling unnecessary services—remediates vulnerabilities by reducing attack surface

Plans of Action (CA.L2-3.12.2): Document vulnerabilities and remediation plans in POA&M

Continuous Monitoring (CA.L2-3.12.3): Track vulnerability remediation progress as part of ongoing security posture monitoring

Security Assessment (CA.L2-3.12.1): Periodic assessments validate vulnerability remediation effectiveness

Implementation Best Practices

Vulnerability Management Program:

Establish comprehensive program including:

• Documented procedures: Vulnerability scanning, prioritization, remediation, and validation processes
• Assigned responsibilities: Designate personnel for scanning, analysis, remediation, and reporting
• Tooling: Deploy vulnerability scanners, patch management systems, and tracking tools
• Metrics: Track mean time to remediate, vulnerability trends, and patch compliance rates
• Reporting: Regular dashboards and reports to management on vulnerability status

Patch Management Process:

Effective patch management supports timely remediation:

• Automated patch deployment: Use tools like WSUS, SCCM, Automox, or Ivanti
• Testing procedures: Test patches in lab before production deployment
• Maintenance windows: Schedule regular patching cycles
• Emergency patching: Procedures for critical zero-day vulnerabilities requiring immediate action
• Patch validation: Rescan after patching to confirm vulnerability eliminated

POA&M Management:

Track vulnerabilities through Plans of Action:

• Document discovered vulnerabilities: Add scan findings to POA&M with CVE numbers and CVSS scores
• Assign owners: Designate person responsible for remediation
• Set target dates: Establish risk-based remediation deadlines
• Track progress: Update POA&M as remediation activities progress
• Close validated items: Remove POA&M items after rescan confirms successful remediation

Assessment Tips

Evidence for Assessors:

• Vulnerability remediation policy with risk-based timelines
• POA&M containing current vulnerabilities with owners and target dates
• Patch management procedures and schedules
• Evidence of timely remediation: closed POA&M items with remediation dates
• Rescan reports validating successful remediation
• Risk acceptance documentation for accepted vulnerabilities
• Metrics showing average remediation times by severity

Common Implementation Challenges

Challenge 1: Limited Security Resources Many small contractors lack dedicated security personnel to conduct risk assessments, analyze scan results, and coordinate remediation. Consider engaging Managed Security Service Providers (MSSPs) who provide vulnerability management as a service, including scanning, analysis, and remediation recommendations.

Challenge 2: Vulnerability Scanner Costs Commercial vulnerability scanners can be expensive. Open-source tools like OpenVAS provide budget-friendly alternatives, though they require more technical expertise to configure and operate. Cloud-based services often offer pay-as-you-go pricing that’s more affordable for small organizations.

Challenge 3: False Positives Vulnerability scanners generate false positives requiring manual validation. Assign knowledgeable personnel to review findings, validate true vulnerabilities, and tune scanner configurations to reduce noise over time.

Challenge 4: Remediation vs. Operations Conflicts Patching can disrupt operations, creating tension between security and production teams. Establish clear change management procedures, schedule regular maintenance windows, and communicate patch schedules in advance to minimize disruption.

Challenge 5: Remote Worker Scanning Scanning remote laptops and devices challenges organizations with distributed workforces. Deploy agent-based scanning tools that report results when devices connect to VPN, or use endpoint management platforms with built-in vulnerability assessment capabilities.

Challenge 6: Risk Assessment Complexity Formal risk assessments can seem overwhelming for small organizations without risk management experience. Start with simplified approaches using qualitative risk matrices (Low/Moderate/High), leverage NIST SP 800-30 guidance, and consider hiring consultants for initial assessment to establish baseline methodology.

Key Takeaways

Critical Points:

1. All 3 RA requirements are mandatory for CMMC Level 2—1 basic and 2 derived requirements
2. Vulnerability scanning is 5-point requirement—highest value in NIST 800-171, reflecting critical importance
3. Periodic means regular—annual risk assessments and at least weekly vulnerability scanning are industry standards
4. Risk-based remediation is required—prioritize by CVSS score, asset criticality, and threat intelligence
5. Integration matters—RA findings drive POA&Ms, security control selection, and resource allocation

Implementation Priorities:

1. Deploy vulnerability scanning tool and establish regular scanning schedule (3.11.2)
2. Conduct initial comprehensive risk assessment identifying threats, vulnerabilities, and impacts (3.11.1)
3. Establish risk-based remediation timelines in vulnerability management policy (3.11.3)
4. Document all vulnerabilities in POA&M with owners, deadlines, and remediation status

Success Factors:

• Automate vulnerability scanning to ensure consistent coverage without manual intervention
• Update scanner vulnerability definitions continuously to detect newly announced CVEs
• Track all vulnerabilities in POA&M until validated remediation
• Establish clear remediation timelines based on risk and enforce accountability
• Integrate risk assessment findings into security program decision-making
• Conduct risk assessments whenever significant changes occur, not just annually

Related Articles and External Resources

Official DoD and NIST Resources:

• DoD Cyber Exchange – CMMC: https://public.cyber.mil/cmmc/
• NIST SP 800-171 Rev 2: https://csrc.nist.gov/publications/detail/sp/800-171/rev-2/final
• NIST SP 800-30 (Risk Assessment Guide): https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final
• NIST SP 800-171A (Assessment Procedures): https://csrc.nist.gov/publications/detail/sp/800-171a/rev-3/final
• DFARS 252.204-7012: https://www.acquisition.gov/dfars/252.204-7012-safeguarding-covered-defense-information-and-cyber-incident-reporting
• 32 CFR Part 170 (CMMC Program Rule): https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-G/part-170

Vulnerability and Threat Resources:

• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• National Vulnerability Database: https://nvd.nist.gov/
• Common Vulnerabilities and Exposures (CVE): https://cve.mitre.org/
• CISA Alerts and Advisories: https://www.cisa.gov/news-events/cybersecurity-advisories

---

Last Updated: November 2025

This article provides guidance on Risk Assessment (RA) requirements for CMMC Level 2 compliance based on NIST SP 800-171 Revision 2, DoD CMMC Assessment Methodology, and official CMMC program documentation.