FutureFeed · CMMC Thursday Education Series
Risk Assessment (RA): 3.11.1, 3.11.2, 3.11.3
The short version
If you’re responsible for CMMC compliance, here’s what these three requirements come down to. You need to:
- Understand what could hurt your organization and how likely it is, on a regular schedule
- Scan your systems and software for weaknesses, regularly and whenever new ones show up
- Fix what you find, worst first, based on how risky it is
- Keep dated records of your assessments, scans, and fixes
If you already have those things and can prove them, you’re well on your way. Now let’s talk about what each one actually looks like.
In plain English
This family is about knowing what could hurt you and doing something about it, before someone else finds the weak spot first.
Think of risk assessment as your decision-making process. Every time you choose which vulnerability to fix first, decide whether a risk is acceptable, or pick where to spend your security budget, you’re making a risk-based decision. These three controls make sure those decisions are intentional instead of reactive.
It comes in three parts that build on each other:
- Assess your risk: step back and figure out what could go wrong for your business because you store and handle Controlled Unclassified Information (CUI), how likely it is, and how bad it would be.
- Scan for weaknesses: regularly check your systems and applications for known vulnerabilities, and check again when new ones are announced.
- Fix what you find: clean up those weaknesses, starting with the ones that carry the most risk.
The order matters. Your sense of risk is what tells you which fixes come first.
It’s the first of the quarter, so your team runs a vulnerability scan across your laptops and servers. It flags a missing security update on three machines and an out-of-date application on another. You check which of those touch CUI, patch the highest-risk ones first, and log what you fixed and when. Once a year, you also step back and write down the bigger picture: what could go wrong for the business, how likely it is, and how much it would hurt. That’s what these requirements are asking you to do.
Without a risk assessment: you patch whichever systems are easiest first.
With a risk assessment: you patch the systems that process CUI first, because they carry the greatest business risk. That is exactly why the third requirement says to remediate “in accordance with risk assessments.”
What you need to have in place
To be compliant, each of those boxes needs to be real and repeatable:
- A written risk assessment done on a documented schedule (many organizations choose annually) and after significant changes, covering your CUI environment.
- Regular vulnerability scanning of your systems and applications, on a cadence and when new vulnerabilities are identified.
- A remediation process that fixes findings in order of risk, not at random.
- A risk register, a simple list of the risks you’ve identified, the decisions you’ve made about them, and who’s responsible for addressing each one.
- Dated records of the assessments, the scans, and the fixes.
The thread running through all of it is risk. Scanning tells you what is weak; the risk assessment tells you what to worry about first.
A new stop every Tuesday and Thursday.
Our twice-weekly series breaking CMMC down one step at a time. Opt in and we’ll send each one to your inbox.
What you need to prove it
Think in three buckets. An assessor will want all three, so it helps to build them at the same time.
People
- Someone who owns the risk assessment (often your security lead or a virtual CISO)
- Whoever runs the vulnerability scans
- The IT people who apply the fixes
Tools
- A vulnerability scanner or managed scanning service
- Your patching or remediation tooling
- Somewhere to record risks (a risk register, a spreadsheet, or a GRC platform)
Documents
- A written risk assessment method and the assessment itself
- A risk register listing risks and decisions
- Scan reports with dates
- Remediation records showing what was fixed, and when
- A note in your System Security Plan (SSP) describing the process
You don’t need an expensive platform. You need to show that you look for risk on purpose, and act on what you find.
When should I work on this
Once you understand who has access to your environment and how your people are trained, the next question is: what should I worry about first? That’s what this family answers, so I’d build it right after the people-focused families. So many of the decisions you’ll document later point back to risk: which weaknesses you fixed first, what you decided was acceptable, how you handle a finding. Standing up a repeatable risk process early gives you the “why” behind choices you’ll write down again and again in your SSP. It also pairs directly with Security Assessment, which comes next, so it makes sense to build them close together.
Common challenges
The risk assessment is written once and forgotten.
Why it happens: It gets created to check a box, then never revisited as the business changes.
Recommendation: Schedule it on a documented cadence (many organizations choose annually) and after any major change, and date each version so the history is clear.
You scan but never fix, or can’t prove you fixed.
Why it happens: Findings pile up with no owner, and the remediation that does happen is never recorded.
Recommendation: Give findings an owner, work them in order of risk, and log what was remediated and when.
Everything is treated as equally urgent.
Why it happens: There’s no risk ranking, so the team either panics at every finding or ignores the whole list.
Recommendation: Rank findings by risk so the most dangerous get fixed first. That is exactly what “in accordance with risk assessments” means.
What good looks like
A compliant contractor can usually answer yes to all of these:
- Do you assess your risk on a regular schedule, not just once?
- Do you scan for vulnerabilities on a cadence and when new ones appear?
- Do you fix findings based on risk, worst first?
- Can you prove, with dates, that assessments, scans, and fixes happened?
If any answer is no, that’s your next place to start.
A vulnerability scan is not the same as a risk assessment. The scan finds technical weaknesses in your systems. The risk assessment is the bigger-picture look at what could harm your business and how much. CMMC expects both, and the third requirement specifically ties your fixes back to risk, so scanning alone will not satisfy it.
How this connects to other controls
This family doesn’t stand alone. A few close relationships:
- Security Assessment: your risk decisions feed your self-assessments and your plans to fix gaps (POA&Ms). These two families work as a pair.
- System & Information Integrity: that family handles ongoing patching and monitoring, while this one sets the risk-based priorities for what to fix first.
- Access Control and beyond: many of the narratives you write for later controls point back to the risk decisions you make here.
The requirements, word for word
For your reference, here’s the exact language so you’re working from the source and not a paraphrase:
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.
Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
Remediate vulnerabilities in accordance with risk assessments.
CMMC: Everything You Need to Know to Get Started (6th Edition)
Want the full compliance framework and the funding resources available to defense contractors? Our guide has it.
Sources
- NIST SP 800-171 Rev 2, Risk Assessment (3.11): the source for 3.11.1, 3.11.2, and 3.11.3
- Related standards: NIST SP 800-53 Rev 5 (RA-3, RA-5)
- DFARS 252.204-7012
