NIST 800-171. Protecting CUI. Proven Continuously.

NIST Special Publication 800-171, "Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations," defines 110 security requirements that nonfederal organizations must implement when they process, store, or transmit Controlled Unclassified Information (CUI). Published by the National Institute of Standards and Technology, the standard exists because CUI routinely flows beyond federal boundaries into contractor networks, university research environments, and commercial supply chains. The federal government cannot directly mandate how nonfederal organizations configure their infrastructure. NIST 800-171 bridges that gap by specifying the minimum security posture required to protect CUI outside federal systems. DFARS clause 252.204-7012, "Safeguarding Covered Defense Information and Cyber Incident Reporting," makes NIST 800-171 compliance a contractual obligation for every defense contractor and subcontractor handling CUI. This clause has been in effect since December 2017. Organizations that accepted contracts with this clause committed to implementing all 110 security requirements. The requirements are not recommendations. They are contractual obligations with legal consequences for noncompliance.

NIST 800-171 Revision 2 contains 110 security requirements organized into 14 families. It is the version currently referenced by DFARS 252.204-7012 and the version that CMMC Level 2 maps to directly. Revision 3, published in May 2024, reorganizes the requirements to align more closely with NIST 800-53 rev5. Rev3 adds new requirements, consolidates others, and restructures the family organization. The transition from Rev2 to Rev3 has significant implications for organizations that have already built their compliance programs around the Rev2 structure. CMMC currently maps to Rev2, meaning organizations pursuing CMMC Level 2 certification must implement the Rev2 requirements regardless of Rev3 availability. However, organizations building new compliance programs should understand both versions, because Rev3 will eventually become the authoritative baseline. The structural differences between revisions are not cosmetic. Requirements that existed as single items in Rev2 may be decomposed into multiple requirements in Rev3, and new requirement areas that Rev2 did not address appear in Rev3 for the first time.

The 14 requirement families in Rev2 cover the full spectrum of security controls. Access Control (3.1) contains 22 requirements, the largest family, covering user authentication, session management, remote access, wireless access, and mobile devices. Awareness and Training (3.2) contains 3 requirements for security literacy and role-based training. Audit and Accountability (3.3) contains 9 requirements for logging, retention, and audit review. Configuration Management (3.4) contains 9 requirements for baselines, change control, and least functionality. Identification and Authentication (3.5) contains 11 requirements for identity verification and credential management. Incident Response (3.6) contains 3 requirements for detection, reporting, and recovery. Maintenance (3.7) contains 6 requirements for system maintenance controls. Media Protection (3.8) contains 9 requirements for CUI storage, transport, and sanitization. Personnel Security (3.9) contains 2 requirements for screening and termination. Physical Protection (3.10) contains 6 requirements for facility access and monitoring. Risk Assessment (3.11) contains 3 requirements for vulnerability scanning and risk evaluation. Security Assessment (3.12) contains 4 requirements for periodic assessment and system connections. System and Communications Protection (3.13) contains 16 requirements for boundary protection, encryption, and network segmentation. System and Information Integrity (3.14) contains 7 requirements for flaw remediation, malicious code protection, and monitoring.

DFARS 252.204-7012 required NIST 800-171 compliance beginning in December 2017. The enforcement mechanism was self-attestation: contractors evaluated their own implementation status and reported it to the Department of Defense. There was no third-party verification. There was no standard scoring methodology until SPRS was introduced in 2020. There was no mechanism for the government to confirm that a contractor's reported compliance status matched reality. The result was predictable. Many contractors self-reported compliance without implementing the required controls. Some completed cursory assessments, checking boxes against the 110 requirements without examining whether the controls were actually operating in their environments. Others submitted compliance claims without performing any assessment at all. The gap between reported and actual security posture across the Defense Industrial Base became a national security concern. CUI was flowing through contractor networks that lacked the protections the government required, while official records indicated those protections were in place.

The Supplier Performance Risk System (SPRS) was introduced to bring some quantitative rigor to self-assessment. Organizations now compute a score between -203 and 110 based on weighted deductions for unimplemented requirements. This score is posted to the SPRS portal and referenced during source selection. But the fundamental problem persists: the score is still self-reported. Organizations calculate their own score, determine their own implementation status for each requirement, and submit without external validation. The gap between reported and actual posture remains invisible until someone examines it. Some organizations report scores in the high 90s while their environments lack basic controls like multi-factor authentication, encrypted CUI storage, or centralized audit logging. The score on the portal says one thing. The infrastructure says another. CMMC was created specifically to close this gap by adding third-party verification, but until CMMC Phase 2 enforcement begins, self-attestation remains the primary mechanism. Organizations that report accurately are competing against organizations that do not.

The legal consequences of inaccurate reporting have sharpened dramatically. The Department of Justice Civil Cyber-Fraud Initiative, launched in October 2021, explicitly targets cybersecurity misrepresentation in government contracting. The False Claims Act provides the enforcement mechanism: organizations that submit inaccurate SPRS scores or claim NIST 800-171 compliance without implementing the required controls face qui tam lawsuits (whistleblower-initiated actions on behalf of the government), treble damages, per-claim fines, and potential debarment from government contracting. Multiple enforcement actions have already been filed. A former employee, a subcontractor, or a competitor who knows that an organization's reported compliance status is inaccurate can initiate legal proceedings. The financial exposure is not theoretical. Organizations that reported a score of 95 while their actual posture warrants a score of 30 face liability calculated as three times the government's loss on every affected contract. Beyond financial penalties, debarment removes the organization from government contracting entirely. The era of consequence-free self-attestation is ending.

NIST 800-171A, "Assessing Security Requirements for Controlled Unclassified Information," defines the assessment procedures for each of the 110 requirements. Each requirement has specific assessment objectives that decompose the requirement into testable components. Requirement 3.1.1 (Limit information system access to authorized users) contains multiple assessment objectives: determine if authorized users are identified, determine if processes acting on behalf of authorized users are identified, determine if devices authorized to connect are identified, and determine if system access is limited to those authorized entities. A thorough self-assessment evaluates each objective independently. Marking a requirement as "implemented" without evaluating every objective produces an incomplete assessment. The assessment must examine three evidence types for each requirement: documentation (policies, procedures, system security plans), mechanisms (technical controls, configurations, automated enforcement), and activities (operational processes, reviews, training). Requirements that rely solely on documentation without supporting technical mechanisms or operational activities are not fully implemented.

Self-assessment accuracy suffers from three systemic challenges. Optimism bias is the most pervasive: teams familiar with their own environment consistently overestimate implementation completeness. A requirement marked "implemented" often means "we started implementing this" or "we have a policy that addresses this" rather than "all assessment objectives for this requirement are satisfied with verifiable evidence across documentation, mechanisms, and activities." The distinction between implemented and partially implemented is where most self-assessments diverge from reality. Requirement 3.5.3 (multi-factor authentication) might be enforced for VPN access but not for privileged local accounts. Requirement 3.3.1 (system auditing) might generate logs for production systems but miss development environments that also process CUI. Each partial implementation inflates the self-assessed score beyond what a C3PAO would validate. Incomplete evidence is the second challenge: organizations can describe what they do but cannot produce the artifacts that prove it. Configuration baselines exist in engineers' knowledge but not in documented, version-controlled form. Access reviews happen informally but lack the recorded approvals that satisfy assessment objectives. The third challenge is distinguishing between controls that are designed and controls that are operating. A firewall rule that was configured correctly at deployment but has since accumulated exceptions is designed but not operating as intended. A self-assessment that does not test current operational state captures design intent, not security posture.

Artificer guides the self-assessment process by asking targeted questions for each requirement. Rather than presenting a blank form for 110 requirements and expecting your team to know what to evaluate, Artificer adapts its questions based on what Sentinel has already discovered about your environment. If Sentinel has detected that your infrastructure uses centralized identity management with MFA enforced at the provider level, Artificer focuses its questions for Identification and Authentication requirements on the specific configurations observed, not on whether MFA exists at all. For requirements that involve policy and procedure (Personnel Security, Awareness and Training, Incident Response), Artificer asks about organizational practices and generates assessment findings from the responses. For requirements that involve technical controls, Artificer correlates your answers with observed infrastructure state. When a discrepancy surfaces between what the team reports and what the infrastructure shows, the platform flags it for resolution. The result is an assessment that reflects actual posture, not aspirational compliance.

The Supplier Performance Risk System score quantifies your NIST 800-171 implementation status as a single number between -203 and 110. A score of 110 indicates full implementation of all 110 security requirements. Each unimplemented requirement carries a weighted deduction based on the security significance of the gap. The DoD Assessment Methodology assigns point values of 1, 3, or 5 to each requirement based on its contribution to CUI protection. Not all requirements carry equal weight. Failures in Access Control (3.1) and System and Communications Protection (3.13) carry larger deductions than failures in Awareness and Training (3.2) or Personnel Security (3.9). A single unimplemented requirement with a 5-point deduction has the same score impact as five unimplemented 1-point requirements. This weighting reflects the security reality: a missing encryption control creates more risk than a missing training record. The score is required for DFARS 252.204-7012 reporting, posted to the SPRS portal, and referenced during source selection. Some contracting officers now specify minimum SPRS score thresholds in solicitations.

Reporting an inaccurate SPRS score is not a compliance oversight. It is a legal liability with specific enforcement precedent. The score must reflect the organization's current implementation status, not its target state or its planned posture after remediation. Every requirement marked as implemented must be demonstrably implemented with verifiable evidence. Every unimplemented requirement must be accurately reported with a corresponding Plan of Action and Milestones. The Department of Justice has made cybersecurity fraud in government contracting an explicit enforcement priority through the Civil Cyber-Fraud Initiative. The False Claims Act provides qui tam (whistleblower) provisions, meaning any current or former employee, subcontractor, or competitor can initiate legal action. Penalties include treble damages, per-claim fines, and debarment. An organization that reports a score of 90 when its actual implementation warrants a score of 40 faces material legal exposure on every contract where that score was referenced. The SPRS score is not a marketing number. It is a legal representation of security posture.

Artificer computes your SPRS score from live assessment data in Rampart. The score updates continuously as requirements are assessed, remediated, or regressed. Artificer applies the DoD weighting methodology to each requirement, incorporating the point value assigned by the Assessment Methodology and the specific deduction for each unimplemented control. The platform identifies which requirements drive the largest deductions and which remediations deliver the greatest score improvement per unit of effort. When your team closes a gap, the score reflects it immediately. When infrastructure drifts and a previously satisfied requirement degrades because a configuration changed or an evidence artifact expired, the score reflects that degradation too. You always know your current number, your trajectory over time, and exactly which requirements to address for maximum score improvement. The delta between your current score and your target score is decomposed into a prioritized remediation list that maps directly to the action queue in Citadel. No manual spreadsheet. No point-in-time calculation that goes stale before you submit it to the SPRS portal.

For every requirement scored as not implemented, the organization must develop a Plan of Action and Milestones (POA&M) that documents the gap, the remediation plan, the responsible party, required resources, and the target closure date. POA&Ms are not optional documentation. DFARS 252.204-7012 requires that the SPRS score submission include both the current implementation status and the POA&M for every unimplemented requirement. The POA&M must be specific and actionable. "Implement multi-factor authentication" is not a plan. A plan identifies which systems require MFA, which identity provider will enforce it, what credential types will be supported, what the implementation timeline is, who is responsible for each phase, what testing will verify the control is operating correctly, and when the requirement will be marked as implemented with supporting evidence. Vague POA&Ms signal that the organization does not understand the gap well enough to close it. They also create risk during audits, because an assessor who reviews a POA&M and finds no specific remediation steps will question whether the organization intends to close the gap at all.

Effective POA&Ms distinguish organizations that are genuinely remediating from organizations that are using documentation to defer action indefinitely. The difference is measurable. Effective POA&Ms have defined technical steps that match the specific requirement's assessment objectives. They have resource allocation: budget for infrastructure changes, personnel time for policy development, training schedules for awareness requirements. They have milestone dates that reflect realistic implementation timelines, not aspirational targets that slip quarter after quarter. They have dependency chains: requirement 3.4.1 (baseline configuration) must be satisfied before requirement 3.14.6 (monitoring for unauthorized changes) can be fully implemented. Performative POA&Ms, by contrast, contain generic remediation language, no resource commitments, no milestone tracking, and target dates that have been extended multiple times. An assessor reviewing POA&Ms during a CMMC assessment or a DoD audit will evaluate whether the plans represent genuine remediation intent or administrative compliance theater.

Rampart tracks every POA&M item with full lifecycle visibility. Each item displays the specific requirement it addresses, the current remediation status, the assigned owner, linked evidence showing progress, milestone dates, and days remaining until the target closure date. When a POA&M involves infrastructure changes, Sentinel monitors the affected resources and detects when changes are deployed. Rampart re-evaluates the requirement's assessment status as new evidence arrives. Artificer flags items approaching their deadline without sufficient progress, calculating the gap between current status and required completion. Escalation triggers fire at configurable intervals: 30 days remaining, 14 days, 7 days. The escalation path follows the organization's notification chain. POA&M items do not age silently into expiration. When remediation is complete and evidence confirms the control is operating, Rampart updates the requirement status, recalculates the SPRS score, and archives the closed POA&M with its full remediation history for audit trail purposes.

Remediation spans four categories: infrastructure changes, policy development, procedure implementation, and personnel training. Infrastructure changes address technical requirements: deploying encryption for CUI at rest and in transit, configuring centralized audit logging with tamper-evident storage, implementing network segmentation between CUI and non-CUI environments, enforcing session timeouts, and hardening baseline configurations. Policy development addresses organizational requirements: documenting access control policies, incident response procedures, media protection protocols, and maintenance authorization processes. Procedure implementation operationalizes those policies: establishing access review cadences, conducting vulnerability scans at defined intervals, performing configuration audits against baselines, and executing incident response exercises. Training addresses the human element: security awareness for all users with CUI access and role-based training for administrators, incident responders, and system owners. Effective remediation addresses all four categories in parallel because they are interdependent. A technical control without a supporting policy lacks organizational authority. A policy without a technical mechanism lacks enforcement. A procedure without trained personnel lacks execution capability.

Remediation stalls when organizations lack a systematic method for prioritizing across competing demands. Not all gaps carry equal SPRS weight, but remediation effort does not correlate with point value. A 5-point requirement affecting encryption (3.13.11) may require infrastructure changes across every system that stores CUI, while a 1-point requirement affecting personnel screening (3.9.2) may require only a policy update and HR process change. Dependency chains create sequencing constraints that teams discover mid-execution: you cannot implement continuous monitoring (3.14.6) without first establishing baseline configurations (3.4.1), and you cannot enforce least privilege (3.1.5) without first defining authorized access levels (3.1.1). Teams that remediate requirements in isolation discover these dependencies after investing effort in controls that cannot operate without their prerequisites. Resource constraints force tradeoffs between infrastructure changes and policy development. Engineering teams are pulled between remediation tasks and operational work. Security staff split time between writing policies, conducting training, and validating technical implementations. Without clear sequencing that accounts for dependencies, SPRS point values, and cross-requirement synergies, remediation degrades into a scattered effort where high-effort, low-impact tasks consume cycles that should target the gaps driving the largest score deductions.

Armory provides hardened Terraform modules that satisfy NIST 800-171 requirements from the first deployment. An encryption module that satisfies requirement 3.13.11 (CUI encryption) by configuring storage-level and transit-level encryption with key management policies that meet NIST specifications. A logging module that satisfies requirement 3.3.1 (system auditing) by deploying centralized log collection with tamper-evident storage, retention policies, and alerting on audit processing failures. A network segmentation module that satisfies requirement 3.13.1 (boundary protection) by establishing network boundaries between CUI and non-CUI segments with enforced traffic inspection and deny-by-default ingress rules. These are deployable infrastructure code with STIG parameters and CIS benchmark configurations built in. Deploy the module, and the requirement is satisfied by design. The infrastructure IS the evidence. Sentinel monitors every remediation action and re-evaluates affected requirements as changes take effect. For certain infrastructure drift scenarios, Sentinel can auto-remediate after approval: if a storage volume loses its encryption configuration, Sentinel detects the drift and restores the compliant state within your defined change windows. Each closed gap updates your SPRS score and your readiness posture across all mapped frameworks in real time.

CMMC Level 2 maps directly to NIST 800-171 rev2. The 110 CMMC Level 2 practices ARE the 110 NIST 800-171 security requirements, reorganized into CMMC's domain and practice structure. This is not an alignment or an approximation. It is a structural identity. CMMC practice AC.L2-3.1.1 IS NIST 800-171 requirement 3.1.1. Every practice in every CMMC Level 2 domain traces to a specific 800-171 requirement with a deterministic, auditable mapping published by the DoD. An organization that has fully implemented NIST 800-171 has, by definition, satisfied all 110 CMMC Level 2 practices. The security posture is identical. The difference is verification: NIST 800-171 compliance under DFARS is self-attested, while CMMC Level 2 requires third-party assessment by a C3PAO accredited through the Cyber AB. The work is the same. The evidence is the same. The controls are the same. CMMC adds an independent verification layer on top of what DFARS already requires.

Moving from NIST 800-171 self-assessment to CMMC Level 2 certification requires additional preparation beyond control implementation. The organization must define and document a formal assessment boundary that identifies every system, environment, and data flow that handles CUI. A System Security Plan (SSP) must describe the system, its authorization boundary, the implemented controls, and the operational environment in sufficient detail for a C3PAO to evaluate. Practice narratives must explain how each requirement is satisfied with specific references to infrastructure components, configurations, policies, and procedures. Evidence must be organized by practice family and cross-referenced to each narrative. Personnel must be prepared for interviews covering their respective control families. Operational processes must be documented for observation. The C3PAO assesses not just whether controls exist, but whether they are operating effectively as described. None of this preparation requires new security controls. It requires structuring the documentation and evidence that already supports your NIST 800-171 implementation into an assessment-ready package.

Every assessment action taken in Rampart for NIST 800-171 maps directly to the corresponding CMMC Level 2 practice. When you assess requirement 3.1.1 in the 800-171 workspace, Rampart simultaneously updates the status of CMMC practice AC.L2-3.1.1. Evidence collected for one framework satisfies both. Narratives generated by Artificer for 800-171 requirements are reusable for CMMC practice descriptions with practice-specific formatting applied automatically. POA&M items tracked against 800-171 requirements carry over to the CMMC assessment context. When you activate a CMMC Level 2 assessment in Rampart, it arrives pre-populated from your 800-171 work. The additional preparation for C3PAO engagement (boundary documentation, evidence package assembly, practice narrative formatting, Alliance assessor access configuration) builds on top of the foundation you have already constructed. Organizations that maintain accurate NIST 800-171 compliance through the platform are perpetually CMMC Level 2 ready. The certification engagement becomes a verification exercise, not a preparation scramble.

DFARS clause 252.204-7012, "Safeguarding Covered Defense Information and Cyber Incident Reporting," imposes three primary obligations on defense contractors. First, adequate security: the contractor must provide adequate security on all covered contractor information systems. For systems that process, store, or transmit CUI, adequate security means implementing all 110 NIST 800-171 security requirements. The standard is not aspirational. The clause states that the contractor "shall implement" the requirements, not that it should pursue them or work toward them. Second, cyber incident reporting: within 72 hours of discovering a cyber incident that affects covered contractor information systems or CUI, the contractor must report to the DoD through DIBNet (the Defense Industrial Base Cybersecurity portal). The report must include the affected systems, the CUI involved, a description of the compromise, and the methodology used. This 72-hour clock starts at discovery, not at the completion of investigation. Third, flow-down: the clause must be included in all subcontracts where CUI will be processed, stored, or transmitted. The prime contractor is responsible for ensuring subcontractor compliance.

The 72-hour incident reporting requirement is operationally demanding and legally consequential. Discovery of a cyber incident triggers a clock that allows no time for deliberation about whether the incident qualifies. Organizations must have incident detection capabilities that identify qualifying events, triage processes that escalate to authorized reporters, and reporting procedures that generate the required DIBNet submission within the 72-hour window. The report must include specific technical details: malware samples, network logs, forensic images of affected systems, and an assessment of the CUI potentially compromised. Failure to report within the required timeframe is itself a DFARS violation, independent of the underlying incident. Organizations that lack the monitoring infrastructure to detect incidents in real time cannot meet the 72-hour reporting requirement because their discovery timeline extends well beyond the reporting window. The clause effectively mandates continuous monitoring even though it does not use those words, because without it, the incident reporting obligation cannot be fulfilled.

Flow-down creates supply chain compliance obligations that extend beyond the prime contractor's own systems. Every subcontractor that handles CUI must also implement NIST 800-171 and accept the DFARS 252.204-7012 clause. The prime contractor bears responsibility for ensuring that flow-down occurs and that subcontractors maintain adequate security. In practice, many prime contractors have limited visibility into their subcontractors' security posture. They rely on contractual representations without verification. Alliance addresses this gap by establishing trust networks between organizations. A prime contractor can invite subcontractors to share their NIST 800-171 compliance status through Alliance, providing read-only visibility into assessment scores, POA&M status, and evidence coverage without exposing the subcontractor's internal infrastructure details. Subcontractors maintain control over what they share. The prime contractor gains the supply chain visibility that DFARS requires. When a subcontractor's posture degrades, the prime contractor is notified through Alliance before that degradation becomes a contractual liability on the prime's reporting obligations.

NIST 800-171 derives from the NIST 800-53 Moderate baseline. Each of the 110 security requirements traces to one or more specific 800-53 controls through a published mapping in NIST SP 800-171A. This derivation chain means that work done for NIST 800-171 simultaneously satisfies controls in every framework that traces back to the same NIST lineage. CMMC Level 2 is the same 110 requirements in a different organizational structure. FedRAMP baselines (Low, Moderate, High, LI-SaaS) are specific control selections from the same NIST 800-53 catalog, meaning substantial overlap with 800-171's parent controls. SOC 2 Trust Service Criteria map to 800-53 control families through published cross-walks maintained by the AICPA. ISO 27001:2022 Annex A controls have NIST-published mappings to 800-53 through the NIST Cybersecurity Framework. These relationships are deterministic and auditable. The investment in NIST 800-171 compliance is not a single-use expenditure. It compounds across your entire compliance portfolio.

A concrete example demonstrates how the derivation chain works. NIST 800-171 requirement 3.1.1 (Limit information system access to authorized users, processes acting on behalf of authorized users, and devices) derives from NIST 800-53 control AC-2 (Account Management). In CMMC Level 2, this same requirement appears as practice AC.L2-3.1.1 with identical assessment objectives. In FedRAMP Moderate, AC-2 applies with FedRAMP-specific parameter requirements for account review frequency, automated enforcement mechanisms, and evidence collection intervals. In SOC 2, the same underlying capability maps to CC6.1 (Logical and Physical Access Controls) under the Common Criteria. In ISO 27001:2022, it maps to A.8.2 (Privileged Access Rights) in Annex A. One 800-171 requirement assessed. One set of defenses implemented. One evidence chain collected. Five frameworks advanced. The derivation chain is deterministic and auditable at every link: from the 800-171 requirement to the 800-53 control to the target framework's specific criterion. No interpretation required. Structural derivation.

Rampart maintains the cross-reference engine that resolves these derivation chains through five strategies: native control mapping (direct requirement-to-requirement relationships published by the framework authority), NIST 800-53 derivation chain tracing (following the path from any framework back through 800-53 to any other framework that derives from it), NIST CSF 2.0 bridging (using the Cybersecurity Framework's function/category/subcategory structure as an intermediary between frameworks that lack direct mappings), published cross-walks from authoritative sources (AICPA for SOC 2, ISO for 27001, NIST for all NIST publications), and AI-suggested mappings that require human confirmation before activation. As you satisfy NIST 800-171 requirements, Rampart computes your readiness percentage for every other framework in the catalog. The computation resolves each individual control relationship through the derivation chain and accounts for framework-specific parameter differences. When you activate a new framework assessment, it arrives pre-populated from your existing 800-171 work. The marginal effort to add each subsequent framework decreases because the control overlap compounds through the derivation chain. One security posture. Every framework computed.