NIST 800-171 compliance means you have implemented the security requirements in NIST Special Publication 800-171 on every system that processes, stores, or transmits Controlled Unclassified Information (CUI), and that you can prove it. For most U.S. companies the trigger is a federal contract, most often with the Department of Defense (DoD), that carries a clause such as DFARS 252.204-7012. This guide explains what the standard asks for, which revision your contract actually points to, how the control families are organized, and a step-by-step path to a defensible assessment score.
TL;DR
- NIST SP 800-171 protects the confidentiality of CUI in nonfederal systems and organizations. It applies to every system component that touches CUI, not just to the whole company by default.
- Rev. 3 was published in May 2024 and has 17 requirement families, but DoD contractors have been told to keep using Rev. 2 (110 requirements, 14 families) until DoD rescinds its class deviation. Check your contract clause before you map anything.
- For DoD work, compliance is verified through CMMC and your assessment score in SPRS. A self-assessment carries a Low confidence level, and a stale score can block an award.
- The practical path is: scope your CUI, write a System Security Plan (SSP), find gaps, fix them with a plan of action, assess against 800-171A, and keep the evidence current.
Table of Contents
- What NIST 800-171 is and who has to follow it
- Rev. 2 or Rev. 3: which one applies to you
- The requirements and controls, family by family
- How compliance is proven: SPRS, DFARS, and CMMC
- A step-by-step path to NIST 800-171 compliance
- Making the SSP a living document
- Common mistakes we see
- Where we see questionnaires and 800-171 collide
- Our perspective: compliance is an engineering problem now
- Related reading for your program
- FAQ
- Sources
What NIST 800-171 is and who has to follow it
NIST SP 800-171 is a publication that gives federal agencies recommended security requirements for protecting the confidentiality of CUI when it lives outside federal systems. The current version, Revision 3, was published in May 2024 and supersedes Rev. 2, which dated from January 2021.
CUI is information the government creates or possesses, or that a contractor handles for it, that requires safeguarding but is not classified. Think of export-controlled technical drawings, controlled engineering data, or certain contract-related financial and personnel records. If your company receives it from an agency or a prime contractor, or generates it for them, the requirements flow to you.
In practice, the standard reaches:
- Prime contractors and subcontractors on DoD contracts that include DFARS 252.204-7012, and the downstream suppliers who receive CUI from them.
- Research universities and labs that handle CUI under federal grants or agreements.
- Software and SaaS providers whose products store or process CUI on behalf of a contractor. If a defense customer sends you a security questionnaire asking about 800-171, this is usually why.
NIST's own government contractor resources page points smaller companies to a Small Business Primer for 800-171 and encourages a "Brilliant at the Basics" mindset. That is good advice: most gaps we see described in the field are basic hygiene (access control, logging, configuration baselines), not exotic technology.
Rev. 2 or Rev. 3: which one applies to you
This is the question that trips up the most teams, and the answer depends on your contract, not on which document is newest.
The two revisions differ materially:
| Rev. 2 | Rev. 3 | |
|---|---|---|
| Published | January 2021 | May 2024 |
| Security requirements | 110 | 97 |
| Families | 14 | 17 |
| Assessment procedures | NIST SP 800-171A | NIST SP 800-171A Rev. 3 |
In May 2024, DoD issued a class deviation to DFARS 252.204-7012. As Holland & Knight describes, the deviation says contractors subject to that clause are to comply with a specific version of 800-171, not simply the one in effect when the solicitation is issued. Analysts at Planet Technologies summarize the practical effect: vendors continue to use Revision 2, with its 320 assessment objectives across 110 requirements, until DoD rescinds the deviation.
The CMMC program is also anchored in Rev. 2 for Level 2. The DoD acquisition rule that puts CMMC into contracts took effect on November 10, 2025, and that source notes Level 2 currently maps to Rev. 2.
So here is a rule of thumb we would give a colleague:
- Read the clause in your contract or solicitation. It names the standard and the assessment path.
- If you work under DoD clauses, build and assess against Rev. 2 today. It is what your assessor will use.
- Map to Rev. 3 in parallel. NIST warns that it supersedes Rev. 2, and civilian agencies, universities, and commercial customers may already reference it. Teams that document their controls in a way that survives a revision change will not redo the work later.
- Write the revision into your SSP. Auditors and customers should never have to guess which version you mean.
This matters for questionnaires too. When a customer asks "Are you compliant with NIST 800-171?", the honest answer names the revision, the scope, and the date of your last assessment.
The requirements and controls, family by family
NIST organizes the requirements into families. Rev. 3 has 17 families; Rev. 2 has 14. The Rev. 2 families are the ones most contractors are assessed against today:
| Family | What it asks of you, in plain terms |
|---|---|
| Access Control | Limit system access to authorized users and devices, and limit what they can do. Enforce least privilege and control remote access. |
| Awareness and Training | Make sure staff know the risks and are trained for their role. |
| Audit and Accountability | Create and retain logs so actions can be traced to individual users. |
| Configuration Management | Maintain baseline configurations and control changes. |
| Identification and Authentication | Identify users and devices, and use multifactor authentication where required. |
| Incident Response | Have a tested plan to detect, report, and recover from incidents. |
| Maintenance | Perform and control system maintenance, including remote sessions. |
| Media Protection | Protect and sanitize media that holds CUI, and mark it properly. |
| Personnel Security | Screen people before access and revoke access on termination or transfer. |
| Physical Protection | Limit and monitor physical access to systems and facilities. |
| Risk Assessment | Assess risk periodically and scan for vulnerabilities. |
| Security Assessment | Review controls, track corrective actions, and maintain the SSP. |
| System and Communications Protection | Separate and protect networks, encrypt CUI in transit, and manage cryptographic keys. |
| System and Information Integrity | Find and fix flaws, defend against malicious code, and monitor for attacks. |
Rev. 3 reshapes this list. It adds families for areas such as planning, system and services acquisition, and supply chain risk management, and it replaces many fixed values with organization-defined parameters that DoD has since published. Read the Rev. 3 publication for the authoritative wording and the full list.
Two habits make the family list manageable. First, treat each requirement as a question your SSP must answer: who does this, with what tool, and where is the evidence? Second, remember that many requirements are policy and process, not technology. NIST's guidance for small organizations is blunt that compliance is a continuous process, not a one-time project.
How compliance is proven: SPRS, DFARS, and CMMC
Implementing the controls is half the job. The other half is demonstrating it in the way your contract requires.
DFARS 252.204-7020 sets out the NIST SP 800-171 DoD Assessment Requirements. It defines three assessment types:
- Basic: your own self-assessment of how well you implement 800-171. It carries a Low confidence level.
- Medium and High: conducted by the government, carrying Medium or High confidence respectively.
The resulting score is posted in the Supplier Performance Risk System (SPRS). That score is more than an internal metric: a current assessment is a precondition for contract award eligibility, so a missing or outdated score can cost you business.
CMMC (Cybersecurity Maturity Model Certification) adds verification on top. Under 32 CFR Part 170, the program covers Level 1 (self-assessment), Level 2 (self-assessment or a certified third-party assessor organization, depending on the contract), and Level 3 (government-led by DIBCAC). Assessments generally need to be current: for most levels no more than three years old, with shorter windows for some statuses. CMMC does not replace DFARS 252.204-7012. As the DoD policy section frames it, protecting FCI and CUI on contractor systems is of paramount importance, and CMMC provides a consistent, verifiable way to confirm the existing requirements are really implemented rather than merely attested to.
If you want a plain-language read on how these pieces interact, remember this order: DFARS clause says what you must do, 800-171 says how, 800-171A says how it is assessed, SPRS and CMMC say how you show it.
A step-by-step path to NIST 800-171 compliance
There is no shortcut, but there is a sensible order. Here is the sequence we recommend.
1. Scope your CUI
List where CUI enters, where it is stored, who touches it, and where it leaves. The requirements apply to all system components that process, store, or transmit CUI, so a tight scope is the single biggest lever on cost. Many teams create a dedicated enclave for CUI instead of bringing the whole corporate network into scope. Document the boundary with a diagram.
2. Write the System Security Plan
The SSP describes how your system implements each requirement. NIST's assessment publication 800-171A is the companion that gives the procedures for assessing those requirements, and it allows assessment depth to be tailored to threat environment and risk tolerance. Use its objectives as the outline of your evidence. Each statement should name an owner, a system, and a proof point.
3. Run a gap assessment
Score each requirement as implemented, partially implemented, or not implemented. Be strict. A Basic self-assessment feeds your SPRS score, and an inflated score is a legal and contractual risk, not just an embarrassment.
4. Build a plan of action
For every gap, record the fix, the owner, the budget, and the date. Prioritize items that touch many requirements at once: multifactor authentication, centralized logging, endpoint management, and encryption usually clear many rows in a single quarter.
5. Implement and collect evidence
Evidence is screenshots, configuration exports, policy documents with approval dates, training records, and tickets. Store it where assessors can be given access without exposing other data. Our guide on real-time GRC compliance monitoring covers how to keep that evidence fresh instead of rebuilding it before each audit.
6. Assess, post, and maintain
Assess against 800-171A, post your score in SPRS if your contract requires it, and schedule the next review. Then run the program continuously. Our overview of continuous monitoring explains why point-in-time audits age quickly.
Making the SSP a living document
The old pattern was a 200-page Word file updated once a year. The better pattern treats the SSP as data. A GRC-focused OSCAL pocket guide from a NIST workshop lists a machine-readable catalog for SP 800-171 Rev. 3 alongside others such as CSF 2.0, and describes using OSCAL in JSON to map controls between frameworks. That lets a team show how implementations of NIST CSF 2.0 or SP 800-53 partially satisfy 800-171 requirements, which speeds SSP creation.
You do not need to adopt OSCAL tomorrow to benefit from the idea. Even in a spreadsheet, keep one row per requirement with a stable ID, an owner, a status, evidence links, and a last-reviewed date. If you already run NIST CSF or 800-53, our walkthrough of NIST CSF to 800-53 mapping and OSCAL shows how to reuse that work. For a wider view of how security teams sequence this kind of effort, see our guide to risk assessments with ISO and NIST.
Common mistakes we see
- Citing the wrong revision. Some SSPs still reference Rev. 2 language while the customer has asked for Rev. 3 mapping, and others do the reverse. State the revision, and keep a crosswalk.
- Scoping too wide. Every extra system holding CUI is one more system to harden, log, and assess.
- Treating the score as a trophy. The SPRS number is only as good as the evidence behind it, and a Basic score has a Low confidence level by definition.
- Forgetting the supply chain. If you pass CUI to a subcontractor or cloud provider, the requirements follow it. Ask for their evidence early.
- Letting answers drift. The SSP says one thing, the security questionnaire you sent last month says another, and the trust page says a third. Consistency is a compliance control in its own right.
Where we see questionnaires and 800-171 collide
Once you are compliant, you spend the next year proving it, repeatedly. Prime contractors send supplier questionnaires. Customers send due diligence questionnaires. Procurement portals ask you to re-enter the same facts about access control, encryption, and incident response.
That is the problem we built Skypher to solve. Our Questionnaire Automation Tool reads questionnaires in any format, drafts answers from your approved knowledge base, and shows a confidence score so reviewers can focus on the answers that need judgment. If your SSP is the source of truth, your questionnaire answers should be drawn from it, not retyped from memory. Our Smart Security Knowledge Base is designed for that: one place for approved content with document versioning, so an answer about your 800-171 status says the same thing everywhere. For the proactive side, a Trust Center lets you publish your security posture so fewer questionnaires arrive in the first place. And when the request is a financial-sector diligence questionnaire, see how we handle DDQ automation.
If you want to see it on your own questionnaires, you can book a walkthrough of the Questionnaire Automation Tool. Pricing is quote-based and depends on your usage and the features you need.
Our perspective: compliance is an engineering problem now
We talk to security, GRC, and sales teams who handle hundreds of questionnaires a year, and a pattern shows up with 800-171. The standard itself is rarely what slows people down. What slows them down is the gap between what the organization has done and what it can show, quickly and consistently, to the person asking.
We believe three things.
First, the SSP should be a living artifact. Security architecture guidance increasingly treats it as data-driven, with controls mapped programmatically instead of copied between documents. When a configuration changes, the record should change with it.
Second, one approved answer beats ten good ones. Retrieval-based AI only helps when it draws from a curated, versioned knowledge base. That is why we built our own retrieval models with confidence scoring: a draft that looks fluent but cites nothing is a liability for a team that has to sign an attestation. A reviewer should see where each answer came from and how sure the model is.
Third, the sales team is part of the compliance program. Every delayed questionnaire is a delayed contract. When security and sales share the same source of truth, in real time and without per-seat limits on who can collaborate, deals move faster and the answers stay accurate.
If you are early in your 800-171 journey, do the scoping and the SSP first and well. The questionnaires will be far easier afterwards, and we are glad to help with that part. Please feel free to reach out if you would like to compare notes.
— Gaspard
Related reading for your program
NIST 800-171 rarely lives alone. If you are building a wider program, these guides from our blog may help: the cybersecurity checklist for CISOs, a roadmap for CIS Controls v8.1 in 90 days, and our notes on security monitoring and automation for compliance.
FAQ
What are the NIST 800-171 requirements?
They are security requirements for protecting the confidentiality of CUI on nonfederal systems, grouped into families such as access control, audit and accountability, incident response, and system and communications protection. Rev. 2 has 110 requirements in 14 families, and Rev. 3 has 97 requirements in 17 families. Which set you are assessed against depends on your contract clause.
How do I get NIST 800-171 compliant?
Scope the systems that handle CUI, write an SSP, assess your gaps against 800-171A, and close them through a plan of action. Then post your assessment score in SPRS if your contract requires it, and review the evidence on a schedule. Most organizations find that a narrow scope and early multifactor authentication and logging save the most time.
Is NIST 800-171 the same as CMMC?
No. NIST 800-171 defines the security requirements, while CMMC is the DoD program that verifies contractors have implemented them. CMMC Level 2 is built around 800-171, and it does not replace DFARS 252.204-7012.
Does a self-assessment count as compliance?
A Basic self-assessment produces a score you can post in SPRS, but it carries a Low confidence level. Some contracts require a government assessment or a third-party CMMC assessment instead. Check your solicitation to see which applies.
Sources
- NIST SP 800-171 Rev. 3, CSRC
- NIST SP 800-171 Rev. 3 (PDF)
- NIST SP 800-171A Rev. 3 (PDF)
- NIST Government Contractor Resources
- Holland & Knight: DoD Organization-Defined Parameters for NIST SP 800-171 Rev. 3
- Planet Technologies: What Now for DoD's Rev. 3 Class Deviation
- The Defense Compliance Report: 48 CFR CMMC Final Rule
- eCFR: 48 CFR 252.204-7020
- eCFR: 32 CFR Part 170
- eCFR: 32 CFR 170.5
- NIST OSCAL Pocket Guide