NIST 800-171 Requirements Checklist: All 110 Rev. 2 Controls, Evidence, SSP & SPRS
Bottom line, before you scroll. The NIST 800-171 requirements checklist you should be working from for any Department of Defense (DoD) contract that touches Controlled Unclassified Information (CUI) is NIST Special Publication 800-171, Revision 2 — 110 security requirements organized into 14 families. That is the version the Cybersecurity Maturity Model Certification (CMMC) Level 2 still verifies today. We confirmed it by reading the CMMC rule itself at 32 CFR 170.14 — not from a slide deck.
Here is the part most checklists won’t say out loud: the list of 110 is the easy 10%.Anyone can hand you the controls — we’ll give you all 110 below. What decides whether you keep the contract is the evidencebehind each line: the proof an assessor will examine, the owner who can defend it, the score it produces in the Supplier Performance Risk System (SPRS). That gap — between “we have a checklist” and “we can prove it” — is where companies lose months and money.
So this isn’t another wall of bullet points. It’s the working checklist we wish someone had handed us: which version applies to your exact situation, what each of the 14 families has to prove, every one of the 110 requirement IDs, the first piece of evidence to put in the folder, who owns it, the trap that quietly sinks self-assessments, and what to do when the gap is bigger than your team can close.
Which NIST 800-171 checklist should you actually use?
It comes down to one thing: what is driving the requirement. If a DoD contract or flow-down touches CUI, you use the NIST SP 800-171 Rev. 2 evidence checklist (110 requirements). The contract clause then tells you what the checklist has to feed— a SPRS score, a CMMC status, or both.
| Your situation | The checklist to use | Why |
|---|---|---|
| You store, process, or transmit CUI for a DoD contract or subcontract | NIST SP 800-171 Rev. 2 evidence checklist | DFARS 252.204-7012 requires NIST SP 800-171 on covered systems; CMMC Level 2 verifies the 110 Rev. 2 requirements |
| Your solicitation includes DFARS 252.204-7019 / -7020 or, in solicitations issued under the Feb. 1, 2026 Revolutionary FAR Overhaul deviation, the new DFARS 252.240-7997 | Rev. 2 checklist + DoD Assessment Methodology / SPRS score | These clauses tie your NIST 800-171 assessment result and summary score to SPRS. The Feb. 2026 deviation renumbered the clause but did not change CMMC or remove SPRS posting |
| Your solicitation includes DFARS 252.204-7021 | Rev. 2 checklist + a CMMC level and assessment-type path | This is the CMMC clause: it requires the CMMC status the contract specifies, by award, and flows the obligation down to subs |
| A non-DoD federal customer asked for “NIST 800-171” | Confirm the contract-required revision first | Rev. 3 supersedes Rev. 2 in NIST’s library, but CMMC has not moved to Rev. 3. Your contract language controls which one binds you |
| You handle only Federal Contract Information (FCI), not CUI | CMMC Level 1 / FAR safeguarding path — not the full 110-control checklist | The 110-requirement checklist is the Level 2 / CUI path; Level 1 covers the 15 basic FAR safeguards. See our FCI vs. CUI guide |
Stop building the wrong checklist.Answer a few scoping questions and get the Rev. 2 evidence checklist that matches your contract trigger, your environment, and your CUI boundary — with owner, evidence, and SPRS columns already built in. Build My NIST 800-171 Checklist →
What we actually verified for this page
We are a trade publication, not the government — your binding obligations come from your contracts, clauses, CUI scope, and official DoD direction.
| Source we read | What it supports | Verified |
|---|---|---|
| 32 CFR 170.14 | CMMC Level 2 is keyed to NIST SP 800-171 Rev. 2; Level 3 adds selected NIST SP 800-172 requirements | |
| 32 CFR 170.24 | CMMC scoring methodology, including the narrow partial-credit cases | |
| 32 CFR 170.21 | POA&M eligibility rules and the 180-day closeout window | |
| NIST SP 800-171 Rev. 2 | The 110 security requirements / 14 families, the authoritative Rev. 2 publication | |
| NIST SP 800-171A | Assessment procedures (examine / interview / test) used to judge each requirement | |
| DoD NIST SP 800-171 Assessment Methodology | Scoring math, the −203 to 110 range, and Basic / Medium / High assessment levels | |
| DFARS class deviation 2026-O0025 | Feb. 1, 2026 Revolutionary FAR Overhaul — introduced DFARS Part 240 and clause 252.240-7997 |
What a NIST 800-171 requirements checklist actually is
A NIST 800-171 requirements checklist is the working tracker your organization uses to manage implementation of the NIST SP 800-171 security requirements that protect CUI on non-federal systems. For CMMC Level 2 and DoD CUI work today, that tracker should be built on Rev. 2’s 110 requirements and should record evidence, the System Security Plan (SSP) reference, the Plan of Action and Milestones (POA&M) status, the owner, and assessment readiness — not just a column of yes/no checkboxes.
Think of it as four levels of maturity:
| What you have | What it contains | Good for | The limitation |
|---|---|---|---|
| A family list | The 14 families | Orientation | Far too shallow to act on |
| A control list | All 110 requirement IDs | Talking to leadership | Still just a list — no proof |
| An evidence-ready checklist | Requirement + status + SSP reference + evidence + owner + POA&M + SPRS impact | A real defense contractor | Requires actual implementation work |
| An assessment tracker | Each requirement mapped to assessment objectives and tested evidence | A company that is assessment-ready | Needs formal prep and review |
Most pages ranking for this topic stop at the second level — they hand you the 110 and call it a checklist. This page gives you the third, and shows you how to climb to the fourth.
Do you actually have CUI — or only FCI?
Before you implement a single control, confirm whether you handle Controlled Unclassified Information (CUI) at all — because the full 110-requirement checklist is the CUI path, and if you only handle Federal Contract Information (FCI), you’re on the shorter CMMC Level 1 path instead. FCI is information provided by or generated for the government under a contract that isn’t intended for public release; CUI is a defined category of government information that requires safeguarding under law, regulation, or government-wide policy. They are different triggers, with different checklists. Confusing them early is expensive to unwind.
A few ways to resolve it quickly:
- Read the contract and the markings. Look for CUI markings on deliverables, and for clauses like DFARS 252.204-7012 (which travels with CUI) versus only the basic FAR safeguarding clause (which travels with FCI).
- Ask the prime or the contracting officer. If a prime is flowing requirements down to you, they should be able to tell you what category of information you’ll receive and create.
- Map the data flow. Trace where contract information enters, where it’s stored, who touches it, and where it leaves. The answer to “do we have CUI” usually falls out of that map.
For the full CUI/FCI distinction, see our FCI vs. CUI guide and CMMC scoping guide. If the honest answer is “we don’t know,” treat that as your first task — not a reason to start checking boxes.
Should your checklist use NIST 800-171 Rev. 2 or Rev. 3?
Use NIST SP 800-171 Rev. 2 for CMMC Level 2 unless your contract or government customer specifically requires a different version. NIST published Rev. 3 in May 2024, and in NIST’s own library Rev. 3 supersedes Rev. 2 — but CMMC Level 2 still verifies the 110 Rev. 2 requirements, because that’s the version written into the CMMC rule at 32 CFR 170.14. Changing that reference isn’t a memo; it requires new federal rulemaking that hasn’t happened.
| Publication | Status in the NIST library | What it means for CMMC | Source |
|---|---|---|---|
| NIST SP 800-171 Rev. 2 (Feb. 2020) | Superseded in NIST’s library by Rev. 3 | Still the controlling version for CMMC Level 2 — incorporated by reference in the CMMC rule | 32 CFR 170.14 (eCFR) |
| NIST SP 800-171 Rev. 3 (May 2024) | Current in the NIST library; reorganized into 17 families | Not used by CMMC unless DoD amends the rule through new rulemaking | NIST CSRC; 32 CFR Part 170 |
The 110 requirements across 14 families — and what each must prove
NIST SP 800-171 Rev. 2 organizes its 110 CUI security requirements into 14 families, numbered 3.1 through 3.14, ranging from 2 requirements (Personnel Security) to 22 (Access Control). Knowing the family names is orientation. The work is translating each family into evidence, an owner, an SSP reference, and a defensible status.
The DCR Evidence-Ready NIST 800-171 Checklist Matrix
| Family (code · §) | # | What the checklist must prove | First evidence object to collect | Likely owner | The trap that sinks self-assessments |
|---|---|---|---|---|---|
| Access Control (AC · 3.1) | 22 | Only authorized users, processes, and devices reach CUI; least privilege; remote access controlled | Access-authorization matrix tying each account to a documented need, plus a privileged-account list | IT / Security | “We have MFA” is treated as access control, while the authorization itself is never documented |
| Awareness & Training (AT · 3.2) | 3 | People who handle CUI are trained for it, including insider-threat awareness | Role-based training records mapped to CUI roles | HR / Security | Generic annual security-awareness training counted as CUI training |
| Audit & Accountability (AU · 3.3) | 9 | Logs are generated, protected, retained, and actually reviewed, traceable to a user | Log-source inventory + a dated review record + retention setting | Security / MSSP | Logging is on, but nobody reviews or protects the logs |
| Configuration Management (CM · 3.4) | 9 | Secure baselines, controlled changes, least functionality | A documented, versioned baseline configuration + change tickets | IT / Engineering | A “standard image” exists but is not approved, versioned, or enforced |
| Identification & Authentication (IA · 3.5) | 11 | Unique identification and authentication of users and devices, including MFA | Identity-provider report + MFA enforcement policy across local, network, and privileged access | IT / IAM | MFA on email only; privileged or local access missed; shared accounts still live |
| Incident Response (IR · 3.6) | 3 | You can detect, report, and respond to incidents — and you have tested it | An incident-response plan + a tabletop exercise record | Security / Contracts | A plan exists on paper but was never exercised |
| Maintenance (MA · 3.7) | 6 | Maintenance and maintenance tools are controlled, including remote and vendor maintenance | Maintenance logs + remote-support approval records | IT | Vendor remote access is unmanaged or unlogged |
| Media Protection (MP · 3.8) | 9 | CUI media is marked, controlled, transported, sanitized, and destroyed | Media inventory + sanitization records + portable-media encryption setting | IT / Facilities | “We don’t use USBs,” asserted with no policy and no evidence |
| Personnel Security (PS · 3.9) | 2 | Personnel are screened before CUI access; access is removed on termination/transfer | Onboarding/offboarding checklist + an access-termination sample | HR / IT | HR records and IT deprovisioning don’t match |
| Physical Protection (PE · 3.10) | 6 | Physical access to CUI systems and areas is limited and monitored, including visitors | Badge/access list + visitor logs + facility diagram | Facilities / Security | Remote and home-office locations ignored in the boundary |
| Risk Assessment (RA · 3.11) | 3 | You assess risk and scan for and remediate vulnerabilities | Vulnerability scan report + remediation tracking + a risk assessment | Security / vCISO | Scans run, but findings are never tied to remediation decisions |
| Security Assessment (CA · 3.12) | 4 | You maintain an SSP, a POA&M, and ongoing control assessment | The SSP and the POA&M themselves | Compliance lead / Leadership | The checklist says “met,” but the SSP doesn’t describe the actual system |
| System & Communications Protection (SC · 3.13) | 16 | Boundary protection, FIPS-validated cryptography, segmentation, protected data flows | Network/data-flow diagram + FIPS-validated module evidence + boundary configuration | Security architect / IT | Assuming the cloud platform inherits everything |
| System & Information Integrity (SI · 3.14) | 7 | Flaw remediation/patching, malicious-code protection, monitoring | Patch-cadence report + endpoint protection report + alert/remediation evidence | IT / MSSP | Tools are installed, but alerts and remediation are never operationalized |
| Total | 110 | ||||
A word on the “owner” column, because it’s the most underrated part of any checklist: CMMC failures are rarely about a single missing tool. They’re about requirements that live nowhere — IT assumes HR has it, HR assumes contracts has it, and the SSP claims it’s done. Assign an accountable owner to every family before you write a single “met,” and you’ve already dodged the most common self-assessment failure in the table.
The complete 110-requirement NIST 800-171 Rev. 2 checklist
Every requirement ID, in plain language, grouped by family. Pair it with the evidence, owner, and SSP columns from the matrix above.
Access Control (AC) — 3.1 — 22 requirements
| ID | Requirement (plain language) |
|---|---|
| 3.1.1 | Limit system access to authorized users, processes, and devices |
| 3.1.2 | Limit access to the transactions and functions authorized users may execute |
| 3.1.3 | Control the flow of CUI in accordance with approved authorizations |
| 3.1.4 | Separate the duties of individuals to reduce the risk of malevolent activity |
| 3.1.5 | Employ least privilege, including for privileged accounts and security functions |
| 3.1.6 | Use non-privileged accounts or roles for nonsecurity functions |
| 3.1.7 | Prevent non-privileged users from running privileged functions; log such attempts |
| 3.1.8 | Limit unsuccessful logon attempts |
| 3.1.9 | Provide privacy and security notices consistent with CUI rules |
| 3.1.10 | Use session lock with pattern-hiding displays after inactivity |
| 3.1.11 | Automatically terminate a user session after a defined condition |
| 3.1.12 | Monitor and control remote access sessions |
| 3.1.13 | Use cryptography to protect the confidentiality of remote access sessions |
| 3.1.14 | Route remote access through managed access control points |
| 3.1.15 | Authorize remote execution of privileged commands and remote access to security-relevant information |
| 3.1.16 | Authorize wireless access before allowing connections |
| 3.1.17 | Protect wireless access using authentication and encryption |
| 3.1.18 | Control the connection of mobile devices |
| 3.1.19 | Encrypt CUI on mobile devices and mobile computing platforms |
| 3.1.20 | Verify and control/limit connections to and use of external systems |
| 3.1.21 | Limit use of portable storage devices on external systems |
| 3.1.22 | Control CUI posted or processed on publicly accessible systems |
Awareness & Training (AT) — 3.2 — 3 requirements
| ID | Requirement (plain language) |
|---|---|
| 3.2.1 | Make managers, admins, and users aware of security risks and applicable policies |
| 3.2.2 | Train personnel to carry out their assigned information-security duties |
| 3.2.3 | Provide security awareness training on recognizing and reporting insider threats |
Audit & Accountability (AU) — 3.3 — 9 requirements
| ID | Requirement (plain language) |
|---|---|
| 3.3.1 | Create and retain audit logs to enable monitoring, analysis, investigation, and reporting |
| 3.3.2 | Ensure individual user actions can be uniquely traced (accountability) |
| 3.3.3 | Review and update logged events |
| 3.3.4 | Alert in the event of an audit logging process failure |
| 3.3.5 | Correlate audit record review, analysis, and reporting for investigations |
| 3.3.6 | Provide audit record reduction and report generation |
| 3.3.7 | Synchronize internal system clocks with an authoritative time source for audit records |
| 3.3.8 | Protect audit information and logging tools from unauthorized access or modification |
| 3.3.9 | Limit management of audit logging to a subset of privileged users |
Configuration Management (CM) — 3.4 — 9 requirements
| ID | Requirement (plain language) |
|---|---|
| 3.4.1 | Establish and maintain baseline configurations and inventories |
| 3.4.2 | Establish and enforce security configuration settings |
| 3.4.3 | Track, review, approve/disapprove, and log changes to systems |
| 3.4.4 | Analyze the security impact of changes before implementation |
| 3.4.5 | Define, document, approve, and enforce access restrictions for changes |
| 3.4.6 | Employ the principle of least functionality |
| 3.4.7 | Restrict, disable, or prevent nonessential programs, ports, protocols, and services |
| 3.4.8 | Apply deny-by-exception (blacklist) or permit-by-exception (whitelist) for software |
| 3.4.9 | Control and monitor user-installed software |
Identification & Authentication (IA) — 3.5 — 11 requirements
| ID | Requirement (plain language) |
|---|---|
| 3.5.1 | Identify users, processes acting for users, and devices |
| 3.5.2 | Authenticate or verify the identities of those users, processes, and devices |
| 3.5.3 | Use multifactor authentication for privileged accounts and for network access to non-privileged accounts |
| 3.5.4 | Employ replay-resistant authentication for network access |
| 3.5.5 | Prevent reuse of identifiers for a defined period |
| 3.5.6 | Disable identifiers after a defined period of inactivity |
| 3.5.7 | Enforce minimum password complexity and required changes |
| 3.5.8 | Prohibit password reuse for a specified number of generations |
| 3.5.9 | Allow temporary passwords only with an immediate change to permanent |
| 3.5.10 | Store and transmit only cryptographically protected passwords |
| 3.5.11 | Obscure feedback of authentication information |
Incident Response (IR) — 3.6 — 3 requirements
| ID | Requirement (plain language) |
|---|---|
| 3.6.1 | Establish an operational incident-handling capability |
| 3.6.2 | Track, document, and report incidents to designated officials and authorities |
| 3.6.3 | Test the organizational incident response capability |
Maintenance (MA) — 3.7 — 6 requirements
| ID | Requirement (plain language) |
|---|---|
| 3.7.1 | Perform maintenance on organizational systems |
| 3.7.2 | Control the tools, techniques, mechanisms, and personnel used for maintenance |
| 3.7.3 | Sanitize equipment of CUI before off-site maintenance |
| 3.7.4 | Check diagnostic and test media for malicious code before use |
| 3.7.5 | Require MFA for nonlocal maintenance sessions and terminate them when complete |
| 3.7.6 | Supervise maintenance by personnel without required access authorization |
Media Protection (MP) — 3.8 — 9 requirements
| ID | Requirement (plain language) |
|---|---|
| 3.8.1 | Physically control and securely store CUI media (paper and digital) |
| 3.8.2 | Limit access to CUI on media to authorized users |
| 3.8.3 | Sanitize or destroy CUI media before disposal or reuse |
| 3.8.4 | Mark media with required CUI markings and distribution limitations |
| 3.8.5 | Control access to and account for CUI media during transport |
| 3.8.6 | Use cryptography to protect CUI on digital media during transport |
| 3.8.7 | Control the use of removable media on system components |
| 3.8.8 | Prohibit use of portable storage devices with no identifiable owner |
| 3.8.9 | Protect the confidentiality of backup CUI at storage locations |
Personnel Security (PS) — 3.9 — 2 requirements
| ID | Requirement (plain language) |
|---|---|
| 3.9.1 | Screen individuals before authorizing access to CUI systems |
| 3.9.2 | Protect CUI and systems during and after personnel actions (transfers, terminations) |
Physical Protection (PE) — 3.10 — 6 requirements
| ID | Requirement (plain language) |
|---|---|
| 3.10.1 | Limit physical access to systems, equipment, and operating environments |
| 3.10.2 | Protect and monitor the physical facility and support infrastructure |
| 3.10.3 | Escort visitors and monitor visitor activity |
| 3.10.4 | Maintain audit logs of physical access |
| 3.10.5 | Control and manage physical access devices |
| 3.10.6 | Enforce safeguarding measures for CUI at alternate work sites |
Risk Assessment (RA) — 3.11 — 3 requirements
| ID | Requirement (plain language) |
|---|---|
| 3.11.1 | Periodically assess risk from operating systems that handle CUI |
| 3.11.2 | Scan for vulnerabilities periodically and when new ones are identified |
| 3.11.3 | Remediate vulnerabilities in accordance with risk assessments |
Security Assessment (CA) — 3.12 — 4 requirements
| ID | Requirement (plain language) |
|---|---|
| 3.12.1 | Periodically assess security controls for effectiveness |
| 3.12.2 | Develop and implement POA&Ms to correct deficiencies |
| 3.12.3 | Monitor security controls on an ongoing basis |
| 3.12.4 | Develop, document, and periodically update the System Security Plan (SSP) |
System & Communications Protection (SC) — 3.13 — 16 requirements
| ID | Requirement (plain language) |
|---|---|
| 3.13.1 | Monitor, control, and protect communications at external and key internal boundaries |
| 3.13.2 | Employ security-promoting architectural and engineering design principles |
| 3.13.3 | Separate user functionality from system management functionality |
| 3.13.4 | Prevent unauthorized information transfer via shared system resources |
| 3.13.5 | Separate publicly accessible system components into subnetworks |
| 3.13.6 | Deny network traffic by default and allow by exception |
| 3.13.7 | Prevent split tunneling on remote devices |
| 3.13.8 | Use cryptography to protect CUI during transmission unless otherwise protected |
| 3.13.9 | Terminate network connections after sessions end or after inactivity |
| 3.13.10 | Establish and manage cryptographic keys |
| 3.13.11 | Employ FIPS-validated cryptography when protecting the confidentiality of CUI |
| 3.13.12 | Prohibit remote activation of collaborative computing devices; indicate use |
| 3.13.13 | Control and monitor the use of mobile code |
| 3.13.14 | Control and monitor the use of Voice over IP (VoIP) |
| 3.13.15 | Protect the authenticity of communications sessions |
| 3.13.16 | Protect the confidentiality of CUI at rest |
System & Information Integrity (SI) — 3.14 — 7 requirements
| ID | Requirement (plain language) |
|---|---|
| 3.14.1 | Identify, report, and correct system flaws in a timely manner |
| 3.14.2 | Provide protection from malicious code at designated locations |
| 3.14.3 | Monitor security alerts and advisories and act on them |
| 3.14.4 | Update malicious-code protection when new releases are available |
| 3.14.5 | Perform periodic and real-time scans of files from external sources |
| 3.14.6 | Monitor the system, including inbound and outbound traffic, to detect attacks |
| 3.14.7 | Identify unauthorized use of organizational systems |
► Download the evidence-ready checklist
A spreadsheet you can actually work in beats a list you have to retype. The file carries all 110 requirement IDs plus the columns that make a checklist defensible: family, implementation status, evidence location, owner, SSP reference, POA&M status, and SPRS-point impact — in Excel, CSV, or PDF.
Download the Evidence-Ready Checklist →What makes a checklist “evidence-ready” — and why a yes/no list fails
An evidence-ready checklist proves each requirement the way an assessor will judge it. NIST SP 800-171A — the companion assessment publication — turns each requirement into a set of assessment objectives evaluated three ways: by examining documents and configurations, interviewing the people who run them, and testing what the environment actually does. That’s the difference between “we wrote a policy” and “we can show it operating right now.”
| Requirement area | Weak “checklist” answer | Evidence-ready answer (examine · interview · test) |
|---|---|---|
| Multifactor authentication (3.5.3) | “Enabled” | An identity-provider MFA policy export, a privileged-account sample showing MFA enforced, the remote-access policy, a live test or screenshot — and someone who can explain the configuration |
| Audit logging (3.3.x) | “We have a SIEM” | A log-source inventory, retention settings, a dated review record, and the alert-and-escalation workflow |
| Awareness training (3.2.x) | “Annual training done” | A training roster, the CUI-specific content, and admin/role-based training records |
The posture that protects your SPRS score: walk every requirement as if a stranger will say, “Show me.” If the only answer is a checkbox, it isn’t done. If the answer is a document, a screenshot, and a person who can defend it, it is.
What documents should sit behind your checklist?
A complete NIST 800-171 checklist connects to a small set of documents that an assessor will expect, and that your SPRS score depends on.
- System Security Plan (SSP) — describes your system boundary, the CUI you handle, and how each requirement is implemented. Required by 3.12.4 and itself scored. If your SSP doesn’t describe your real environment, the rest of the checklist is fiction.
- Plan of Action & Milestones (POA&M) — lists what isn’t done yet and when it will be, under 3.12.2. (POA&M eligibility rules are covered in the next section.)
- CUI data-flow diagram — shows where CUI enters, moves, rests, and leaves. This defines and defends your boundary.
- Asset and user inventory — you can’t protect what you haven’t listed; this anchors access control, configuration management, and media protection.
- Policies and procedures — written rules behind families like access control, training, incident response, and media protection.
- Vendor / external service provider (ESP) responsibility matrix — spells out which requirements are inherited from a cloud platform or managed provider, which are shared, and which are yours. This is where “the cloud handles it” claims either hold up or fall apart.
- Evidence folder — the screenshots, exports, logs, and records that turn a “yes” into a defensible “met.”
- Training and incident-response records — completion logs, role-based training, the tested IR plan, and tabletop notes.
Build these alongside the checklist, not after it. The companies that move fastest treat the SSP and evidence folder as living documents from day one.
How your checklist becomes a SPRS score
For applicable DoD systems, you self-score your NIST 800-171 implementation using the DoD Assessment Methodology and post the result in SPRS. You start at a perfect 110 and subtract a weighted value — 1, 3, or 5 points — for each requirement you have not fully implemented, producing a score between −203 (nothing implemented) and 110 (everything implemented). A current score is required for award under the NIST 800-171 assessment clause.
The lack of partial credit is the part people get wrong — with two narrow exceptions worth knowing. Under 32 CFR 170.24, the CMMC scoring methodology credits partial implementation only in limited cases: IA.L2-3.5.3 (multifactor authentication) and SC.L2-3.13.11 (CUI encryption) can have adjusted deductions depending on how they’re implemented. Every other NOT MET requirement loses its full 1-, 3-, or 5-point value.
- There are three assessment levels. A contractor self-assessment is a Basic assessment, which DoD treats as “low” confidence. Medium and High assessments are government-led.
- Your SSP is the backbone of the score. If your SSP requirement (CA.L2-3.12.4) is marked NOT MET, SPRS can’t produce a score at all.
- SPRS stores the result, not the work. It records your score, scope, assessment date, CAGE codes, SSP details, POA&M completion date, and a confidence level. An old score with no current evidence behind it is a liability, not an asset.
One current-state note. As of , a Revolutionary FAR Overhaul class deviation (DARS tracking number 2026-O0025) replaced DFARS 252.204-7019/-7020 with a new clause, DFARS 252.240-7997, reorganized under a new DFARS Part 240. We read the deviation memo: it changes how the Department administers NIST 800-171 assessments and which clause numberyou’ll see — it does not amend the CMMC rule (32 CFR Part 170), does not touch DFARS 252.204-7021 (the CMMC clause), and does noteliminate Level 2 self-assessments or SPRS posting where a solicitation requires them. In plain terms: same work, new clause numbers.
Before you touch SPRS, make sure your checklist matches your evidence. If your score is stale, unsupported, or based on a scope that has changed, find out what needs to be revalidated before you post. Check My SPRS Readiness →
Which requirements can sit on a POA&M (and which can’t)
For CMMC, a Plan of Action & Milestones lets you defer a limited set of unmet requirements and still earn a Conditionalstatus — but the rules are strict, and most of the requirements that hurt your score can’t be deferred at all. Under 32 CFR 170.21, Conditional Level 2 requires a score of at least 88 out of 110 (80%), and the POA&M can hold only narrow categories of requirements, closed out within 180 days.
- Only 1-point requirements are POA&M-eligible. Every 3-point and 5-point requirement must be fully met before assessment.
- One narrow encryption exception: SC.L2-3.13.11 (CUI encryption) may be placed on a POA&M if encryption is employed but is not FIPS-validated — in which case it counts as a 3-point deduction.
- Six specific 1-point requirements are excluded by name under 170.21(a)(2)(iii), even though they’re only worth a point.
- The closeout is hard-dated: the POA&M must be confirmed closed within 180 days of the Conditional CMMC Status Date, or the Conditional status expires.
Practitioner analyses count 63 of the 110 as ineligible for a POA&M. This is precisely why you run the checklist first and fix in order of weight: you want the expensive, non-deferrable requirements done long before an assessor is in the room. See our Conditional Level 2 POA&M closeout guide for the full closeout process.
How the checklist connects to CMMC Level 2 — and whether you need a C3PAO
NIST 800-171 is the requirement set; CMMC is the DoD program that verifies it. CMMC Level 2 uses the same 110 Rev. 2 requirements, but your contract decides whether your Level 2 path is a self-assessment or a certification assessment by an authorized C3PAO (a Certified Third-Party Assessment Organization). DFARS 252.204-7021 requires you to hold and maintain the CMMC status the contract specifies, and it flows that obligation down to your subcontractors.
A checklist cannot make you compliant or certified. It’s a tracker.Finish it perfectly and you still haven’t “passed” anything — and the work an honest checklist exposes is routinely bigger, slower, and more expensive than leadership expects. Separate the two jobs permanently:
- Readiness and remediation — scoping, the SSP, the POA&M, implementing controls, managing your environment — is one job. This is where your time and money go first if you’re not assessment-ready.
- Formal assessment — a C3PAO confirming Level 2 when the contract requires certification — is a different job, done later, by a different party. Any combined “we’ll fix you and certify you” pitch is a conflict question to verify before you sign.
See our CMMC self-assessment vs. C3PAO guide and CMMC Level 2 requirements for the full picture.
Not ready to talk to a provider? Start with the evidence checklist and use the SPRS-impact column to see whether you have adocumentation problem, an implementation problem, or a scope problem. Start With the Evidence Checklist →
If the gap is clearly bigger than your team can close in time — get matched with source-checked CMMC provider options →
How much does NIST 800-171 compliance cost, and how long does it take?
There’s no single number, because cost and timeline scale with three things: how mature you already are, how large your CUI environment is, and how much you outsource. In practice, readiness commonly runs from several months to a couple of years, and from the low five figures for a tightly scoped small shop to well into six figures for a broad, multi-system environment.
Where the money actually goes:
- MFA everywhere CUI is reachable — not just on email, but on privileged accounts, remote access, and local logons.
- FIPS-validated cryptography — for data at rest and in transit, which often means replacing or reconfiguring tools you assumed were “encrypted enough.”
- Shrinking the boundary — moving CUI into a controlled environment such as GCC High or a purpose-built CUI enclave, so you protect a small, well-defined space instead of your entire company.
- Documentation — a real SSP and a clean POA&M, which is labor, not licensing.
- Ongoing monitoring — logging, vulnerability management, and incident response that operate continuously, not once a year.
One nuance: DoD’s own economic analysis of the CMMC rule focused on the cost of assessments and affirmations— not the underlying NIST 800-171 implementation — because that implementation was already required under DFARS 252.204-7012. The security work itself is a cost you already owed; CMMC mostly adds the bill for proving it. For cost breakdowns across levels, see our CMMC certification cost guide and CMMC Level 2 cost guide.
The fastest safe order to work through the checklist
Do not start at requirement 3.1.1 and march down the list. Unless you already know your CUI scope, linear order is how you burn weeks protecting systems that should never have been in scope. The fastest safe sequence is scope-first.
- Read the clause or the flow-down. Identify the required level and which clauses are present. Don’t assume your CMMC level from hearsay.
- Identify your CUI and FCI. Know what data you actually hold and where it came from.
- Define the CUI system boundary. Where does CUI enter, move, rest, and leave? This single decision determines the size and cost of everything that follows.
- Decide whether an enclave makes sense. If CUI is sprawled across commercial email and file shares, isolating it into a smaller controlled environment can shrink the boundary dramatically.
- Build the SSP skeleton. Describe the system you just scoped. A generic SSP that doesn’t match your environment is worse than none.
- Inventory users, devices, cloud apps, vendors, and data flows. You can’t protect what you haven’t listed.
- Prioritize the high-leverage technical baselines. Identity and access, MFA, logging, vulnerability management, incident response, and configuration baselines — the families that carry the heavy SPRS weights and that can’t sit on a POA&M.
- Close evidence family by family. Use the matrix and 110-list above. For each line: status, evidence, owner, SSP reference.
- Calculate or update SPRS only when the evidence supports it. Not before.
- Decide your path. Self-assessment-ready, readiness-provider-ready, or C3PAO-ready — and act accordingly.
| Phase | Output | The wrong move to avoid |
|---|---|---|
| Contract trigger | Required level and clauses | Assuming your CMMC level from rumor |
| Scope | A defined CUI boundary | Putting the whole company in scope by default |
| SSP | A real system description | Generic controls with no tie to your environment |
| Evidence | A proof folder | Checking "yes" with no records |
| SPRS | A supported score | Posting before the evidence exists |
| Path | The right provider category | Calling a C3PAO to do implementation |
Can you do this yourself, or do you need a provider — and which kind?
You can absolutely start the checklist yourself — scope discovery, owner mapping, document inventory, and evidence collection are squarely in reach for an internal team. You typically need outside help when the checklist exposes technical implementation gaps, a CUI environment that’s too broad, SSP or POA&M uncertainty, SPRS scoring risk, or a near-term certification assessment.
| If your checklist shows… | The provider category that fits | Don’t confuse it with |
|---|---|---|
| No SSP, unclear scope, policy and documentation gaps | RPO / Registered Practitioner / vCISO — readiness and advisory | A C3PAO (they assess; they don’t remediate) |
| Weak MFA, logging, patching, endpoint, or identity | CMMC-focused MSP or MSSP | A pure policy consultant with no operational reach |
| CUI sprawled across commercial email and file shares | CUI enclave / secure-collaboration provider | “Just buy a GRC tool” |
| Evidence scattered with no control-mapping workflow | GRC / compliance-evidence software — a supporting layer | Actual implementation |
| Evidence ready, and the contract requires certification | An authorized C3PAO | A readiness or remediation firm |
| Level 3 in play | The DIBCAC assessment path | The Level 2 C3PAO path |
For the full category breakdown, see our CMMC provider categories guide and who to hire first.
The checklist exposed gaps — now route them correctly. Match what your checklist revealed to the right provider category, so you don’t pay a remediation firm for an assessment or an assessor for remediation. Compare Provider Categories →
Where CMMC enforcement actually stands right now
The DFARS rule that puts CMMC into contracts became effective , starting a phased rollout, and the underlying CMMC Program rule (32 CFR Part 170) took effect . In Phase 1 — where we are now — contracting officers can require Level 1 and Level 2 self-assessments, and may require Level 2 C3PAO assessments at program discretion. Phase 2 begins around : for solicitations and contracts that require CMMC Level 2 (C3PAO), a self-assessment is no longer enough.
| What the rule / program says | What you should verify | Where to check |
|---|---|---|
| Phase 1 (–): officers can require Level 1/Level 2 self-assessment, with discretion to require Level 2 C3PAO | Which CMMC status your solicitation requires | 32 CFR Part 170; the solicitation |
| Phase 2 begins ; Level 2 C3PAO required for applicable contracts | Whether your next contract falls in Phase 2 timing and names a C3PAO requirement | DoD CIO; the solicitation |
| Conditional Level 2 needs ≥88/110, limited POA&M, 180-day closeout | Your score, and whether any open gap is non-POA&M-able | 32 CFR 170.21 / 170.24 |
| A C3PAO must be authorized; a readiness firm can’t assess its own prep | A C3PAO’s current authorization status | Cyber AB Marketplace |
As of the October 2025 Cyber AB Town Hall, only about 431 organizationsheld a final CMMC Level 2 certification, against the roughly 80,000companies DoD estimates will need Level 2 (treat those as market indicators — verify current numbers in the Cyber AB Marketplace). The takeaway isn’t panic — it’s sequence. The contractors who do well from here run the checklist now, fix in priority order, and get in line for assessment before the crowd does. See how long CMMC certification takes for timeline planning.
The most common NIST 800-171 checklist mistakes
Most checklist failures aren’t new regulatory requirements — they’re practical errors that make the checklist unreliable.
- Using a Rev. 3 checklist for CMMC Level 2. CMMC verifies Rev. 2.
- Treating “the tool can do it” as evidence. Capability isn’t implementation. Show it operating.
- Ignoring BYOD, vendors, file shares, and email. CUI hides in the places nobody scoped.
- No link between the SSP and the evidence. If the SSP doesn’t describe your real system, the checklist is fiction.
- No owner for each family. Compliance that lives nowhere fails everywhere.
- Putting a non-eligible gap on a POA&M. If a 3- or 5-point gap (or one of the six named 1-point requirements) is on your POA&M, you don’t get a Conditional status.
- A stale SPRS score with no current evidence. This is a contractual risk, not a formality.
- Hiring an assessor before you’re ready. Expensive, and it can put a poor result on record.
A real, honest checklist may reveal that your environment is further behind and more expensive to fix than you hoped. That isn’t a reason to soften the checklist — it’s the entire point of running one. It’s far cheaper to learn it now than to learn it from a failed assessment, a lost recompete, or a DOJ Civil Cyber-Fraud problem tied to a SPRS score you knowingly couldn’t support.
NIST 800-171 requirements checklist FAQ
How many NIST 800-171 requirements are there?
For CMMC Level 2 today, the control set is 110 NIST SP 800-171 Rev. 2 security requirements across 14 families. Contractors usually call them “controls”; NIST’s term is “security requirements.” They’re the same thing.
Is NIST 800-171 Rev. 2 or Rev. 3 required for CMMC?
CMMC Level 2 currently uses NIST SP 800-171 Rev. 2. Rev. 3 exists and supersedes Rev. 2 in NIST’s publication library, but it doesn’t become the CMMC checklist unless DoD changes the rule through new rulemaking, which hasn’t happened.
Is NIST 800-171 the same as CMMC?
No. NIST SP 800-171 is the set of security requirements for protecting CUI on non-federal systems. CMMC is the DoD program that verifies implementation at the required level and assessment type. The standard is the “what”; CMMC is the “prove it.”
What is NIST 800-171A?
NIST SP 800-171A is the companion publication that provides procedures for assessing the NIST SP 800-171 requirements. It’s used for self-assessments, independent third-party assessments, and government-sponsored assessments, and it judges each requirement by examining, interviewing, and testing.
Did the February 2026 DFARS change end the NIST 800-171 self-assessment?
No. A Revolutionary FAR Overhaul class deviation replaced DFARS 252.204-7019/-7020 with a new clause (DFARS 252.240-7997) under a new DFARS Part 240, and renumbered the FAR safeguarding clause. It reorganized how the Department administers NIST 800-171 assessments; it did not amend CMMC (32 CFR Part 170), touch the CMMC clause (252.204-7021), or remove Level 2 self-assessments and SPRS posting where a solicitation requires them.
Do I have to post a NIST 800-171 score in SPRS?
If your covered DoD system is subject to the NIST 800-171 assessment requirements, the relevant result is posted in SPRS, and a current score is required for award consideration. A contractor self-assessment is a “Basic” assessment based on your SSP using the DoD Assessment Methodology.
Do I need a C3PAO for NIST 800-171?
Not automatically. Your contract decides whether your CMMC Level 2 path is self-assessed or requires an authorized C3PAO. If certification is required and you’re ready, you engage a C3PAO; if not, you do readiness work first — and keep the two roles separate.
Can I use a POA&M for unfinished requirements?
For CMMC, POA&M use is limited. None is permitted at Level 1. At Level 2, you need a score of at least 88/110, only 1-point requirements are eligible (with a narrow exception for SC.L2-3.13.11 if encryption is employed but not FIPS-validated, at 3 points), six specific 1-point requirements are excluded by name, and the POA&M must be closed within 180 days or your Conditional status expires. See 32 CFR 170.21 for the exact list.
Does GCC High, Azure Government, AWS GovCloud, or a GRC tool make me compliant?
No single platform makes your organization compliant by itself. The checklist still has to show the system boundary, which responsibilities are inherited versus shared versus yours, the settings as implemented, the operating evidence, and the SSP language. The platform is a foundation, not a finish line.
My boss just handed me “NIST 800-171” — what do I do first?
Start with scope, not control 3.1.1. Determine whether you handle CUI, where it lives, who can access it, which systems touch it, and which clauses apply. Then build the Rev. 2 evidence checklist — and use the matrix and 110-list on this page as your template. See also our NIST 800-171 gap analysis guide and NIST 800-171 consultant guide.
The next move
You came here for a checklist. You’re leaving with the version that matters: Rev. 2, all 110 requirements, 14 families, mapped to the evidence, owners, and score that actually decide whether you keep the contract. The list was the easy part. The evidence is the work — and now you know the order to do it in.
If you can see your path from here, run the checklist and go. If the gap is bigger than your team can close before your contract needs it, don’t guess at who to call.
► Need help deciding what type of CMMC provider you need?
Tell us your level, scope, and timeline, and we’ll match you with source-checked CMMC provider options — so you talk to the right kind of provider the first time.
Get Matched With Source-Checked Provider Options →Keep going from here
- CMMC Level 2 requirements — the full 110 controls and what they mean for CMMC
- CMMC Level 2 checklist — the assessment-ready version
- CMMC self-assessment vs. C3PAO — who can assess what and when
- CMMC certification process — what a C3PAO assessment actually involves
- SPRS score guide — how to calculate, post, and maintain your score
- NIST 800-171 gap analysis — finding and prioritizing your gaps
- NIST 800-171 consultant guide — what to look for and what to avoid
- CMMC scoping guide — the five asset categories and how to define your boundary
- FCI vs. CUI — which path you’re actually on
- CMMC provider categories — RPO, C3PAO, MSP, MSSP — what each one does
- CMMC readiness checklist — pre-assessment checklist across all levels
- CMMC Level 3 requirements — the 24 NIST SP 800-172 enhanced controls