RA.L2-3.11.1 Risk assessments: requirements and evidence

What RA.L2-3.11.1 risk assessment asks a defender to prove

A defense contractor preparing for a Level 2 assessment has to show that it assesses risk on a schedule it set itself. RA.L2-3.11.1 requires periodic risk assessments of the risk to organizational operations, assets and individuals from the systems that process, store or transmit CUI. The organization chooses the interval, but under 32 CFR 170.14(d) it may be no longer than one year. The requirement is worth 3 points under the scoring methodology, and because it is worth more than 1 point it cannot be placed on a plan of action and milestones. It has to be MET before the organization can reach Conditional or Final Level 2 status.

The difficulty is that a single well-written risk assessment does not satisfy the requirement. The assessor will look for a defined frequency, evidence that the assessment happened at that frequency, and a documented method for conducting, reviewing and updating it. NIST SP 800-171A breaks the requirement into two assessment objectives: defining how often risk is assessed, and assessing risk from CUI systems at that frequency. Each objective needs evidence in final form, so a draft risk register or an undated spreadsheet will not count. Confirm your frequency against the current assessment guidance before you write it into the System Security Plan, because the DoW has changed its CMMC schedule and guidance in 2026.

Start by writing the risk assessment procedure and naming the owner, the systems in scope and the trigger events, such as significant system changes. Then run the first assessment, record its results, and set the next review date in the risk register. Ask your assessor or C3PAO which artifacts they expect to see, and ask any implementation partner to state in writing which parts of the procedure they prepare and which parts your staff must sign off on. The assessment itself is owned by your organization. An independent assessor is the only party that can issue a certification, so the evidence must stand on its own without anyone explaining it.

Which systems, data and teams the RA.L2-3.11.1 risk assessment covers

The risk assessment is only as complete as its scope. Before the first assessment, decide which systems, data flows, hosted services and people feed into it, and record those decisions where an assessor can trace them. Confirm each boundary against your own system security plan, since Appendix D of NIST SP 800-171 Rev. 2 maps 3.11.1 to SP 800-53 RA-3 only as a reference point.

Operating systems and environments handling CUI

Start with every operating system, virtual machine, container host and endpoint that processes, stores or transmits CUI, then trace where the data actually goes. Include build servers, backup targets, print servers and administrator workstations, since these often hold CUI copies that nobody lists. Map each environment to the risk assessment so an assessor can see that the review covers the systems the requirement is about. Missing a single CUI path is the most common scoping gap. Confirm the list against your data flow diagrams and SSP.

Enclaves and shared services

Decide whether a CUI enclave sits inside the assessed boundary and whether shared services such as directory, logging, email or patching tools are inside or outside it. A shared service that authenticates or relays CUI generally carries the same risk as the enclave it supports. Document each decision with its reason, because an assessor will ask why a shared system was left out. Confirm the treatment with your assessor's expectations before you finalize the boundary.

Third-party hosted services

Cloud platforms, SaaS collaboration tools and managed services that touch CUI need their own entries in the risk assessment. Record what the provider controls, what you control, and which evidence you receive from them, such as their security documentation or independent reports. Do not assume a provider's assessment covers your risk to operations. Confirm each provider's responsibilities against your contracts and the CMMC cloud guidance before you rely on them.

Teams that supply risk inputs

Risk inputs come from more than the security team. IT operations supplies asset and configuration data, engineering supplies design and change information, facilities supplies physical access and site risks, and HR supplies role changes and terminations that affect who can reach CUI. Name an owner for each input and set a date for their contribution. Without named owners, the assessment tends to reflect only the systems the security team can see directly.

Risk to individuals

The requirement asks about risk to operations, assets and individuals, so the assessment must consider people as well as systems. Consider who can reach CUI, including privileged administrators, contractors and offshore support staff, and what harm a misuse or disclosure could cause to those people. Record the reasoning, not only the outcome. Confirm with your legal or privacy lead whether any personal information in CUI systems changes how individual risk is described.

How an assessor tests RA.L2-3.11.1 against NIST SP 800-171A

This table compares the two assessment objectives that NIST SP 800-171A sets for RA.L2-3.11.1, showing how an assessor examines, interviews and tests each one, what evidence to have ready, and where organizations usually fall short. Read each row as a question the assessor will ask, and treat the evidence column as the minimum set to prepare before the assessment starts.

Assessment objective	Test approach	Evidence requested	Common findings
Objective 1: The organization defines how often risk is assessed	Examine the documented policy or procedure for risk assessments and confirm a stated frequency exists. Interview the risk owner to confirm staff know the interval and follow it.	A written risk assessment policy or procedure that names the frequency, approved by an accountable owner, plus the system security plan entry that refers to it.	No frequency is defined anywhere, the interval differs between documents, or the stated interval is longer than one year, which 32 CFR 170.14(d) does not allow.
Objective 2: Risk to operations, assets and individuals is assessed at that frequency	Examine the most recent risk assessment for the CUI systems in scope and check it covers operations, assets and individuals. Interview system owners to confirm the assessment reflected how the systems are actually used. Test by comparing the assessment against the asset inventory and system boundary.	The completed risk assessment report with a date, scope, threat and impact analysis, identified risks, and results signed by the organization, plus the record of each assessment cycle that falls within the defined frequency.	Assessments cover IT assets but skip operations or individuals, the scope omits CUI systems or cloud services, or the most recent assessment is older than the organization's own defined interval.
Potential evidence: the risk assessment itself	Examine the assessment document for method, scope and approval. Confirm the assessment was performed by people with defined roles.	The final, dated risk assessment document, not a working draft, with the methodology used and the named reviewers.	Only draft or template versions exist, or the document has no date, approver or scope statement, so the assessor cannot confirm it was completed.
Potential evidence: risk assessment results	Examine how identified risks are recorded and whether they are rated and linked to decisions. Interview staff to see whether results informed priorities.	A risk register or results summary with risk ratings, owners and the decision for each risk, such as mitigate, accept or transfer.	Risks are listed without ratings or owners, or results never connect to remediation or plans of action.
Potential evidence: reviews and updates	Test whether the assessment was reviewed and updated after significant changes to systems, including the change records that triggered the update.	Review records, revision history, and change tickets showing when the assessment was revisited after system or boundary changes.	No evidence of review between cycles, or changes to CUI systems, such as new cloud services or new remote access, are not reflected in any update.
Potential evidence: procedures for organizational risk assessments	Examine the procedure document and test whether it is implemented by walking through one recent assessment against it.	A written procedure describing steps, roles, inputs, outputs and how results are disseminated to stakeholders.	The procedure exists but no one can describe it, or the steps in the procedure are not followed in the most recent assessment.

Steps to build a repeatable RA.L2-3.11.1 risk assessment process

This sequence turns the single requirement to periodically assess risk into a documented cycle that names the frequency, the systems in scope, the method, the results, the owners of each decision and the next review date. Each step leaves a record an assessor can read without a walkthrough.

Set the assessment frequency in policy
Write a risk assessment policy or standard that states how often the organization assesses risk. The interval is yours to set, but under 32 CFR 170.14(d) it can be no longer than one year, so the policy should say so in plain terms. Have an accountable executive approve the policy and record the approval date. You are done when the approved document names a specific interval, an owner for the assessment and a trigger for an unscheduled reassessment after significant system changes.
Define scope and build the asset inventory
List every operating system and system that processes, stores or transmits CUI, including the boundary components that connect to them. Record the owner, location, data types and the people or functions that depend on each asset. Confirm the list against the system security plan so the risk assessment and the SSP describe the same environment. You are done when you hold a scoped asset list signed off by the system owner, with a note of anything excluded and why.
Choose a risk method and scoring scale
Select a documented method for identifying threats, vulnerabilities, likelihood and impact to operations, assets and individuals. Define a scale, such as low, moderate and high, and write down how each level is assigned. Keep the method consistent across assessments so results can be compared over time. Ask your assessor or consultant to confirm that the method addresses the assessment objectives in NIST SP 800-171A. You are done when the method is written, approved and applied to a test asset.
Run the assessment and record results
Work through each in-scope asset using the chosen method. Draw on vulnerability scan output, configuration reviews, incident history, threat information and interviews with system owners. Record each risk with its source, the affected operations, assets or individuals, the likelihood and impact ratings and the evidence used. Date the report and keep the draft and final versions separate, because assessors look for final evidence. You are done when a dated results report and the associated risk register exist in final form.
Assign treatment decisions and owners
For each risk, decide whether to mitigate, transfer, accept or avoid it. Name an owner for every decision and a target for the corrective action, and link mitigations to the plan of action and milestones where needed. Accepted risks need a named approver and a justification in writing. Coordinate with the vulnerability remediation process so that the priority of each fix follows the assessed risk. You are done when every register entry has a treatment, an owner and an approver recorded.
Schedule reviews and update the record
Set the next assessment date at or before the interval in your policy and add it to the compliance calendar. Update the risk assessment when systems change, new vulnerabilities affect in-scope assets, or incidents occur, and reflect those changes in the system security plan. Keep prior versions so an assessor can trace how the risk picture evolved. You are done when the calendar shows the next review date, the change triggers are logged and the most recent results are linked from the SSP.

Evidence that passes an RA.L2-3.11.1 assessment

An assessor testing RA.L2-3.11.1 looks for a defined assessment frequency, a completed risk assessment, and proof that the results were acted on and communicated. The six artifacts below connect those steps, and each one must exist in final form at the time of assessment.

Written risk assessment policy

The policy states who runs the risk assessment, what scope it covers, and the interval at which it repeats. Under 32 CFR 170.14(d), the interval you set may be no longer than one year, so the policy must name a specific frequency. The assessor checks that the stated frequency matches what the organization actually did. Confirm that the approval date, owner and version history are recorded, and that the document has been reviewed since the last change to your systems.

Signed and dated risk assessment report

The report records the risk to organizational operations, assets and individuals from systems that process, store or transmit CUI. It must be complete and signed by the accountable official, with a date that falls inside the defined interval. A report that is still a draft does not satisfy the assessment objectives, so finalize it before the assessment begins. Check that it covers every in-scope system in the boundary described in the System Security Plan.

Risk register with owners and treatment decisions

The risk register lists each identified risk, its likelihood and impact rating, a named owner, and a treatment decision: mitigate, accept, transfer or avoid. Assessors check that every risk from the report appears in the register and that each accepted risk has an approver. Entries that remain open should link to a remediation record or plan of action. Keep the register in a tool with change history so that edits over time can be shown.

Review and update records

These records show that the risk assessment was revisited when conditions changed, such as a new system, a significant architecture change or a new threat, and not only on the calendar date. Each entry should name the trigger, the reviewer, the date and the changes made. Assessors use these records to confirm that the assessment reflects the current environment. Link each update to the change ticket or security impact analysis that prompted it.

Asset and data-flow inventory

The inventory is the input to the assessment. It lists hardware, software, cloud services and external connections, and shows where CUI enters, is stored, moves and leaves the environment. An assessor compares the inventory with the risk assessment scope and looks for systems that appear in one document but not the other. Confirm the inventory has an owner, a last-reviewed date and the same boundary used in the System Security Plan.

Distribution records to responsible owners

These records show that the risk assessment results reached the people who must act on them, including system owners, the security lead and executives who accept residual risk. Email transmittals, meeting minutes or tracker assignments all work if they show the recipient, the date and the content. Assessors look for this link because a risk nobody received is a risk nobody treats. Keep acknowledgments with the report so the trail is complete at the time of assessment.

What meeting RA.L2-3.11.1 costs in money and effort

This table compares the main cost components of keeping a periodic risk assessment for RA.L2-3.11.1, who is paid for each, whether it is one-time or recurring, and what drives it up. No dollar figures or durations are given because none are supplied for this requirement, so use the drivers and quote questions to compare written offers. Staff time and evidence upkeep usually cost the most over time.

Cost component	One-time or recurring	What drives the cost	How to keep it down
Staff time to define scope and frequency	One-time, repeated when scope changes	Number of systems, sites, enclaves and CUI flows in scope; how many business units own risks	Keep the CUI boundary in the SSP current so the risk assessment starts from an accurate system list
Staff time to run the assessment	Recurring, at the interval the organization sets (no longer than one year)	Depth of threat analysis; number of asset owners interviewed; whether risk to individuals is assessed separately	Reuse the prior results as a baseline and record only what changed
Tooling and licenses	Recurring (subscriptions, support) plus one-time setup	Commercial GRC or risk platforms priced per user or per asset; open-source tools cost staff time to install and maintain	Compare open-source options against paid platforms on integration effort, hosting and support terms
Evidence upkeep and reviews	Recurring, continuous between assessments	Frequency of system changes that trigger updates; number of document owners; draft and final version control	Tie risk record updates to change management so updates happen when systems change
External review or assessment support	Usually one-time per cycle, sometimes recurring	Whether a consultant reviews methodology, scope and results; who owns the final risk decisions	Buy a review of the method and sample outputs rather than full-time support, and confirm the organization still owns the risk decisions
Assessor sampling effort (certification)	Recurring at each assessment cycle	Number of risk assessment records and system changes the assessor samples; quality of final-form evidence	Keep one final, dated risk assessment record set that maps directly to the assessment objectives

Open-source tools that support RA.L2-3.11.1 evidence

These tools can hold the records that show RA.L2-3.11.1 is performed: the risk register, assessment results and the threat input behind them. None of them makes an organization compliant, because the organization must set its assessment interval, perform the assessment and keep it current. Two of the tools are licensed under AGPL-3.0-only, so confirm the license obligations with counsel before deployment.

Risk register and assessment records

CISO Assistant (AGPL-3.0-only) can hold the risk assessment record that 3.11.1 calls for. Store the systems that process, store or transmit CUI, the threats and impacts considered for operations, assets and individuals, the owner of each risk and the date of each review. Keeping these in one place gives an assessor a single trail to test against the SP 800-171A objectives on frequency and risk. Check whether your edition supports the fields, approvals and versioning you need, and whether the review interval is enforced or only recorded.

Framework mapping and audit trail

CISO Assistant ships more than 200 frameworks, including NIST CSF, ISO 27001 and SOC 2, and runs audits and compliance assessments against them. Use the audit trail to show when each assessment was performed, by whom and against which requirement version. Confirm the mapping the tool applies to NIST SP 800-171 Rev. 2 and to 3.11.1 before relying on it, because a tool-generated mapping is not a determination by an assessor.

Indicator correlation and sightings

MISP (AGPL-3.0-only) supplies threat input that a risk assessment can cite. It correlates indicators by exact match and by advanced patterns such as fuzzy hashes and CIDR overlaps, and it records sightings when an indicator appears in your environment. Its REST API exports to STIX 1 and 2, CSV, and Suricata, Snort and Zeek rule formats, so the same intelligence can feed detection and the risk record. Share events only through sharing groups that your contracts and counsel allow.

STIX-based threat knowledge

OpenCTI (Apache-2.0) organizes threat intelligence as STIX-based entities, relationships and containers. It ingests data through connectors and TAXII, RSS, CSV and JSON feeds, or manual file upload. Use it to document which threat actors and campaigns are relevant to your CUI systems and how they relate to the vulnerabilities in your scan results, which gives the risk assessment a traceable basis. Confirm which connectors your deployment needs and who maintains them, since feed quality determines how defensible the input is.

Who owns the RA.L2-3.11.1 risk assessment and who can help

Your organization owns RA.L2-3.11.1. Under the CMMC rule, the contractor sets how often risk is assessed for the systems that process, store or transmit CUI, but that interval may be no longer than one year. Choosing the interval, deciding what the risk means for operations, assets and individuals, and approving the outcome are management decisions that cannot be handed to a vendor or consultant. Your team is also the party that must be able to show the assessment was carried out and acted upon.

Defined frequency: Set and document the interval for periodic risk assessments, and record any event that triggers an unscheduled review.
Risk decisions: Decide which risks to accept, reduce or transfer, and record the rationale behind each decision.
Risk register: Maintain the register of identified risks, owners and status, and keep it current between assessments.
Sign-off: Have an accountable executive approve each assessment result and its follow-up actions.
Scope of systems: Keep the list of systems that handle CUI current so that every in-scope system is covered.

Before engaging anyone, confirm that you can name the person who signs the assessment and the date on which the next one is due.

Where organizations fall short on the RA.L2-3.11.1 risk assessment

Most failures on RA.L2-3.11.1 come from paperwork that does not match how the system actually runs. The gaps below cover frequency, drafts, scope, change review, ownership and traceability, and each one has a correction an assessor can verify.

No defined assessment frequency

Many organizations say they assess risk "periodically" without naming an interval. The requirement leaves the interval to the contractor, but 32 CFR 170.14(d) caps it at one year, so an undefined or longer cycle fails the first objective. Write a specific frequency into the risk assessment procedure, such as an annual cycle with a fixed review month, and confirm that the last completed assessment falls inside that window when the assessor asks.

Assessments that exist only as drafts

A risk assessment saved as a working document, with open comments or unsigned tables, does not satisfy the assessment objectives. Assessors look for evidence in final form, so a draft from last year shows that someone started the work, not that the organization completed it. Finalize each assessment, record the approver and approval date, and retain the signed version as the record that the assessor reviews.

Skipped cloud and enclave systems

Assessments often cover the corporate network and leave out cloud tenants, enclaves, remote workstations or test environments that process, store or transmit CUI. The requirement covers operating systems that handle CUI wherever they run, so the asset inventory used for the assessment must match the CUI boundary in the system security plan. Reconcile the two lists during each cycle and document any system that falls outside the boundary, with the reason.

No review after system changes

Risk changes when a system changes, yet many organizations run the assessment once a year and never revisit it after a migration, new integration or major patch cycle. Assessors expect to see how changes trigger a reassessment or update, and the DoW FAQ places RA.L2-3.11.1 alongside change management and SSP updates. Tie the assessment to the change process, so each significant change records whether the risk picture moved and which SSP section was updated.

Risk decisions without owners or dates

A risk register that lists threats and ratings but names no accountable owner, target date or accepted-risk approver leaves assessors with nothing to test. The objective asks whether risk to operations, assets and individuals is assessed, and an unowned decision looks like an assessment that was never acted on. Assign a named owner, a decision (accept, mitigate, transfer or avoid) and a review date to every entry, and keep the approval trail with the assessment record.

Evidence that does not trace to the SSP

Risk assessment results often sit in a separate spreadsheet that never links back to the system security plan, so the SSP describes controls that the assessment does not mention. Assessors trace from the SSP statement to the assessment result and then to the control evidence, and a broken link forces a rework. Keep a cross-reference table that maps each assessed risk to the SSP section and the control implementation that addresses it, and update both files together.

How much effort and time does the RA.L2-3.11.1 risk assessment need?

How often must a CMMC Level 2 risk assessment be repeated?

The organization sets the interval, but it cannot be longer than one year. 32 CFR 170.14(d) says that where CMMC requirements use the word periodically, the contractor defines the frequency, capped at one year. NIST SP 800-171A asks the assessor to confirm two things: that a frequency is defined, and that risk to operations, assets and individuals from systems handling CUI is assessed at that frequency. Shorten the interval when the environment changes quickly, such as after major architecture changes, new cloud services or a significant incident. Record the chosen interval in the system security plan so an assessor can compare it with the evidence of each cycle.

Can a small defense contractor run the RA.L2-3.11.1 risk assessment in-house?

Often yes, provided someone owns the process and can show the results. The requirement does not call for a specific tool or a third party. The work is documentation-heavy: defining the method, identifying the systems that process, store or transmit CUI, assessing threats and impacts, recording decisions and reviewing them. Staff who already run the system security plan and the plan of action can usually absorb it. Outside help is most useful for the first cycle, when the method and scope are being set, or where the internal team lacks security assessment experience. Only an independent C3PAO can issue a certification assessment result, so an internal or partner-prepared assessment is evidence for your own program, not a third-party finding.

What does the risk assessment need from engineering and risk owners?

It needs accurate system inputs and named decision makers. Engineering supplies the asset inventory, data flows, network boundaries, hosting locations, third-party connections and recent changes. Risk owners, typically the business or system owner, confirm the impact on operations, assets and individuals and accept or direct the treatment of each risk. Security staff translate threats and vulnerabilities into a consistent scoring method. Plan for a review meeting per cycle and for follow-up when engineering changes a system between cycles. Ask who signs the final version, because an assessor will look for a document in final form, not drafts, and for proof that its findings feed the plan of action and system security plan.

How long does the first risk assessment cycle usually take?

The first cycle takes longest because the method, scope and baseline are created at the same time. Stages typically run in this order: define the risk assessment method and scoring criteria, establish the CUI system boundary and asset inventory, gather threat and vulnerability inputs, assess risk to operations, assets and individuals, document results and treatment decisions, and get owner approval. Duration depends on how many systems handle CUI, how current the inventory is and how many owners must review. Later cycles are shorter because they update existing results. Request a stage-by-stage plan with dependencies in any proposal rather than a single fixed duration, since the true length depends on your environment.

Does a Level 2 assessment currently require C3PAO certification?

The July 2026 suspension changed the schedule, so confirm the current status before planning. The Department of War suspended CMMC Phase II, which had covered the Level 2 C3PAO certification requirement for applicable contracts, and opened a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The DoW CIO About CMMC page, which lists the current phase status, is the place to check, and your contracting officer can confirm what a specific contract requires. Because the eCFR text still shows the original four-phase schedule, do not rely on the regulation alone for timing.

Can the RA.L2-3.11.1 requirement be placed on a POA&M?

No. RA.L2-3.11.1 is worth 3 points under the CMMC Scoring Methodology, and 32 CFR 170.21(a)(2) does not allow requirements worth more than 1 point on a plan of action and milestones. It must be MET to reach Conditional or Final Level 2 status. This makes the first risk assessment cycle a hard dependency for any assessment date. Plan to have a final, approved assessment with evidence of the defined frequency before the assessment window opens, and treat the assessment as a gating item rather than a remediation item.

What should a written scope with a partner include for this requirement?

A written scope should name every deliverable, the systems covered and who approves each step. Ask for: the CUI system boundary and asset inventory covered; the risk assessment method and scoring criteria; the defined assessment frequency and how it is documented in the system security plan; the workshops and interviews with engineering and risk owners; the final risk assessment report in final form; a mapping of findings to the plan of action and to RA.L2-3.11.2 and RA.L2-3.11.3 follow-up; the evidence index that matches NIST SP 800-171A objectives; and the handover and review cycle for later years. Also confirm what the partner will not do, including issuing any audit or certification result, which only an independent assessor can provide.

How DeployOpen prepares RA.L2-3.11.1 risk assessment evidence

DeployOpen prepares the systems, risk assessment process and evidence that an organization needs for RA.L2-3.11.1, while the organization owns its controls and the risk decisions. Independent assessors, not DeployOpen, judge whether the requirement is met.

How we scope

The written scope names every system that stores, processes or transmits CUI and the operating environments they run in.
We agree on the assessment frequency the organization sets, which 32 CFR 170.14(d) caps at one year.
Scope documents list the stakeholders who own operations, assets and individual-impact decisions in each risk assessment.

How we build

We set up a documented risk assessment procedure that defines method, roles, inputs and how results feed the System Security Plan.
We configure a risk register and assessment templates that capture risk to operations, assets and individuals for each in-scope system.
We connect change records, scan results and incident data to the risk assessment so reviews and updates are traceable.

How we hand over

You receive the risk assessment procedure, completed assessment records and dated review and update logs in final form.
We provide a mapping of each assessment record to the two assessment objectives in NIST SP 800-171A so assessors can trace evidence quickly.
Handover includes a short runbook for repeating the assessment at the defined interval and for recording out-of-cycle reassessments after significant changes.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer if the organization wants help between assessments.
Before any formal assessment, confirm with your assessor which evidence formats and review cycles they will accept for RA.L2-3.11.1.