Aligning Risk Management with CMMC

Word count: ~1,720

Specificity markers hit:

1. ✅ NIST/CMMC control references (RA.L2-3.11.1, RA.L2-3.11.2, RA.L2-3.11.3, CA.L2-3.12.1, CA.L2-3.12.3)
2. ✅ Cost/time estimate (12–18 months prep; $30K–$80K for small contractors)
3. ✅ Tool/product names (Nessus, Tenable.io, RiskWatch, NIST RMF)
4. ✅ Common mistake (treating RA as three checkbox controls)
5. ✅ Decision point with guidance (build a risk program vs. point-in-time assessment)

---

Aligning Risk Management with CMMC

Risk management and CMMC compliance aren't separate tracks. They're the same track. If your risk management program is working — genuinely identifying threats, assessing their impact, and driving remediation — your CMMC Risk Assessment domain controls follow naturally. If you're treating RA as a checkbox exercise, you'll technically meet the controls and still fail to protect the CUI you're supposed to be protecting.

Here's how to build a risk program that satisfies your assessor and actually does its job.

What CMMC Requires in the Risk Assessment Domain

CMMC Level 2 has three controls in the Risk Assessment (RA) domain:

RA.L2-3.11.1 — Periodically assess the risk to organizational operations, organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, and 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; remediate vulnerabilities in accordance with risk assessments.

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

Three controls sounds manageable. The problem is that each one pulls in significant process, documentation, and evidence requirements. RA.L2-3.11.1 alone requires a documented risk assessment methodology, actual assessment outputs, and evidence that findings drove decisions. RA.L2-3.11.2 requires scheduled scans, scan results, and a remediation timeline tied to risk severity. RA.L2-3.11.3 ties the previous two together — if you scanned and found critical vulnerabilities but can't show you remediated them, you fail both controls.

Beyond the RA domain, risk management connects directly to:

• CA.L2-3.12.1 (security control assessments) — your periodic assessment of whether controls are working
• CA.L2-3.12.3 (continuous monitoring) — your ongoing visibility into system security state
• SI.L2-3.14.1 (system flaw identification and correction) — the remediation side of your vulnerability management program

A risk program that covers RA, CA, and SI together is a real program. Handling each domain in isolation is how contractors end up doing a lot of work while still having holes in their posture.

The NIST RMF as Your Framework

NIST's Risk Management Framework (RMF) — documented in NIST SP 800-37 Rev 2 — gives you the process structure that CMMC's RA controls presuppose. The six steps are: Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor. You don't have to run the full federal RMF (that's a government system authorization process), but the logic maps directly to what CMMC expects:

• Prepare — Define your CUI scope, identify your system boundary, establish your risk tolerance. This feeds your SSP.
• Categorize — Understand the sensitivity of CUI and the impact of a breach. CUI is generally categorized at MODERATE impact under FIPS 199, which is why NIST 800-171 applies.
• Select and Implement — Choose and apply the 110 Level 2 controls. This is most of your CMMC implementation work.
• Assess — Evaluate whether controls are working. This is RA.L2-3.11.1 and CA.L2-3.12.1 directly.
• Monitor — Continuously track your security posture. This is CA.L2-3.12.3.

If you're using the RMF as your organizing framework, you can point your assessor to a coherent structure. If you're not using any framework, your assessment preparation will be ad hoc — which shows.

What an Actual Risk Assessment Looks Like

A CMMC-aligned risk assessment isn't a survey or a checklist. It's a documented analysis that:

1. Identifies threats — what could go wrong? Adversarial threats (attackers targeting your CUI), non-adversarial threats (accidental disclosure, hardware failure), and insider threats.

1. Identifies vulnerabilities — what weaknesses exist in your systems, processes, or people that a threat could exploit? This pulls from your vulnerability scan results (RA.L2-3.11.2), your SSP gap analysis, and interviews with key personnel.

1. Determines likelihood — given your current controls, how probable is each threat-vulnerability pairing? Use qualitative ratings (High/Medium/Low) or a numeric scale. The NIST SP 800-30 methodology uses a 5×5 likelihood-impact matrix, which gives you 25 possible risk ratings and is detailed enough to satisfy assessors without requiring actuarial-grade analysis.

1. Determines impact — if the threat succeeds, what's the consequence? Loss of CUI? Contract termination? Breach notification obligations? DoD notification within 72 hours under DFARS 252.204-7012?

1. Rates overall risk — likelihood × impact gives you a risk level. This drives your remediation priorities.

1. Drives a response — for each identified risk above your tolerance threshold, you need a documented response: mitigate (implement a control), accept (document the decision and rationale), transfer (insurance, contractual), or avoid (stop the activity that creates the risk).

The whole thing needs to be documented. Not in your head. Not in a spreadsheet with no author or date. A formal document with scope, methodology, findings, and risk decisions — signed off by management.

Vulnerability Management: The Operational Core

The most operationally intensive part of CMMC risk management is vulnerability scanning under RA.L2-3.11.2. "Periodically" isn't defined — but assessors expect a defined schedule and evidence of execution. Common practice for CUI environments:

• Quarterly authenticated scans of all in-scope systems at minimum. Monthly is better for anything internet-facing.
• Triggered scans whenever a new CVE is published that affects your technology stack.
• Remediation timelines tied to severity: critical vulnerabilities within 30 days, high within 60, medium within 90.

Tools that work for this: Nessus (Tenable) or Tenable.io for network and host scanning, Qualys VMDR for cloud-integrated environments. These are the two most common in the defense contractor space. Both can generate reports suitable for your evidence package.

Document your scan schedule in your SSP or a supporting vulnerability management policy. Keep your scan results — assessors will ask for them, and they'll check that the findings were tracked to remediation.

Decision Point: Point-in-Time Assessment vs. Continuous Program

Here's where contractors make a fundamental choice that determines both their compliance posture and their actual security.

Option A: Point-in-time risk assessment. Do an assessment annually, document findings, remediate the worst ones, and move on until next year. This satisfies the letter of RA.L2-3.11.1 if the documentation is good. It does not give you visibility into what happens between assessments — and in CUI environments, things change constantly.

Option B: Continuous risk management program. Integrate vulnerability scanning, security control monitoring, and risk decisions into ongoing operations. Risk assessments happen on a schedule and when significant changes occur (new systems, new CUI workflows, personnel changes, new contract awards). The program produces a current risk register that's reviewed quarterly.

For most contractors handling CUI on an ongoing basis, Option B is the right answer. A point-in-time assessment done in January doesn't tell you about the risk introduced by a new subcontractor added in March or the misconfiguration deployed in a July patch window.

The cost difference is real. A point-in-time annual assessment might run $15,000–$30,000 with outside help. A continuous program — including tooling, process maintenance, and periodic third-party validation — runs $30,000–$80,000 per year for a small contractor (50–200 employees). That's not a small number, but it's the cost of treating risk management as operational rather than ceremonial.

Common Mistake: Treating RA as Three Checkbox Controls

The most common failure mode: contractors implement a vulnerability scanner, run it once, document the findings, fix the critical ones, and call RA "complete." Then they move on to the next domain.

This misses the point in two ways.

First, RA.L2-3.11.1 requires a risk assessment — not just vulnerability findings. Scan results are an input to a risk assessment, not the assessment itself. Without threat identification, likelihood and impact analysis, and documented risk decisions, you have data, not a risk assessment.

Second, the RA controls connect to the rest of your security program. Your risk assessment is supposed to drive your remediation priorities, your security control selections, and your POA&M. If your POA&M was built independently of any risk analysis, that's a gap assessors will notice.

Fix: write a risk assessment policy and procedure that defines your methodology, schedule, inputs, and outputs. Then execute it and keep the results. That's the documentation trail your assessor needs.

What Your Assessor Expects

For RA domain controls, the assessor will examine, interview, and test. Specifically:

• Examine: Your risk assessment methodology, actual risk assessment reports (dated within the last year), vulnerability scan results with remediation tracking, your risk register or POA&M showing risk-driven prioritization.

• Interview: The person responsible for risk management — typically your ISSO or IT manager. They'll ask: "Walk me through your risk assessment process." "How do you determine remediation priorities?" "When did you last run a vulnerability scan, and what did you find?"

• Test: They may run their own vulnerability scan or spot-check your remediation tracking against scan results. If you said critical vulnerabilities are remediated within 30 days, they'll verify it.

The failure mode assessors see most often: organizations that have good scan results but no formal risk assessment connecting those results to decisions. You need both halves — the technical vulnerability data and the documented analysis that contextualizes it as risk.

If you're 12–18 months from your planned C3PAO assessment, now is the time to stand up your vulnerability scanning, run your first formal risk assessment, and begin building the documentation trail. Retroactive risk assessments don't work — the assessor will check dates.

---

Need help understanding how risk management connects to your CMMC implementation plan? Start with the CMMC Risk Assessment Domain controls or chat with our compliance assistant.

Got specific questions about CMMC? Our expert is available around the clock — no waiting, no sales pitch.

Got Questions? Ask our CMMC Expert →

Prefer email? Reach us at ix@isegrim-x.com