NIST 800-171 Rev 2 vs Rev 3: which revision applies

Which NIST 800-171 revision your contract requires today

DoD contracts and CMMC Level 2 are assessed against the 110 requirements of SP 800-171 Rev. 2 as of October 2026, even though NIST's current version is Rev. 3, which has 97 requirements. The proposed FAR overhaul rule published 23 June 2026 would move contractors handling CUI to Rev. 3 with ODP values published by the DoW CIO, but that rule was not final as of October 2026. Until it is final and any DFARS or CMMC change takes effect, the revision that binds you is the one your contract and clause name.

The revision named in the clause, the contract and the assessment method decides the answer, so check each in that order before committing budget. Read the DFARS 252.204-7012 text in your contract, and confirm which edition of the clause is incorporated. Then ask the contracting officer in writing which revision applies to the work, and whether any class deviation changes it. DoW Class Deviation 2026-O0025, Revision 3, has contracting officers use a revised clause that names Rev. 2 explicitly, and it cites a 13 July 2026 DoW CIO memorandum. Confirm that these instructions still apply on the date you plan to sign or modify a subcontract, because the direction has changed during 2026. The DoW class deviation memo is the document to bring to that conversation.

Spending on Rev. 3 before it is required is a planning choice, not a compliance obligation, and the answer changes the work. Rev. 2 and Rev. 3 differ in requirement numbering, ODPs and the new families, so a gap assessment against one does not transfer cleanly to the other. Ask your assessor or prime contractor whether they will evaluate against Rev. 2 now, and what they expect if the FAR rule becomes final during your contract. Build the plan around the revision you must meet today, and keep a mapped Rev. 3 gap view so the switch, if it comes, does not restart the program.

Plan for Rev. 2, Rev. 3 or both

This table compares three ways to plan around SP 800-171 Rev. 2 and Rev. 3, showing the contract trigger, the evidence each path produces, the main risk if the rule changes and when each fits. The organization makes the choice and owns it, and the independent assessor tests whichever revision the contract names.

Planning option	Contract trigger and evidence	Main risk if the rule changes and when it fits
Build to Rev. 2 now	DoD contracts under DFARS 252.204-7012 and CMMC Level 2 work. Evidence is mapped to the 110 Rev. 2 requirements, with an SSP and SPRS posting based on the Rev. 2 scoring method.	If a final FAR rule requires Rev. 3 with DoW-published ODP values, the Rev. 2 evidence must be re-mapped. Fits organizations whose current contracts name Rev. 2 and who need to show compliance now.
Build to Rev. 3 now	Civilian or future-facing contracts that name Rev. 3, or buyers who ask for it in writing. Evidence is organized by the 97 Rev. 3 requirements, with ODP values documented and assigned by the organization.	A DoD contract may still require Rev. 2 and CMMC Level 2 may still be assessed against the 110 requirements, so duplicate evidence may be needed. Fits organizations whose contracts or buyers name Rev. 3 and who can document ODP choices.
Rev. 2 baseline with a Rev. 3 gap analysis	Evidence built to Rev. 2 for current contracts, plus a requirement-by-requirement gap analysis using NIST's change analysis workbook. The gap list identifies new families, new ODPs and changed requirements.	Gap findings can be incomplete if the analysis is treated as a one-time exercise and not updated. Fits organizations that must meet Rev. 2 today and expect a Rev. 3 requirement, but have no date from a contract.
Who chooses and owns the decision	The organization selects the revision based on the contract, the buyer and its own risk appetite. The contracting officer or buyer defines what applies to the work.	An implementation partner can prepare systems and evidence for either option, but cannot choose the revision for the organization. Confirm the governing revision in writing before work starts.
What the independent assessor tests	The assessor tests the revision the contract or assessment scheme requires, using the assessment procedures that go with it.	Ask the assessor which SP 800-171A edition applies to your assessment before scoping evidence. For CMMC Level 2 self-assessments, the rules in 32 CFR Part 170 govern the procedure.
Ask before committing to a path	Confirm the revision named in the solicitation, the current DFARS clause text, and any pending FAR rule status with the contracting officer.	Ask whether the contract requires specific ODP values, whether a Rev. 3 gap analysis is acceptable as interim evidence, and how a later revision change will be handled in the contract.

What changed between Rev. 2 and Rev. 3

SP 800-171 Rev. 3 reorganized the requirements that Rev. 2 set out, so the count, the families and the way each requirement is worded all moved. Each card below covers one change, with the source that reports it, so you can judge which parts of an existing Rev. 2 implementation carry over and which need work.

Requirement count and families

Rev. 2 has 110 security requirements in 14 families, the set that CMMC Level 2 and DoD self-assessments use today. Rev. 3 has 97 requirements in 17 families, numbered 03.01.01 to 03.17.03. The lower count does not mean less work, because several Rev. 3 requirements bundle or restate Rev. 2 items. Check the numbering against your existing SSP before you map anything.

Withdrawn and new requirements

NIST's change analysis counts 33 Rev. 2 requirements withdrawn and 19 requirements new in Rev. 3. Withdrawn items are not dropped silently: their intent is usually absorbed into another Rev. 3 requirement. Use the workbook's row-by-row mapping to find where each Rev. 2 control now lives, and treat any Rev. 2 item without a clear successor as a gap to close.

Three added families

Rev. 3 adds Planning (03.15), System and Services Acquisition (03.16) and Supply Chain Risk Management (03.17). These align Rev. 3 with the SP 800-53B moderate baseline. Planning covers the policies, procedures and system security plan. The other two cover security engineering in acquisitions and supplier risk. Most organizations will need new evidence for these families, including a supply chain risk management plan, even where they already have good practices.

Security Assessment and Monitoring

The former Security Assessment family is now Security Assessment and Monitoring (03.12). The rename reflects a shift from periodic testing alone toward continuous monitoring of the security requirements. Confirm that your plan of action and milestones process, and your ongoing monitoring of controls, produce records an assessor can follow over time, not only a point-in-time review.

No more basic and derived split

Rev. 2 separated basic requirements from derived requirements. Rev. 3 drops that split, so every requirement is now stated the same way. Teams that built their assessment tracking around the basic and derived labels will need to re-key their control inventory. Do not assume that a requirement once treated as derived now carries less weight.

Organization-defined parameters

Rev. 3 introduces organization-defined parameters (ODPs) for values such as review frequencies and time periods. NIST's change analysis counts 49 requirements with new ODPs, while NIST's OSCAL catalog defines 88 ODPs across 50 requirements. The two sources count differently, so cite the one you rely on. If a federal agency does not set the values, your organization must assign them, and an assessor will check that each value is defined.

Why ODPs and the new families change the work, not only the count

A lower requirement count does not mean less work. Rev. 3 cut the total from 110 to 97, but it added organization-defined parameters (ODPs) to 49 requirements, according to NIST's change analysis, and those parameters are the values that Rev. 2 often left unstated. Review frequencies, time periods and similar settings now have to be fixed somewhere. NIST does not assign those values. If the federal agency with the contract does not specify them, the nonfederal organization must assign them to complete the requirement. The agency's contracting officer and program office own the first decision, and the organization owns the fallback. Ask the agency in writing which ODP values apply, and record every value you set yourself in the system security plan, along with the basis for choosing it.

Rev. 3 also changed what counts as a requirement. It removed Rev. 2's NFO category, which covered controls expected to be in place without being spelled out, and turned foundational policy and procedure controls into explicit requirements. It also added an ORC category for controls covered by other related controls. In practice, an assessor will now ask for a written policy and a written procedure for each family rather than accepting that the practice exists. The three new families make this concrete. Planning (03.15) requires the policies, the system security plan and rules of behavior. System and Services Acquisition (03.16) requires security engineering principles and external provider requirements. Supply Chain Risk Management (03.17) requires a supply chain risk management plan, acquisition strategies and supplier processes. Each one produces a document, a signed acceptance or a contract clause that you must be able to show.

For each new or changed requirement, the evidence is a dated, approved artifact plus proof it is used. Start by listing every requirement that now needs an ODP value or a new policy, then map each to the artifact that will show it, such as a policy document with an approval record, a rules of behavior form signed by users, a supplier security clause in a purchase agreement, or a review log that matches the frequency you set. The NIST change analysis workbook identifies which Rev. 2 requirements changed and how, so you can check this list against your current gaps. Confirm with your assessor which form of evidence they will accept before you write the artifacts.

How to use NIST's change analysis to plan the transition

The sequence turns NIST's Rev. 2 to Rev. 3 change analysis into a requirement-by-requirement plan, so the organization knows which controls, parameters, documents and evidence must change before an assessor tests against the revision named in the contract.

Download the change analysis workbook
Obtain the NIST Rev. 2 to Rev. 3 change analysis workbook from the NIST publication page and keep the version you used on file. The compliance lead or security architect should confirm that the workbook matches the Rev. 2 and Rev. 3 requirement lists in NIST's publications. The output is a versioned copy of the workbook that the rest of the sequence references, so every later decision can be traced to NIST's published mapping.
Map each Rev. 2 requirement to Rev. 3
Build a mapping sheet that lists every current Rev. 2 requirement from the 110 in the 14 families and records its Rev. 3 counterpart from the workbook. Requirements with no counterpart, and the 19 new Rev. 3 requirements, must be listed separately so nothing is dropped silently. The mapping sheet is complete when every Rev. 2 line has a Rev. 3 entry or a withdrawn status, and every new Rev. 3 requirement has an owner for review.
Read change types and summaries line by line
For each mapped line, read the change type and NIST's summary of what changed, then add a column with your reading of the practical effect on your environment. Distinguish requirements that changed only in wording from those with significant changes, because the effort differs. The security architect and a control owner should review the lines together. The output is an annotated mapping with a short effect note for every requirement.
Flag ODP values and new evidence needs
Mark each requirement that carries an organization-defined parameter, such as a review frequency or time period that Rev. 2 left unstated. Confirm with the contracting agency or the prime contractor whether it has specified values, and if not, record which values the organization must assign itself. Note which requirements will need new evidence, such as new policies or a supply chain artifact. The output is an ODP register and an evidence gap list, each with an owner and a source for every value.
Update the system security plan and policies
Revise the system security plan and the supporting policies and procedures to reflect the Rev. 3 requirement structure, the new families and the ODP values chosen in the previous step. The system owner approves the changes, and the document should record the revision it describes. The output is an updated SSP with a change log that links each changed section to the requirement it addresses.
Run a gap assessment against Rev. 3 determination statements
Test the current environment against the Rev. 3 determination statements in SP 800-171A Rev. 3, using the examine, interview and test methods where applicable. Record a finding for each determination statement as met, partly met or not met, with the artifact that supports it. The output is a gap list ranked by remediation effort, which becomes the input to the remediation plan.
Confirm the revision your assessor will test
Before treating the gap list as final, confirm with the contracting officer or prime contractor which revision the contract names and which assessment method applies. Rev. 2 and Rev. 3 can require different evidence, and an assessor tests against the revision in the contract, not the one you prefer. The output is a written confirmation of the revision and assessment method, filed with the gap list so later changes can be checked against it.

What the 2024 and 2026 rules say about timing

What happened when NIST published Rev. 3 in May 2024?

NIST published SP 800-171 Rev. 3 and its assessment companion SP 800-171A Rev. 3 on 14 May 2024, and withdrew Rev. 2 on the same date. Rev. 3 contains 97 requirements in 17 families, while Rev. 2 had 110 requirements in 14 families. Both Rev. 3 documents remain NIST's current versions as of October 2026. For planning, the NIST publication date does not decide which revision your contract enforces. Contracts and the CMMC rule set that revision, so your obligation depends on the clause in your agreement. Your planning should track the Rev. 3 publication as the direction of travel, and the clauses in force as the deadline you must meet.

Why does CMMC Level 2 still use Rev. 2 after NIST withdrew it?

Under 32 CFR 170.14(c)(3), the CMMC Level 2 security requirements are identical to SP 800-171 Rev. 2, so DoD contractors assessed at Level 2 are measured against the 110 Rev. 2 requirements even though NIST withdrew that revision in May 2024. For planning, this means a Rev. 3 program does not replace Rev. 2 evidence for CMMC purposes. Map each Rev. 2 requirement to its Rev. 3 counterpart using NIST's change analysis, but keep the Rev. 2 numbering in your evidence set until the CMMC rule or your contract changes. Ask your contracting officer which revision applies to your specific award.

Which SP 800-171A edition do Level 2 self-assessments follow?

Under 32 CFR 170.16(c)(1), Level 2 self-assessments must follow the June 2018 edition of SP 800-171A, not SP 800-171A Rev. 3. This matters because the Rev. 3 assessment procedures use different determination statements, including checks that ODP values are defined, so an assessment scored against Rev. 3 procedures will not match the method the CMMC rule requires. For planning, prepare your assessment workpapers against the 2018 procedures for Level 2 work, and keep a separate crosswalk if you want to show readiness for Rev. 3. Confirm the current edition requirement with your assessor before you begin.

What does the 23 June 2026 FAR proposed rule mean for contractors?

The FAR overhaul proposed rule published on 23 June 2026 would require contractors handling CUI to comply with SP 800-171 Rev. 3, using organization-defined parameter values published by the DoW CIO. For planning, this would move civilian and governmentwide CUI obligations toward Rev. 3, which means ODP values become part of the contract requirement rather than something you choose. Treat the proposal as a signal to define your ODP values now and to document how each one was set. The rule was not final as of October 2026, so do not assume its text will survive comment review unchanged. Your counsel and contracts team should track the final rule.

What did the 13 July 2026 DoW CIO memorandum change for CMMC?

The 13 July 2026 DoW CIO memorandum, as cited in the September 2026 class deviation, requires baseline compliance with Rev. 2 and suspends the November 2026 CMMC Phase 2 transition. It also lets requiring activities specify CMMC Level 1 (Self) or Level 2 (Self) assessments. For planning, the suspension means the date you expected third-party assessment to begin may have moved, but the Rev. 2 baseline did not. Confirm with each contracting officer which assessment level your solicitations specify, and keep your evidence ready for a Level 2 self-assessment in case it is required.

Why does the 3 September 2026 class deviation matter for DFARS clauses?

DoW Class Deviation 2026-O0025, Revision 3, signed on 3 September 2026, directs contracting officers to use a revised DFARS 252.204-7012 (JUN 2026) that names SP 800-171 Revision 2 explicitly and links the Rev. 2 PDF. For planning, this is the clause most DoD suppliers will see in new and modified contracts, so it sets the revision you are contractually bound to today. Check whether your existing contracts carry the earlier clause version or the revised one, because a modification can change the revision. Do not plan a Rev. 3 cutover as if it were already a contract requirement.

When did the FAR proposed rule comment period close?

The public comment period for the FAR overhaul proposed rule closed on 23 July 2026, and the rule was not final as of October 2026. For planning, the closing date means the text could still change before publication, including the ODP mechanism and the compliance dates. Organizations should not treat the proposed clause as binding, but they can use the comment period as a checkpoint. Confirm the status of the final rule in the Federal Register before you commit budget to a Rev. 3 program tied to a specific date.

How can an implementation partner help with timing decisions?

DeployOpen plans, implements and documents systems and evidence for compliance assessments, so it can help you build a Rev. 2 evidence set and a parallel Rev. 3 gap view under a written, fixed scope. DeployOpen does not issue audit reports or certifications, and it does not decide which revision your contract requires. Ownership of the controls stays with your organization, and the contracting officer and the assessor determine the applicable revision and the assessment. Ask any partner to confirm in writing which revision and assessment method their scope targets, and to state how the work will change if the FAR rule or a new deviation changes the requirement.

Planning mistakes that cost the most in a revision change

Most of the expensive errors in a Rev. 2 to Rev. 3 transition come from reading the wrong document first, treating the lower requirement count as a lower evidence burden, or letting records drift apart. Each card below names one mistake, how to avoid it, and the contract clause or document to check before you spend effort.

Building only to Rev. 3

Teams often start from the newer revision because it is the current NIST publication. Yet DoW Class Deviation 2026-O0025, Revision 3 has contracting officers use a DFARS 252.204-7012 that names SP 800-171 Revision 2, and a 13 July 2026 DoW CIO memorandum requires baseline compliance with Rev. 2. Before any gap work, check the revision named in the solicitation and the awarded contract clause. Build the system security plan and evidence against the named revision, and track Rev. 3 as a planned change.

Equating fewer requirements with less evidence

The drop from 110 requirements to 97 does not reduce the proof an assessor expects. Rev. 3 folds in new policy, planning, acquisition and supply chain expectations, and it adds organization-defined parameters that must be set and documented. Assessors work from the determination statements in SP 800-171A, so each retained requirement still needs artifacts. Ask your assessor which assessment procedure applies to each requirement before you assume the evidence load has shrunk.

Leaving ODP values unset or undocumented

Rev. 3 requirements carry organization-defined parameters, such as review frequencies and time periods. NIST does not assign these values, and if the federal agency does not specify them, the nonfederal organization must assign them to complete the requirement. Record every value you choose, the rationale and the approver, then reference those values in the system security plan. Check the contract for any agency-specified values, and watch for the DoW CIO values that the proposed FAR rule would require.

Updating the SSP without the POA&M and SPRS

A revised system security plan that describes controls the organization has not yet implemented creates a record that contradicts the plan of action and the score posted in SPRS. Each time the SSP changes, reconcile open plan of action items, dates and the requirements they cover, then confirm the posted score still reflects the current state. Assessors compare these records, and a mismatch undermines the credibility of the whole submission. Check the DFARS posting rules and the plan of action clauses in your contract before you update the score.

Treating the change analysis as an assessment

NIST's Rev. 2 to Rev. 3 change analysis maps each old requirement to its new counterpart and flags the type of change, which makes it a useful gap-planning input. It does not measure whether your systems meet either revision, and it is not an assessment result. Use it to build a crosswalk, then test each mapped requirement against the assessment procedures in SP 800-171A and your own evidence. Confirm with the contracting officer which revision will be assessed before treating any crosswalk as a compliance record.

Who owns the controls, who prepares the evidence, who assesses

The organization that holds the contract or handles CUI owns its controls, its risk decisions and its compliance position. Its leadership decides which revision the contract requires, accepts residual risk, and signs the system security plan. Its own staff operate the controls every day, and the organization remains responsible for any statement it makes to a contracting officer or in a score submission. Under NIST's FAQ, application and implementation of SP 800-171, and any compliance issues, rest with the federal agency that holds the contract, regardless of the organization's size, so the contract terms are the first thing to read.

Revision decision: confirm in the contract and the current DFARS clause whether Rev. 2 or Rev. 3 applies, and track the pending FAR rule.
Mapping: own the Rev. 2 to Rev. 3 gap analysis using NIST's change analysis workbook.
ODP values: request values from the contracting agency or the DoW CIO document, and approve any values the organization must assign itself.
SSP and evidence: author and approve the system security plan, and make sure artifacts reflect real operation.
Assessment: choose the assessment type, respond to findings, and manage the plan of action.

Ask the contracting officer which revision and which ODP values apply before any gap work starts.

What to have in place before a Rev. 3 gap assessment

A Rev. 3 gap assessment is only as useful as the inputs behind it. The six items below connect the revision decision, the systems in scope, the CUI data flow, the organization-defined parameters, the plan documents and the people who answer for each requirement. Check them in this order, because each one depends on the one before it.

A written revision decision

Record which revision governs each contract, agreement or system before any gap work starts. Today DoD contracts point to Rev. 2 under the September 2026 class deviation, while the proposed FAR rule would move contractors to Rev. 3. Ask the contracting officer or program office to confirm the revision in writing, and file that answer with the contract record. Sign-off comes from the contracts or legal lead, with the CISO confirming that the assessment target matches the contract.

Change analysis mapped to scoped systems

Use NIST's change analysis workbook to map each Rev. 2 requirement to its Rev. 3 counterpart, then limit the map to the systems that handle CUI. Mark each row as withdrawn, new, significantly changed, no significant change or minor change. The output should be a gap list per system, not a generic summary. The security engineering lead signs off, and the compliance lead confirms the mapping matches the requirement text in the current revision.

Current scope statement and CUI data flow

Document where CUI is created, received, stored, processed, transmitted and destroyed, including every system, cloud service and person involved. The scope statement determines which of the 97 Rev. 3 requirements apply to which assets, so an outdated diagram will produce a wrong gap list. Walk the data flow with system owners and confirm it against access logs and network diagrams. The system owner and the security architect sign off together.

ODP register with values and sources

List every organization-defined parameter that applies to your systems, the value you set, and where that value came from. Rev. 3 leaves many values unassigned, and a nonfederal organization must assign them when the federal agency does not. Note whether each value comes from the contract, a DoW document, or your own policy, and record the date of the decision. Sign-off comes from the risk owner, and the contracting team checks that no value conflicts with the contract.

Current SSP and policies

Confirm that the system security plan describes the scope, the boundary, the implemented controls and the responsible roles, and that the policies and procedures it cites exist and were reviewed in the last cycle. Rev. 3 turns foundational policy and procedure controls into requirements, so missing policy documents now count as gaps, not background. The SSP owner signs off, and an executive sponsor approves the policy set.

A named owner for each requirement

Assign one accountable person to each of the 97 requirements, grouped by the 17 families, and record the evidence each owner will produce. Gaps stall when a requirement such as supply chain risk management or system and services acquisition belongs to no one. Owners should be named in a responsibility matrix, with a backup for each. The CISO approves the matrix, and each owner confirms their assignment in writing.

Questions buyers ask about the Rev. 2 and Rev. 3 decision

Can a Rev. 2 implementation be reused for Rev. 3?

Mostly, but not without a gap review. NIST's Rev. 2 to Rev. 3 change analysis workbook maps each Rev. 2 requirement to its Rev. 3 counterpart and flags the type of change, so a Rev. 2 implementation can be assessed requirement by requirement. Rev. 2 controls that carry over unchanged still need evidence that matches the new wording. The gaps usually appear in three places: the 19 new requirements, the three added families (Planning, System and Services Acquisition, and Supply Chain Risk Management), and the organization-defined parameters that Rev. 2 left unstated. Many requirements with significant changes also need their procedures and evidence rewritten, even where the control itself already exists.

How long does a move from Rev. 2 to Rev. 3 take?

No duration is fixed for this change, so the answer depends on your contract and your own gap analysis. Start by asking the contracting officer which revision your contract requires and when, because the requirement has been changing in 2026. Then run a gap analysis against the change workbook to size the work. The time needed depends on how many requirements your environment already meets, how many system owners must change procedures, how many ODP values you must set, and how much of the system security plan must be rewritten. Ask any implementation partner for a written schedule tied to a defined scope.

Can we map Rev. 2 to Rev. 3 in-house?

Yes, a capable internal team can do the mapping, and the NIST workbook is the starting point. The mapping itself is a reading exercise: find each Rev. 2 requirement, its Rev. 3 counterpart and the change type. The harder work is judging whether your current evidence still proves the new wording. Teams that do this in-house usually need people who know the systems, the security assessment procedures in SP 800-171A Rev. 3, and the organization's CUI boundary. Keep in mind that Rev. 2 remains the assessed baseline in current DoD contracts, so keep the Rev. 2 evidence current while you prepare for Rev. 3.

What does the transition need from our own team?

The work depends on your team's decisions more than on tooling. You need to define the CUI scope, name owners for each system and control area, and decide the ODP values that your contract does not specify. You also need to own the system security plan, because it documents how each requirement is met and must reflect your actual environment. An implementation partner can prepare configurations, logs and evidence, but the organization must approve the policies, risk decisions and ODP values, and must keep the SSP accurate after the work ends.

Can DeployOpen issue a Rev. 2 or Rev. 3 compliance result?

No. DeployOpen prepares systems, controls and evidence for an assessment, but it does not issue assessment reports, attestations or certifications. Only an independent assessor can issue a result, and which assessor applies depends on the contract and the assessment type, such as a self-assessment, a Government assessment or a CMMC third-party assessment. Confirm the assessment method and the required assessor with the contracting officer before you scope the work. Any consultant who promises a compliance result for either revision should be treated with caution.

What drives cost up or down in a revision change?

The main cost drivers are the size and complexity of the CUI boundary, the number of systems and cloud services in scope, and how much existing evidence is reusable. A narrow enclave with documented controls usually requires less rework than a broad environment where policies, logs and configurations are spread across many teams. Costs also rise with the number of ODP decisions, the amount of SSP rewriting and the number of third-party services that must be reviewed under the new supply chain and acquisition families. Ask which of these factors your environment triggers, because the labor mix shifts with each one.

What should we ask for in a written quote?

Ask for a quote that ties every line to a written scope. The scope should name the CUI boundary, the systems and cloud services covered, and the requirements in scope under each revision. Ask the provider to list the deliverables, such as the gap analysis, configuration changes, evidence packages, ODP recommendations and SSP updates, and to state which items the organization must approve or own. Confirm what is one-time and what recurs, including retainers for upgrades, testing and support. Also ask how changes to the contract's revision or ODP values would be handled, and whether any assessment fees are excluded.

How DeployOpen plans the revision transition and prepares evidence

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, and prepares the systems and evidence that a Rev 2 or Rev 3 assessment will examine. We do not issue audit reports or certifications; your contracting officer, assessor or certification body decides which revision applies to your contract.

How we scope

We confirm which revision your contract, DFARS clause or deviation names before any mapping work starts.
Engagements are fixed-scope, with the CUI boundary, systems in scope and deliverables agreed in writing.
We record which organization-defined parameter values your agency has specified and which ones you must assign yourself.

How we build

We map each Rev 2 requirement to its Rev 3 counterpart using NIST's change analysis workbook, flagging gaps one by one.
We configure logging, access control, encryption and configuration baselines in your environment to meet the revised requirements.
We test the controls against the SP 800-171A procedures for the revision your assessment will use, recording what passes and what fails.

How we hand over

You receive the system security plan, policy set and evidence register, with each artifact tied to a requirement number.
Documentation is written so your assessor can examine and interview against it without us presenting it as their finding.
We walk your team through the gap register, open items and the owner responsible for each remaining action.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
When NIST, DoW or the FAR rule changes the required revision, we review the mapping and update the affected evidence.
Retainer scope, response expectations and review cadence are written into the agreement before work begins.