Does NIST SP 800-172 apply to our CUI?
NIST SP 800-172 applies only to CUI in a nonfederal system that is associated with a high value asset or a critical program, and only when the federal agency identifies it that way in its contract or agreement. A contract clause or agency notice that mentions enhanced protections is a signal to check, not proof that the enhanced requirements apply to your environment. NIST states that these requirements are intended for federal agencies to use in contracts or other agreements, so the question starts with the agency, not with your own risk appetite. Ask the contracting officer or program office in writing whether the contract identifies a critical program or high value asset, and which system boundary that designation covers.
Three things decide the answer for a given organization. The first is the agency's identification, which should name the program or asset and state whether the enhanced requirements attach to it. The second is the system boundary: only the systems that store, process or transmit that CUI fall within scope, so the boundary you document in your system security plan and enclave design determines how much of your environment is affected. The third is whether the 24 Level 3 requirements selected from SP 800-172 appear in your contract or CMMC assessment scope, since 32 CFR 170.14(c)(4) lists them with DoD-assigned organization-defined parameters where applicable. Your organization owns its controls. An implementation partner can prepare systems, configurations and evidence, but only an independent assessor issues a report or certificate.
Who can require NIST SP 800-172 for CUI?
Four separate decisions determine whether SP 800-172 applies to a given contract. Each one comes from a different authority, so a contractor should confirm all four before scoping work, and treat any gap as a question for the contracting officer.
The federal agency's contract or agreement
NIST describes SP 800-172 as recommended requirements that federal agencies use in contracts or other agreements with nonfederal organizations. Nothing in SP 800-172 applies to a contractor by default. The obligation starts only when the agency's contract or agreement names it. Check the solicitation, the statement of work and every clause the award incorporates, and ask the contracting officer to confirm in writing whether SP 800-172 is part of the award.
Critical program or high value asset designation
NIST ties the enhanced requirements to CUI associated with a high value asset or a critical program. The designation belongs to the agency, not the contractor. A contractor holding CUI for a program that the agency has not marked as critical may face only the SP 800-171 baseline. Ask the contracting officer which program or asset the designation covers, which systems and data it reaches, and whether the designation is recorded in the contract file.
CMMC Level 3 selection
Under 32 CFR 170.14(c)(4), the CMMC Level 3 requirements are 24 requirements selected from SP 800-172 (February 2021), with DoD-assigned organization-defined parameters where they apply. Level 3 is the route through which DoD contracts reach these requirements. Confirm the required CMMC level in the solicitation, since Level 3 applies only where the contract specifies it and Level 3 assessments carry their own scoping and evidence expectations.
Proposed FAR 52.240-7 clarification
The June 2026 FAR overhaul proposed rule would clarify in FAR 52.240-7 that SP 800-172 requirements apply only when the agency identifies them for a critical program or high value asset. The rule was a proposal, not a final rule, when this page was prepared. Contractors should read the clause text in the final version, and ask the contracting officer whether the clause applies to the contract and which identified program or asset it covers.
Cost exposure for enhanced controls
The enhanced requirements are the costliest part of the framework. The rule that adds them estimated initial implementation costs by business size and a recurring cost of 20 percent per year, with the largest figure for businesses with 750 to 1,500 endpoints. A contractor should know which of its systems fall under the designation before committing budget, because scoping the designation to a narrow enclave changes the cost base. Ask for the designated systems list before you price the work.
What NIST SP 800-172 adds on top of SP 800-171
NIST SP 800-172 is a set of recommended enhanced security requirements that sit on top of SP 800-171. It does not replace the 97 Rev. 3 or 110 Rev. 2 requirements a contractor already implements. It targets a narrower threat: advanced persistent threats, meaning patient, well-resourced adversaries who aim to get into a system, stay there and move laterally toward sensitive data. The February 2021 version of SP 800-172 is the edition agencies cite in contracts and agreements, and the PDF on NIST's CSRC site is the authoritative text. Any summary, including this one, is only a guide to it. Before scoping work, read the PDF directly and confirm which edition your contracting agency names.
In plain terms, the enhanced set pushes protection further in areas where a basic control can be bypassed by a determined attacker. The themes are tighter control of privileged access and administrative activity, more thorough detection of suspicious behavior and anomalies across the system, stronger integrity checks on systems and components, deeper analysis of threats, and more deliberate design of systems so that a compromise in one place does not spread. Each theme adds requirements and assessment expectations on top of the matching SP 800-171 family. Expect the most work where your current environment relies on shared administrator accounts, flat networks or manual inventories.
Two decisions come first. Ask the contracting agency whether it has identified any CUI in your system as associated with a critical program or high value asset, because the enhanced requirements are meant for that CUI only. Then map your current SP 800-171 implementation against the SP 800-172 themes to see which gaps are design gaps and which are operating gaps. Ask for the enhanced requirements in writing as part of the contract scope, and confirm with the agency and your assessor how it will be evaluated. Any cost estimates you see should be traced to a named source and a stated scope before you rely on them.
The 2021 version and the Rev. 3 draft compared
NIST published SP 800-172, *Enhanced Security Requirements for Protecting Controlled Unclassified Information*, in February 2021. It provides recommended enhanced requirements for protecting the confidentiality of CUI in nonfederal systems against advanced persistent threats. Federal agencies use it in contracts or agreements when they decide that CUI needs protection beyond the baseline in SP 800-171. The PDF on the NIST site is the authoritative text, so take requirement wording from that document rather than from summaries.
- Status: This is the version referenced in 32 CFR 170.14(c)(4), which selects 24 Level 3 requirements from it, with DoD-assigned organization-defined parameters where applicable.
- Structure: It extends the SP 800-171 requirement families and is built around the advanced persistent threat problem rather than general CUI handling.
- Objectives: Its requirements focus on confidentiality of CUI, without separate integrity and availability objectives.
- Alignment: It predates SP 800-171 Rev. 3, so its numbering and families do not follow the Rev. 3 structure.
- Use: Organizations that must meet CMMC Level 3 or a contract's enhanced requirements work from this text.
Confirm which version a specific contract, solicitation or CMMC requirement names before mapping controls to it.
NIST published SP 800-172 Rev. 3 as a final public draft on 29 September 2025, with comments due 16 January 2026. It was released alongside an initial public draft of SP 800-172A Rev. 3, the companion assessment procedures. Because the text is a draft, its requirements and status may have changed after comment review, so do not treat it as final without checking the NIST publication page first.
- Status: Draft text. Confirm whether NIST has issued a final version and what it says before relying on it.
- Alignment: Rev. 3 aligns with SP 800-171 Rev. 3, so the enhanced requirements use the same family structure as the baseline.
- Added families: Planning, System and Services Acquisition, and Supply Chain Risk Management are added, matching the families that SP 800-171 Rev. 3 introduced.
- Extended objectives: Objectives extend beyond confidentiality to integrity and availability of CUI.
- Scope: NIST says these requirements apply to CUI in a nonfederal system associated with a high value asset or critical program, for use by federal agencies in contracts or agreements.
Confirm the current status and final wording on the NIST SP 800-172 Rev. 3 publication page, and check whether a proposed FAR clause such as FAR 52.240-7 would apply it in your contracts.
Which 24 requirements does CMMC Level 3 select?
CMMC Level 3 draws its requirements from NIST SP 800-172, and 32 CFR 170.14(c)(4) names the 24 requirements it selects from the February 2021 version of that publication. The list is not a copy of the SP 800-172 catalog. Each Level 3 entry carries a DoD-assigned identifier with an L3 marker, and some entries also carry organization-defined parameters that the DoD sets for the program. Because the selection is written into the regulation, the authoritative list is the eCFR text itself, so pull the full set of 24 entries from the eCFR section on the CMMC Model rather than working from a secondary summary or a vendor table.
The two supplied examples show how a Level 3 entry adds to its SP 800-171 counterpart. AC.L3-3.1.2e restricts access to organization-owned or issued resources, which goes beyond the base access control requirement for limiting access to authorized users and transactions by extending the boundary to devices and resources the organization issues. CM.L3-3.4.3e requires automated discovery and inventory of system components, which extends the base configuration management requirement for maintaining a component inventory by making the inventory machine-generated. In both cases, the reader should compare the Level 3 text against the SP 800-171 requirement it extends, identify the added condition, and map that condition to a tool, log source or procedure in the environment.
Before scoping Level 3 work, confirm with the contracting officer or the program office which parameter values the DoD has assigned for the contract, and whether the enhanced requirements apply to the whole CUI environment or only to the critical program or high value asset the contract identifies. Those two answers determine which systems must meet the 24 requirements and what evidence an assessor will expect for each one. Record the assigned values in the system security plan so that the scope and the evidence trace back to the same source.
What the Government estimated for enhanced implementation
This table sets the rule's initial implementation estimates for three nonfederal business sizes against the cost components a buyer actually pays for. The figures apply only to the enhanced SP 800-172 requirements that cover critical programs or high value assets, so read them as a floor for scoping conversations, not a budget. DeployOpen does not publish prices, and any quote follows from a written scope.
| Cost component | Who is paid in practice | One-time or recurring | What drives it |
|---|---|---|---|
| Initial estimate, 25 to 50 endpoints | Rule estimate: $202,500 for a small business (32 CFR rule estimate) | One-time | Endpoint count and number of systems tied to a critical program or high value asset |
| Initial estimate, 50 to 100 endpoints | Rule estimate: about $1,000,000 for this size band | One-time | Scope of enhanced controls applied to each in-scope system |
| Initial estimate, 750 to 1,500 endpoints | Rule estimate: about $2,315,000 for this size band | One-time | Breadth of the enclave, number of integrated tools and the supply chain work required |
| Annual recurring cost | Rule estimate: 20 percent of initial implementation each year | Recurring | Monitoring, tool licenses, re-assessment and staff time to keep enhanced controls operating |
| Internal staff | Your security, IT and compliance teams | Both | Time to define scope, own controls and collect evidence; confirm with your own plan |
| Implementation partner | Firm you hire to prepare systems and evidence | Mostly one-time | Written scope, number of systems and how much custom integration is needed |
| Tooling and licenses | Software vendors and infrastructure providers | Both | Whether existing tools already cover enhanced requirements; confirm with each vendor |
| Independent assessor | Assessor or certification body you engage | Recurring at each assessment | Assessment method and scope; the assessor issues results, not your partner |
What moves the cost of enhanced requirements up or down
The Government's endpoint bands show that cost follows the size of the environment that the enhanced requirements touch. The cards below cover the factors that separate one organization's cost from another's, and what to write into a scope before asking for a quote.
Endpoint count in scope
The rule's cost bands rise with the number of endpoints, running from a small business with 25 to 50 endpoints to one with 750 to 1,500. Each endpoint inside the critical program or high value asset boundary needs monitoring, inventory and configuration control. Narrow the count by confirming which devices actually store, process or transmit the protected CUI. Record the device list and its owner in the written scope.
Boundary of the critical program
The enhanced requirements apply only when the agency identifies a critical program or high value asset, so the boundary decides how much of the environment is covered. A boundary drawn around a whole business unit costs far more than one drawn around the specific program systems. Ask the contracting officer to state the program or asset in writing. Keep that statement in the scope document so the boundary is not argued later.
Number of systems holding the CUI
Every additional system that stores or processes the protected CUI adds configuration, logging, access review and monitoring work. Map data flows from intake to archive, including backups, collaboration tools and reporting databases. Consolidating CUI into fewer, well-documented systems usually lowers the recurring effort. Name each system, its role and its data owner in the scope.
Existing SP 800-171 maturity
An organization that already runs a current system security plan, a plan of action and milestones, and tested SP 800-171 controls starts the enhanced work from a stronger position. Gaps in basic controls, such as unmanaged accounts or unpatched systems, must be closed before the enhanced layer adds value. Review the current assessment record and open findings before requesting a quote. State the baseline in writing so both sides price the same starting point.
Cloud or on-premises hosting
Cloud hosting can reduce some hardware and facility work, but it adds configuration baselines, provider responsibility mapping and logging across accounts. On-premises environments carry more hardware inventory, physical controls and network segmentation work. Either model can meet the requirements, so the cost depends on the chosen architecture. Document the hosting model, provider agreements and shared responsibility matrix in the scope.
Third parties touching protected data
Each external service provider, maintenance vendor or subcontractor that accesses the protected CUI adds due diligence, contract review and monitoring work. Limiting access to a short list of approved providers reduces both the effort and the recurring oversight. Ask for a list of every third party with access, the data they touch and the contract clauses that cover them. Include that list in the written scope before asking for a quote.
How to scope enhanced requirements before work starts
This sequence turns an agency's flag on a critical program or high value asset into a written scope that fixes which systems, requirements and parameter values apply before any implementation partner begins work. Each step closes with a document that the next step depends on.
Obtain written identification from the contracting officer
Start by asking the contracting officer, in writing, whether the CUI is tied to a critical program or high value asset and which systems or data sets that covers. The contract or agreement is owned by the agency, and the agency decides whether SP 800-172 applies at all, so the answer must come from the contracting officer rather than from internal assumptions. The output is a signed or dated record naming the program, the asset and the scope of the flag. Keep it in the system security plan file, because every later decision points back to it.
Map the systems that hold the flagged CUI
Build an inventory of every system, service, cloud account, endpoint and backup location that stores, processes or transmits the CUI named in the written identification. The organization owns this inventory, and its engineering and security leads sign it off. Include the connections that move data into and out of those systems, since they often decide the boundary. The output is a data flow diagram and an asset list that show where the enhanced requirements will reach, and it is complete when a reviewer can trace each copy of the flagged CUI to a named system.
Decide how the enclave or boundary isolates the CUI
Choose whether the flagged CUI stays in a dedicated enclave or security domain, or whether the existing boundary is extended around the mapped systems. The security architect and the system owner make this call, and the choice determines how many endpoints and components the enhanced requirements touch. Record the reasons, the trust relationships with other systems, and the controls that must hold the isolation in place. The output is an approved boundary decision that lists in-scope, separated and out-of-scope assets.
Select the Level 3 requirements that apply
Work from the 24 Level 3 requirements that 32 CFR 170.14(c)(4) selects from SP 800-172 (February 2021), and mark each one as applicable, not applicable or already met by a control elsewhere in the program. The security architect prepares the matrix and the compliance lead reviews it against the boundary decision. Confirm with the agency whether the Rev. 3 draft requirements apply to the contract, since the version in force governs the list. The output is a requirement-by-requirement applicability matrix with a short rationale for every exclusion.
Record the agreed organization-defined parameter values
For each selected requirement that uses an organization-defined parameter, record the value agreed with the agency. Where the agency supplies the value, copy it exactly and cite the source document. Where the agency has not supplied one, the organization must assign it, and the value should be approved by the accountable security owner and reviewed by the contracting officer before use. The output is a parameter register that lists each requirement, each value, who set it and the date it was agreed. Assessors will test against this register, so gaps here delay the whole program.
Write the scope statement and deliverable list
Combine the earlier outputs into a written scope statement that names the systems, the boundary, the selected requirements, the parameter register and the responsible owner for each control. From that statement, write the deliverable list an implementation partner would be asked to produce, such as configuration baselines, technical evidence, documentation updates and test results, with acceptance criteria for each. The organization's accountable executive approves the document before any partner is engaged. The output is a signed scope document that can be used as the basis for a fixed-scope quote.
Confirm the quote matches the written scope
Give the scope document and deliverable list to any prospective implementation partner and ask for a quote that refers to each item. Confirm that the quote lists what is excluded, which agency decisions it depends on, and what the organization must supply, such as staff time, access and hardware. Compare the quote against the costs the Government estimated in the enhanced requirements rule, and ask the partner to explain any gap. The output is an agreed statement of work that is written before work starts, and it is complete when the organization and the partner both sign the same scope.
Who owns the controls, who prepares evidence and who assesses
The organization that holds the CUI contract owns its controls, its risk decisions and its compliance position. NIST says that application and implementation of SP 800-171, and any compliance issues, are the responsibility of the federal agency that holds the contract, and the enhanced SP 800-172 requirements are intended for use through those same contracts or agreements. Internal staff therefore decide scope, accept residual risk and answer to the contracting officer. Typical internal responsibilities include:
- Scope and risk decisions: deciding which systems hold CUI or are tied to a critical program or high value asset, and documenting that boundary.
- Control ownership: naming an accountable owner for each control family, including the organization-defined parameter values the agency has not set.
- Operating the controls: running access reviews, incident response, patching and monitoring day to day after any build is finished.
- Evidence accountability: keeping artifacts current, such as the system security plan, logs and tickets, and confirming that partner-prepared evidence reflects how the system really runs.
- Contract communication: managing the relationship with the sponsoring agency and any subcontractor flow-down.
Before engaging any outside party, confirm which of these tasks your team can staff and which must be contracted.
An implementation partner such as DeployOpen works inside the client's own infrastructure to prepare systems, controls and evidence. It does not own the controls, does not decide scope on the client's behalf and does not issue assessment results. Work is usually fixed-scope, with scope and deliverables agreed in writing before work starts. Activities commonly outsourced include:
- System hardening: applying secure configuration baselines to the systems in the CUI boundary and documenting the settings.
- Logging and monitoring setup: configuring audit collection, time synchronization, alert routing and retention so the records exist when an assessor asks for them.
- Evidence collection: gathering configuration exports, access lists, scan results and screenshots mapped to the requirements being assessed.
- Documentation support: drafting the system security plan and procedures from the actual build, for the organization to review and approve.
- Testing: running security testing against the enhanced controls and reporting findings for the owner to remediate.
A partner's work improves readiness but does not guarantee any assessment outcome. Confirm in the written scope exactly which artifacts you receive and who signs off on each.
Only an independent assessor, auditor or certification body issues a report or certificate. For CUI work tied to DoD contracts, the assessment body is the DoD assessment organization or an authorized third-party assessor under the CMMC program, depending on the contract and the assessment level. The assessor tests the organization's implementation against the requirements, using the assessment procedures in the relevant NIST publication, and reaches its own conclusions. Its role includes:
- Independent testing: examining evidence, interviewing staff and observing systems without relying on the partner's conclusions.
- Scoring and findings: determining whether each requirement is met and recording any gaps.
- Report issuance: producing the formal assessment report or certification decision where the program requires one.
- Limits of role: an assessor that also built the environment is generally not independent of it, so confirm conflict rules before engaging.
- Timing and cost: assessment fees and scope are set by the assessor under its own terms, and you should request those in writing.
Confirm with the sponsoring agency which assessment body applies to your contract before you plan the work.
Questions buyers ask about SP 800-172 before hiring help
Does every contractor have to implement NIST SP 800-172?
No. NIST says the SP 800-172 requirements apply to CUI in a nonfederal system that is associated with a high value asset or critical program, and they are intended for federal agencies to use in contracts or other agreements. An agency identifies where they apply. A contractor that handles CUI under a standard contract without that designation generally works from SP 800-171 alone. The proposed June 2026 FAR overhaul would tie the requirements to the agency's identification of a critical program or high value asset, so ask the contracting officer in writing which requirements, if any, apply to your work.
How much does SP 800-172 cost, and what drives the price?
The cost depends mostly on how many systems and endpoints fall within the critical program or high value asset scope. The Government's rule estimated initial implementation at $202,500 for a small business with 25 to 50 endpoints, about $1,000,000 for one with 50 to 100 endpoints, and about $2,315,000 for one with 750 to 1,500 endpoints, with annual recurring costs of 20 percent of those figures. Those are federal estimates, not quotes. Your own cost will depend on the number of systems in scope, existing tooling, staff time, third-party assessment and how many requirements you already meet under SP 800-171. Ask any implementation partner for a fixed-scope quote that lists each system, deliverable and recurring activity separately.
How long does SP 800-172 implementation take?
No supplied duration exists for implementing SP 800-172, so no reliable number can be given here. Timing depends on how many systems are in scope, how far your environment already meets SP 800-171, the tooling you need to add, and the schedule the contracting agency sets. Treat any published duration with caution unless it comes from the agency, a contract, or a written scope from your implementation partner. Ask for a phased plan with milestones tied to the scope you confirm, and confirm the deadline in the contract before committing staff.
What does the work need from our own team?
Expect the work to need named owners from security, IT operations, identity and network teams, plus a business owner who can approve the scope and accept risk. Engineers configure logging, access control, encryption, monitoring and boundary protection. Compliance staff maintain the system security plan, plans of action and evidence. Leadership signs off on decisions about which systems fall in scope. Because the requirements cover enhanced monitoring and supply chain controls, also involve procurement and the teams that manage external service providers. Assign these roles before the engagement starts, since most delays come from unclear ownership.
Can our own team implement SP 800-172 without outside help?
Yes, an in-house team can implement SP 800-172 if it has the skills and time. Start with the requirement text in NIST SP 800-172 and the assessment procedures in the companion assessment guidance, then map each requirement to a specific control, owner and piece of evidence. Organizations often find the monitoring, configuration and supply chain requirements the hardest to build alone. An outside implementation partner can take on specific technical work, such as deploying self-hosted tooling, hardening, documentation and evidence collection, while your team keeps ownership of the controls and decisions.
Can an implementation partner issue our SP 800-172 certification or report?
No. An implementation partner prepares systems, controls and evidence, but only an independent assessor or certification body can issue an assessment report or certificate. For CUI requirements, the contracting agency or an authorized assessor decides how compliance is verified. Your organization owns its controls and the statements it makes to the government. When you select a partner, confirm in writing that its role is implementation and readiness, and that the assessment is performed by an independent party you choose or the agency designates.
How DeployOpen scopes and prepares enhanced requirements
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so enhanced requirements for CUI tied to a critical program or high value asset can be built into the systems that hold that CUI. DeployOpen prepares systems, controls and evidence for an assessment, while the organization owns its controls and only an independent assessor issues results.
How we scope
- Confirm in writing whether the contract or agreement identifies the CUI as tied to a critical program or high value asset.
- Map which systems, users and cloud accounts hold that CUI and which SP 800-172 requirements apply to them.
- Agree deliverables, scope boundaries and timelines in a fixed-scope written statement before any work starts.
How we build
- Implement the enhanced requirements in the client's own cloud accounts, data center or air-gapped network, on self-hosted open-source platforms.
- Set and document any organization-defined parameters the agency specifies, and flag any values the agency has not provided for confirmation.
- Test the implemented controls against the assessment objectives and record the results for the client's review.
How we hand over
- Deliver system documentation, configuration baselines and evidence artifacts mapped to each enhanced requirement in scope.
- Walk the client's security, compliance and platform teams through the controls, owners and evidence sources they must maintain.
- Hand over runbooks so the client's own staff can operate and evidence the controls without DeployOpen on site.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover.
- Help the client keep evidence current as requirements, agency parameters or the rule text change.
- Ask the client's independent assessor to confirm readiness, since DeployOpen does not issue audit reports or certifications.
