Risk assessment.
What could go wrong, what’s actually vulnerable, and what gets fixed first.
Risk Assessment is 3 of Level 2’s 110 requirements — one of the smallest families, tied with Awareness & Training and Incident Response at three requirements. It asks an organization to periodically think through what could go wrong, scan for the specific vulnerabilities that could let it happen, and remediate in an order that reflects the actual risk rather than whatever’s easiest. Small in count; it’s the loop that keeps the rest of the program honest about where the real exposure sits.
This page explains the family. It does not replace the requirement text or assessment objectives.
01What this family protects
Risk Assessment protects an organization from spending its limited security effort on the wrong things. Periodically stepping back to ask what could go wrong, scanning to find the specific technical gaps that could let it happen, and fixing what’s found in an order that reflects real risk keeps a small IT team’s attention pointed at what actually matters, instead of whatever’s loudest or most recent.
02The rule says
All 3 requirements, condensed to their operative sentence. NIST SP 800-171 Rev. 2 §3.11 has the full text and discussion for each; Source Library covers when to open it.
| § | Requirement |
|---|---|
| 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. |
| 3.11.2 | Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified. |
| 3.11.3 | Remediate vulnerabilities in accordance with risk assessments. |
03In practice
Risk Assessment’s three requirements form a small loop: know what could go wrong and how bad it would be (3.11.1), find the specific vulnerabilities that could let it happen (3.11.2), and fix them in an order that reflects the risk, not just the order they were discovered (3.11.3).
Periodic risk assessment (3.11.1). This doesn’t require a formal enterprise risk framework for a small shop — a periodic, documented look at what could go wrong (a compromised CAD/CAM account, a phishing email that lands on the wrong desk, a vendor’s remote-access credential) and what it would cost the business, revisited on a defined cadence and after anything material changes.
Vulnerability scanning (3.11.2). An actual scanning tool or service run against the organization’s systems periodically and whenever a new vulnerability affecting those systems becomes known — not a one-time scan before an assessment. A scan that only ever runs once, right before a certification event, does not meet a requirement written as “periodically… and when new vulnerabilities… are identified.”
Remediation (3.11.3). This closes the loop: what the scan finds gets fixed, prioritized by the risk it represents rather than worked in whatever order is convenient. A critical, internet-facing vulnerability moves ahead of a low-severity finding on an isolated machine, and the reasoning for that ordering doesn’t need to be elaborate — it needs to be real and consistent.
04Where it fails
The trap is a scan run once, months before an assessment, treated as done rather than as an ongoing practice — the rule’s “periodically” language doesn’t tolerate a single point-in-time snapshot.
A second gap is a scan report that gets filed and not acted on: findings pile up in a spreadsheet nobody works from, and remediation happens opportunistically rather than by any risk-based order. The scan covers half the family; without 3.11.3 actually closing findings, the loop doesn’t complete.
05What evidence may look like
A vulnerability-scan report with a date and a scope that matches the organization’s actual systems; a remediation tracker or ticket log showing findings closed, with rough timing that reflects severity; and a short written risk assessment — even a page — covering the organization’s main systems and what could go wrong on them, updated on a defined cadence.
06At the shop
Blanchard Tool & Machining is the desk’s fictional composite (any resemblance to an actual company is coincidental). Blanchard’s MSP runs an external vulnerability scan against the shop’s internet-facing systems quarterly and an internal scan twice a year, feeding results into a shared tracker the two-person IT team reviews together. A scan last fall turned up an unpatched remote-desktop service exposed to the internet by a misconfigured firewall rule left over from a prior project — flagged critical, fixed within the week, well ahead of a low-priority finding on an isolated test machine that waited until the next scheduled maintenance window.
07Commonly confused with
Security Assessment (CA). CA’s periodic assessment (3.12.1) asks whether the organization’s security controls are working as intended; RA’s risk assessment (3.11.1) asks what could go wrong and how badly. They inform each other — a risk assessment often surfaces controls worth re-assessing — but they’re different questions asked for different reasons. See Security Assessment.
System & Information Integrity (SI). RA’s vulnerability scanning (3.11.2) finds weaknesses before they’re exploited; SI’s monitoring (3.14.6–3.14.7) watches for signs an exploit is already happening. See System & Information Integrity.
08Cross-desk links
None load-bearing for this family. Vulnerability scanning and remediation cadence are covered on this desk’s own family pages; see Security Assessment and System & Information Integrity.
09Sources
| Document | What it’s for |
|---|---|
| NIST SP 800-171 Rev. 2, §3.11 | Full requirement text and discussion for all 3 RA requirements. |
| NIST SP 800-171A | Assessment objectives — how an assessor determines MET for each RA requirement. |
| 32 CFR 170.4 | Defines “CMMC Level 2 security requirement” and ties the 800-171 R2 families to the CMMC Program. |