Risk assessment is the foundation for everything else you do in security. It answers the basic question: what could actually hurt us and our data? Without a formal assessment, you’re implementing controls based on guesswork, compliance checkboxes, or vendor marketing rather than real threats to your operation.
For CMMC purposes, a risk assessment is a documented analysis of your CUI-handling systems, the threats facing those systems, the likelihood of those threats, the impact if they occur, and your current defenses against them. It doesn’t have to be elaborate. For a small contractor with 20 people and three systems handling CUI, a spreadsheet is fine. The key is that it exists, it’s been updated at least annually, and you actually acted on what it found.
What the assessor is actually evaluating
The assessor is looking for three things:
First, a dated risk assessment document. This could be a spreadsheet, a formal NIST RMF document, or something in between. It needs to identify your CUI systems, list realistic threats (unauthorized access, data loss, insider threats, ransomware, phishing, supply chain compromise), rate each threat for likelihood and impact, and document your current controls that mitigate each threat.
Second, evidence the assessment hasn’t sat on a shelf. They’ll check the date, ask when you last updated it, and look for a new assessment after significant events (new system, new location, major infrastructure change, security incident, change of leadership in security roles).
Third, proof you actually did something with the findings. If your assessment said “USB write access is a risk to data exfiltration” and your response was “we’ll assess this later,” the assessor will note the gap. If you said “we blocked USB write in BIOS and policy,” they’ll see you addressed it. Risk assessment feeds directly into your Plan of Action and Milestones (POA&M) for items you haven’t yet mitigated.
The organization conducts a documented risk assessment of organizational systems that process, store, or transmit CUI. The risk assessment is performed at least annually and whenever significant changes occur to systems or the operating environment. The assessment includes identification of CUI-handling systems, potential threats (including unauthorized access, data loss, insider activity, ransomware, and phishing), the likelihood and impact of each threat, and a review of existing security controls that mitigate those threats. Findings are documented in a formal risk assessment report and are used to inform updates to the organization's Plan of Action and Milestones, ensuring identified gaps are tracked and remediated according to documented timelines.
How to present your evidence
Gather these before your assessment: the most recent risk assessment document with a clear date, any prior versions showing you update periodically, evidence of review (email chains discussing findings, meeting notes, updated spreadsheets with newer dates), documentation showing you acted on findings (policy changes, control implementation, system changes), and your POA&M showing how gaps are being addressed.
Walk the assessor through the process: “Here’s the assessment we completed in January. We identified these threats. For each one, we documented current controls and any gaps. For the gaps we haven’t closed yet, here’s our POA&M and the timeline.” If you’ve updated it since, show them the new version and explain what changed.
For a small contractor, this is straightforward. A risk assessment spreadsheet with system names, threats, likelihood, impact, current controls, gaps, and action items is sufficient. The key is that it exists, you’ve looked at it in the past year, and you’ve acted on at least some of the findings.
Common failures
No assessment exists. The organization has implemented controls but never formally documented the risks those controls are supposed to address. This is common because controls often come from compliance checklists or industry guidance, and the organization assumes they’re sufficient without assessing actual threats to their environment.
Assessment is outdated. The organization completed a risk assessment three years ago and never updated it. The assessment is now useless because systems have changed, new threats have emerged, and staffing has turned over. The assessor will ask when it was last reviewed and if anything significant has happened since then.
Findings were ignored. The assessment identified a risk (e.g., “remote access without MFA is a threat”), but the organization never addressed it. The risk sits in the assessment, no control was implemented, and no POA&M item was created to track remediation. The control exists elsewhere (maybe it was mandated by another requirement), but the assessment and the control implementation are disconnected.
Assessment is too generic. The assessment lists threats that could apply to any organization (ransomware, phishing, insider threat) but doesn’t connect them to the actual systems or environment the organization operates in. A small manufacturing firm’s risk profile looks different from a healthcare contractor’s. The assessment should reflect your specific operation.
Confusion with vulnerability scans. An organization runs a vulnerability scanner on their network and calls that a risk assessment. A scan finds specific weaknesses in systems. A risk assessment identifies threats, evaluates the likelihood and impact of those threats, and determines whether current controls are adequate. Related but not the same.
If you use an MSP or MSSP
The contractor typically runs the risk assessment, with the MSSP advising on their portion. The MSSP knows your technical environment and can help identify threats specific to the systems they manage, but the risk assessment itself is your document. You own the findings, the ratings, and the decisions about what to mitigate.
What the MSSP typically contributes: expertise on threats to your specific technical stack, help identifying which systems handle CUI, input on the likelihood and impact of technical threats they monitor for, and recommendations for your POA&M based on what they see in your environment.
What they should not do is hand you a generic risk assessment to rubber-stamp. If the MSSP says “you have a critical risk around data backup security” and you don’t understand why, ask them to explain it. The MSSP will be in the room during the assessment, but the assessor may direct risk assessment questions at you specifically since it’s your document.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Q&A: What the assessor asks and what good answers sound like
Disclaimer: This page is a practical guide based on CMMC requirements and assessor feedback. It’s not official CMMC documentation. For formal policy guidance, refer to the official CMMC practice guide published by the CMMC Accreditation Body. Requirements and assessment criteria may change; verify current expectations with your C3PAO before your assessment.