NIST Special Publication 800-171 specifies security requirements for protecting the confidentiality of Controlled Unclassified Information (CUI) when it resides in non-federal systems and organisations. It is the backbone of CMMC Level 2 and is contractually required of US government (especially Department of Defense) contractors and their supply chains via DFARS clause 252.204-7012. This is a practical implementation and assessment guide; it does not reproduce NIST’s copyrighted publication.
Version note
This guide reflects the widely-implemented Revision 2 structure (110 requirements across 14 families). Revision 3 reorganises the families and requirement count; contractors should confirm the version their contract cites. The assessment discipline below applies to both.
What 800-171 protects
The single objective of 800-171 is protecting the confidentiality of CUI in non-federal systems. Everything — scope, controls, scoring — flows from where CUI lives and moves. Getting the CUI boundary right, then reducing it, is the most important first step.
| Term | Meaning |
|---|
| FCI | Federal Contract Information — information provided by or generated for the government under a contract, not intended for public release (basic safeguarding, CMMC Level 1). |
| CUI | Controlled Unclassified Information — government information requiring safeguarding under law/regulation/policy; the focus of 800-171 (CMMC Level 2). |
| CUI environment | Every system, network, application, person and process that stores, processes or transmits CUI, plus anything that provides security protection to it. |
| Flowdown | The obligation to pass 800-171 requirements to subcontractors that will also handle CUI. |
Who must comply
- US Department of Defense contractors and subcontractors handling CUI (via DFARS 252.204-7012 and the CMMC programme).
- Other federal agency contractors handling CUI (via FAR clauses).
- Any organisation in a defense/federal supply chain that receives CUI flowdown — including non-US suppliers to US primes.
- Managed service providers and cloud providers that store or protect a contractor’s CUI.
The 14 requirement families
| Family | Requirements | Focus |
|---|
| 3.1 Access Control | 22 | Who and what can access CUI and how access is limited |
| 3.2 Awareness & Training | 3 | Security awareness and role-based training |
| 3.3 Audit & Accountability | 9 | Logging, review and traceability of actions |
| 3.4 Configuration Management | 9 | Baselines, change control and least functionality |
| 3.5 Identification & Authentication | 11 | Unique IDs, MFA and authenticator management |
| 3.6 Incident Response | 3 | Detect, report and respond to incidents |
| 3.7 Maintenance | 6 | Controlled system maintenance |
| 3.8 Media Protection | 9 | Protecting, sanitising and controlling media |
| 3.9 Personnel Security | 2 | Screening and protecting CUI during personnel actions |
| 3.10 Physical Protection | 6 | Physical access and facility controls |
| 3.11 Risk Assessment | 3 | Risk assessment and vulnerability scanning |
| 3.12 Security Assessment | 4 | Assess controls, build the SSP and POA&M |
| 3.13 System & Communications Protection | 16 | Boundary protection, encryption and segmentation |
| 3.14 System & Information Integrity | 7 | Flaw remediation, malware and monitoring |
Master assessment checklist
For each family, assess whether the requirements are implemented, and gather the evidence an assessor (self, DoD or a C3PAO) will expect.
3.1 Access Control (22)
| What to verify | Typical evidence |
|---|
| Access is limited to authorised users, processes and devices; least privilege and separation of duties are enforced. | Access-control policy, role definitions, access-request/approval records |
| CUI flow is controlled; remote access is authorised, monitored and encrypted; wireless and mobile access is controlled. | Network/data-flow diagrams, remote-access (VPN) config, wireless policy |
| Privileged accounts and functions are limited and logged; sessions lock after inactivity; failed logon attempts are limited. | Privileged-account inventory, session-lock config, logon-attempt settings |
| Publicly accessible systems do not contain CUI; external connections and portable storage on external systems are controlled. | System inventory, external-connection agreements, portable-media policy |
3.2 Awareness & Training (3)
| What to verify | Typical evidence |
|---|
| Users, managers and admins are made aware of security risks and their responsibilities. | Awareness-training content and completion records |
| Personnel are trained to carry out their assigned security duties, including insider-threat awareness. | Role-based training records, insider-threat briefing |
3.3 Audit & Accountability (9)
| What to verify | Typical evidence |
|---|
| Audit logs capture the events needed to trace actions to individual users; content is defined and adequate. | Logging policy, defined audit events, sample logs |
| Logs are reviewed/analysed, protected from deletion, time-synchronised and retained; failures alert responsible staff. | SIEM/review records, NTP config, retention setting, alerting config |
3.4 Configuration Management (9)
| What to verify | Typical evidence |
|---|
| Baseline configurations and inventories are established and maintained; changes are controlled and analysed for security impact. | Baselines, CMDB/inventory, change tickets with approvals |
| Least functionality is enforced; nonessential programs/ports/services are disabled; software execution is controlled (allow-listing). | Hardening standards (e.g., CIS/DISA STIG), allow-list config, port/service list |
3.5 Identification & Authentication (11)
| What to verify | Typical evidence |
|---|
| Users, processes and devices are uniquely identified; MFA is enforced for privileged accounts and network access. | Identity store, MFA configuration and coverage |
| Authenticators are managed (complexity, reuse, encrypted storage/transmission); temporary passwords are changed; feedback is obscured. | Password/authenticator policy, config settings |
3.6 Incident Response (3)
| What to verify | Typical evidence |
|---|
| An incident-handling capability exists (preparation, detection, analysis, containment, recovery, user response). | Incident-response plan, incident tickets |
| Incidents are tracked, documented and reported to internal and external authorities (incl. DoD 72-hour reporting under DFARS). | Reporting records, DIBNet submission evidence |
| The incident-response capability is tested. | Tabletop/exercise records |
3.7 Maintenance (6)
| What to verify | Typical evidence |
|---|
| Maintenance is performed and controlled; tools, techniques and personnel are controlled; media is sanitised before off-site maintenance. | Maintenance policy/logs, media-sanitisation records |
| MFA is used for nonlocal maintenance sessions and connections are terminated when complete; maintenance personnel are supervised. | Remote-maintenance config, supervision records |
3.8 Media Protection (9)
| What to verify | Typical evidence |
|---|
| CUI on media is protected, access is limited, and media is marked and controlled during transport. | Media-handling policy, marking, transport logs |
| Media is sanitised or destroyed before disposal/reuse; removable media use is controlled; media is encrypted during transport. | Sanitisation certificates, removable-media policy, encryption evidence |
3.9 Personnel Security (2)
| What to verify | Typical evidence |
|---|
| Individuals are screened before authorising access to CUI. | Screening/background-check records |
| CUI and systems are protected during and after personnel actions (transfers, terminations) — access is revoked promptly. | Offboarding checklists, access-revocation records |
3.10 Physical Protection (6)
| What to verify | Typical evidence |
|---|
| Physical access to systems, equipment and operating environments is limited and escorted/monitored; visitors are controlled. | Facility access policy, visitor logs, badge records |
| Physical access devices are managed; alternate work sites are safeguarded. | Key/badge inventory, remote-work policy |
3.11 Risk Assessment (3)
| What to verify | Typical evidence |
|---|
| Risk to operations, assets and individuals from CUI processing is assessed periodically. | Risk-assessment report |
| Systems are scanned for vulnerabilities periodically and on new-vulnerability disclosure; findings are remediated. | Vulnerability-scan reports, remediation records |
3.12 Security Assessment (4)
| What to verify | Typical evidence |
|---|
| Controls are assessed periodically for effectiveness; a System Security Plan (SSP) describes the environment and control implementation. | SSP, assessment results |
| A Plan of Action & Milestones (POA&M) tracks deficiencies; the security posture is monitored on an ongoing basis. | POA&M, continuous-monitoring records |
3.13 System & Communications Protection (16)
| What to verify | Typical evidence |
|---|
| Communications are monitored/controlled at boundaries; subnetworks for public components are separated; architecture separates user and management functions. | Boundary/firewall config, network architecture diagram |
| CUI is encrypted in transit and (where required) at rest with FIPS-validated cryptography; keys are managed; mobile code and VoIP are controlled. | Encryption config, FIPS module list, key-management records |
| Deny-by-default network policy; shared resources are protected; collaborative devices and split tunneling are controlled. | Firewall rules, configuration standards |
3.14 System & Information Integrity (7)
| What to verify | Typical evidence |
|---|
| Flaws are identified, reported and remediated promptly; malicious-code protection is deployed and updated. | Patch records, anti-malware config |
| System security alerts/advisories are monitored and acted on; inbound/outbound traffic and system behaviour are monitored to detect attacks. | Advisory-monitoring process, IDS/monitoring records |
Scoping the CUI environment
- Identify every place CUI is stored, processed or transmitted — including email, endpoints, file shares, SaaS and backups.
- Reduce and enclave: consolidate CUI into a defined enclave (e.g., a dedicated environment such as a GCC High tenant) so fewer systems are in scope.
- Categorise assets: CUI assets, Security Protection assets, Contractor Risk Managed assets, Specialized assets, and Out-of-scope — a distinction CMMC assessments use.
- Document the boundary in the SSP; everything in scope must meet the requirements.
Implementation approach (phased)
Phase 1 — Scope & discover
- Map CUI flows and define the boundary/enclave; inventory in-scope assets, people and third parties.
- Deliverables: CUI data-flow diagram, asset inventory, scoping document.
Phase 2 — Assess
- Assess all 110 requirements (implemented / partially / not); gather evidence.
- Deliverables: gap assessment, evidence inventory, draft SPRS score.
Phase 3 — Document (SSP)
- Write the System Security Plan describing the environment and how each requirement is met (or not).
- Deliverables: approved SSP.
Phase 4 — Remediate
- Close gaps by priority; record residual gaps and dates in the POA&M.
- Deliverables: remediated controls, POA&M, updated SSP.
Phase 5 — Score & submit
- Compute the SPRS score and submit it; prepare for a CMMC Level 2 (C3PAO) assessment where the contract requires it.
- Deliverables: SPRS submission, assessment-readiness pack.
Phase 6 — Monitor
- Continuously monitor controls, rescan, retrain and keep the SSP/POA&M current.
- Deliverables: continuous-monitoring evidence, updated score.
SPRS scoring methodology
The DoD Assessment Methodology assigns a score out of 110. You start at 110 and subtract the weighted value of each unmet requirement (most are −1, some higher-impact controls are −3 or −5). The result — which can be negative — is submitted to the Supplier Performance Risk System (SPRS).
| Point value | Meaning |
|---|
| −1 | Most requirements — limited direct impact if unmet |
| −3 | Higher-impact requirements |
| −5 | Highest-impact requirements (e.g., MFA, FIPS encryption, boundary protection) |
Scoring note
A high score with unmet high-value (−5) controls is still weak. Prioritise the −5 and −3 requirements — MFA, encryption of CUI, boundary protection, incident response — first.
The two key artefacts
| Artefact | Purpose & contents |
|---|
| System Security Plan (SSP) | Describes the system boundary, environment, roles, and how each of the 110 requirements is implemented — the central document an assessor reviews. |
| Plan of Action & Milestones (POA&M) | Lists each unmet/partial requirement with the remediation action, owner, resources and completion date. |
Assessment & audit approach
- Confirm the assessment type required by the contract: self-assessment (Level 1 / some Level 2) or C3PAO third-party (Level 2), or government-led (Level 3).
- Define scope with a current CUI data-flow diagram and asset categorisation.
- Assess each requirement using examine (documents/config), interview (staff) and test (technical validation).
- Rate each requirement met / not met and capture evidence; compute the SPRS score.
- Record deficiencies in the POA&M with owners and dates; remediate high-value items first.
- For CMMC Level 2, engage a C3PAO; pass criteria require meeting requirements (with limited POA&M allowances).
- Re-assess and maintain continuous monitoring.
Evidence request list
- Scope & architecture: CUI data-flow diagram, network diagram, asset inventory and categorisation.
- Policies & the SSP: information-security policies, the System Security Plan and the POA&M.
- Access: access-control policy, account/privileged-account inventories, MFA configuration, access reviews.
- Config & integrity: hardening baselines, change records, patch and anti-malware evidence, vulnerability scans.
- Logging: audit-log policy, sample logs, review records, time-sync and retention config.
- Crypto: FIPS-validated module list, encryption configuration (in transit and at rest), key management.
- Operations: incident-response plan and records (incl. DoD reporting), maintenance and media-sanitisation records.
- People & physical: screening and offboarding records, awareness/role-based training, facility access and visitor logs.
Roles & responsibilities
| Role | Responsibility |
|---|
| Executive sponsor | Owns the compliance decision and funds remediation |
| CUI / ISSO lead | Owns the SSP, scope and requirement implementation |
| IT & security engineers | Implement and evidence technical controls |
| HR | Screening, training and offboarding controls |
| Contracts / compliance | Manages DFARS flowdown, SPRS submission and assessor coordination |
| Assessor (self / C3PAO) | Independently assesses control implementation |
KPIs to track
- SPRS score and trend (target 110).
- Number of open POA&M items and overdue items.
- Percentage of −5/−3 requirements met.
- MFA and encryption coverage across the CUI boundary.
- Vulnerability-remediation time; patch compliance.
- Training completion; incident detection/response time.
Readiness checklist
- CUI is mapped and the boundary/enclave is defined and documented.
- An SSP describes how all 110 requirements are met.
- MFA is enforced for privileged and network access.
- CUI is encrypted in transit and at rest with FIPS-validated cryptography.
- Boundary protection, logging and monitoring are operating.
- Incident response is documented, tested and meets DoD reporting timelines.
- Media handling, sanitisation and physical controls are in place.
- Personnel screening, training and offboarding controls operate.
- A POA&M tracks all gaps with owners and dates.
- The SPRS score is computed and submitted; DFARS flowdown is managed.
Common gaps
- Scoping too broadly instead of enclaving CUI — inflating cost and risk.
- MFA or FIPS-validated encryption missing (high-value −5 deductions).
- An SSP that describes intent but not actual, evidenced implementation.
- No POA&M, or gaps tracked without owners/dates.
- Logs collected but never reviewed; no continuous monitoring.
- DFARS flowdown to subcontractors not managed.
NIST 800-171 mapped to other frameworks
| Framework | Relationship |
|---|
| NIST 800-53 | 800-171 is a tailored subset of 800-53 (moderate baseline) for non-federal systems |
| CMMC | CMMC Level 2 assesses and certifies implementation of the 110 800-171 requirements |
| NIST 800-172 | Adds enhanced requirements for advanced persistent threats (CMMC Level 3) |
| ISO 27001 | Heavy control overlap; an ISMS provides a strong foundation for 800-171 |
How CyberSigma helps
We scope and enclave your CUI environment, assess all 110 requirements, author the SSP and POA&M, improve your SPRS score by prioritising high-value controls, and prepare you for the CMMC Level 2 (C3PAO) assessment.
