Building a Risk Assessment Framework for CMMC

Executive Summary

Key takeaways: - CMMC Level 2 requires three specific risk practices: periodically assess risk (RA.L2-3.11.1), scan for vulnerabilities (RA.L2-3.11.2), and remediate vulnerabilities according to risk (RA.L2-3.11.3). - A risk assessment is not a vulnerability scan. Scans find technical weaknesses. Risk assessments evaluate the likelihood and business impact of threats across your entire CUI environment. - Your risk assessment output feeds your POA&M and your SSP — without it, those documents are fiction. - Plan for an annual formal assessment with quarterly scan cycles. This cadence satisfies the "periodically" language in the practices and produces the ongoing evidence your assessor needs. - Cross-framework note: ISO 27001 Clause 6.1.2 and NIST CSF 2.0's Govern function require nearly identical outputs. If you're already doing ISO 27001 risk management, you're 70% of the way there.

What CMMC Requires

The Risk Assessment domain in NIST SP 800-171 has three practices, all required at CMMC Level 2:

RA.L2-3.11.1 — 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.

RA.L2-3.11.2 — Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems are identified.

RA.L2-3.11.3 — Remediate vulnerabilities in accordance with risk assessments.

Three sentences in the standard. But the assessment objectives in NIST SP 800-171A — the guide your C3PAO uses to evaluate you — break these into roughly 12 discrete things you have to demonstrate. Let's unpack what each practice actually requires.

RA.L2-3.11.1: Periodic Risk Assessment

This practice requires a documented, repeatable process for evaluating the risk your systems create. Not just a list of vulnerabilities — an actual analysis that ties threats to your business operations and the CUI you handle.

A CMMC-ready risk assessment has five components:

1. Asset inventory. You can't assess risk to systems you haven't identified. Your risk assessment starts with your scoped asset inventory from your SSP — every CUI Asset, Security Protection Asset, and relevant system in your environment. If your asset inventory isn't current, your risk assessment is wrong before it starts.

2. Threat identification. What could go wrong? For defense contractors, the relevant threat categories are: external adversaries (nation-state actors, ransomware groups, hacktivists), insider threats (malicious and negligent), third-party and supply chain compromises, and environmental threats (power failure, hardware failure, natural disaster). You're not writing a spy novel — document the realistic threat actors and scenarios that apply to your industry and contract type.

3. Vulnerability identification. This is where vulnerability scanning (RA.L2-3.11.2) feeds into the broader risk assessment. Scan results give you technical vulnerabilities. Your risk assessment also needs to capture process and policy vulnerabilities: gaps in access control, missing MFA, inadequate logging, untrained personnel. Technical scanning finds holes in your systems. Risk assessment identifies holes in your program.

4. Likelihood and impact analysis. For each identified risk (threat + vulnerability), estimate how likely it is to occur and what the impact would be if it did. You don't need actuarial precision. Most organizations use a 5×5 or 3×3 matrix — Low/Medium/High likelihood crossed with Low/Medium/High impact — to produce a risk level that drives prioritization.

5. Risk determination and acceptance. For each identified risk, your organization makes one of four decisions: mitigate (implement a control), transfer (cyber insurance, contractual requirement), accept (document that the risk is acceptable given cost/benefit), or avoid (stop the activity that creates the risk). Every risk needs an explicit disposition. Risks that aren't explicitly accepted or mitigated are just ignored — and your assessor will find them.

The "periodically" language means at minimum annually. Trigger a full reassessment whenever you have significant system changes, a security incident, a new contract with different CUI types, or major changes to your threat environment.

RA.L2-3.11.2: Vulnerability Scanning

Vulnerability scanning is a distinct, ongoing activity that feeds data into your risk assessment. The key requirements:

Scan scope: All systems in your CMMC assessment boundary — CUI Assets and Security Protection Assets. Missing a system from your scan scope is a finding. Your scan scope should match your asset inventory exactly.

Scan frequency: "Periodically" means at least quarterly for most assessors. When new vulnerabilities are identified (think Log4Shell, PrintNightmare) — scan immediately after patching to verify remediation. Some organizations run continuous scanning, which satisfies both the periodic and event-driven requirements.

Scan tools: Three options dominate the CMMC market: - Tenable.io — cloud-managed, strong for mixed on-prem/cloud environments, good DoD-sector reference base; ~$5,000–$20,000/year depending on asset count - Qualys VMDR — solid enterprise option, integrates well with CMMC GRC tools; similar pricing - Nessus Professional — the on-premises option, perpetual license around $3,000–$4,500/year per scanner; good for organizations that don't want to send scan data to the cloud

Whichever tool you use, run authenticated scans — agent-based or credentialed. Unauthenticated network scans find a fraction of the vulnerabilities an authenticated scan finds. An assessor who asks "were these authenticated scans?" and gets a vague answer will probe further.

Scan output: Keep scan reports as evidence. Store them dated and accessible — your assessor will ask to see recent scan results and may ask to see historical results to confirm the cadence. SIEM integration (Splunk, Microsoft Sentinel) that ingests vulnerability scan data makes continuous monitoring evidence automatic.

RA.L2-3.11.3: Remediate According to Risk

This practice closes the loop: you found vulnerabilities (RA.L2-3.11.2), you assessed their risk (RA.L2-3.11.1), now you remediate them in priority order based on that risk.

The practice doesn't mandate specific timelines, but your risk assessment and remediation policy should. A standard approach:

Document these timelines in your vulnerability management policy. Then follow them. Your assessor will pull a sample of vulnerabilities from your scan history and check whether they were remediated within policy timelines. Undocumented timelines make this comparison impossible — which is worse than missing a target, because it implies no process exists.

Vulnerabilities you can't remediate immediately go on your Plan of Action & Milestones (POA&M). A POA&M entry for a vulnerability isn't a failure — it's a documented, managed risk. A vulnerability that's been sitting in scan results for six months with no POA&M entry and no remediation is a failure.

Building Your Risk Assessment Process

Step 1: Define Scope Before You Start

Your risk assessment scope must match your CMMC assessment scope. Pull your asset inventory from your SSP. Confirm every CUI Asset and Security Protection Asset is captured. Add any third-party environments (cloud services, MSP-managed infrastructure) that touch CUI.

Common miss: organizations assess their on-premises environment thoroughly but forget that the Microsoft 365 tenant, the cloud file sync, or the backup service that copies CUI offsite is also in scope.

Step 2: Choose Your Risk Methodology

You need a documented methodology — a repeatable approach so this year's risk assessment is comparable to next year's. The most common options for defense contractors:

NIST SP 800-30 Rev 1 — the native methodology for NIST 800-171. If you want alignment with DoD's own approach, use this. It's thorough but verbose. Many organizations adapt it rather than follow it literally.

ISO 27001 Annex A risk treatment — if you're cross-referencing ISO 27001 (ISO 27001:2022 Clause 6.1.2 requires an identical risk assessment process), this methodology works well and produces ISO-compatible outputs. If you're running a dual certification effort, this is efficient.

Simplified likelihood/impact matrix — practical for organizations without a dedicated security team. Use a 3×3 or 5×5 risk matrix, define your likelihood and impact scales clearly, and apply them consistently. Less rigorous than 800-30, but acceptable to most assessors if documented and consistently applied.

Whatever you choose, write it down and stick to it. "We assessed risk" is not a methodology. "We use a 5×5 likelihood/impact matrix based on NIST SP 800-30 threat categories, applied annually to all assets in our SSP boundary" is a methodology.

Step 3: Run the Assessment

For most small-to-mid defense contractors, the annual risk assessment takes 40–80 hours of internal staff time if you have a reasonably current SSP and asset inventory. Break it into sessions by asset type or system category rather than trying to do everything in one sitting.

The decision of whether to run this internally or hire external consultants depends on staff expertise and organizational size. A rule of thumb:

• Run internally if you have a dedicated IT security person with compliance experience and a mature SSP. The risk assessment is a documentation exercise at this point — you know your environment, you need to formalize what you know.
• Hire external if this is your first risk assessment, your IT staff is primarily operational rather than security-focused, or you're 6–12 months from your C3PAO assessment and want a pre-assessment view of your risk posture. External consultants typically charge $15,000–$40,000 for a full CMMC-scoped risk assessment, including documentation and a prioritized remediation roadmap.

The external option also has an evidence value: an independent assessment is more credible than a self-assessed one, particularly for risk determinations that involve accepting risk rather than mitigating it.

Step 4: Document Outputs

Your risk assessment produces two key outputs:

Risk Register. A living document that lists every identified risk, its likelihood and impact scores, the risk level, and its current disposition (mitigate, transfer, accept, avoid). The risk register is referenced by your SSP, your POA&M, and your executive leadership when they sign off on accepted risks.

Risk Assessment Report. A point-in-time document that captures the methodology used, the scope, the findings, and the summary of risk determinations. This is the evidence document your assessor examines. It should be dated, version-controlled, and signed by whoever owns the risk assessment process at your organization (typically the ISSO or CISO, with executive acknowledgment).

Step 5: Connect Risk to POA&M

Every risk that results in a "mitigate" decision and isn't immediately mitigated becomes a POA&M item. Your POA&M should reference the underlying risk from the risk register — this creates a traceable chain from "we identified a risk" to "here's our plan to address it" to "here's when we completed it."

Assessors look for this chain. A POA&M without a risk basis looks like you're listing things you haven't done yet. A POA&M with risk traceability looks like a managed program.

Continuous Monitoring: Keeping the Assessment Current

Your annual risk assessment is a snapshot. The threat landscape changes continuously, and so does your environment. CMMC's CA.L2-3.12.3 requires ongoing monitoring of security controls — which means your risk management process can't live only in an annual document.

Practical continuous monitoring: - Quarterly vulnerability scans — scheduled, authenticated, results reviewed by security staff within 5 business days - Monthly review of the risk register — are open mitigations on track? Have new risks emerged from system changes? - Event-triggered reassessments — new contract type, major system change, security incident, significant new vulnerability announced - Annual full refresh — covers all five components above, produces a new risk assessment report

If you're using a GRC platform (ServiceNow GRC, Drata, RegScale, or similar), configure it to pull vulnerability scan data automatically and flag when remediation timelines are approaching or exceeded. This transforms your continuous monitoring from a manual tracking exercise into an automated alert-and-evidence system.

Cross-Framework Alignment

If your organization already works within other frameworks, here's how the CMMC RA domain maps:

ISO 27001:2022 — Clause 6.1.2 requires an information security risk assessment process that is essentially identical to RA.L2-3.11.1. If you're ISO 27001-certified, your risk assessment methodology already satisfies the CMMC requirement. You may need to adjust scope to match your CMMC boundary specifically. Clause 6.1.3 (risk treatment) maps to RA.L2-3.11.3.

NIST CSF 2.0 — The new Govern function (GV.RM) and Identify function (ID.RA) directly cover risk assessment activities. If you're using CSF as your security program framework, your risk assessment work within CSF translates well to CMMC's RA domain. CSF 2.0's Govern function explicitly requires that risk management processes be integrated into organizational decision-making — which aligns with CMMC's expectation that risk assessment outputs drive your POA&M and SSP.

FedRAMP — FedRAMP's risk assessment process (based on NIST SP 800-37 RMF) is more rigorous than CMMC's RA domain requirements. If you're operating in a FedRAMP-authorized environment, your cloud provider's risk assessment documentation can supplement your own, but doesn't replace it — CMMC requires you to assess risk to your operations, not your CSP's.

The Most Common Mistake

Defense contractors treat the risk assessment as a one-time compliance checkbox: hire a consultant (or run a vulnerability scan), generate a report, file it, move on. Twelve months later, the same report gets handed to the C3PAO assessor — unchanged, with vulnerabilities listed that were identified 11 months ago and never addressed.

Your assessor will ask: "How has your risk posture changed since your last assessment?" If the answer is "it hasn't," that's evidence your risk management process isn't working. The assessment is not the product. The ongoing decisions and actions it drives are the product.

A risk assessment that changes nothing is bureaucratic theater. One that produces a prioritized remediation list, feeds your POA&M, gets revisited quarterly, and evolves as your environment changes is a working risk management program — and that's exactly what CMMC is designed to establish.

What Your Assessor Expects

For the RA domain, your C3PAO assessor will use three assessment methods: examine, interview, and test.

Examine: Risk assessment report (dated, signed, in scope), risk register, vulnerability scan reports (recent and historical demonstrating cadence), remediation records showing vulnerabilities were addressed within documented timelines, POA&M showing open risks, and your vulnerability management policy defining scan frequency and remediation timelines.

Interview: Who owns the risk assessment process? What methodology does your organization use? How are scan results reviewed and acted on? What triggers an out-of-cycle reassessment? What happens when a vulnerability can't be patched within the defined timeline?

Test: The assessor may ask to see your scanning tool in action, verify that scans are configured to cover your full asset inventory, and pull samples from your vulnerability history to verify remediation timelines were met.

The most common RA domain findings: - Scan scope doesn't match the SSP asset inventory (systems are in the SSP but not in the scan) - No documented remediation timelines (scans exist; nothing says how long you have to fix findings) - Vulnerabilities on POA&M with no progress toward remediation - Risk assessment exists as a one-time document with no evidence of periodic refresh

Prepare for the assessor interview by knowing your risk register cold. Know which risks you've accepted and why. Know your scan cadence and when the last scan ran. Know your highest-priority open vulnerabilities and their remediation status. This isn't a test you can fake your way through — but it's also not hard if you've been running the process consistently.

Getting Started

If you're building a risk assessment program from scratch, the sequence matters:

1. Confirm your asset inventory — risk assessment scope equals SSP scope
2. Select your risk methodology — document it before you apply it
3. Run your first authenticated vulnerability scan — establish a baseline
4. Complete your first formal risk assessment — use the five components above
5. Update your POA&M — connect open risks to planned remediation
6. Schedule your cadence — quarterly scans, annual full assessment, event-driven updates

Don't let perfect be the enemy of done. A risk assessment that's 80% rigorous and actually maintained beats a methodologically perfect one that sits in a folder for three years. Your assessor is looking for a working process, not an academic paper.

Ready to talk through your specific risk posture before your assessment? Schedule a consultation.

Related reading: How to Write Your SSP | Building Your POA&M | CMMC Scoping: What's In and What's Out