AC.L2-3.11.1[b] — Risk Assessment (Risk Assessments)Domain: Risk Assessment (RA) | Practice: RA.L2-3.11.1 | Objective ID: 3.11.1[b] | Source: NIST SP 800-171 Rev. 2 / CMMC 2.0 Level 2 | Assessment Objective: Risks to organizational assets are periodically assessed. |
Executive Summary (For Leadership and the Board)
CMMC objective AC.L2-3.11.1[b] sits inside the Risk Assessment domain (RA.L2-3.11.1 — Risk Assessments) and reads: Risks to organizational assets are periodically assessed.. Assess risks to organizational assets (systems, data, intellectual property, personnel) on a regular schedule and when significant changes occur. For organizations that handle Controlled Unclassified Information (CUI), this objective is part of the foundation that every downstream control depends on.
Under DFARS 252.204-7012, AC.L2-3.11.1[b] will be evaluated during a full third-party CMMC Level 2 assessment, Joint Surveillance Voluntary Assessment, or formal certification gating DoD CUI contract awards. Leadership and the board should be asking: Who owns this objective? When was it last reviewed? Where is the evidence stored? And what is our remediation plan if a C3PAO flags a gap? Failing this objective in isolation may be POA&M-able under CMMC 2.0; failing it in conjunction with related objectives in the same practice is typically not.
Business Question | What Leadership Must Confirm |
|---|---|
Do we have a documented, owned, and current implementation for the requirement that risks to organizational assets are periodically assessed? | A named control owner exists, the implementation is documented in the SSP, and a defined review cadence is in force. |
Can we produce evidence that this objective is operating effectively across every CUI-bearing system in scope? | Artifacts (logs, tickets, config exports, attestations) are collected on a defined cadence and tied back to AC.L2-3.11.1[b]. |
What happens if this control fails or drifts out of compliance? | A documented detection, escalation, and remediation path exists, with the vCSO as the executive backstop. |
Can we prove this objective to a C3PAO? | The evidence package — policy, configuration, monitoring output, and recertification records — is pre-built and mapped directly to AC.L2-3.11.1[b]. |
Executive Risk Lens: Failures against this objective routinely surface in Verizon DBIR and Mandiant M-Trends data as contributors to CUI exfiltration, ITAR-relevant data exposure, and engineering CUI loss to nation-state adversaries. A single weak point in Risk Assessments can undermine every other access-control and integrity control in the CUI boundary.
How Authorization Should Flow
AC.L2-3.11.1[b] — Risk Assessments Lifecycle
Every step produces audit evidence the C3PAO will request. Source of truth: authoritative system-of-record.
Technical Deep Dive (For Engineers, IAM Admins, and ISSOs)
What the Objective Requires
The implementation must demonstrate: A documented control implementation specifically addressing the requirement that risks to organizational assets are periodically assessed. A named control owner accountable for AC.L2-3.11.1[b]. A monitoring and detection mechanism that produces evidence the objective is operating across all CUI-bearing systems in scope. A documented review cadence with signed evidence of each review.
Evidence Package
Risk Assessment Policy, SSP narrative, Operational evidence (logs, tickets, reports), Review/recertification records, POA&M entries (if any).
Real-World Examples — What Goes Wrong
Example 1 — The Drift That Was Never Caught
During a Cyberwatch engagement, a mid-tier defense supplier discovered that the risk control supporting RA.L2-3.11.1 had drifted out of compliance. The SSP was not the implementation. AC.L2-3.11.1[b] requires evidence of the control as it operates today.
How Northern Data Solutions Helps
NDS provides Cyberwatch assessments, Cyberwatch Advanced services, Compliance-as-a-Service, and vCSO guidance for CMMC Level 2 compliance.