NIST Special Publication 800-171
110 security requirements, 14 families, 320 assessment objectives — and one question that trips up almost everyone: which revision you are actually required to implement. It is not the newest one, and it is not the one NIST currently lists as current.
Revision 2 is withdrawn by NIST — and still the version you owe
Both halves of that sentence are true, and the combination causes more confusion than anything else in this standard. NIST withdrew Revision 2 on May 14, 2024, superseding it with Revision 3. Visit the Rev. 2 page on NIST’s site today and it is stamped “Withdrawn,” pointing you at Rev. 3.
DoD still enforces Revision 2. The CMMC program rule at 32 CFR Part 170 is written against Rev. 2, and DoD issued acquisition guidance keeping DFARS 252.204-7012 pointed at Rev. 2 pending future rulemaking. NIST withdrawing a publication does not amend a federal acquisition regulation — only DoD can do that, and it has not.
So Rev. 2 is what you implement, what you score yourself against, what you affirm in SPRS, and what an assessor will open your SSP against. Rev. 3 is worth reading and is not yet your obligation. Full detail in the revision comparison below.
What NIST SP 800-171 is — and what it is not
NIST Special Publication 800-171, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, is a technical standard published by the National Institute of Standards and Technology. It defines 110 security requirements for protecting the confidentiality of Controlled Unclassified Information when that information sits on systems a federal agency does not own or operate.
It is worth being precise about what it is not, because the terms get used interchangeably and the difference matters when you are reading a contract.
| What it is | Who issues it | |
|---|---|---|
| NIST SP 800-171 | The technical standard — the actual list of security requirements you implement | NIST, a non-regulatory agency within the Department of Commerce |
| DFARS 252.204-7012 | The contract clause that makes the standard legally binding on you | DoD, through the Defense Acquisition Regulations System |
| CMMC (32 CFR Part 170) | The program that verifies you implemented the standard | DoD |
NIST writes the standard but enforces nothing. DFARS makes it a contract term. CMMC checks the work. If you comply with 800-171 in full and never post a score, you have a DFARS problem, not a NIST one — the standard has no compliance mechanism of its own. Our DFARS compliance guide covers the contractual side.
This separation is also the key to the revision question below. NIST manages its publications; DoD manages your obligations. The two do not move in step.
Who it applies to
NIST SP 800-171 applies when three conditions hold together:
- CUI resides in a nonfederal system or organization. Your systems, not the government’s.
- You are not collecting or maintaining that information on behalf of a federal agency, and not operating a system on an agency’s behalf. Where you are acting on the agency’s behalf, the far heavier NIST SP 800-53 baseline applies instead.
- No more specific safeguarding requirement exists for that category of CUI in the authorizing law, regulation, or government-wide policy. Some CUI categories carry their own rules, which take precedence.
For DoD contractors, in practice: if your contract contains DFARS 252.204-7012 and you handle CUI, all three conditions hold and you owe the full 110. If you handle only Federal Contract Information — information not intended for public release, but nothing marked or markable as CUI — your obligation is the 15 basic safeguarding requirements in FAR 52.204-21 rather than 800-171.
The most common scoping error is assuming you are in the FCI-only camp. Defense technical data, drawings, specifications, and export-controlled information are all CUI, and they tend to turn up in email attachments and shared drives that nobody included in scope.
Revision 2 vs. Revision 3
This is the single most consequential question on this page, and the answer runs against instinct twice over: implement Revision 2 — the older revision, and the one NIST has withdrawn.
| Revision 2 | Revision 3 | |
|---|---|---|
| Structure | 110 requirements, 14 families | 97 requirements, 17 families |
| Status at NIST | Withdrawn May 14, 2024 | Current |
| Enforced by DoD? | Yes — written into 32 CFR Part 170 and used for DFARS 7012 | No — not incorporated into the CMMC rule |
| Basis for CMMC Level 2 | Yes, all 110 requirements | No |
| Assessment guide | NIST SP 800-171A, 320 objectives | NIST SP 800-171A Rev. 3 |
| What to do about it | Implement, assess, score, and affirm against this | Read it. Do not restructure your program around it yet |
Rev. 3 introduced organization-defined parameters, folded some requirements together, and reorganized families. It is a better document in several respects. None of that matters until DoD amends its rules, because your score, your affirmation, and any assessment you undergo are all measured against Rev. 2.
The version of a NIST publication you are required to implement is whichever one DoD wrote into the rule — not whichever one NIST lists as current.
Why the NIST page says “Withdrawn”
NIST maintains its publication catalog on its own schedule. When Rev. 3 was finalized, Rev. 2 was withdrawn as a NIST publication — standard practice, and unrelated to anyone’s contractual obligations.
A regulation that incorporates a specific revision by reference keeps pointing at that revision until the regulation itself is amended. 32 CFR Part 170 names Revision 2. Until DoD conducts rulemaking to change it, Rev. 2 governs your contract regardless of its status in NIST’s catalog. This is ordinary in federal acquisition, and it is why “the newest NIST publication” and “the required NIST publication” are different questions.
The authoritative Rev. 2 documents remain available on NIST’s site, and NIST’s own planning note specifies that the PDF is the normative source — where the spreadsheet or CSV versions disagree with it, the PDF governs.
What to do about Revision 3 in the meantime
Where a Rev. 3 practice is simply better security and costs nothing extra, adopt it. Where it would mean re-architecting, re-documenting, or re-scoping, wait. Your SSP should map to Rev. 2 requirement numbers, because that is what an assessor will open it against — an SSP organized around Rev. 3 numbering creates work for everyone during an assessment and signals that you built to the wrong baseline.
The 110 requirements across 14 families
Revision 2 distributes 110 security requirements across 14 families. The distribution matters for planning: Access Control alone accounts for one in five requirements, and together with System and Communications Protection and Identification and Authentication makes up nearly half the standard.
| Family | Requirements | What it covers |
|---|---|---|
| Access Control | 22 | Who can reach CUI, from where, with what privileges, and how remote and wireless access is controlled |
| Awareness and Training | 3 | Security awareness, role-specific training, insider threat recognition |
| Audit and Accountability | 9 | Logging, log protection, correlation, and actual review of what the logs say |
| Configuration Management | 9 | Baselines, change control, least functionality, software allowlisting, user-installed software |
| Identification and Authentication | 11 | Identity management, multifactor authentication, replay resistance, credential handling |
| Incident Response | 3 | Response capability, tracking and reporting, testing the plan |
| Maintenance | 6 | Maintenance controls, tool inspection, remote maintenance, sanitization before off-site service |
| Media Protection | 9 | CUI marking, storage, transport, sanitization, encryption on portable media, removable media limits |
| Personnel Security | 2 | Screening before granting access, protecting CUI during transfers and terminations |
| Physical Protection | 6 | Facility and equipment access, visitor escort and logs, alternate work sites |
| Risk Assessment | 3 | Periodic risk assessment, vulnerability scanning, remediating what the scans find |
| Security Assessment | 4 | Control assessment, the SSP itself, the POA&M, continuous monitoring |
| System and Communications Protection | 16 | Boundary protection, encryption in transit, session termination, subnetworks for publicly accessible components |
| System and Information Integrity | 7 | Flaw remediation, malicious code protection, security alerts, system monitoring |
How compliance is assessed
You implement 110 requirements. You are assessed against 320 assessment objectives in NIST SP 800-171A. Most requirements decompose into two, three, or more objectives, each of which has to be satisfied.
The consequence catches people out: partial implementation scores as zero. A requirement where you have satisfied three of four objectives is not 75 percent credit — it is a gap. This is why contractors who self-assess against the 110 requirement statements consistently overestimate their position compared with contractors who assess against the 320 objectives.
Three tiers of assessment
-
Basic
You assess yourself
- Your own review against all 110 requirements
- Score posted in SPRS by your team
- Lowest confidence level from DoD’s perspective
-
Medium
The government reviews
- DoD examines your SSP and supporting documents
- Tests whether your described implementation is plausible
- Can revise the score you posted
-
High
DIBCAC verifies
- Evidence examined, personnel interviewed, controls tested
- Verifies controls operate, not just that they are written down
- Where documentation-only compliance falls apart
Medium and High assessments are conducted by DoD’s Defense Industrial Base Cybersecurity Assessment Center. For how scores are calculated and posted, see our DFARS compliance guide.
Your SSP and POA&M
Two documents are required, and both sit inside the Security Assessment family rather than being administrative extras.
The System Security Plan describes your in-scope environment and how each of the 110 requirements is met within it. Requirement 3.12.4 makes it mandatory. The failure mode here is not an absent SSP — it is a well-written SSP describing a system that does not exist. Assessors compare the document to the environment, and a mismatch is worse than an honest gap.
The Plan of Action & Milestones documents what is not yet implemented, what you will do about it, and by when. Requirement 3.12.2 makes it mandatory. A realistic POA&M with dates you can hit is a sign of a program under control. A POA&M with everything due next quarter is a sign of the opposite.
NIST publishes a CUI SSP template and a POA&M template. Both are starting structures rather than finished documents, and NIST notes there is no prescribed SSP format so long as the information required by 3.12.4 is conveyed.
One thing worth knowing before you rely on a POA&M: under CMMC, open items must close within 180 days to convert a Conditional status to Final, and the most heavily weighted requirements are not POA&M-eligible at all.
The requirements that cause the most trouble
Across the contractors we have assessed, the same handful of requirements account for a disproportionate share of gaps — and they are weighted heavily, so missing them hurts twice.
| Area | Why it goes wrong |
|---|---|
| Multifactor authentication | Usually deployed for remote access but not for local and privileged accounts, which is what the requirement actually reaches. One of only two requirements in the methodology that allow partial credit. |
| FIPS-validated cryptography | Encryption is not enough — the module must be FIPS-validated, with a certificate number. Plenty of products encrypt without meeting this, and the distinction is invisible until someone asks for the certificate. |
| Audit log review | Logging gets configured; review does not happen. The requirement is that logs are analyzed and acted on, and evidence of review is what assessors ask for. |
| CUI marking and handling | Requires knowing what is CUI, marking it, and controlling how it moves. Most organizations discover their marking is inconsistent the moment they look. |
| External service providers | Any provider storing, processing, or transmitting your CUI — or protecting your in-scope environment — comes into scope. You need a shared responsibility matrix showing which controls are theirs and which remain yours. |
| Cloud services | Under DFARS 252.204-7012, cloud services handling CUI must meet FedRAMP Moderate equivalency. Commercial Microsoft 365 does not; GCC High does. This is a migration, not a setting. |
Where CUI is confined to part of the business, a segmented enclave — frequently on Microsoft 365 GCC High — addresses several of these at once by shrinking what has to comply in the first place.
800-171 vs. 800-53 vs. 800-172 vs. FISMA
These get conflated constantly, including in guidance that should know better. They are four distinct things.
| What it is | Who it applies to | |
|---|---|---|
| NIST SP 800-171 | 110 requirements for protecting CUI in nonfederal systems | Contractors and other nonfederal organizations handling CUI |
| NIST SP 800-53 | The comprehensive security and privacy control catalog, far broader than CUI | Federal agencies and their systems, and contractors operating systems on an agency’s behalf |
| NIST SP 800-172 | Enhanced requirements for defending against advanced persistent threats, layered on 800-171 | Contractors on DoD’s highest-priority programs — the basis for CMMC Level 3 |
| FISMA | A federal statute requiring agencies to run information security programs. Not a NIST publication | Federal agencies. 800-53 is the catalog used to implement it |
As a DoD contractor, your standard is 800-171. Familiarity with 800-53 is useful for understanding how your agency customers operate and why their expectations sometimes exceed your contractual obligation, but it is not your baseline. Contractors are sometimes told they need 800-53 when they need 800-171, and the difference in effort is very large.
How to implement it
Six steps to an implemented baseline
-
1
Find the CUI
Identify what CUI you hold and where it actually lives, including email, file shares, endpoints, and third-party platforms. Everything downstream depends on getting this right.
-
2
Draw the boundary
Decide what is in scope. An enclave that contains CUI is dramatically cheaper to bring into compliance than an entire network, and the decision is hard to reverse later.
-
3
Assess against 320
Evaluate the in-scope environment objective by objective using NIST SP 800-171A, not requirement by requirement. This produces your real score rather than your assumed one.
-
4
Document
Write the SSP to describe the environment as it is, and the POA&M to cover what is open, with dates you can actually meet.
-
5
Remediate
Close gaps in weighted order — the 5-point requirements first. MFA, FIPS-validated encryption, and logging typically dominate the effort.
-
6
Operate
Review logs, manage vulnerabilities, keep evidence current, and reassess as the environment changes. Implementation ends; operation does not.
Steps 1 and 2 determine the cost of steps 3 through 6. Contractors who rush scoping to get to remediation faster reliably spend more.
In-house or with a consultant
Doing it in-house
A capable internal security team can implement 800-171 without outside help, and NIST publishes everything you need to work from directly:
- SP 800-171 Rev. 2 (PDF) — the authoritative source for all 110 requirements.
- Security requirements spreadsheet (XLSX) — the requirements in a format you can actually track status in. There is also a CSV version for importing into a GRC tool.
- SP 800-171A — the assessment procedures and the 320 objectives. This is the document you should actually assess against, not the 110 requirement statements.
- CUI SSP template (DOCX) and CUI Plan of Action template (DOCX) — starting structures for the two required documents.
- CSF to 800-171 Rev. 2 mapping (XLSX) — useful if you already run a Cybersecurity Framework program and want to see what carries over.
The constraint is rarely access to documents. Assessing 320 objectives, remediating what surfaces, and maintaining evidence is a sustained workload alongside running IT for a business with other priorities. Teams that succeed usually have someone whose job this substantially is.
Working with a consultant
Outsourcing gives you people who assess these environments continuously, documentation and tooling that already exist, and monitoring capacity you would otherwise build from nothing. Our own engagements follow a three-step process: gap analysis against the objectives, remediation of what it finds, and ongoing monitoring to keep the result true.
Two things to hold onto. You remain responsible — the affirmation is signed by your senior official, not your provider’s. And a provider handling your CUI enters your assessment scope, so a shared responsibility matrix is not optional. Where CMMC certification is the destination, look for a Cyber AB Registered Provider Organization.
Frequently asked questions
How many controls are in NIST 800-171?
Revision 2 contains 110 security requirements across 14 families. Assessment is performed against the 320 assessment objectives those requirements decompose into, published in NIST SP 800-171A.
Is NIST 800-171 Rev. 2 withdrawn?
Yes, as a NIST publication — NIST withdrew it on May 14, 2024 and superseded it with Rev. 3. It remains the version DoD enforces. The CMMC rule at 32 CFR Part 170 names Rev. 2, and a regulation keeps pointing at the revision it names until the regulation is amended. Withdrawal from NIST’s catalog and removal from your contract are different events, and only the first has happened.
Should I implement Revision 2 or Revision 3?
Revision 2, despite Rev. 3 being newer and Rev. 2 being withdrawn. CMMC is written against Rev. 2, and DoD acquisition guidance keeps DFARS 252.204-7012 pointed at Rev. 2 pending future rulemaking. Restructuring your program around Rev. 3 now means being scored against a baseline you did not assess yourself on, and an SSP that uses the wrong requirement numbering.
Is NIST 800-171 the same as DFARS?
No. NIST SP 800-171 is a technical standard published by NIST, which enforces nothing. DFARS 252.204-7012 is a DoD contract clause that makes the standard legally binding on you. The standard tells you what to implement; the clause is why you have to.
Is NIST 800-53 the same as NIST 800-171?
No. 800-53 is the comprehensive control catalog for federal information systems, used by agencies and by contractors operating systems on an agency’s behalf. 800-171 is a narrower set of 110 requirements for protecting CUI on nonfederal systems. As a DoD contractor, 800-171 is your standard. And FISMA is a statute, not another name for 800-53.
Do I need NIST 800-171 if I only handle FCI?
No. Federal Contract Information triggers the 15 basic safeguarding requirements in FAR 52.204-21, which corresponds to CMMC Level 1. NIST SP 800-171 applies once you store, process, or transmit CUI. Most contractors who believe they hold only FCI find CUI somewhere once they look properly.
Is NIST 800-171 still required with CMMC Phase 2 suspended?
Yes. The suspension paused third-party certification assessments. DFARS 252.204-7012 is untouched, all 110 requirements remain enforced, and SPRS scores and annual affirmations are still required.
How long does NIST 800-171 implementation take?
Several months for a contractor with a modern, well-managed environment and CUI confined to a defined boundary. Twelve to eighteen months where CUI is spread across shared drives and legacy on-premises systems with no logging in place. Scope and starting posture drive the timeline far more than headcount does.
What is the difference between a requirement and an assessment objective?
A requirement is one of the 110 statements in 800-171. An objective is one of the 320 specific determinations in 800-171A used to decide whether a requirement is met. Because every objective for a requirement must be satisfied, partial implementation scores as zero rather than partial credit.
Does NIST 800-171 require FIPS-validated encryption?
Yes, where cryptography is used to protect CUI confidentiality. The distinction that matters is between encryption and FIPS-validated encryption — the module needs a validation certificate. Many products encrypt without meeting this, and it is not visible until someone asks for the certificate number.
Are an SSP and POA&M actually required?
Yes. Both are requirements within the Security Assessment family, not optional documentation. They are also the first artifacts any assessor asks for, and the most common failure is an SSP that describes a system more capable than the one that exists.
Sources and references
- NIST SP 800-171 Revision 2 (PDF) — the 110 security requirements DoD enforces, and the authoritative source per NIST’s own planning note.
- NIST SP 800-171 Rev. 2 publication page — hosts the requirements spreadsheet, SSP and POA&M templates, and CSF mapping. Shows as withdrawn; see above for why that does not change your obligation.
- NIST SP 800-171A — assessment procedures and the 320 objectives.
- NIST SP 800-172 — enhanced requirements underpinning CMMC Level 3.
- FAR 52.204-21 — the 15 basic safeguarding requirements for FCI.
- 32 CFR Part 170 — the CMMC Program rule, written against Revision 2.
- DoD CUI Program — what counts as CUI and how it is marked.
- DCMA DIBCAC — conducts Medium and High assessments.
- DoD class deviations — current FAR and DFARS deviation memos.
Assessed against 110, or against 320?
SysArc is a Cyber AB Registered Provider Organization and has guided more than 1,000 DoD contractors through NIST SP 800-171, DFARS, and CMMC. We assess objective by objective, which is the only way to produce a score that survives someone else checking it.