Organization-Defined Parameters in NIST 800-171 Rev 3

NIST SP 800-171 Rev 3 makes organization-defined decisions a core part of compliance work. DoD now publishes binding values for some of those decisions for DFARS contractors. You need an ODP governance plan that your assessors can test.

Concrete definition and scope

NIST published SP 800-171 Rev 3 in May 2024 and set 97 security requirements for protecting CUI in nonfederal systems. NIST defines an organization-defined parameter as the variable part of a requirement that you instantiate by assigning a value or selecting from a list in the requirement text. NIST expects you to set those values during tailoring and to carry those settings into implementation.

You do not treat ODPs as side notes. Assessors will test against the values you set and the evidence that proves you follow them. The CMMC Level 2 Assessment Guide defines organization-defined as set by the organization except where DoD defines specific parameters. That definition puts your ODP choices and records on the table during a C3PAO engagement.

Rev 3 requirement structure

NIST Rev 3 aligns its families with SP 800-53 Rev 5 and reduces the requirement count to 97. NIST increased the use of ODPs inside those requirements. You will see parameters for frequencies and thresholds. You will also see parameters for approval authorities.

Expect parameters such as:

A cadence for control assessments or reviews.
A time threshold for account inactivity or session timeout.

NIST built this pattern to let you fit control intent to your system and risk picture while staying inside the standard. You now carry the burden to set values that match your environment, then prove that your teams follow them.

DoD memorandum and contractor obligations

DoD issued an “Organization-Defined Parameters for NIST SP 800-171 Rev 3” memorandum that assigns specific values for select parameters. DoD wrote those values for contractors that handle CUI under DFARS and CMMC. You must adopt those DoD-defined values where the memo assigns them. You then continue to set values for other parameters that the memo leaves to you.

The memo gives examples that name ODP fields such as a required frequency for assessing security requirements for systems and their environments of operation. The DoD CIO CMMC Resources page lists this memorandum alongside NIST SP 800-171 and CMMC assessment materials, which confirms its place in the program stack for contractors.

CMMC alignment and assessed boundaries

DoD still runs CMMC Level 2 assessments against the Rev 2 control set until DoD updates guidance. The current guide and process still rely on NIST SP 800-171A assessment methods. You should keep your Rev 2 score accurate, then prepare your Rev 3 ODP positions in parallel. That preparation work will shorten your transition when DoD signals a Rev 3 move.

The Assessment Guide v2.13 calls out organization-defined parameters as org-set unless DoD defines them. The Cyber AB CAP v2.0 issues a certificate of status for a discrete system boundary. That scope rule puts a fence around your ODPs. You must apply each parameter consistently inside the assessed system. Your SSP and asset inventory need to show that consistent application across the boundary you define.

You will also see ODP thinking map back to Rev 2 expectations that remain in play while DoD completes the transition. Examples include:

CA.L2-3.12.1, where you assess controls to test effectiveness on a set cadence.
RA.L2-3.11.1, where you assess risk for operations that process, store, or transmit CUI.

Those Rev 2 identifiers do not govern Rev 3 numbering. They do remind you that assessors already expect defined cadences and thresholds that teams follow and document. That same discipline carries forward when you instantiate Rev 3 parameters.

Practical governance and documentation

Set up an ODP governance model that names owners, decision inputs, and the approval path. You can scale this for a small IT team or a distributed security function. The model needs to produce decisions you can defend and repeat.

Build these artifacts and keep them versioned:

An ODP register that lists each requirement with a parameter, the chosen value, the rationale, and the approval record.
A mapping from the ODP register to SSP sections, procedures, and technical settings.

Place the ODP register under change control. Security owners propose value changes with a risk case and evidence. An approval authority reviews the case and signs the change. You then update the SSP and downstream procedures, and you trigger configuration changes where controls live in systems.

Prove the values in production. Sample evidence that shows human actions and system behavior over time. Examples include:

Access control settings that show lockout thresholds and inactivity timers.
Tickets or change records that show review cadences and sign-offs.

Keep scope discipline firm. The CAP requires a defined system boundary, and the CMMC guide expects consistent practice inside that boundary. If you need different parameter values for separate systems, define clean boundaries and defend the split in your SSP. Do not drift into untracked variation inside one assessed system.

Implementation tips for Microsoft 365 and beyond

Most contractors carry part of the CUI system in Microsoft 365 or GCC High. You set ODP values in the register, then you set matching configuration in tenant controls. Focus on controls that expose parameters you will need to prove.

Prioritize two workstreams:

Identity and session. Set and enforce inactivity timeouts and MFA scope in conditional access, then record the exact numbers in the ODP register and SSP.
Device and data. Set and enforce screen lock, encryption, and data loss prevention timers or thresholds in Intune and Purview, then record the exact numbers in the ODP register and SSP.

Run a control check for each parameter with two checks:

A configuration export that shows the current value.
An operations record that shows users and admins following the rule.

Tie each check back to the ODP register entry. Assessors will ask for the value, where you set it, and how you prove that teams follow it.

You can review additional mapping guidance in our post on NIST 800-171 to CMMC Level 2 mapping. For documentation discipline and evidence design, see our guidance on the System Security Plan for NIST 800-171. For scoping, see our post on CMMC scoping and the CUI boundary.

Transition posture and next steps

Set a near-term plan that holds your Rev 2 posture steady and readies your Rev 3 ODPs. You do not need a rip-and-replace. You need clear decisions and clean records.

Work two cycles in parallel:

Maintain Rev 2. Keep your SSP, SA, and POA&M aligned to Rev 2 while DoD continues to assess against it.
Prepare Rev 3. Stand up the ODP register, set initial values for high-impact parameters, and pilot evidence collection.

Focus early on high-friction parameters that drive daily operations or security engineering effort. Cadences and thresholds often fit that profile. Set values that your teams can meet without exception drift. Tie those values to risk drivers and contract needs, then capture the rationale and the approval in the register.

Train the owners who will keep the parameters alive. Name the system admins who set the values in tools. Name the managers who approve changes. Name the compliance lead who keeps the register accurate. Run a short tabletop where the team walks one parameter change from proposal to production, then fix points of friction.

Assessors will look for coherence. They will read the value in your register, find it in your SSP, and pull the matching setting from your systems. They will also pull a sample that shows users and admins following the rule over time. If those three views line up, you reduce debate and keep the assessment on schedule.