NIST 800-53 vs NIST 800-171: which one applies to your systems
SP 800-53 Rev. 5 controls are mandatory for federal information systems, while SP 800-171 Rev. 3 gives recommended security requirements for protecting controlled unclassified information (CUI) in nonfederal systems and organizations. If a contract, agency or CMMC clause now names one of these documents, the first question is not which standard is stronger but which system and which data the clause reaches. The answer changes with who holds the data and which system it sits in. A federal agency operating its own system, or a contractor running a system on the agency's behalf, points toward 800-53. A nonfederal contractor that receives and stores CUI in its own environment points toward 800-171, and the contract or program rule decides which revision applies.
Start by writing down every system that will store, process or transmit the data in question, including cloud tenants, backups, support tools and any environment a subcontractor operates. For each one, record who owns the system, whether it is federal or nonfederal, and what the governing contract or rule says. Then confirm the revision the contract cites. The CMMC Program rule at 32 CFR 170.14(a)(2) incorporates SP 800-171 Revision 2, not Revision 3, so a contractor working toward CMMC should confirm the revision in the solicitation before adopting the newer text. The contract, the agency's authorizing body or the CMMC assessment process settles scope. Your organization owns its controls and evidence, a partner can help prepare them, and only the authorizing official, an independent assessor or the relevant assessment body reaches the conclusion that a system meets the requirement.
Where the two documents overlap, the 800-171 requirements were derived from the 800-53 moderate baseline, so a control you build for one usually supports the other. Map the evidence once and then check each requirement against the source controls listed in the SP 800-171 Rev. 3 appendix that traces them, rather than assuming equivalence. The moderate baseline holds 287 controls and enhancements in NIST's Release 5.2.0 OSCAL profile, while SP 800-171 Rev. 3 has 97 requirements, so the 800-171 set is narrower by design. Ask your assessor or contracting officer to confirm in writing which systems and requirements are in scope before you invest in documentation for the wider catalog.
Who each document applies to
Federal agencies operate their own information systems under the Federal Information Security Modernization Act (FISMA) and OMB Circular A-130, and SP 800-53 controls are mandatory for those federal information systems. Contractors that run systems on behalf of an agency generally bring those systems into the same control framework through the contract, so the agency's authorization decision depends on SP 800-53 evidence. The baseline a system uses comes from its impact level, not from the document choice itself.
- Agency-operated systems: The agency is the owner and the authorizing official, and SP 800-53 is the control catalog it assesses against.
- Contractor-operated systems: The contract usually names the baseline and the authorization path, so the contractor's scope is defined by that document, not by SP 800-171.
- Cloud services: Providers that serve federal customers typically reach SP 800-53 through FedRAMP, which sets its own baselines.
- Impact-driven baselines: Low, moderate and high baselines are selected from the FIPS 199 categorization of each system.
Confirm with the contracting officer or agency security office which SP 800-53 baseline and release apply to each system in scope.
Nonfederal organizations that receive or hold CUI on behalf of the government generally do not run federal information systems, so SP 800-53 is not mandatory for them. NIST SP 800-171 Rev. 3 gives those organizations recommended security requirements for protecting CUI confidentiality in nonfederal systems. The requirements are derived from the SP 800-53B moderate baseline, with controls removed where they are primarily a federal responsibility or are covered elsewhere.
- Recommended, not mandatory: SP 800-171 Rev. 3 is guidance, and the contract or agency instruction decides whether it is required.
- Moderate starting point: Under 32 CFR 2002, CUI is categorized at no less than the FIPS 199 moderate confidentiality value, which is why the moderate baseline is the source.
- Smaller scope: The 97 requirements in 17 families are narrower than the 287 controls and enhancements in the moderate baseline.
- Omitted families: Contingency Planning (CP) and Program Management (PM), along with PII Processing and Transparency (PT), are not part of the Rev. 3 requirement set.
Confirm in the contract whether SP 800-171 is required and which revision it names.
Defense contractors that handle CUI for the Department of Defense are subject to CMMC, and the CMMC Program rule at 32 CFR 170.14(a)(2) incorporates NIST SP 800-171 Revision 2, not Revision 3, as the source of CMMC security requirements. This means a defense contractor's assessment scope may follow Rev. 2 even though Rev. 3 is the newer publication. Rev. 3 is still the more current NIST text, so organizations should not assume it replaces the revision named in CMMC.
- Revision named by the rule: The CMMC source requirements follow Rev. 2 under 32 CFR 170.14(a)(2).
- Newer guidance: SP 800-171 Rev. 3 may be useful for internal design, but it does not change the CMMC scope by itself.
- Scoping documents: The CMMC scoping and assessment documents define which requirements a given assessment covers.
- Contract clauses: Solicitations and contracts can add requirements or name a different revision for a specific program.
- Program changes: Confirm any revision change with the CMMC program documentation before scoping a new assessment.
Confirm the applicable revision in the contract and the CMMC scoping documents before you choose which requirement set to implement.
How SP 800-171 Rev. 3 was derived from the 800-53 moderate baseline
SP 800-171 Rev. 3 is a derived set, not an independent one. NIST started from the SP 800-53B moderate baseline, which holds 287 controls and enhancements in the Release 5.2.0 OSCAL profile, and removed every item that was primarily a federal responsibility, not directly related to protecting CUI confidentiality, adequately addressed by another control, or not applicable to nonfederal systems. What remained is 97 requirements. The starting point is moderate because, under 32 CFR 2002, CUI is categorized at no less than the FIPS 199 moderate confidentiality impact value. Before you map your program, confirm which SP 800-53B baseline your CUI environment inherits, since a system that also holds higher-impact data may need more than the moderate set.
Appendix C of SP 800-171 Rev. 3 is the document to work from. It assigns each moderate-baseline control one of five labels: FED (a federal responsibility), NCO (not directly related to CUI confidentiality), ORC (adequately covered by other requirements), N/A (not applicable), or CUI (retained as a requirement). Every excluded control has a stated reason, and every retained control points to the resulting requirement. The example is clear: requirement 03.13.01 Boundary Protection derives from SC-7 in the moderate baseline. An assessor who reads a contractor's boundary evidence against 03.13.01 is therefore testing the SC-7 intent, scoped to CUI systems. The practical check is to read the Appendix C entry for each requirement you claim, not only the requirement text, because a label such as ORC means someone else's control may carry the evidence.
Which SP 800-53 families SP 800-171 leaves out
SP 800-171 Rev. 3 keeps 17 of the 20 SP 800-53 families, so the requirements it contains are a subset of the moderate baseline. The cards below cover the areas it drops or narrows, what each gap means for a nonfederal system, and what your contract or risk program may still require you to handle.
PII processing and transparency (PT)
SP 800-171 Rev. 3 excludes the PT family because PII is treated as a category of CUI, so PII protection is covered through the CUI requirements rather than as a separate family. That does not remove privacy duties. Notices, purpose limits and PII handling rules may still arrive through your contract, a privacy law or your own program. Check Appendix C for how each excluded PT control is recorded.
Contingency planning (CP)
The CP family is not carried into SP 800-171 Rev. 3 as a requirement family. Backup, recovery and alternate processing for a nonfederal system often remain contract or availability obligations even when the CUI requirements do not name them. Confirm with the contracting agency whether continuity commitments sit in the contract, and check Appendix C to see which CP controls were excluded and why.
Program management (PM)
SP 800-171 Rev. 3 does not include the PM family, which holds organization-wide security and risk program controls. A nonfederal organization still needs a documented security program to run the 97 requirements, including roles, risk decisions and supply chain oversight. Confirm which PM-type obligations your contract or internal governance requires, and check Appendix C for the excluded PM controls.
Federal-only and overlapping controls
Appendix C labels many excluded controls as FED (primarily a federal responsibility), ORC (adequately addressed by other controls) or N/A. A FED label does not mean the topic disappears for your organization, since the agency may still expect evidence from you. An ORC label means the subject is covered elsewhere in the requirements. Read the label for each control before assuming you can skip it.
Reduced scope within kept families
Keeping a family does not mean keeping every control in it. SP 800-171 Rev. 3 starts from the 287 controls and enhancements in the SP 800-53B moderate profile and retains 97 requirements. Some controls in kept families are removed or merged, so an assessor may test a narrower set than your SP 800-53 program would. Map each retained requirement to its SP 800-53 source before deciding what extra controls to add.
Gaps that need your own risk decision
Where a removed control matters to your risk, the decision belongs to you, not to the omission itself. A nonfederal system holding CUI that also handles data outside the contract may need controls the requirements never name. Document the gap, the risk owner's decision and any compensating measure. Confirm with the contracting officer which exclusions the agency accepts before relying on them.
Requirement and family counts side by side
This table sets the SP 800-53 moderate baseline, the full Rev. 5 catalog and SP 800-171 Rev. 3 next to each other using the counts NIST publishes for each. The numbers describe different units, so read each row on its own terms: a count does not show how much of one document is covered by the other, or how much work it takes to meet.
| Measure | SP 800-53 Rev. 5 | SP 800-171 Rev. 3 |
|---|---|---|
| Document role | Catalog of controls for federal information systems, with baselines in SP 800-53B | Recommended requirements for protecting CUI in nonfederal systems |
| Top-level families | 20 control families | 17 families |
| Count of items | 324 base controls (300 not withdrawn) and 872 enhancements (714 not withdrawn) in Release 5.2.0 | 97 active security requirements (130 entries including 33 withdrawn) |
| Moderate baseline size | 287 controls and enhancements in the Release 5.2.0 OSCAL moderate profile | Derived from the SP 800-53B moderate baseline, then tailored down to 97 requirements |
| Organization-defined parameters | Set per organization or system within controls, with values chosen by the organization | 88 organization-defined parameters |
| What the count includes | Base controls, enhancements and withdrawn entries, depending on how the count is taken | Requirements, with withdrawn entries listed separately in the catalog |
| What to confirm before comparing | Whether the count includes withdrawn items and enhancements | Whether the count includes withdrawn entries and how requirements map to source controls in Appendix C |
Why CMMC still references SP 800-171 Rev. 2
A defense contractor preparing for a CMMC assessment must work from SP 800-171 Rev. 2, because the CMMC Program rule at 32 CFR 170.14(a)(2) names Revision 2 as the source of CMMC security requirements. That holds even though NIST published Rev. 3 in May 2024 and Rev. 3 now supersedes Rev. 2 for NIST's own purposes. Rev. 3 is the newer, more tightly derived requirement set, but a newer NIST publication does not change the text of the regulation that the assessment is built on.
Before you plan remediation, confirm the current CMMC rule text and any transition language with your contracting officer or the DoD CMMC program office. Ask specifically whether a Rev. 3 mapping is accepted for any assessment, how the Rev. 2 requirement numbers will be used in assessment scoping, and whether the Rev. 2 requirement set is expected to change. Get the answer in writing and keep it in your assessment file.
Do not assume that meeting a Rev. 3 requirement satisfies the matching CMMC requirement until the government confirms that in writing. Some Rev. 3 requirements are reorganized or reworded relative to Rev. 2, so a gap analysis should be run against Rev. 2 for CMMC purposes, with Rev. 3 used as a reference for where the controls are heading. A self-assessment or SPRS score based on the wrong revision can create contract and False Claims Act exposure, so treat the revision question as a scoping decision owned by the organization.
How to decide which framework your program needs
This sequence turns a vague request for NIST compliance into a written decision on whether SP 800-53, SP 800-171 or both apply, which revision governs, and where the system boundary sits. Each step produces a document you can hand to an assessor, a contracting officer or a prime contractor.
Identify the contract or regulator clause
Start with the document that creates the obligation: the contract clause, task order, regulator letter, program rule or customer security addendum. Quote the exact clause and note which framework or revision it names, if any. Some clauses cite NIST by family or by 'NIST SP 800 series' without a revision, and those need clarification from the contracting officer or customer before you go further. The output is a short requirement log that records the source document, the clause number and the wording. You know this step is done when every framework reference in the obligation is traced to a specific clause.
Classify the system and the data
Decide whether the obligation covers a federal information system, controlled unclassified information (CUI) held in a nonfederal system, or both. A federal information system is one an agency or a contractor operates on an agency's behalf, which points to SP 800-53. CUI in a contractor's own environment points to SP 800-171, which derives its requirements from the SP 800-53 moderate baseline. Systems that handle both need the boundary decision in the next steps. The output is a classification note for each system, stating who operates it, what data it holds and whether that data is CUI. You know this step is done when each system has exactly one of these classifications, or is marked as dual scope for later review.
Confirm the revision the contract names
Find the revision the contract, program or CMMC scope names. SP 800-53 is currently at Release 5.2.0, and SP 800-171 Rev. 3 supersedes Rev. 2. The CMMC Program rule at 32 CFR 170.14 incorporates SP 800-171 Revision 2, not Revision 3, so a CMMC-scoped contractor must not assume Rev. 3 applies. If the clause is silent on revision, ask the contracting officer in writing and record the answer. The output is a revision decision line for each framework that names the revision, the date of the decision and the person who confirmed it. You know this step is done when no framework is left with an unstated version.
Check for an applicable overlay
Review NIST's Security Control Overlay Repository to see whether an overlay already packages the tailoring for your situation. The repository lists SP 800-171 Rev. 3 as an overlay based on SP 800-53 Rev. 5, which means the 800-171 requirements can be read as a tailored subset of the 800-53 controls. Check the list of current overlays for anything that matches your system type or data, and confirm whether the overlay's revision matches the one you recorded in the previous step. Where no overlay fits, your tailoring will need to be documented from the baseline itself. The output is an overlay note that names each overlay considered, whether it applies and why. You know this step is done when every candidate overlay has a recorded yes or no.
Define the scope statement
Write a scope statement that names the frameworks in force, the systems and data each one covers, and the organizations that operate them. For a mixed environment, state which components fall under SP 800-53 (federal systems), which fall under SP 800-171 (nonfederal CUI systems) and which are excluded. The statement should also note any shared services that serve both groups, because they need to be addressed explicitly. Have the system owner and the compliance lead sign off, and have the customer or contracting officer review it if the contract requires. The output is a signed scope statement. You know this step is done when a reviewer who did not write it can tell, for any given asset, which framework applies.
Draw the system boundary
Using the scope statement, draw the system boundary for each system in scope. Show the assets, data flows, interconnections, external services and user populations that sit inside it. Identify where CUI or federal data enters and leaves, because boundary protection and information flow decisions depend on those points. For systems that touch both scopes, record the handoff points and the controls that mark each side. The output is a boundary diagram and an inventory list that match the scope statement. You know this step is done when every interconnection on the diagram appears on the inventory and each one has an owner.
Record the written revision decision
Bring the earlier steps together into one written revision decision. It should state which framework applies to each system, which revision governs each framework, which overlay or tailoring basis is used, and what evidence will be produced. Where SP 800-171 applies, note that its requirements derive from the SP 800-53 moderate baseline and that its own tailoring appendix records why certain 800-53 families are absent. Where SP 800-53 applies, cite the baseline you selected under SP 800-53B. Get the decision approved by the authorizing or accountable official. The output is the signed decision record that feeds the system security plan or the SSP equivalent. You know this step is done when the record can be given to an assessor without further explanation.
Common questions about NIST 800-53 and NIST 800-171
Can SP 800-171 Rev. 3 satisfy an SP 800-53 requirement?
Not on its own, and only the contracting authority or the authorizing official can decide whether a specific SP 800-53 requirement is met. SP 800-171 Rev. 3 is a set of recommended requirements for protecting CUI in nonfederal systems, and it was derived from the SP 800-53B moderate baseline by removing controls that are primarily a federal responsibility, not directly tied to CUI confidentiality, adequately covered elsewhere, or not applicable. Its Appendix C maps each moderate-baseline control to the resulting requirement or to the reason it was excluded, which is the starting point for checking a gap. Federal systems that must meet SP 800-53 need the full set of controls their baseline and tailoring decisions select, so the mapping shows where to look, not what passes.
Does a CMMC assessment use SP 800-171 Rev. 3?
No. The CMMC Program rule at 32 CFR 170.14(a)(2) incorporates NIST SP 800-171 Revision 2 as the source of CMMC security requirements, even though Rev. 3 was published in May 2024. Contractors preparing for CMMC should confirm the revision in the current rule and in any contract clause with their sponsor, because a program office may still ask for specific details that differ between revisions. The requirement set, assessment procedures and evidence expectations should be taken from the revision the rule names, and any move to Rev. 3 would depend on future rulemaking or contract terms that the reader must verify with the Department of Defense or the contracting officer.
Is SP 800-171 a subset of SP 800-53?
It is derived from SP 800-53 but it is not a simple subset. SP 800-171 Rev. 3 starts from the SP 800-53B moderate baseline, which holds 287 controls and enhancements in NIST's Release 5.2.0 OSCAL profile, and it reduces that to 97 requirements in 17 families. It also reorganizes and rewrites the material, and it adds requirements of its own that do not appear in SP 800-53. Some SP 800-53 families are left out, including Contingency Planning (CP), Program Management (PM) and PII Processing and Transparency (PT), which NIST excludes because PII is treated as a category of CUI. Anyone mapping the two should work from the source column in Appendix C and the OSCAL content rather than from family names.
Which document needs an authorization to operate?
SP 800-53 is the document that underpins authorization to operate (ATO) for federal information systems. An ATO is granted by a federal authorizing official after reviewing a security assessment against the controls selected for the system's impact level. SP 800-171 does not produce an ATO for a contractor's nonfederal system. Instead, the contracting agency sets the requirements, and the contractor's own assessment, or a third-party assessment where the contract requires one, shows status. Where a contract references SP 800-171 but the system is operated for a federal agency, the agency's security office should confirm which authorization path applies, since that decision belongs to the agency.
What drives the effort of moving from 800-171 to 800-53?
The main driver is the gap between the two requirement sets for the specific system. Moving from SP 800-171 to SP 800-53 means adding the controls the 800-171 derivation removed, such as Contingency Planning, Program Management and PII processing controls where they apply, and then selecting a baseline from SP 800-53B based on the system's FIPS 199 impact level. Other drivers include the number of systems in scope, how much existing evidence already maps to SP 800-53 control IDs, whether controls are inherited from a cloud provider or shared service, and how much the agency's tailoring and parameter choices change the baseline. Ask any implementation partner to show the gap list and the evidence each control needs before you accept a quote.
Where should a team start when it must meet both publications?
Start with the contract or agency document that names the requirement, since it decides which publication and which revision apply. If both are named, map the SP 800-171 requirements to their SP 800-53 sources using Appendix C, then list the SP 800-53 controls the baseline adds beyond that mapping. Keep one control inventory with a column for each source so evidence is collected once. The contracting authority, an accredited or authorized assessor, or the authorizing official makes the final determination on whether the combined set is satisfied, so confirm that scope with them before the assessment begins.
Can an outside partner handle the whole mapping?
An implementation partner can prepare the mapping, build the control inventory, configure self-hosted systems to produce evidence and document the results, but it cannot decide the outcome. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, and it prepares systems and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and the organization keeps ownership of its controls. Most engagements are fixed-scope, so ask for the written scope, the deliverables and the list of controls that remain with your team before work starts.
Who owns the controls, who prepares the evidence, and who assesses
The organization owns its controls. Whether the system falls under SP 800-171 Rev. 3 for a contractor handling controlled unclassified information or under the SP 800-53 moderate baseline for a federal system, the organization that operates the system is accountable for implementing each requirement, making the risk decisions behind it and keeping it working after go-live. An implementation partner can configure a system, but it cannot accept the residual risk for the organization. Before any work starts, name the internal owner for each requirement family, confirm who signs the system security plan, and decide who can accept a deviation. Those decisions stay in-house even if the build is outsourced.
DeployOpen plays the preparation role. Within the client's own cloud accounts, data centers or air-gapped networks, it can plan, configure, harden and document self-hosted open-source platforms so that the evidence for each requirement exists and can be retrieved. That work covers configuration baselines, logging, access settings and the artifacts an assessor will ask for. DeployOpen does not issue audit reports, attestations, certificates or authorizations, and it does not assess its own work. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins, so the reader can check what was promised against what was delivered.
Only an independent party issues findings or decisions. For SP 800-171, that is typically a third-party assessor under the CMMC program or the contracting agency's review process, depending on the contract. For SP 800-53, the assessment is performed by an independent assessor and the authorization decision belongs to the authorizing official. Before engaging anyone, confirm with the contracting officer or sponsor which assessment regime applies, whether the assessor must be independent of the implementation partner, and which SP 800-171 or SP 800-53 version the assessor will use. Ask the partner to document, in its statement of work, exactly which artifacts it hands over and which activities it will not perform.
How DeployOpen scopes NIST 800-53 and 800-171 readiness
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the systems and evidence behind NIST 800-53 or NIST 800-171 requirements are prepared before any assessor looks at them. We do not decide which framework applies to you, and we do not issue assessment reports or authorizations; those remain with your authorizing official, your assessor and your contracting customer.
How we scope
- Confirm with your contracting officer or customer which framework and which requirement set applies to your systems.
- Agree in writing which systems, boundaries and CUI or federal data flows fall inside the engagement.
- Record which controls you own, which a platform will satisfy and which a third party provides as inherited common controls.
How we build
- Configure self-hosted open-source platforms in your cloud accounts or data centers to meet the agreed requirement set.
- Harden logging, access, encryption and configuration settings, and document each setting against its requirement.
- Test the built environment against the assessment procedures you have chosen, and record gaps for your remediation plan.
How we hand over
- Deliver system documentation, configuration records and evidence packages mapped to each requirement in scope.
- Provide a plan of action listing open gaps, owners and the work needed to close them, for your own decisions.
- Train your staff to run the evidence collection, so that assessments do not depend on our continued involvement.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing upgrades, evidence refreshes and continuous security testing are available as a retainer.
- Ask any partner, including us, for a written quote tied to a defined scope before committing budget.
