Platform
Modules
By sector
By sector
By standard
Blog
News
Events
NIST SP 800-171
Nonfederal organizations that process, store, or transmit Controlled Unclassified Information under a federal contract or agreement
US federal security requirements for protecting Controlled Unclassified Information on nonfederal systems, binding once a federal contract or agreement invokes them.
NIST SP 800-171 Revision 3 sets the security requirements for protecting the confidentiality of Controlled Unclassified Information (CUI) when that information is processed, stored, or transmitted on a nonfederal organization's own systems. NIST wrote it, in its own words, "for use by federal agencies in contractual vehicles or other agreements" with the nonfederal organizations they share CUI with. The publication does not bind anyone by existing; a federal agency's contract or agreement has to invoke it first. Revision 3 was approved in April 2024 and published in May 2024, superseding Revision 2 from February 2020.
The requirements are organized into 17 families, from access control and audit logging through physical protection and supply chain risk management, and every one of them is tailored down from the much larger control catalog in NIST SP 800-53. Three families that exist in that larger catalog are dropped here entirely: Contingency Planning, because it addresses availability rather than confidentiality; Program Management, because it is not tied to a specific system; and PII Processing and Transparency, because personally identifiable information is already treated as a category of CUI and needs no separate family. That is worth knowing if you are used to the fuller SP 800-53 baseline and expect to see them.
The document names two roles directly. From what it calls the "Federal perspective," it addresses "the entity establishing and conveying the security requirements in contractual vehicles or other types of agreements." From the "Nonfederal perspective," it addresses "the entity responding to and complying with the security requirements set forth in contracts or agreements." Underneath those two roles sit individuals with system development, acquisition, risk management, and security assessment responsibilities.
Nothing in the document makes it binding on its own. It becomes real for a nonfederal organization the moment a federal contract or agreement names it, and only to the extent that contract says. The requirements apply to "components of nonfederal systems that process, store, or transmit CUI or that provide protection for such components," with no restriction to a particular sector or technology: a covered system can be anything from a conventional IT network to "operational technology (OT)... Internet of Things (IoT) devices, Industrial IoT (IIoT) devices, specialized systems, cyber-physical systems, embedded systems, and sensors."
The document itself flags where the cost of this work actually sits. Section 1.1 notes that an organization can limit the scope of the security requirements "by isolating the system components" that handle CUI "in a separate security domain," which avoids "increasing the organization's security posture beyond what it requires for protecting its missions, operations, and assets." Decided before a system is built, that is an architecture choice. Decided after a contract naming this document has already been signed, it usually means separating CUI-handling components out of a system that was never built with that boundary in mind. Before any of the 97 requirements can be assessed, requirement 03.11.01 states plainly that "establishing the system boundary is a prerequisite to assessing the risk of the unauthorized disclosure of CUI" - so the first real question is not which requirement to start with, but where CUI actually lives.
Access Control requires defined and managed account types, least privilege enforcement (including a rule that privileged users use non-privileged accounts for everyday, non-security work), lockout after repeated failed logons, and remote and wireless access routed through managed control points. Mobile devices need full-device or container-based encryption before they can hold CUI, and any external system, personally owned or otherwise, "is prohibited unless specifically authorized."
Awareness and Training, Audit and Accountability, and Configuration Management ask for security literacy and role-based training tied to actual roles, a defined and reviewed set of logged events with protected audit records, and a documented baseline configuration with formal change control. Software execution is deny-by-default: only software on an approved list may run.
Identification and Authentication is where Revision 3 changes what an auditor used to older guidance will expect. Multi-factor authentication now applies to non-privileged accounts as well as privileged ones, not privileged accounts alone. Password management moves away from mandatory periodic rotation and toward checking new passwords against a maintained list of "commonly-used, expected, or compromised passwords" before they are accepted.
Incident Response, Maintenance, Media Protection, and Personnel Security cover a documented incident response plan tested on its own schedule (not just written and filed), approved and malware-checked maintenance tools with multi-factor authentication for remote maintenance sessions, sanitization of media before disposal or reuse, and screening plus a defined process for disabling access the moment employment ends or changes.
Physical Protection, Risk Assessment, and Security Assessment and Monitoring require a maintained facility access list with monitored and logged entry points, a risk assessment that explicitly includes supply chain risk, and a requirement that the organization assess, on its own defined schedule, whether it is actually meeting these requirements, tracking anything unresolved in a plan of action and milestones (POAM).
System and Communications Protection and System and Information Integrity require boundary protection separating public-facing components from internal ones, a deny-by-default network traffic policy, cryptographic protection for CUI both in transit and at rest, and malicious code protection with a defined patching timeframe for security-relevant updates.
Planning, System and Services Acquisition, and Supply Chain Risk Management close the set: documented policies and procedures behind every other family, a system security plan describing the system's boundary and how each requirement is met, security engineering principles applied to new development, a plan for replacing unsupported components, and a supply chain risk management plan covering the system from research and development through disposal.
There is no certification against NIST SP 800-171. The document names no accredited certification body and describes no scheme for certifying an organization or a product against it. What it requires instead is self-assessment: the organization must "assess the security requirements for the system and its environment of operation... to determine if the requirements have been satisfied," on a frequency it defines itself, and document any gap in a plan of action and milestones. NIST's companion publication, SP 800-171A, sets out procedures for running that assessment, but the document leaves the decision about what evidence is enough to whoever is party to the contract: a federal agency "may consider system security plans and POAMs as inputs to risk-based decisions on whether to process, store, or transmit CUI on a system hosted by a nonfederal organization." In practice, what an assessor or a contracting officer asks to see is the system security plan, the POAM, audit records, and the training, screening, and maintenance records the individual requirements call for, not a certificate.
NIST SP 800-171's requirements are tailored from the full control catalog in NIST SP 800-53, Rev. 5, using the moderate baseline in SP 800-53B. Its companion, NIST SP 800-171A, Rev. 3, provides the procedures for assessing the requirements described here. The underlying CUI protection scheme traces to FIPS 199 and FIPS 200, which set the confidentiality impact value the requirements are built to, and to Executive Order 13556 and the CUI federal regulation at 32 CFR Part 2002. Individual requirements point to FIPS 140-3 for cryptographic modules and to roughly forty further NIST Special Publications and Interagency Reports as supporting, non-normative guidance, none of which are held separately in our catalogue.
NIST SP 800-171 is an evidence-and-process document, not a piece of software a vendor installs, so ComplyTrain is the system an organization runs this work in, alongside whatever technical controls its IT and security teams put in place directly. Concretely: the system security plan and the plan of action and milestones the requirements call for live as controlled, versioned documents with an owner and a review history, rather than a spreadsheet nobody has opened since the last customer questionnaire. Security literacy and role-based training records, personnel screening and termination records, and maintenance and incident response evidence all sit in one auditable place a reviewer can produce quickly rather than assemble under deadline.
What ComplyTrain does not do: it does not configure multi-factor authentication, encrypt data at rest or in transit, run vulnerability scans, or perform the technical boundary protection and audit logging the requirements describe. Those stay the work of an organization's own IT and security engineering functions and the tools they choose. It is also not an assessor: it does not perform the self-assessment the requirements call for, or the contracting federal agency's own review of that evidence.
Most readers land here already holding a customer security questionnaire, a federal contract clause, or a request to show how CUI is protected. See what else sits alongside NIST SP 800-171 in the standards explorer, and talk to us about the evidence trail behind it.
Tell us how you need to work with NIST SP 800-171 and what you need from it. We will come back to you about what ComplyTrain can do.
Thank you. Your list is on its way to your inbox, and we will come back to you on what working with these standards in ComplyTrain involves, usually within one business day.
No. NIST SP 800-171 names no accredited certification body and describes no scheme for certifying an organization or a product against it. It requires the organization to assess its own compliance and record the results in a system security plan and a plan of action and milestones; the federal agency that is party to the relevant contract may review that evidence directly.
Not by itself. It applies once a federal agency's contract or other agreement invokes it for a specific nonfederal organization and its systems. Outside a contract that names it, the document does not bind anyone on its own.
Revision 3, published May 2024, restructures the requirements around the moderate baseline in NIST SP 800-53B and drops the earlier split between basic and derived requirements. Two changes an organization working from an older policy is likely to miss: multi-factor authentication now applies to non-privileged accounts as well as privileged ones, and password management shifts from mandatory periodic rotation toward checking new passwords against a maintained list of compromised or commonly used ones.
NIST SP 800-171 sets the security requirements themselves. NIST SP 800-171A, published alongside Revision 3, is the companion publication that provides the procedures for assessing whether each requirement has been satisfied. The two are meant to be used together.
The requirements apply to any nonfederal system component that processes, stores, or transmits CUI, or that protects such a component, regardless of the underlying technology - the document lists conventional IT alongside operational technology, IoT devices, and embedded systems as examples. It does not name a specific sector or product type as the only one in scope.
One system for the whole compliance programme. Start with the module you need most.
Collect information the same way every time, and decide in advance what happens next.
Know whether your controls are operating, not just whether a policy says they exist.
Turn the compliance work you already know about into a plan with owners, dependencies and dates.
Know what you can offer, and hold the evidence behind every configuration you offer it in.
Eight built-in reports across every module, scheduled, delivered, and filed where the evidence lives.
The sector news that matters to your organisation - read and rated by AI, and delivered as a scheduled digest in your own language.
AI reads the tender pack and pulls out the requirements, deadlines and rules - then helps you draft the response from your own approved content, with you reviewing every step.
One current register of the suppliers and partners you depend on - each risk-assessed, re-assessing itself on schedule, and wired straight into your risk register.
See every requirement you face - across every standard, plus your own contracts and policies - traced to the documents, evidence and processes that satisfy it.
Identify, score, treat and review your risks in one place - with AI to help anyone run a proper assessment, and a defensible trail behind every decision.
Assign training, prove it was understood, and hold the competence records an auditor asks for.
Draft compliance documents with AI, keep every version under control, and export them beautifully branded - all in one place.
Audits, corrective actions, processes and approvals in one quality system, organised around ISO 9001.
A 90-day plan for the smallest defence suppliers: let the tender set your scope, document what you already do, fix the security basics primes check, and keep the system small enough for two people to maintain.
Learn how to qualify, approve and monitor sub-suppliers, flow down requirements through purchase orders, and keep the records an auditor will ask to see under ISO 9001 clause 8.4 and AQAP.
Learn how to run an ISO 9001 Clause 9.3 management review that turns evidence into decisions, with the right inputs, actionable outputs, and a cadence that fits your risks.