What is NIST SP 800-171?
NIST Special Publication 800-171 is the federal standard for protecting Controlled Unclassified Information when that information lives on systems a private organization owns and operates. It is the answer to a specific question: the government has rules for its own systems, so what must a contractor do when sensitive-but-unclassified government information sits on the contractor’s laptops, servers, and cloud tenants?
It matters far beyond its own name because it is the substrate other programs are built from. CMMC Level 2 assessments evaluate this requirement set. Defense contract clauses invoke it directly. Civilian agencies increasingly reference it. Implement it well once and several separate obligations become close to satisfied at the same time.
What it actually requires
Revision 2 defines 110 security requirements across fourteen families. Grouped by where the effort concentrates:
- Identity and access — access control, identification and authentication. Multifactor authentication, least privilege, and separation of privileged from ordinary accounts. Reliably the largest engineering lift.
- Visibility — audit and accountability. Centralized, protected logging with evidence that someone reviews it.
- Change discipline — configuration management. Baselines, controlled changes, and detection of drift.
- Response — incident response. Tested procedures with defined reporting.
- Protection — system and communications protection, system and information integrity, media protection. Encryption, boundary protection, flaw remediation.
- People and place — awareness and training, personnel security, physical protection, maintenance, risk assessment, security assessment.
Nothing here is exotic for a company with a real security program. The gap for most companies is not the controls themselves but the evidence — being able to demonstrate, on demand, that a control operates as described.
Where it applies, and where it does not
The standard applies to nonfederal systems that store, process, or transmit CUI. That scope statement is doing a lot of work: if CUI never enters your environment, the standard does not apply to you, and the cheapest compliance strategy available is often to keep it out.
For a software vendor, this makes product design a compliance decision. A product that can be deployed so that the customer’s CUI stays in the customer’s tenant is in a materially different position from one that necessarily ingests CUI into the vendor’s environment.
The System Security Plan and the plan of action
Two documents carry the weight.
The System Security Plan describes your environment and how each requirement is implemented within it. It is the assessor’s working document, and its precision determines the shape of the assessment. A plan that says “we use encryption” invites questions; one that names the mechanism, the scope, and the key management path answers them.
The plan of action and milestones lists what is not yet implemented, with dates and owners. Its existence is normal and expected. What is not acceptable is silence — an unimplemented requirement that appears nowhere is the finding that turns an assessment into an enforcement question.
Which revision applies to you
The standard has been revised, and the revisions differ in structure and requirement count. Contracts cite a specific version. The CMMC rule is keyed to Revision 2’s 110 requirements; the later revision reorganizes the material.
Read the clause in the contract in front of you and implement what it names. This is one of the few areas in federal compliance where the general answer is genuinely less useful than the specific one.
Why implementing it early pays
The standard is the common denominator. A company that has implemented it can respond to a prime’s supply-chain questionnaire, prepare for a CMMC Level 2 assessment, and satisfy a defense contract clause from largely the same body of work. A company that has not is starting each of those from zero, usually on someone else’s deadline.