NIST SP 800-171 · Introduction
Protecting CUI
Security requirements for Controlled Unclassified Information in nonfederal systems and organizations
CUI protection lifecycle · from federal authority through nonfederal implementation and verification
NIST Special Publication 800-171 establishes the security requirements that nonfederal organizations must implement when they process, store, or transmit Controlled Unclassified Information (CUI) on behalf of federal agencies. It is not optional guidance — for DoD contractors, compliance is a contractual obligation under DFARS 252.204-7012, and it serves as the foundation for CMMC Level 2 certification.
The publication is derived from NIST SP 800-53, the comprehensive security control catalog used by federal agencies. SP 800-171 tailors the 800-53 moderate baseline down to the controls directly related to protecting CUI confidentiality — currently 110 requirements across 14 control families in Rev 2, and 97 requirements across 17 control families in Rev 3.
Core principle
CUI has the same value regardless of where it resides
Whether CUI is on a federal network or a contractor’s laptop, its confidentiality must be protected to the same standard. SP 800-171 exists because the federal government’s ability to conduct its missions depends on information that lives outside federal boundaries. The publication ensures nonfederal organizations don’t become the weak link in the information supply chain.
What it covers — at a glance
14 FAMILIES (REV 2)
Access Control through System Integrity
The original 14 control families span technical controls (access, audit, encryption), operational controls (maintenance, media, incident response), and management controls (risk assessment, security assessment).
110 REQUIREMENTS (REV 2)
Basic & Derived requirements
Each family contains basic requirements (from FIPS 200) and derived requirements (from SP 800-53). Every requirement maps to one or more 800-53 controls in the moderate baseline.
320 ASSESSMENT OBJECTIVES
SP 800-171A verification
The companion assessment guide (SP 800-171A) breaks each requirement into determination statements — the specific checks an assessor uses to verify implementation. Rev 3 expands this to 422.
SPRS SCORE
Quantified compliance posture
The Supplier Performance Risk System score ranges from −203 to 110. A score of 110 means full implementation. Anything less requires a Plan of Action & Milestones (POA&M) for each gap.
NIST SP 800-171 · Chapter 1
Scope & Applicability
Who must implement, what’s in scope, and where the boundary falls
SP 800-171 applies to any nonfederal organization that processes, stores, or transmits CUI — or that provides protection for system components that do. This includes defense contractors, subcontractors, research universities, state and local governments, and any entity receiving CUI through a federal contract, grant, or agreement.
What triggers the requirement
DFARS
DFARS 252.204-7012
Defense Federal Acquisition Regulation Supplement clause. Requires DoD contractors to implement 800-171 on any system handling Covered Defense Information (CDI) — the DoD’s term for CUI. Non-negotiable for contract award.
FAR
FAR CUI clause (forthcoming)
The Federal Acquisition Regulation will extend 800-171 requirements to all federal agencies, not just DoD. When finalized, any contractor handling CUI for any agency will need compliance.
CMMC
CMMC Level 2 certification
Cybersecurity Maturity Model Certification Level 2 maps directly to SP 800-171. Third-party assessment (C3PAO) verifies implementation. Required for DoD contracts involving CUI.
Scoping the CUI boundary
In scope — CUI assets
Any system component that processes, stores, or transmits CUI. Includes servers, workstations, laptops, mobile devices, network infrastructure, cloud services, and applications that touch CUI data.
In scope — security protection assets
Components that provide security functions for CUI assets even if they don’t directly handle CUI — firewalls, SIEM, authentication servers, backup systems, and security monitoring tools.
Potentially in scope — contractor risk assets
Systems that can, but are not intended to, process CUI. If CUI could traverse these components, they must either be brought into scope or architecturally isolated.
Out of scope — isolated systems
Systems with no physical or logical connection to CUI processing. Must be genuinely isolated — not just segmented. Architectural evidence required.
Scope reduction through architectural isolation
Organizations can limit their compliance boundary by isolating CUI processing into a dedicated security domain — using subnetworks, firewalls, boundary protection devices, and information flow control. This is legitimate scope reduction, but the isolation must be provably enforced. A VLAN tag alone is not sufficient; the isolation must be architecturally defensible.
32 CFR Part 2002 · CUI Program
Controlled Unclassified Information
What CUI is, where it comes from, and why it requires protection
Controlled Unclassified Information (CUI) is information that the government creates or possesses — or that an entity creates or possesses for or on behalf of the government — that requires safeguarding or dissemination controls, but is not classified. It sits in the gap between publicly releasable information and classified national security information.
Common CUI categories in defense contracts
CTI
Controlled Technical Information
Technical data with military or space application, subject to distribution controls. Includes engineering drawings, specs, and technical manuals.
ITAR
Export-Controlled
Information subject to ITAR or EAR export control regulations. Overlaps heavily with CUI in defense manufacturing contexts.
PCII
Critical Infrastructure
Protected Critical Infrastructure Information related to vulnerability assessments, security plans, and operational details.
PII
Personally Identifiable
Personal information that, if disclosed, could result in harm. Social Security numbers, medical records, financial data of government personnel.
PROPIN
Proprietary Business
Contractor proprietary information provided to the government under contract, requiring protection from unauthorized disclosure.
FOUO
For Official Use Only
Legacy marking largely replaced by CUI. Still encountered in older documents. Treat as CUI for protection purposes.
CUI marking is the trigger — not classification
If your contract specifies CUI, DFARS 7012 applies, and SP 800-171 compliance is required. You don’t need to determine CUI categories yourself — the federal agency originating the information is responsible for marking it. Your job is to protect anything marked CUI (or CDI in DoD parlance) on your systems to the SP 800-171 standard.
Revision comparison
Rev 2 vs Rev 3
What changed, what it means, and which version applies today
NIST published the final version of SP 800-171 Revision 3 in May 2024. However, the DoD issued Class Deviation 2024-O0013 mandating that contractors continue using Revision 2 for DFARS 252.204-7012 compliance. All CMMC Level 2 assessments currently reference Rev 2’s 110 controls. Rev 3 adoption for DoD contractors is expected between late 2026 and early 2027.
Rev 2 — Current for CMMC
110 requirements · 14 families
Published: February 2020 (Updated January 2021)
Basic + Derived requirements — dual sourced from FIPS 200 and SP 800-53
320 assessment objectives in SP 800-171A
“Periodically” used throughout — ambiguous timing
NFO assumptions — 60+ controls assumed in place but not specified
SPRS scoring against these 110 controls
Rev 3 — Future state
97 requirements · 17 families
Published: May 14, 2024 (Final)
Single source — all requirements derived from SP 800-53 only
422 assessment objectives — 32% increase in verification depth
“Periodically” eliminated — specific frequencies required
NFO controls eliminated — if it’s required, it’s in the standard
49 ODPs — organization-defined parameters for flexibility
Key structural changes
| Attribute | Rev 2 | Rev 3 |
|---|---|---|
| Control families | 14 | 17 (+PL, SA, SR) |
| Requirements | 110 | 97 (but broader scope each) |
| Assessment objectives | 320 | 422 |
| 800-53 controls represented | ~110 | 156 |
| ODPs | None | 49 |
| NFO assumptions | 60+ | Eliminated |
| Basic vs Derived | Yes | Eliminated |
| Withdrawn controls | N/A | 33 (absorbed into others) |
Fewer requirements does not mean a lower bar
Rev 3’s reduction from 110 to 97 requirements is primarily consolidation, not relaxation. Many withdrawn controls are folded into broader requirements. The companion assessment guide’s jump from 320 to 422 determination statements tells the real story — the verification burden increased by 32%. Combined with 49 ODPs, the total number of items requiring documentation is approximately 510.
Family 3.1 · 22 Requirements
Access Control
The largest control family — governs who can access CUI, under what conditions, with what enforcement
Access Control is the foundation of CUI protection. Its 22 requirements address system access limitations, information flow control, separation of duties, least privilege, session management, and remote access. If an attacker can bypass access controls, no other family matters.
Key requirements
3.1.1
Limit system access to authorized users
Access to CUI systems must be limited to authorized users, processes acting on behalf of authorized users, and authorized devices (including other systems). This is the foundational gate — every other AC control builds on it.
3.1.2
Limit system access to authorized functions
Users receive only the transactions and functions they are authorized to execute. Role-based access control (RBAC) is the most common implementation, but attribute-based (ABAC) is increasingly adopted.
3.1.3
Control CUI flow
Control the flow of CUI in accordance with approved authorizations. Prevent CUI from flowing to unauthorized systems, users, or external networks. DLP, boundary protection, and network segmentation are typical controls.
3.1.5
Least privilege
Employ the principle of least privilege, including for specific security functions and privileged accounts. Users get the minimum access needed to perform their duties — no more.
3.1.12
Monitor and control remote access
Remote access sessions must be monitored and controlled. Encrypted tunnels (VPN/ZTNA), MFA, and session monitoring are required. Remote access is a primary attack vector.
3.1.22
Control CUI on publicly accessible systems
Control CUI posted or processed on publicly accessible systems. Prevent inadvertent disclosure of CUI through web servers, file shares, or collaboration platforms with public-facing components.
Access Control is where Zero Trust and 800-171 converge
Requirements 3.1.1 through 3.1.22 collectively establish the access model that Zero Trust Architecture (SP 800-207) operationalizes. No implicit trust from network location (3.1.14), least privilege (3.1.5), session control (3.1.10–11), and remote access monitoring (3.1.12) are ZTA tenets expressed as compliance requirements.
Family 3.2 · 3 Requirements
Awareness & Training
Ensuring personnel understand cybersecurity risks and their responsibilities for CUI protection
This family ensures that all users of CUI systems are aware of security risks and trained in their responsibilities. It covers general security awareness, role-based training for privileged users, and insider threat awareness. The human layer is often the weakest link — this family addresses it directly.
Requirements
3.2.1
Security awareness for all users
Ensure that managers, systems administrators, and users are made aware of the security risks associated with their activities and the applicable policies, standards, and procedures related to the security of CUI systems.
3.2.2
Role-based security training
Ensure personnel are trained to carry out their assigned information security-related duties and responsibilities. Privileged users and system administrators receive specialized training beyond general awareness.
3.2.3
Insider threat awareness
Provide security awareness training on recognizing and reporting potential indicators of insider threats. In Rev 3, this is absorbed into requirement 3.2.1 — it isn’t removed, just consolidated.
Family 3.3 · 9 Requirements
Audit & Accountability
Logging, monitoring, and retaining evidence of all CUI system activity
Audit and Accountability establishes the requirement to create, protect, retain, and review audit logs for all CUI system activity. Without audit trails, breaches cannot be detected, investigated, or attributed. This family provides the forensic foundation for incident response and the compliance evidence for assessments.
Key requirements
3.3.1
Create and retain audit logs
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
3.3.2
Individual user accountability
Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable. Shared accounts must not be used for CUI access.
3.3.5
Correlate audit records
Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity. SIEM integration is the typical implementation.
3.3.8
Protect audit information
Protect audit information and audit logging tools from unauthorized access, modification, and deletion. If an attacker can tamper with logs, accountability is destroyed.
Family 3.4 · 9 Requirements
Configuration Management
Maintaining secure, documented, and change-controlled system configurations
Configuration Management ensures that CUI systems are established, documented, and maintained in a known-secure state. Misconfigurations are one of the most common root causes of breaches. This family requires baseline configurations, change control, least-functionality principles, and restriction of unauthorized software.
Key requirements
3.4.1
Establish and maintain baselines
Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
3.4.2
Security configuration enforcement
Establish and enforce security configuration settings for IT products employed in organizational systems. CIS Benchmarks and DISA STIGs are common reference configurations.
3.4.6
Least functionality
Employ the principle of least functionality by configuring systems to provide only essential capabilities. Disable unused ports, protocols, services, and functions.
3.4.8
Application execution policies
Apply deny-by-exception (blacklisting) or allow-by-exception (whitelisting) policy to prevent the use of unauthorized software. Application whitelisting is the stronger control.
Family 3.5 · 11 Requirements
Identification & Authentication
Verifying the identity of users, devices, and processes before granting access to CUI
This family ensures that every entity accessing CUI systems is positively identified and authenticated before access is granted. It covers user identification, multi-factor authentication, password management, device authentication, and replay-resistant mechanisms. Identity is the first gate in the access decision chain.
Key requirements
3.5.1
Identify system users and processes
Identify information system users, processes acting on behalf of users, or devices. Every entity that touches CUI must have a unique identity that supports accountability.
3.5.2
Authenticate identities
Authenticate (or verify) the identities of those users, processes, or devices as a prerequisite to allowing access. Authentication must precede authorization — always.
3.5.3
Multi-factor authentication
Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. MFA is non-negotiable for CUI systems.
3.5.4
Replay-resistant authentication
Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts. Prevents credential replay attacks.
MFA is the single highest-impact control for CUI protection
Requirement 3.5.3 (multi-factor authentication) is consistently cited as the control most likely to prevent unauthorized CUI access. Password-only authentication does not meet the 800-171 standard for any CUI system. Hardware tokens, FIDO2/passkeys, and authenticator apps are all acceptable second factors — SMS is accepted but discouraged.
Family 3.6 · 3 Requirements
Incident Response
Detecting, analyzing, containing, and recovering from security incidents involving CUI
Incident Response ensures the organization has an operational capability to detect, report, and respond to security incidents. For DoD contractors, DFARS 7012 adds a 72-hour reporting requirement to the DoD Cyber Crime Center (DC3) for any cyber incident involving CUI. This family is where preparation meets operational reality.
Requirements
3.6.1
Establish incident handling capability
Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
3.6.2
Track, document, and report incidents
Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization. For DoD: report to DC3 within 72 hours of discovery.
3.6.3
Test incident response capability
Test the organizational incident response capability. Tabletop exercises, simulations, and red team engagements validate that the IR plan actually works under pressure.
DFARS 7012 adds teeth to incident response
Beyond the 800-171 requirements, DFARS 252.204-7012 mandates 72-hour reporting to DC3, preservation of forensic evidence for 90 days, and cooperation with DoD damage assessment activities. Failure to report can result in contract termination and False Claims Act liability. The IR plan must account for these DFARS-specific obligations.
Family 3.7 · 6 Requirements
Maintenance
Controlled maintenance of CUI systems — local and remote
This family governs how systems are maintained without introducing new vulnerabilities. It covers timely maintenance, tool control, remote maintenance security, and media sanitization for equipment removed for off-site maintenance. Maintenance windows are high-risk periods — elevated privileges, open access, external personnel.
Key requirements
3.7.1
Perform timely maintenance
Perform maintenance on organizational systems. Maintenance must be timely, documented, and performed by authorized personnel with appropriate access controls in place.
3.7.2
Control maintenance tools
Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance. Prevent introduction of malicious tools during maintenance operations.
3.7.5
Multifactor auth for remote maintenance
Require multifactor authentication to establish nonlocal maintenance sessions and terminate such sessions when maintenance is complete.
Family 3.8 · 9 Requirements
Media Protection
Safeguarding digital and physical media containing CUI throughout its lifecycle
Media Protection addresses how CUI is stored, transported, and destroyed on both digital and physical media. This includes access limitation, marking, storage, transport, sanitization, and disposal. A USB drive in a parking lot is a classic attack vector — this family prevents it.
Key requirements
3.8.1
Protect and control media
Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital. Access limited to authorized users.
3.8.3
Sanitize before disposal
Sanitize or destroy system media containing CUI before disposal or release for reuse. NIST SP 800-88 provides sanitization guidelines — degaussing, overwriting, or physical destruction.
3.8.6
Portable storage encryption
Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
Family 3.10 · 6 Requirements
Physical Protection
Securing facilities, equipment, and physical access to CUI processing environments
Physical Protection ensures that physical access to CUI systems is limited to authorized individuals and that the facilities themselves are monitored and secured. Cyber controls are meaningless if an attacker can walk up to a server and plug in. This family covers facility access, visitor management, and physical device security.
Key requirements
3.10.1
Limit physical access
Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
3.10.2
Protect physical facility
Protect and monitor the physical facility and support infrastructure for organizational systems. Includes surveillance, access logs, and environmental controls.
3.10.4
Maintain visitor audit logs
Maintain audit logs of physical access. Visitor logs must record name, organization, date/time, escort, and purpose of visit.
Family 3.9 · 2 Requirements
Personnel Security
Screening individuals and managing access upon personnel changes
Personnel Security focuses on the human element — ensuring that individuals with CUI access are screened before access is granted, and that access is promptly revoked upon termination or role change. It’s a small family (2 requirements), but the consequences of failure are significant.
Requirements
3.9.1
Screen individuals before access
Screen individuals prior to authorizing access to organizational systems containing CUI. Background checks, employment verification, and clearance validation as appropriate.
3.9.2
Protect CUI during personnel actions
Ensure that CUI and systems containing CUI are protected during and after personnel actions such as terminations and transfers. Disable access immediately upon termination. Retrieve all CUI-containing media.
Family 3.11 · 3 Requirements
Risk Assessment
Identifying, analyzing, and managing risk to CUI and organizational systems
Risk Assessment requires organizations to periodically assess the risk to CUI, scan for vulnerabilities, and remediate findings. It’s the analytical backbone that drives prioritization — without risk assessment, security investments are uninformed. This family links directly to the POA&M process and ongoing compliance maintenance.
Requirements
3.11.1
Assess risk periodically
Periodically assess the risk to organizational operations, organizational assets, and individuals resulting from the operation of CUI systems and the processing, storage, or transmission of CUI.
3.11.2
Scan for vulnerabilities
Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified. Qualys, Tenable, and Rapid7 are common tools.
3.11.3
Remediate vulnerabilities
Remediate vulnerabilities in accordance with risk assessments. Prioritize based on CVSS severity, exploitability, and asset criticality. Track remediation in the POA&M.
Family 3.12 · 4 Requirements
Security Assessment
Evaluating, monitoring, and documenting the effectiveness of security controls
Security Assessment is the meta-family — it governs how organizations assess whether their own controls are effective. It requires periodic evaluation of security controls, development of a System Security Plan, management of a Plan of Action and Milestones, and continuous monitoring. This is where self-assessment and CMMC intersect.
Requirements
3.12.1
Assess security controls periodically
Periodically assess the security controls in organizational systems to determine if the controls are effective in their application. The assessment produces the SPRS score for DoD contractors.
3.12.2
Develop and implement action plans
Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems. The POA&M is a living document — updated as gaps are identified and remediated.
3.12.3
Monitor security controls
Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls. Continuous monitoring, not annual checkbox exercises.
3.12.4
System Security Plan
Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and relationships with other systems.
Family 3.13 · 16 Requirements
System & Comms Protection
Network architecture, boundary protection, and cryptographic safeguards for CUI in transit and at rest
The second-largest family addresses the technical architecture that protects CUI during processing, storage, and transmission. It covers boundary protection, network segmentation, FIPS-validated encryption, session authenticity, DNS protection, and architectural isolation of security functions.
Key requirements
3.13.1
Monitor and protect communications at boundaries
Monitor, control, and protect communications at the external and key internal boundaries of organizational systems. Firewalls, proxies, IDS/IPS, and WAFs are typical implementations.
3.13.2
Architectural security designs
Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security. Defense in depth. Separation of concerns. Least privilege in code.
3.13.8
CUI encryption in transit
Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. TLS 1.2+ minimum. FIPS 140-2 validated modules.
3.13.11
FIPS-validated cryptography
Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. Non-FIPS crypto does not meet the standard regardless of algorithm strength.
3.13.16
CUI encryption at rest
Protect the confidentiality of CUI at rest. Full-disk encryption (BitLocker, FileVault) with FIPS-validated modules, or application-layer encryption for sensitive data stores.
FIPS 140-2 validation is a hard gate
Requirements 3.13.8 and 3.13.11 together mean that CUI must be protected by FIPS 140-2 (or 140-3) validated cryptographic modules — both in transit and at rest. Using AES-256 is not sufficient if the implementation isn’t FIPS-validated. This catches many organizations that rely on default TLS libraries without checking their FIPS validation status.
Family 3.14 · 7 Requirements
System & Info Integrity
Identifying flaws, monitoring for malicious activity, and responding to security alerts
System and Information Integrity ensures that CUI systems detect and respond to flaws, malicious code, and unauthorized changes. It covers vulnerability identification, malicious code protection, security alert monitoring, and system integrity verification. This is the operational detection family — the always-on sensor layer.
Key requirements
3.14.1
Identify and remediate flaws
Identify, report, and correct information and system flaws in a timely manner. Patch management, vulnerability scanning, and remediation tracking.
3.14.2
Malicious code protection
Provide protection from malicious code at designated locations within organizational systems. Endpoint detection and response (EDR), antivirus, and application control.
3.14.3
Monitor security alerts
Monitor system security alerts and advisories and take action in response. Subscribe to vendor alerts, CISA advisories, and CVE feeds. Actionable response, not just collection.
3.14.6
Monitor inbound and outbound traffic
Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks. Network-level detection — IDS/IPS, NDR, or SIEM correlation.
Rev 3 New Family · 3.15
Planning
New in Revision 3 — formalizes security planning and rules of behavior
The Planning family was elevated to its own control family in Rev 3 to align with SP 800-53. In Rev 2, planning requirements were embedded in Security Assessment (3.12.3, 3.12.4). Rev 3 formalizes system security planning, rules of behavior, and security architecture documentation as standalone, assessable requirements.
What it adds
PL
System security plan formalization
Elevates the SSP requirement to its own family. Requires explicit documentation of system boundaries, operational environments, security implementation details, and interconnections. Not new work for Rev 2 compliant organizations — but now independently assessed.
PL
Rules of behavior
Establish rules describing the responsibilities and expected behavior of individuals with access to CUI systems. Acceptable use policies, security responsibilities, and consequences for violations.
If you’re Rev 2 compliant, you’re mostly there
Organizations already maintaining an SSP and acceptable use policies under Rev 2 requirements 3.12.3 and 3.12.4 have the substance of the Planning family already in place. The primary change is that these become independently assessed controls rather than sub-elements of Security Assessment.
Rev 3 New Family · 3.16
System & Services Acquisition
New in Revision 3 — governs unsupported components and external service security
System and Services Acquisition was partially addressed in Rev 2 under System and Communications Protection (3.13.2 — security architecture). Rev 3 breaks it out into its own family to address end-of-life system components and external system services that process CUI.
Key additions
SA
Unsupported system components
Replace or provide compensating controls for system components that are no longer supported by the developer, vendor, or manufacturer. Windows 10 end-of-life, for example, triggers this requirement.
SA
External system services
Require providers of external system services to comply with applicable security requirements. Cloud services, managed security providers, and SaaS platforms processing CUI must meet the same standard — or be contractually bound to it.
Cloud and SaaS providers are now explicitly in scope
Rev 3’s SA family formalizes what was always implied: if a third-party service processes CUI on your behalf, that service must meet 800-171 requirements. FedRAMP Moderate authorization satisfies this for cloud services. For non-FedRAMP services, contractual obligations and security assessments are required.
Rev 3 New Family · 3.17
Supply Chain Risk Management
New in Revision 3 — the only truly new family, responding to supply chain attacks
Supply Chain Risk Management is the only genuinely new control family in Rev 3 — not reorganized from existing requirements, but created in response to supply chain attacks like SolarWinds, Kaseya, and Log4Shell. It requires organizations to develop SCRM plans, implement acquisition strategies that account for supply chain risk, and establish processes to identify and manage supply chain threats.
Key additions
SR
Supply chain risk management plan
Develop a plan for managing supply chain risks associated with the development, acquisition, maintenance, and disposal of systems, components, and services. Must address risk identification, assessment, mitigation, and monitoring.
SR
Acquisition strategies and tools
Develop and implement acquisition strategies, contract tools, and procurement methods to protect against supply chain risks. Vendor assessments, contractual security requirements, and provenance tracking.
SR
Supply chain requirements and processes
Establish processes to identify, assess, and manage supply chain threats throughout the system lifecycle. Software bill of materials (SBOM), vendor risk assessments, and continuous supplier monitoring.
SolarWinds made this family inevitable
The SolarWinds compromise demonstrated that a trusted vendor’s build pipeline can become the attack vector. Rev 2 had no explicit supply chain controls — organizations were expected to address this through risk assessment and configuration management. Rev 3’s SR family makes SCRM a first-class compliance requirement with its own assessment objectives.
CMMC 2.0 · Level 2
CMMC Alignment
How CMMC maps to SP 800-171 and what contractors need to know
The Cybersecurity Maturity Model Certification (CMMC) 2.0 is the DoD’s verification mechanism for SP 800-171 compliance. CMMC Level 2 maps one-to-one with SP 800-171 Rev 2’s 110 requirements. The critical difference is that CMMC adds third-party assessment — you’re no longer just self-attesting compliance, you’re being verified by a Certified Third-Party Assessment Organization (C3PAO).
CMMC 2.0 levels
🔒
Level 1 — Foundational
Self-assessment · 17 practices
Basic safeguarding of Federal Contract Information (FCI). 17 practices from FAR 52.204-21. Annual self-assessment submitted to SPRS. No CUI handling permitted at Level 1.
🛡️
Level 2 — Advanced
C3PAO assessment · 110 practices
Full SP 800-171 Rev 2 implementation. All 110 requirements across 14 control families. Third-party assessment by C3PAO every 3 years. Required for contracts involving CUI. This is where most defense contractors must operate.
⚔️
Level 3 — Expert
Government-led · 800-172
SP 800-171 plus selected SP 800-172 enhanced requirements. Government-led assessment (DIBCAC). Reserved for the most sensitive CUI — APT-level threat protection.
Assessment requirements
All 110 controls must be assessed
The C3PAO evaluates every requirement against SP 800-171A’s 320 assessment objectives. Each objective receives a Met, Not Met, or Not Applicable determination.
POA&Ms permitted with limits
Some unmet requirements can be documented in a POA&M with a 180-day remediation window. However, certain requirements are POA&M-ineligible — they must be fully implemented at time of assessment.
No certification without minimum threshold
If the number or severity of unmet requirements exceeds the threshold, the assessment fails. Conditional certification is available only if all remaining gaps are POA&M-eligible.
CMMC uses Rev 2 until further notice
Despite Rev 3’s release in May 2024, DoD Class Deviation 2024-O0013 mandates that CMMC Level 2 continues to reference Rev 2. Do not shift resources to Rev 3 compliance at the expense of Rev 2. Understand Rev 3 changes for future planning, but assess against Rev 2 today.
DFARS 252.204-7019 · SPRS
SPRS Scoring
The Supplier Performance Risk System score — quantified compliance from −203 to 110
The SPRS score is a numerical representation of an organization’s SP 800-171 compliance posture. It ranges from −203 (no controls implemented) to 110 (full implementation). The score must be submitted to the SPRS portal and is visible to DoD contracting officers. It directly affects contract award decisions.
How the score works
| Score | Meaning | Implication |
|---|---|---|
| 110 | All 110 controls implemented | Full compliance. No POA&M required. |
| 80–109 | Most controls met, minor gaps | Generally competitive. POA&M documents gaps with remediation timeline. |
| 50–79 | Significant gaps remain | At risk for contract award. Aggressive POA&M remediation required. |
| Below 50 | Major compliance deficiencies | Unlikely to win CUI-handling contracts. Fundamental security program gaps. |
| −203 | No controls implemented | Theoretical floor. All 110 requirements scored as Not Met. |
Each unmet requirement is assigned a weighted point value (1, 3, or 5 points) based on its security impact. The total points for unmet requirements are subtracted from 110. Critical controls like MFA (3.5.3), encryption (3.13.11), and audit logging (3.3.1) carry higher weight — failing these drops the score faster.
Your SPRS score is visible to contracting officers
The score is not confidential. Contracting officers can and do check SPRS scores before awarding contracts. A low score can disqualify an otherwise competitive bid. More critically, submitting an inflated score constitutes a False Claims Act violation — the DoJ has already pursued enforcement actions against contractors who misrepresented their compliance posture.
Requirements 3.12.2 · 3.12.4
SSP & POA&M
The two foundational compliance documents every CUI-handling organization must maintain
The System Security Plan (SSP) and Plan of Action & Milestones (POA&M) are the two documents that define and track your compliance posture. The SSP describes how each requirement is implemented. The POA&M documents gaps and the remediation timeline. Together, they produce the SPRS score and serve as the primary evidence artifacts for CMMC assessment.
System Security Plan
How you implement each control
System boundary definition — what’s in scope and what’s out
Environment of operation — physical, logical, and organizational context
Control implementation — how each of the 110 requirements is satisfied
System interconnections — data flows to/from other systems
Living document — updated when systems, controls, or scope change
Plan of Action & Milestones
What’s not yet implemented
Unmet requirements — each gap documented with root cause
Remediation plan — specific actions, resources, and timeline
Milestone tracking — progress checkpoints with responsible parties
Risk acceptance — interim risk documented for each open item
CMMC constraint — 180-day maximum for POA&M closure
The SSP is your compliance evidence — not the policies binder
A common mistake is treating the SSP as a copy-paste of policies and standards. The SSP must describe how each control is actually implemented in your specific environment — not what the policy says should happen, but what happens in practice. Assessors verify the SSP against operational reality. Discrepancies between the SSP and the implemented environment are assessment findings.
Source document
NIST SP 800-171
Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
About this document
NIST Special Publication 800-171 provides federal agencies with recommended security requirements for protecting the confidentiality of CUI when the information is resident in nonfederal systems and organizations. Rev 2 (January 2021) contains 110 requirements across 14 control families and remains the current standard for CMMC Level 2. Rev 3 (May 2024) restructures to 97 requirements across 17 families with increased assessment specificity.
↗ SP 800-171 Rev 2 PDF (current for CMMC)
↗ SP 800-171 Rev 3 PDF (future state)
↗ NIST CSRC publication page
↗ NIST FAQ: Rev 3 Changes
Rev 2 citation: Ross, R., Pillitteri, V., Dempsey, K., Riddle, M., & Guissanie, G. (2020). Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations (NIST Special Publication 800-171 Revision 2). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-171r2
Rev 3 citation: Ross, R., Pillitteri, V., & Dempsey, K. (2024). Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations (NIST Special Publication 800-171 Revision 3). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-171r3