NIST 800-171 Rev 3 ODPs: what you must set and who sets it

Who sets the NIST 800-171 Rev 3 organization-defined parameters?

When a contract or customer points to Rev. 3, the first question is who decides the organization-defined parameter (ODP) values. NIST's OSCAL catalog defines 88 ODPs across 50 of the 97 requirements. NIST does not assign those values itself, and if the federal agency does not specify them, the nonfederal organization must assign them to complete the requirement. In practice, that means the values in your environment are your decision, and an assessor will test whether they are defined, approved and followed.

The DoW CIO document of ODP values referenced in the proposed FAR overhaul rule is not final. That rule was not final as of October 2026, and the comment period closed on 23 July 2026. Until a final rule or contract names values, the organization owns its settings, such as the time period for reporting suspected incidents under 03.06.02 or the vulnerability scanning and remediation frequencies under 03.11.02. An implementation partner can help you document those choices, configure systems to match them and assemble the evidence. Only an independent assessor or certification body reports results, so the values must be defensible on their own terms.

The answer differs by contract. A DoD contract that names Rev. 2 under the current DFARS deviation is assessed against the 110 Rev. 2 requirements, so Rev. 3 ODPs may not apply yet. A civilian or future contract that states Rev. 3 values should be read line by line for the values it supplies. Ask the contracting officer whether the values will be provided in the solicitation or the proposed Standard Form for CUI requirements, and whether they match the DoW CIO list. Where a contract is silent, record your chosen values, the reasoning and the approving owner now, so the evidence is ready if an agency later asks.

How two requirements show ODPs in practice

Requirement 03.06.02 covers tracking, documenting and reporting incidents. It carries two organization-defined parameters: the time period within which suspected incidents must be reported to the organizational incident response capability, and the authorities to whom incident information must be reported. NIST leaves both values open, so if the federal agency that holds the contract does not set them, the nonfederal organization must set them itself before the requirement can be met. An assessor will look for a written, approved value for each parameter and then check that staff actually followed it.

Reporting time period: The value is a defined window, such as a number of hours or days from detection to internal report. Evidence is the incident response plan or procedure stating the window, plus sample tickets showing the time between detection and report.
Reporting authorities: The value names the recipients, which may include the contracting agency, the DoD incident reporting channel, or internal legal and privacy staff. Evidence is a current contact list and a record of who was notified for each sampled incident.
Illustrative example: A team sets a reporting window measured from the moment an analyst confirms a suspected incident. The assessor then pulls three closed tickets and compares the timestamps against that window.
Consistency with other documents: The values in the plan must match the system security plan, the training material and the tooling configuration. Mismatches are a common finding.
Ownership: The security or incident response lead should approve the values and record the approval date and any later change.

Before assessment, confirm with the contracting agency whether it has published values for this parameter and whether the DoD reporting timeline applies to your contract.

Who sets ODP values, and in what order

Organization-defined parameters are values that the requirement leaves open for someone else to fill in. Four parties can be involved, and the order in which they act decides which set of values your system must meet.

The federal agency sets values first

The agency that holds the contract or CUI agreement is the first place to look. If it specifies ODP values in the contract or in its CUI requirements, those values govern your implementation, and NIST's guidance places the application of SP 800-171 with that agency. Ask the contracting officer in writing which values apply to each parameter, and record the answer in your system security plan.

The organization assigns values when silent

If the agency does not specify a value, the nonfederal organization must assign one to complete the requirement. Your values should be defined, justified against your risk assessment and documented in the system security plan. Examples include the frequency of vulnerability scans or the period for reporting suspected incidents, and the same values must then be followed in practice.

The DoW CIO value document

The proposed FAR overhaul rule would have contractors use ODP values published by the DoW CIO, and the Government says it intends to harmonize values across agencies. That document is referenced, not yet binding. Check its current contents before you adopt values, and confirm whether your contracts would point to it once a final rule takes effect.

Form SF XXX communicates values

The proposed rule would use a Standard Form, designated SF XXX, Controlled Unclassified Information (CUI) Requirements, to tell contractors which CUI categories a contract involves, where to report incidents and which ODP values apply. Comments closed 23 July 2026, and the rule was not final as of October 2026. Until a final form exists, ask for ODP values in writing.

The assessor checks definition and use

An assessor under SP 800-171A Rev. 3 checks that each ODP value is defined and that your operations follow it, not only that a value exists on paper. Expect questions on who chose each value, how it was approved and whether logs and scan records show the frequency or time period in use.

Current DFARS deviation still names Rev. 2

DoW Class Deviation 2026-O0025, Revision 3, signed 3 September 2026, has contracting officers use a revised DFARS 252.204-7012 that names SP 800-171 Revision 2 explicitly. It cites a 13 July 2026 DoW CIO memorandum requiring baseline compliance with Rev. 2 while CMMC Phase 2 is suspended. Confirm which revision your current contract names before you plan around Rev. 3 values.

How ODP values change scoping and evidence

Once an organization assigns a value to an organization-defined parameter, that value becomes a commitment the assessor will test. A scanning frequency, a vulnerability remediation window or a review period is no longer background context: it is the standard the system is measured against. For that reason, choose values the system can actually meet on its busiest week, not values that read well in a template. Before fixing a number, have the operations team confirm how the scanner, ticketing queue and change process really behave today, and record who approved each value and why. If a federal agency or contract has already specified a value, use it and document the source. Where the values are still open, expect the proposed FAR rule's reference to DoW CIO published values to change how many of these decisions you own.

The values flow into the system security plan, where each parameter should appear next to the requirement it completes, the tool or process that enforces it and the role responsible. The plan of action and milestones is the other place the values show up. If a scan misses its frequency or a remediation window closes late, the gap belongs in the POA&M with a named owner and a closure date, rather than being quietly absorbed into the SSP. The SSP should describe the actual cadence, so a reviewer comparing the plan with the logs does not find two different stories. Ask your assessor early which format they expect for ODP values, since the SP 800-171A determination statements check that each value is defined as well as followed.

Evidence is where most ODP commitments succeed or fail. A value that was set but never operated is weak evidence, because the assessor has only the document to rely on. A value supported by logs is much stronger: scan reports with dates, ticket histories showing remediation times, alert records from the incident path, and review sign-offs with the reviewer's name. For the incident-reporting parameters in 03.06.02 and the vulnerability parameters in 03.11.02, confirm that your logs can show both the timing of each event and the authority notified. Retain these artifacts over the full period the assessor will sample, and test a few of them before the assessment so gaps surface while you can still fix them.

How to set and document ODP values before an assessment

This sequence turns the organization-defined parameters in your NIST SP 800-171 Rev. 3 scope into agreed, written values that an assessor can trace to specific systems, owners and recurring evidence. It works whether the values come from the contract, from a DoW CIO document, or from your own assignment.

Request ODP values from the contracting officer
Start by asking the contracting officer in writing which NIST SP 800-171 Rev. 3 organization-defined parameter values, if any, the contract or agreement specifies. Ask for the answer to cover each requirement that carries an ODP, and ask which revision the contract cites, because the DFARS clause and the proposed FAR rule point to different revisions. Your output is a dated written reply, or a written statement that none was provided, filed with the contract records. Do not treat a verbal answer as settled.
Check the DoW CIO values and rule status
Next, review the DoW CIO document of ODP values that the proposed FAR overhaul rule refers to, and confirm whether that rule is final. Also check the status of DoW Class Deviation 2026-O0025, Revision 3, which names SP 800-171 Revision 2 explicitly. Record which revision your contract requires, which values apply, and the date you checked each source. The output is a short written applicability note that names the governing revision and the value source for each ODP.
Identify requirements with unset values
Compare the ODPs in your scope against the values you received. NIST's OSCAL catalog defines 88 ODPs across 50 of the 97 requirements, so build the full list from the catalog rather than from memory. Mark each ODP as set by the government, set by a federal document, or unset. The output is a gap register listing every unset ODP and its requirement number, such as 03.06.02 or 03.11.02, which together carry six ODPs.
Assign and justify values for each gap
For each unset ODP, propose a value and document the reasoning, such as the risk tolerance, the system's criticality, and the frequency that your existing processes already support. Have a named accountable official approve each value, and confirm with the contracting officer that the assignment is acceptable where the contract requires it. The output is an ODP value register with the value, rationale, approver and approval date for every parameter. Assessors will test that every ODP has a defined value, so an empty field is a finding.
Map each value to components and owners
Link each approved value to the system components it governs, such as the scanners, SIEM, incident ticketing and authentication services inside the CUI boundary, and name one owner for each. For example, a vulnerability scanning frequency applies to the scanner, its scan scope and the team that reviews results. The output is a traceability matrix that connects each ODP, its requirement, the component it applies to, and the owner who answers for it. (This is an illustrative structure, not a required format.)
Schedule recurring evidence for each value
For every ODP that sets a frequency or time period, define the recurring artifact that proves the value was met, such as scan reports, incident reporting records or remediation tickets, and set who collects it and where it is stored. Confirm that these artifacts can be produced for the period an assessor will examine. The output is an evidence calendar tied to the traceability matrix, so the SSP, the self-assessment and any Government or third-party assessment reference the same values and the same records.

What must be in place before an assessor reviews ODPs

Before an assessor tests organization-defined parameters, the organization needs a written record of every value, proof that each recurring activity actually runs on that schedule, and matching entries in its incident and vulnerability records and its system security plan. Each card below names one item and how to check it.

Written ODP register tied to requirement IDs

Keep one register that lists every ODP by requirement ID, such as 03.06.02 or 03.11.02, with the value in use, who set it, and whether the value came from a federal agency or was assigned by the organization. NIST does not assign values, so an empty or undated entry leaves the requirement incomplete. To check it, pick three requirements at random and confirm that the register value, the SSP text, and the procedure owner all agree.

Proof recurring activities run on schedule

Where an ODP sets a frequency, the assessor expects records showing the activity happened at that interval, not just a policy stating it. Monitoring logs, review sign-offs, and scan job histories should have timestamps that line up with the stated frequency. To check it, compare the most recent three cycles against the register and look for gaps, skipped cycles, or reviews signed after the due date.

Incident reporting paths matching authorities

Requirement 03.06.02 has ODPs for the time period to report suspected incidents and for the authorities that receive incident information. The reporting procedure, on-call roster, and ticketing workflow must name the same authorities and deadlines as the register. To check it, run a tabletop exercise, time how long the report takes to reach each listed authority, and confirm that the contact details are current.

Vulnerability scan and remediation records

Requirement 03.11.02 has four ODPs covering monitoring frequency, scan frequency, remediation response times, and how often the list of scanned vulnerabilities is updated. Assessors will expect scan reports, remediation tickets, and change records that show each finding was closed within the response time the organization set. To check it, sample several high-severity findings and trace each one from detection to closure against the register.

System security plan stating the same values

The system security plan under requirement 03.15.02 must describe how each requirement is implemented, including the parameter values in use. If the SSP says one frequency and the register says another, the assessor will question both. To check it, search the SSP for each ODP value and confirm that the wording, numbers, and the date of last review match the register and the operating records.

Why ODPs change cost and effort

Organization-defined parameters change cost because each value you agree to is a commitment your staff, tools and evidence process must meet for as long as the system handles CUI. A review frequency, a scan cadence or a remediation time limit looks like a paperwork choice during planning, but it sets how often people must act and what records they must keep. Your organization pays its own staff for that agreement work, including the security, compliance and system owners who negotiate values with the contracting agency, and the people who then run the cycles. Ask any quote to show those internal hours separately, so you can see how much effort sits with you before any outside party is involved.

Tighter values usually cost more in tooling and labor. Two examples in the Rev. 3 requirements show the pattern: 03.11.02 has ODPs for how often the system is monitored and scanned for vulnerabilities, and how long remediation may take, and 03.06.02 has an ODP for how quickly suspected incidents must be reported. A faster scan cadence or a shorter remediation window may require a scanner that runs on schedule, asset inventories that stay current, and ticketing that tracks deadlines. An implementation partner is paid under a written scope to design and configure that tooling, build the procedures and prepare the evidence. An independent assessor is paid to test whether the values are defined and followed, which is separate from the preparation work. Ask the partner to price each tooling change and each procedure as its own line item.

Recurring labor is where ODP values often matter most. Each cycle needs a record that proves the frequency was met, such as scan reports, monitoring logs and remediation tickets with dates, and someone must review them. If the agency or the DoW CIO publishes values, your cost may fall because you adopt a standard set, but you still pay to collect evidence against it. Before signing, ask for the agreed ODP values in writing, the evidence each one produces, who reviews it and how often, and a quote that separates one-time setup from recurring monitoring. Confirm these details with the contracting officer, since the published values and the final rule status may change.

What usually causes ODP rework

Most ODP rework traces back to a few repeatable mistakes made early, before any assessment begins. Each pitfall below carries a different risk, from a wrong revision on a contract to a documented value the team cannot actually meet. The avoidance step for each is what a team should settle in writing before it finalizes its values.

Assuming Rev. 2 timing still applies

Teams often carry over Rev. 2 habits, such as treating a periodic check as a fixed cadence they already run, without reading the Rev. 3 wording for each requirement. Rev. 3 added organization-defined parameters that Rev. 2 left unstated, so a process that satisfied Rev. 2 may not define the time period or frequency Rev. 3 expects. Avoid this by mapping each Rev. 3 requirement to its parameters and confirming which revision the contract currently names.

Choosing values without checking the contract

Values set internally can conflict with what the federal agency or the CUI form specifies. The proposed FAR rule would have contractors use a standard CUI requirements form that lists the ODP values that apply, and it points to DoW CIO-published values. Avoid this by reading the contract, the CUI requirements form and any agency-provided values before writing a single parameter, and by logging the source of each value.

Setting values the team cannot meet

A value such as a short vulnerability remediation window or a frequent scan cadence is only useful if the team can perform it and show the records. Aggressive values set on paper become findings the first time an assessor compares logs against the stated cadence. Avoid this by testing each proposed value against current staffing, tool capacity and change windows, then documenting exceptions in the plan of action rather than in silence.

Leaving the system security plan out of date

When an ODP value changes, the system security plan must describe the new value, the procedure behind it and the evidence that proves it. Teams often update the procedure but not the plan, so the plan describes a cadence the operations record no longer matches. Avoid this by assigning an owner to each parameter, linking every change request to a plan revision, and comparing the plan against logs at each review.

Questions buyers ask about NIST 800-171 ODPs

Does Rev. 2 or Rev. 3 apply to our contract right now?

For DoD contracts, the Rev. 2 requirements still govern as of October 2026. DoW Class Deviation 2026-O0025, Revision 3, has contracting officers use a revised DFARS 252.204-7012 that names SP 800-171 Revision 2 explicitly, and it cites a 13 July 2026 DoW CIO memorandum requiring baseline compliance with Rev. 2 while CMMC Phase 2 is suspended. The 32 CFR 170.14(c)(3) rule also ties CMMC Level 2 to the 110 Rev. 2 requirements. Read the clause and any task order in your contract, and confirm the revision with your contracting officer before you plan work against Rev. 3. Rev. 3 has 97 requirements, and its ODPs only matter once a contract or proposed rule points to them.

Can our organization choose its own ODP values?

Yes, but only when the federal agency has not set them. NIST does not assign ODP values. If the agency does not specify a value, the nonfederal organization must assign one to complete the requirement. Each value is a decision the organization must document, such as how often a system is scanned or how quickly a vulnerability is remediated. Those values should match your risk assessment, your policies and what you can actually evidence. A value you cannot meet or prove will fail an assessment just as a missing control would, so set values you can operate every day.

Can a consultant or implementation partner set the ODP values for us?

A partner can propose values, build the procedures and configure systems to meet them, but the organization owns the decision and the controls. Accountability for the values sits with the organization and, for contract purposes, with the federal agency that holds the contract. DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and an independent assessor is needed to test the values against SP 800-171A. Ask the partner to show which ODP values it recommends, why, and which evidence will prove each one.

What would the proposed FAR rule change about ODP values?

The FAR overhaul proposed rule published 23 June 2026 would require contractors handling CUI to comply with SP 800-171 Rev. 3 using ODP values published by the DoW CIO. It would also use a Standard Form, SF XXX, that tells contractors which CUI categories a contract involves, the safeguarding or dissemination authority, where to report CUI incidents, and the ODP values that apply. The Government says it intends to harmonize ODP values so contractors follow one approach across agencies. Comments closed 23 July 2026, and the rule was not final as of October 2026. Track the final rule and the DoW CIO value document, and plan for values to arrive in the contract rather than being chosen by you.

How many Rev. 3 requirements carry organization-defined parameters?

NIST's OSCAL catalog defines 88 ODPs across 50 of the 97 Rev. 3 requirements. NIST's change analysis counts 49 Rev. 3 requirements with new ODPs that let agencies or contractors set values, such as review frequencies and time periods, that Rev. 2 left unstated. Two examples show the range. Requirement 03.06.02 has two ODPs, the time period for reporting suspected incidents and the authorities to receive incident information. Requirement 03.11.02 has four, covering monitoring frequency, scanning frequency, remediation response times and the frequency of updating the list of vulnerabilities to scan. SP 800-171A Rev. 3 also checks that each ODP value is defined.

What does our team need to provide to start an ODP review?

Start with a written inventory of the systems and service providers that store, process or transmit CUI, along with the current system security plan and any existing policies and procedures. Then gather the values you already use for scanning, incident reporting, log review and patching, and the contract's CUI and reporting terms, including any ODP values the agency has specified. Record who operates each control and where its evidence is kept. Ask a prospective partner to scope the work in writing before it starts, listing the systems, the ODP decisions, the deliverables and the timeline, so the quote follows from a defined scope.

How DeployOpen prepares ODP evidence for your assessment

DeployOpen is a Chainscore Labs company that implements self-hosted open-source platforms inside your own infrastructure. We help you prepare the systems and documented values that the organization-defined parameters in NIST SP 800-171 Rev. 3 require, while your organization owns its controls and an independent assessor produces any assessment result.

How we scope

We list every requirement that carries an organization-defined parameter in the systems in scope for your engagement.
We confirm with your contracting officer or sponsor which ODP values the contract specifies and which remain for you to assign.
Scope, deliverables and timelines are agreed in writing before work starts, as engagements are fixed-scope.

How we build

We configure monitoring, scanning and logging so each parameter value, such as scan frequency, is enforced by the system.
We set up incident reporting paths and response timers so the values in requirement 03.06.02 can be shown in operation.
We test configured settings against the determination statements in SP 800-171A Rev. 3 before any assessor sees them.

How we hand over

We document each assigned ODP value with its rationale, owner and the requirement it completes, ready for your system security plan.
We deliver configuration records, scan schedules and sample logs that show each value operating over time.
We record open gaps in a plan of action and milestones so your team can track and close them after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work ends.
We can update documented ODP values when the DoW CIO publishes values or a final rule changes what applies to your contracts.
Confirm with your sponsor and your assessor which evidence format they accept before we finalize the handover package.

NIST 800-171 Rev 3 organization-defined parameters (ODPs)