Risk Assessment is a three-requirement family with an outsized failure rate. Two of its requirements — periodic risk assessment (3.11.1) and vulnerability scanning (3.11.2) — are fourth and fifth on DCMA DIBCAC's list of most-failed requirements.
Part of the reason is confusion between them. A vulnerability scan is not a risk assessment, and a risk assessment that does not draw on scan results is incomplete. The family expects both, and expects them to inform each other.
What the Risk Assessment family covers
Risk Assessment contains 3 requirements, numbered 3.11.1 to 3.11.3 in NIST SP 800-171 Revision 2. In CMMC Level 2 they carry the practice prefix RA.L2, so 3.11.1 appears as RA.L2-3.11.1.
3.11.1 requires periodically assessing risk to operations, assets and individuals from operating your systems and handling CUI. 3.11.2 requires scanning for vulnerabilities periodically and when new vulnerabilities are identified. 3.11.3 requires remediating vulnerabilities in accordance with the risk assessment.
| Requirement | What it requires | SPRS points | POA&M |
|---|---|---|---|
| 3.11.1 | Periodically assess the risk to operations, assets and individuals from operating systems and processing CUI | 3 | No |
| 3.11.2 | Scan for vulnerabilities periodically and when new vulnerabilities are identified | 5 | No |
| 3.11.3 | Remediate vulnerabilities in accordance with risk assessments | 1 | Eligible |
Point values from the DoD Assessment Methodology v1.2.1. POA&M eligibility under 32 CFR 170.21.
What it costs you in SPRS points
The family puts 9 of the 313 deductible points in the SPRS score at risk. The five-point requirement is 3.11.2. 3.11.1 is worth three points. The remaining 1 is worth one point each.
Nine points from three requirements. The family overlaps closely with 3.14.1 (flaw remediation) in System and Information Integrity, which is DIBCAC failure #3 — so a weak vulnerability program typically costs points in both families.
Why these requirements fail
3.11.1 fails because there is no risk management program at all, or because the organization points to its vulnerability scans as its risk assessment. A risk assessment considers threats, vulnerabilities, likelihood and impact across the environment and its operations, and produces decisions; it is typically performed annually and when significant change occurs.
3.11.2 fails because there is no scanning program, scans are unauthenticated and miss most of what matters, or scanning happens once a year. "When new vulnerabilities are identified" means having a way to rescan when a significant advisory is published, not waiting for the next scheduled scan.
Connecting the three requirements
The family works as a loop. The risk assessment (3.11.1) sets priorities and remediation timeframes. Scanning (3.11.2) finds specific vulnerabilities on a schedule and after significant advisories. Remediation (3.11.3) fixes them in the order the risk assessment dictates, and the results feed the next risk assessment. Document the loop in one procedure so that an assessor can follow a single vulnerability from scan to closure.
What you can and cannot defer
Under 32 CFR 170.21 only one-point requirements may be placed on a POA&M, with the single exception of 3.13.11 when encryption exists but is not FIPS-validated. In this family that makes 3.11.3 eligible for deferral.
Only 3.11.3 is deferrable. Remediation itself can be planned, but the program that finds and assesses risk must exist before an assessment.
Evidence assessors expect
Assessors work at the level of the objectives in NIST SP 800-171A and use examine, interview and test. For this family, have the following ready — the full evidence package checklist covers all 14 families:
- A dated risk assessment with methodology, findings and decisions.
- Vulnerability scan reports on a defined cadence, preferably authenticated.
- Evidence of rescanning after significant advisories.
- Remediation tickets tied to scan findings and to risk ratings.
- A policy defining scan frequency and remediation timeframes.
Frequently asked questions
How often should we scan?
NIST SP 800-171 says periodically and when new vulnerabilities are identified. Monthly authenticated scanning plus ad hoc scans after critical advisories is a common, defensible baseline.
Is a penetration test required?
Not by NIST SP 800-171 Rev 2. A penetration test can support a risk assessment, but it does not replace scanning.
What risk assessment method should we use?
Any recognized method works if it is documented and repeatable. NIST SP 800-30 is the usual reference.
Who should perform the risk assessment?
Someone who understands both the environment and the business: often the security lead with input from operations and leadership. An outside party can facilitate, but the decisions on accepting or treating risk belong to the organization.
Do we need to scan cloud services?
You should scan what you manage. For SaaS, rely on the provider's FedRAMP documentation and assess the configuration you control.