CMMC Level 2 Practice 3.11.1: Periodically assess the risk to organizational operations (including mission, functions, image, or

To meet cmmc level 2 practice 3.11.1: periodically assess the risk to organizational operations (including mission, functions, image, or requirement, you must run a recurring, documented risk assessment focused on how threats and vulnerabilities could impact your ability to perform DoD work involving CUI, then track risk treatment decisions to completion. Keep evidence that the assessment happens “periodically” and drives actions. ¹

Key takeaways:

• You need a repeatable cadence, defined scope, and written methodology for risk assessments tied to CUI operations. ²
• Assessments must produce outputs you can defend: risk register entries, treatment plans, and leadership decisions. ²
• Auditors commonly fail organizations on 3.11.1 due to missing evidence of execution, not missing policy language. ³

Practice 3.11.1 is the “prove you manage risk” requirement in CMMC Level 2. It maps directly to NIST SP 800-171 Rev. 2 and expects more than a one-time spreadsheet or an annual checkbox exercise. Your assessor will look for a living process that identifies risks to the parts of the business that handle CUI (systems, people, facilities, and third parties), evaluates likelihood and impact, and then drives real decisions: mitigations, acceptance, transfer, or avoidance. ¹

Operationalizing 3.11.1 quickly is about reducing ambiguity. You define what “periodically” means for your organization, define the scope in terms of CUI flows and supporting assets, pick a simple scoring model your team can run consistently, and set governance so risks are owned and tracked. If you already run enterprise risk management, you can reuse it, but you must show that cyber and CUI-relevant risks are assessed and acted on in a way that supports the CMMC Level 2 control set. ²

Requirement summary (what 3.11.1 is asking for)

CMMC Level 2 Practice 3.11.1 expects you to periodically assess risk to organizational operations. In practice, that means:

• You identify threats and vulnerabilities relevant to your environment.
• You evaluate the potential impact on mission/business functions, including reputation/image and other operational outcomes referenced in the requirement text.
• You document results and track treatment actions. ²

This requirement is part of the Risk Assessment family in NIST SP 800-171 Rev. 2 and is assessed within the CMMC program framework. ⁴

Regulatory text

Excerpt / basis: “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.11.1 (Periodically assess the risk to organizational operations (including mission, functions, image, or).” ⁵

Operator interpretation: You must be able to show an assessor that your organization runs risk assessments on a recurring basis, scoped to what matters for CUI handling and delivery of contracted work. The assessment must be repeatable (same method each cycle), produce documented outputs, and connect to remediation work (POA&Ms, tickets, project plans) and leadership decisions. ¹

Plain-English interpretation

“Periodically assess risk” means you do not wait for an incident, contract award, or audit to think about risk. You run a routine that answers:

• What could go wrong for the systems and processes that store, process, or transmit CUI?
• How bad would it be for operations (ability to deliver), mission/functions, and reputation if it happened?
• What are we doing about it, who owns it, and when will it be done? ²

A good assessor takeaway is: you know your top risks, you can show your work, and you can show progress. ³

Who it applies to (entity and operational context)

This applies to defense contractors and other federal contractors handling CUI in environments that must meet CMMC Level 2 requirements for contract eligibility. ⁶

Operationally, 3.11.1 applies wherever CUI is handled and wherever compromise would affect your ability to deliver DoD work, including:

• The CUI enclave or segmented network (if you use one)
• Endpoints, identity systems, email, file services, and collaboration tooling used for CUI
• Supporting services that could impact confidentiality, integrity, or availability (e.g., logging, backup, vulnerability management)
• Third parties that touch CUI or provide security-relevant services (managed IT, cloud, engineering partners) ²

What you actually need to do (step-by-step)

1) Define scope based on CUI handling reality

Create a short scope statement that includes:

• Where CUI is stored/processed/transmitted (systems, apps, locations)
• Key business processes that depend on those assets (engineering, manufacturing, program management)
• In-scope third parties with access to CUI or security-relevant operations ²

Tip: If your CUI boundary is unclear, your risk assessment will read as generic. Start with a CUI data flow map and asset inventory sufficient to bound the assessment. ²

2) Set a “periodic” cadence and triggering events (and write them down)

Write a procedure that states you will perform risk assessments on a recurring schedule and also after key events, such as:

• Major system or network changes
• Onboarding a new third party with CUI access
• Material security incidents
• Significant changes to CUI types, programs, or locations ²

You do not need a complex cadence. You need one you can execute and prove. ³

3) Choose a simple, repeatable methodology

Document:

• Risk model (likelihood x impact or similar)
• Rating scales (what “high/medium/low” means in your context)
• Impact categories mapped to the requirement language (mission/functions, image/reputation, operations) ²

Keep the scoring model stable across cycles so you can show trend and prioritization. ²

4) Identify threats and vulnerabilities from real inputs

Feed the assessment with evidence-based inputs you likely already have:

• Vulnerability scan summaries and remediation backlog
• Security incidents and near-misses
• Audit/assessment findings (internal or external)
• Changes in architecture, identity, remote access, cloud footprint
• Third-party issues (expired SOC reports, security questionnaire gaps, access exceptions) ²

5) Produce a risk register with clear ownership and treatment decisions

For each material risk, capture:

• Risk statement (cause → event → impact)
• In-scope assets/processes affected (tie back to CUI operations)
• Likelihood and impact ratings, with rationale
• Risk owner (named role)
• Treatment decision: mitigate / accept / transfer / avoid
• Treatment plan with tasks mapped to existing controls ²

6) Governance: approve, track, and close the loop

Hold a risk review with stakeholders who can commit resources (IT, security, program leadership). Record:

• Meeting notes and attendance
• Approved treatment plans and due dates
• Risk acceptances with sign-off (who accepted and why) ¹

7) Preserve assessment-ready evidence continuously

Do not wait until pre-assessment to assemble documentation. Build a small evidence pack each cycle and store it in a controlled repository. ³

Where Daydream fits: Daydream is useful as the system of record to map 3.11.1 to a documented operating procedure and to automate recurring evidence capture (risk register snapshots, approvals, and artifacts), so you can show execution without a last-minute scramble. ⁷

Required evidence and artifacts to retain

Assessors typically expect artifacts that show both process and execution. Keep:

• Risk assessment policy or standard (scope, cadence, triggers, roles) ²
• Risk assessment procedure/work instruction (step-by-step method and scoring model) ²
• Completed risk assessment reports for recent cycles (date, scope, results) ²
• Risk register (current and prior snapshots showing change over time) ²
• Evidence of treatment execution: POA&Ms, tickets, change records, project plans, exception approvals ²
• Risk review meeting notes and management approvals ¹

Common exam/audit questions and hangups

Expect questions like:

• “Show me your last risk assessment. What was the scope and why?” ³
• “How do you define ‘periodically’? Where is that documented?” ²
• “How do identified risks become funded work? Show the linkage to tickets/POA&Ms.” ²
• “Who can accept risk? Show sign-off for accepted items.” ²
• “How do third-party risks appear in your risk assessment?” ²

Hangups that cause findings:

• A policy exists, but no completed assessments exist.
• Assessments exist, but there is no proof of follow-through.
• Assessments are generic enterprise risks with no CUI boundary tie-in. ³

Frequent implementation mistakes (and how to avoid them)

Mistake: Treating vulnerability scans as the risk assessment

A scan is an input. 3.11.1 expects analysis of operational impact and treatment decisions beyond CVSS lists. Convert recurring technical issues into risk statements tied to mission delivery and CUI operations. ²

Mistake: No definition of “periodically”

If your cadence is tribal knowledge, you cannot prove compliance. Put it in the procedure and show dated outputs on that cadence. ²

Mistake: Risk acceptance with no accountable sign-off

Accepted risk without authority is a common assessor objection. Define who can accept risk and retain the approval artifact. ²

Mistake: Ignoring third-party pathways into CUI

If managed IT, cloud hosting, engineering partners, or SaaS tools touch your environment, they belong in the risk picture. Add third-party risks as first-class entries with owners and treatment actions. ²

Enforcement context and risk implications

CMMC requirements are tied to DoD contracting eligibility under the CMMC program rule structure. Failures in core governance practices like risk assessment increase the likelihood of assessment findings that can delay or block Level 2 achievement for in-scope contracts. ⁶

Separately, weak risk assessment creates operational exposure: you may invest in controls that do not address your highest-impact failure modes, and you will struggle to justify exceptions during an assessment. Treat 3.11.1 as the mechanism that prioritizes work across the full 800-171 control set. ²

Practical execution plan (30/60/90)

First 30 days (stand up the minimum viable process)

• Confirm CUI scope: boundary statement + high-level CUI data flows. ²
• Publish a short risk assessment procedure: cadence, triggers, scoring model, roles, and required outputs. ²
• Run the first assessment workshop with IT/security/program stakeholders and create an initial risk register. ²
• Create a tracking mechanism that links risks to remediation work items and captures approvals. ³

Days 31–60 (turn results into action and evidence)

• Convert top risks into formal treatment plans with owners and measurable completion criteria. ²
• Establish a risk review meeting rhythm and record decisions consistently. ²
• Build an “assessment evidence folder” structure for each cycle (inputs, outputs, approvals). ³

Days 61–90 (stabilize and make it repeatable)

• Run a second assessment cycle or a targeted reassessment triggered by a major change to show the process repeats. ²
• Perform a gap check: confirm every high-priority risk has an active treatment plan or documented acceptance. ²
• Package your artifacts into an assessor-ready narrative: scope → method → results → actions → leadership oversight. ³

Frequently Asked Questions

What does “periodically” mean for CMMC Level 2 practice 3.11.1?

The requirement does not give a universal interval; you must define the cadence and triggers in your procedure and then prove you follow it with dated assessments. Assessors focus on repeatability and evidence of execution. ¹

Can we reuse our enterprise risk management (ERM) program for 3.11.1?

Yes, if ERM clearly covers the CUI boundary and produces actionable security risk treatment decisions with owners and follow-through. If ERM is too high-level, add a CUI-scoped annex or separate assessment cycle. ²

Do we need a formal risk register?

You need documented results and tracking; a risk register is the most direct way to show identification, prioritization, ownership, and treatment status. Keep historical snapshots to show periodic reassessment. ²

How should third parties show up in the risk assessment?

Include third parties that access CUI or materially affect security operations as explicit risk scenarios (e.g., access paths, data handling, service outages). Assign internal owners and track treatment actions such as contract controls, access restrictions, or contingency plans. ²

What evidence is most likely to make or break an assessment for 3.11.1?

Completed, dated risk assessments with a consistent method, plus proof that top risks resulted in tracked remediation or documented acceptance with approval. Missing execution evidence is a common failure mode. ⁷

We have a POA&M backlog. Does that satisfy 3.11.1?

A POA&M backlog helps, but 3.11.1 expects an actual risk assessment process that identifies and prioritizes risks, not only a list of deficiencies. Connect POA&M items to specific risk statements and treatment decisions. ²

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance

2. NIST SP 800-171 Rev. 2

3. DoD CMMC Program Guidance

4. NIST SP 800-171 Rev. 2; 32 CFR Part 170; DoD CMMC Program Guidance

5. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170

6. 32 CFR Part 170; DoD CMMC Program Guidance

7. DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2