NIST SP 800-171 Rev.3: NIST SP 800-171 Rev.3 – Tutorial (about 60 minutes)

NIST Special Publication 800-171 Revision 3 is the United States government's catalogue of security requirements for protecting Controlled Unclassified Information (CUI) when that information leaves federal hands and sits on the computers of contractors, universities, research labs and other partners. Federal agencies write it into contracts and agreements, and the companies and institutions that receive CUI use it to design, run and prove the security of the systems that handle that information. After this tutorial you will be able to explain where the requirements come from, read and interpret a single requirement, scope a system sensibly, plan an implementation, and understand how compliance is assessed and why the Department of Defense still points to the previous revision.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is NIST SP 800-171 Revision 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, published by the National Institute of Standards and Technology (NIST), Computer Security Division, on 14 May 2024. It superseded Revision 2 and is final; the NIST Computer Security Resource Center (CSRC) lists no newer revision or open draft. Its companion, SP 800-171A Revision 3 (assessment procedures), was published the same month, and the optional supplement SP 800-172 Revision 3 (enhanced requirements) became final on 13 May 2026. Adoption is uneven, and that matters in practice: the Department of Defense (DoD, also styled the Department of War since September 2025) still requires Revision 2 under its contract clause DFARS 252.204-7012 and for CMMC, under a class deviation issued in May 2024; a July 2026 DoD memo again called for baseline compliance with the 110 Revision 2 requirements. A revised government-wide FAR rule on CUI, proposed on 23 June 2026, would make Revision 3 the baseline for federal contracts; it was still a proposal in the most recent sources checked. Verified 2026-10-29.

Who it is for: security and IT engineers, compliance and contracts staff, research administrators, managed service providers and anyone in a company or institution that receives CUI from a US federal agency or from a prime contractor. Many readers outside the United States meet the publication through supply chains, because the obligations flow down to subcontractors wherever they are located.

Prerequisites: none. Basic familiarity with IT terms such as accounts, networks, logging and encryption helps, and every specialist term is explained when it first appears.

You will be able to explain what CUI is, why a federal publication governs it outside government, and which systems fall in scope.
You will be able to describe how the requirements were derived from the SP 800-53 moderate baseline through tailoring.
You will be able to read a Revision 3 requirement, including its identifier, lettered parts and organization-defined parameters.
You will be able to plan an implementation that produces a system security plan and a plan of action and milestones.
You will be able to explain how SP 800-171A Revision 3 assessments work and what "satisfied" and "other than satisfied" mean.
You will be able to position Revision 3 against Revision 2, SP 800-172, CMMC, ISO/IEC 27001 and other frameworks.

Lesson 1 – Origins, purpose and scope

The problem the publication solves

The US federal government creates and collects a vast amount of information that is not classified but is still sensitive: technical drawings for defence equipment, export-controlled data, law-enforcement records, health and tax information, critical-infrastructure details, research results with security implications, and much more. For decades every agency marked and protected such information in its own way, using labels like "For Official Use Only" or "Sensitive But Unclassified". The result was confusion. A contractor working for three agencies might face three different labelling schemes and three different sets of expectations, and information was sometimes either over-protected or not protected at all.

In 2010 Executive Order 13556 created a single government-wide programme for this kind of information and named it Controlled Unclassified Information. The National Archives and Records Administration (NARA) became the executive agent of the programme. NARA maintains the CUI Registry, which lists the approved categories of CUI and the laws or policies behind each, and a federal regulation, 32 CFR Part 2002, sets the rules for designating, marking, safeguarding, sharing and eventually decontrolling CUI.

That regulation requires agencies to protect CUI on their own systems using NIST standards and guidelines. But agencies do not keep CUI to themselves. They share it every day with contractors, grant recipients, universities, state governments and service providers. The government's view is simple: the value of the information does not change when it moves to someone else's network, so the protection should not change either. Yet it would be unreasonable to impose the full federal security machinery on a private machine shop or a university lab. SP 800-171 is the answer to that tension. It gives agencies a ready-made, consistent set of security requirements to place in contracts and other agreements, sized for organizations that are not federal agencies.

A short history

NIST first published SP 800-171 in June 2015, revised it in December 2016 (Revision 1) and again in February 2020 (Revision 2), with a small update in January 2021. Revision 2 contained 110 requirements in 14 families and split them into "basic" and "derived" requirements. In July 2022 NIST announced a full update, released drafts in 2023 and published the final Revision 3 in May 2024. The main drivers were alignment with the current federal control catalogue, SP 800-53 Revision 5, and feedback from implementers and assessors that the older requirements were too ambiguous to apply and assess consistently.

Where the requirements come from

SP 800-171 does not invent its own controls. It starts from SP 800-53, the large catalogue of security and privacy controls that federal agencies use for their own systems. SP 800-53B groups those controls into low, moderate and high baselines. Because the CUI regulation says CUI must be treated as at least "moderate" for confidentiality under the federal impact scale (FIPS 199), NIST takes the moderate baseline as its starting point. It then removes or adjusts controls that a nonfederal organization should not need, using a small set of tailoring criteria explained in Lesson 2. What remains, rewritten as requirements, is SP 800-171.

Figure 1 – How the SP 800-171 Revision 3 requirements are derived from the federal control catalogue and then used for assessment, enhancement and contracts.

Scope: what the requirements apply to

Scope is the single most important idea to grasp early, because it drives cost. The requirements apply only to the components of a nonfederal system that process, store or transmit CUI, or that protect those components. A component can be a laptop, server, phone, network switch, virtual machine, database, application or operating system. A firewall that guards the CUI network is in scope even if no CUI ever rests on it, because it provides protection. A marketing laptop that never touches CUI and is properly separated is out of scope.

The publication explicitly encourages organizations to limit scope by isolating CUI in a separate security domain, for example a dedicated network segment behind a firewall, or a cloud tenant reserved for controlled work. This is often called an enclave approach. A well-designed enclave lets a company protect CUI to the required level without dragging every printer and office PC into the programme.

Two further scope points matter. First, the focus is confidentiality: preventing unauthorized disclosure of CUI. Because integrity mechanisms often travel with confidentiality mechanisms, the requirements also guard against unauthorized modification, but availability topics such as full contingency planning are left out; only the protection of backup confidentiality is kept. Second, SP 800-171 does not apply when a contractor operates a system on behalf of an agency. In that case the system is effectively a federal information system and the full Federal Information Security Modernization Act (FISMA) regime applies instead.

Who decides what applies

NIST writes the requirements, but NIST does not enforce them and does not certify anyone. A nonfederal organization becomes bound by SP 800-171 only through a contract, grant or other agreement with an agency, or through a flow-down clause from a prime contractor. The agency that shares the CUI is responsible for deciding how the requirements apply, how compliance is checked and what happens when they are not met. Keep this in mind throughout the course: whenever you ask "which revision must we follow?" or "who checks us?", the answer is in your contract, not in NIST's document.

Lesson 2 – Key concepts and vocabulary

Revision 3 uses precise language. The following terms appear constantly in contracts, assessments and conversations with customers. Learn them well; most misunderstandings in CUI programmes come from loose use of these words.

Controlled Unclassified Information (CUI) – information that a law, regulation or government-wide policy requires to be safeguarded or disseminated with controls, but which is not classified. The CUI Registry lists the approved categories.
CUI Registry – the online catalogue run by NARA that lists every CUI category, its legal authority and any special handling rules. It is the first place to check whether a piece of information is really CUI.
Nonfederal organization – any entity that owns, operates or maintains a nonfederal system, such as a company, university, non-profit or state government body.
Nonfederal system – a system that does not meet the definition of a federal information system, because it is not operated by or on behalf of an agency.
System component – an individual element of a system: hardware, software or firmware, such as an endpoint, server, network device, virtual machine or application.
Security requirement – a statement of a protection need. In SP 800-171 each requirement has a number, a title and one or more parts, and must be satisfied in full.
Organization-defined parameter (ODP) – a placeholder inside a requirement whose value the agency or the nonfederal organization must set, such as a review frequency, a time period or a list of roles. Once set, the value becomes part of the requirement.
Assignment and selection operations – the two forms an ODP takes. An assignment asks you to fill in a value; a selection asks you to choose one or more options from a list printed in the requirement.
Tailoring – the process of modifying a control baseline to fit a purpose. NIST tailored the SP 800-53 moderate baseline to produce SP 800-171.
Tailoring criteria – the labels NIST applied to each moderate-baseline control: CUI (kept because it directly protects CUI confidentiality), NCO (not directly related to confidentiality), FED (primarily a federal responsibility), ORC (outcome covered by other related controls) and N/A (not applicable).
System security plan (SSP) – the document that describes the system boundary, components, information types, environment, threats, roles and how each requirement is met or planned. It is itself a requirement in Revision 3.
Plan of action and milestones (POA&M) – a record of known weaknesses and the planned steps, owners and dates to fix them. Revision 3 treats it as a living document fed by assessments, audits and monitoring.
Enduring exception – a permanent, documented departure from a requirement because a component cannot technically meet it, for example a specialised test instrument. Enduring exceptions belong in the SSP; temporary gaps belong on the POA&M.
Security domain – a part of the environment governed by a common security policy and separated from other parts, physically, logically or both. Creating one is the main way to narrow scope.
Determination statement – the smallest testable statement in an SP 800-171A assessment procedure. Each one receives a finding of satisfied or other than satisfied.
External service provider – an outside organization, such as a cloud provider or managed service provider, that delivers services used to meet requirements. Using one shares the work but not the accountability.

Why ODPs are the big idea of Revision 3

Revision 2 often said things like "limit unsuccessful logon attempts" without saying how many, or "review audit logs" without saying how often. Two honest assessors could reach different conclusions about the same company. Revision 3 adopts the parameter style of SP 800-53: the requirement states the protection, and an ODP holds the specific number, period or option. This gives flexibility, because different agencies and missions need different values, and it gives precision, because once the value is fixed an assessor can test against it.

Who sets the value? The agency may set it, may give guidance, or may leave it to the nonfederal organization. NIST itself never sets ODP values. If the agency is silent, the organization must choose a value and document it, usually in the SSP. DoD, for example, published a memo in April 2025 assigning its own values for the Revision 3 parameters, to be used when it adopts Revision 3. A sensible habit is to keep one ODP register that lists every parameter, the chosen value, who decided it and why.

Why "Withdrawn" appears so often

Readers opening Revision 3 for the first time are surprised to see many numbers marked as withdrawn. NIST kept the numbering stable so that people could trace each Revision 2 requirement forward. When a requirement was merged into another, made redundant, recategorised or judged too technology-specific, its number stays in the document with a short note pointing to where the content went. Withdrawn entries carry no obligation; they are signposts.

Lesson 3 – Structure of the publication and its requirements

The document at a glance

Revision 3 is organised into three chapters and five appendices. Chapter 1 introduces the CUI programme, the purpose and scope. Chapter 2, "The Fundamentals", sets out the assumptions behind the requirements, the tailoring method, the families and the role of ODPs, with an annotated example of a requirement. Chapter 3 holds the security requirements themselves. The appendices provide acronyms, a glossary, the full tailoring tables (showing for every moderate-baseline control which tailoring label it received and which requirement it supports), a consolidated list of all ODPs, and a change log.

Several supporting files sit on the NIST publication page rather than inside the PDF: a change-analysis spreadsheet comparing Revision 2 and Revision 3, the CUI overlay (a spreadsheet showing how each control and control item of the moderate baseline was tailored), a frequently asked questions document, and machine-readable versions in the NIST Cybersecurity and Privacy Reference Tool (CPRT), including spreadsheet and JSON formats.

The 17 families

Revision 3 groups its 97 active requirements into 17 families, up from 14. Three families are new: Planning, System and Services Acquisition, and Supply Chain Risk Management. They mirror SP 800-53 families in the moderate baseline whose controls Revision 2 mostly assumed to be in place without stating them or, for supply chain risk management, could not include, because that family only arrived with SP 800-53 Revision 5. The Security Assessment family was renamed Security Assessment and Monitoring. Families from SP 800-53 that are absent include Contingency Planning (an availability topic, except the protection of backups), Program Management (not part of any baseline) and PII Processing and Transparency (personal data that is CUI is already protected as CUI).

Family (Rev 3 section)	Active requirements	What it is about, in plain words
Access Control (03.01)	16	Accounts, least privilege, logon limits, sessions, remote and wireless access, mobile devices, external systems
Awareness and Training (03.02)	2	Security literacy for everyone and role-based training for people with specific duties
Audit and Accountability (03.03)	8	Which events to log, log content, review, time stamps and protection of logs
Configuration Management (03.04)	10	Baselines, secure settings, change control, inventory, allowed software, where CUI is located
Identification and Authentication (03.05)	8	User and device identity, multi-factor authentication, passwords and authenticator handling
Incident Response (03.06)	5	Handling, reporting, testing, training and planning for security incidents
Maintenance (03.07)	3	Maintenance tools, remote maintenance and supervision of maintenance staff
Media Protection (03.08)	7	Storage, access, marking, transport, sanitisation and use of media, and backup encryption
Personnel Security (03.09)	2	Screening before access and actions when people leave or change roles
Physical Protection (03.10)	5	Authorising and controlling physical access, monitoring, alternate work sites
Risk Assessment (03.11)	3	Assessing risk, scanning for vulnerabilities and responding to findings
Security Assessment and Monitoring (03.12)	4	Periodic assessment, POA&M, continuous monitoring and information-exchange agreements
System and Communications Protection (03.13)	10	Boundary protection, deny-by-default networking, encryption in transit and at rest, key management
System and Information Integrity (03.14)	5	Patching, malware protection, security alerts, system monitoring, information retention
Planning (03.15)	3	Policies and procedures, the system security plan and rules of behaviour
System and Services Acquisition (03.16)	3	Security engineering principles, unsupported components and external services
Supply Chain Risk Management (03.17)	3	A supply chain risk plan, acquisition strategies and supply chain requirements

Do not read the counts as a measure of effort. One Revision 3 requirement can contain several lettered parts, and some short families, such as Planning, carry heavy documents like the SSP. Overall, Revision 3 has fewer requirements than Revision 2 (97 against 110) but more detail, so the amount of work generally grows.

Anatomy of a requirement

Every requirement in Chapter 3 follows the same pattern. Learning to read that pattern makes the whole catalogue approachable.

Figure 2 – The parts of a Revision 3 requirement, showing which parts are binding and where organization-defined values end up.

Identifier and title – Revision 3 numbers requirements as 03.FF.RR: the leading 03 refers to Chapter 3, FF is the family and RR the requirement. For example, 03.13.11 is the eleventh requirement of System and Communications Protection, titled Cryptographic Protection. Revision 2 used a shorter style such as 3.13.11, which is why mapping tables matter.
Requirement statement – the binding text. When it has lettered parts (a, b, c, sometimes with numbered sub-items), every part must be met.
ODPs – shown in square brackets as an assignment or selection. Revision 3 places ODPs in many requirements; Appendix D lists them all in one table.
Discussion – explanatory text drawn from SP 800-53. NIST states that it is informative, not normative: it helps you understand and implement but does not add obligations or limit your solutions.
References – the SP 800-53 source controls and other NIST publications for deeper reading.

The cryptography requirement shows why this structure matters. In Revision 2, the requirement itself called for FIPS-validated cryptography. In Revision 3, the requirement asks the organization to implement certain types of cryptography, with the types left as an ODP, while the discussion recommends cryptography validated under FIPS 140. Whether validation is mandatory therefore depends on how the agency fills the parameter, which is exactly the kind of detail you must confirm with your customer.

How the SSP and POA&M fit the structure

Chapter 3 opens with an important instruction. Some systems, such as industrial controllers, medical devices or computer numerical control (CNC) machines, cannot meet every requirement. Revision 3 tells organizations to describe such permanent limitations in the system security plan (requirement 03.15.02) and to manage individual, isolated or temporary deficiencies through the plan of action and milestones (requirement 03.12.02). These two documents are therefore not paperwork added on top of the requirements; they are part of the requirements and the place where honest reality is recorded.

Lesson 4 – How it works in practice

Roles

Implementing SP 800-171 is a team activity. The federal agency (or the prime contractor flowing requirements down) defines the obligation in the contract, identifies the CUI it will share and may set ODP values. Inside the nonfederal organization, a senior leader accepts accountability, signs off on risk decisions and funds the work. A system owner or programme lead is responsible for the system that handles CUI. IT and security staff design and operate the safeguards. Contracts and legal staff track clauses and flow-down. Human resources and facilities handle screening, terminations and physical access. Finally, external service providers such as cloud platforms and managed service providers may run parts of the system, and their responsibilities must be documented.

The implementation lifecycle

Most organizations follow a cycle like the one in Figure 3. It is not prescribed by NIST in this form, but each step corresponds to requirements in the publication or to practices NIST describes.

Figure 3 – A typical implementation lifecycle, ending in continuous monitoring that feeds the next round of gap analysis.

Steps 1 and 2: understand the obligation and find the data

Start with the contract. Identify the clauses that bring SP 800-171 in, which revision they name, any agency-specified parameter values, incident reporting duties and flow-down rules. Then ask the customer what CUI you will receive and check the categories in the CUI Registry. Many organizations discover that CUI arrives through more routes than they expected: email attachments, file-sharing links, engineering portals, paper drawings, USB drives from a test site. Map each route and each place the information is stored, processed or sent. Requirement 03.04.11 on information location exists precisely because you cannot protect what you cannot find.

Step 3: scope with intent

With the data map in hand, decide where CUI is allowed to live. Options range from protecting the whole corporate network to building a tightly separated enclave, often in a cloud environment with strong identity controls. Every component inside the boundary, plus those that protect it, will need to meet the requirements. Smaller scope means less cost, but only if the separation is real: shared administrator accounts, flat networks or unmanaged synchronisation tools quietly pull other systems back into scope.

Step 4: set parameters and policies

Record each ODP value, drawing on contract instructions first, then on laws and guidance, then on your own risk assessment. Write the policies and procedures that requirement 03.15.01 expects, and the rules of behaviour that users accept (03.15.03). Keep them short and specific to the CUI environment; a generic policy library that nobody follows will not survive an interview with an assessor.

Step 5: gap assessment

Walk through every requirement and every lettered part, comparing what exists with what is needed. Using the SP 800-171A determination statements as a checklist at this stage is efficient, because it shows exactly what an assessor will look for. Organizations moving from Revision 2 should use the NIST transition mapping to see which requirements changed, merged or are new, paying particular attention to the three new families and to every place where an ODP now demands a defined value.

Step 6: implement safeguards

Implementation usually mixes technology, process and people. Typical early wins include multi-factor authentication for all accounts (Revision 3 requires it for both privileged and non-privileged accounts), encryption of CUI in transit and at rest, central logging with regular review, hardened configuration baselines, timely patching, managed endpoints and controlled removable media. Process work includes access reviews, change control, incident handling and supplier management. People work includes awareness training, role-based training and screening.

Step 7: document the SSP and POA&M

The SSP describes the system as it really is: its components, the types of information, the threats of concern, the operating environment and connections, the roles, and for each requirement how it is satisfied or what is planned. It must be reviewed at the frequency you define and protected from disclosure, since it is effectively a map of your defences. The POA&M lists remaining weaknesses with planned actions and dates, and is updated after assessments, audits and monitoring.

Steps 8 and 9: assess and keep it running

Requirement 03.12.01 expects the organization to assess its own implementation at a defined frequency, and 03.12.03 expects a continuous monitoring strategy. Compliance is not a single event; accounts drift, software changes and new suppliers arrive. Many organizations run quarterly control checks, monthly vulnerability scans and an annual full assessment, but the right frequencies are those you set and justify.

Working with external service providers

Cloud and managed services are often the fastest way to meet many requirements, but they raise two questions: does the provider protect CUI to the required level, and who is responsible for which part of each requirement? Requirement 03.16.03 on external system services asks organizations to require providers to meet the relevant security requirements and to monitor them. In practice this means contractual commitments, a shared responsibility matrix, and evidence from the provider. Federal customers may set their own expectations here; DoD, for instance, has rules about cloud services holding its information that sit outside SP 800-171 itself.

Lesson 5 – Assessment, certification and compliance

NIST does not certify

There is no "SP 800-171 certificate" issued by NIST, and NIST does not accredit assessors for it. The publication is a set of requirements. Whether and how compliance is verified is decided by the agency in its contract. Some agencies rely on the organization's own statement, some ask for the SSP and POA&M as part of a proposal, some perform their own reviews, and some require independent assessments. Be cautious with any provider that sells a "NIST 800-171 certification": what they can offer is an assessment report, which is only as valuable as the customer considers it.

The assessment companion: SP 800-171A Revision 3

SP 800-171A Revision 3 provides an assessment procedure for every requirement, derived from the procedures in SP 800-53A. Each procedure has an assessment objective made of determination statements and a list of potential assessment methods and objects. When a requirement contains an ODP, the first determination statement checks that the parameter value has actually been defined. Identifiers mirror the requirements with a leading letter A, for example A.03.01.08.ODP[01] for the first parameter of the unsuccessful-logon requirement, or A.03.01.12.a[02] when a part is broken into finer statements.

Assessors gather evidence with three methods. To examine is to review or analyse artefacts such as policies, the SSP, configuration settings and audit records. To interview is to discuss the subject with individuals or groups, such as administrators or the incident response lead. To test is to exercise mechanisms or activities under specified conditions and compare actual with expected behaviour, for example attempting a logon without the second factor. The objects of assessment are specifications (documents), mechanisms (hardware, software, firmware), activities (things people do) and individuals. Each method can be applied with different depth and coverage, which set how rigorous and how broad the assessment is.

Figure 4 – The four assessment phases from SP 800-171A Revision 3 and the two possible findings for each determination statement.

Every determination statement receives one of two findings. Satisfied means the objective was met with an acceptable result. Other than satisfied means it was not, or that the assessor could not obtain enough information to decide. The second meaning is important: missing evidence counts against you, even if the safeguard exists. The assessment process runs in four phases: preparing, developing an assessment plan, conducting the assessment, and documenting, analysing and reporting the results.

SP 800-171A also describes the idea of an assurance case: a body of evidence organised into an argument that the claim "this system complies" is true. Evidence can come from many sources, including independent third-party assessments, product evaluations by testing laboratories (for example Common Criteria evaluations and FIPS 140 cryptographic module validations) and materials produced during the design, development and implementation of the system. A good assurance case is built continuously during design and operation, not assembled in the week before an assessor arrives.

How the defence sector fits in

The largest single user of SP 800-171 is the US defence industrial base. Defence contracts have long included DFARS clause 252.204-7012, which requires contractors to implement SP 800-171 and to report cyber incidents within 72 hours. When Revision 3 was published, DoD issued a class deviation that kept Revision 2 as the required version for that clause, and in July 2026 a DoD memo again called for baseline compliance with Revision 2. The Cybersecurity Maturity Model Certification (CMMC) programme, which verifies contractors' implementation, also assesses Level 2 against Revision 2, and in July 2026 DoD paused Phase 2 of the CMMC rollout, which from November 2026 would have made third-party certification widely required, while Phase 1 self-assessments stayed in force. DoD has published its own ODP values for Revision 3 for use when it does transition, but as of this course's verification date no transition date was set.

Outside defence, the FAR Council has proposed a government-wide CUI rule. A revised proposal published on 23 June 2026 would introduce new FAR clauses requiring Revision 3 for contractor systems handling CUI, ask offerors who cannot meet every requirement to disclose gaps in a POA&M, and allow agencies to add selected SP 800-172 requirements for critical programmes. At the time of writing that rule was still a proposal. The practical lesson: always read which revision your contract names, and expect Revision 3 to become the norm.

Self-assessment done well

Whatever the verification route, the organization's own assessment is the foundation. Use the 171A procedures, assign someone independent of the people who built the safeguards where possible, record evidence for each determination statement, and keep the results with the SSP. Leaders who sign compliance statements should understand what they are affirming; inaccurate claims to the government can carry legal consequences, including under the False Claims Act, as several US enforcement cases have shown.

Lesson 6 – Worked example

This example follows a fictional organization step by step. Names and details are invented for teaching.

The situation

Harbor Metrology is a 75-person company that designs precision measurement systems. It has just won a contract with a civilian federal agency to adapt a sensor for infrastructure monitoring. The contract states that the agency will share technical specifications marked as CUI and that Harbor must protect them according to NIST SP 800-171 Revision 3. The agency has supplied values for some parameters (for example, how quickly incidents must be reported to the agency) and left others for Harbor to define. Harbor already has basic IT hygiene: a cloud email and file platform, laptops with antivirus, and a small IT team of three people. It has never run a formal security programme.

Step 1 – Confirm what is required

The operations director, who has been named accountable executive, sits down with the contracts manager and the IT lead. They list the clauses, the revision named, the agency's ODP values, the incident reporting contact and the flow-down obligation for any subcontractor that will see CUI. They confirm with the agency's contracting officer which CUI categories are involved and check them in the CUI Registry. One subcontractor, a machining shop, will receive drawings, so it will need the same requirements flowed down.

Step 2 – Find the data

The team interviews engineers and discovers that specifications would naturally arrive by email, be saved in the general file share, be opened in a design tool on engineering laptops, be printed for the lab, and be sent to the machining shop. They draw the flows and list every system involved.

Step 3 – Decide the scope

Protecting the entire company would mean bringing sales, finance and the warehouse into scope. Instead, Harbor decides to create a CUI enclave.

Figure 5 – Harbor Metrology's scoping decision: an enclave for CUI, the components that protect it, and the separated corporate network.

Only six engineers who work on the contract receive enclave accounts. The enclave uses a separate cloud tenant suited to controlled information, separately managed laptops, and a dedicated lab workstation with a printer in a locked room. The identity provider and the firewall and log collector are in scope because they protect the enclave. The corporate email system is configured to reject CUI-marked attachments, and the agency is asked to deliver files through the enclave's secure file portal instead.

Step 4 – Parameters and policies

The IT lead builds an ODP register. Values provided by the agency go in first. For the rest, Harbor chooses values based on its risk assessment and common practice: for instance, how many failed logons trigger a lock and for how long, how often privileges are reviewed, how quickly inactive accounts are disabled and how often the SSP is reviewed. Each value has a short justification. The team writes concise enclave policies and rules of behaviour that the six engineers sign.

Step 5 – Gap assessment

Using the SP 800-171A determination statements as a checklist, the IT lead and an external consultant review all 97 requirements. They find strengths (patching and antivirus are in good shape) and gaps: no central log review, no documented incident response plan or test, no inventory of the lab equipment, no supply chain risk management plan, no process for unsupported components, and no formal media sanitisation procedure. The lab's measurement instrument runs an embedded operating system that cannot support multi-factor authentication.

Step 6 – Implement

Over four months Harbor deploys multi-factor authentication for all enclave accounts, encrypts laptops and the cloud tenant, centralises logs with a weekly review routine, writes and tests an incident response plan with a tabletop exercise, builds a component inventory, adopts a sanitisation procedure for drives, and drafts a short supply chain risk management plan that covers the machining shop and key software vendors. The instrument is placed on an isolated network segment with no internet access, reachable only from the lab workstation.

Step 7 – Document honestly

The SSP describes the enclave boundary, its components and connections, the threats Harbor considers most likely (phishing, stolen laptops, compromised suppliers), roles and, requirement by requirement, how each is met. The measurement instrument's inability to use multi-factor authentication is described in the SSP as an enduring exception, together with the compensating isolation. Two items still in progress, a data-loss prevention rule and role-based training for the IT team, are recorded on the POA&M with owners and target dates.

Step 8 – Assess

Before the first CUI arrives, Harbor asks a person who did not build the enclave to run a self-assessment using the 171A procedures. She examines the SSP, configuration exports and log review records, interviews the IT lead and two engineers, and tests a logon without the second factor and a USB drive insertion. Three determination statements are found other than satisfied: one policy document was never approved, the log review records skipped two weeks, and the printer was missing from the inventory. All three are fixed or added to the POA&M, and the report is filed with the SSP.

Step 9 – Keep it running

Harbor adopts a monitoring calendar: monthly vulnerability scans, quarterly access reviews, an annual incident response test and an annual full self-assessment. Six months later, when a new engineer joins and an old laptop is retired, the onboarding and sanitisation procedures run as written, and the SSP and inventory are updated. When the agency asks for evidence of compliance at a programme review, Harbor can provide the SSP, POA&M and assessment report within a day.

The lesson of the example: most of the effort went into understanding the data, choosing a scope and writing down decisions. The technology was the easier part.

Lesson 7 – Relationship to other standards and frameworks

SP 800-171 is part of a family of related publications and programmes. Knowing the neighbours helps you reuse work and avoid duplication.

Standard or programme	Owner	Relationship to SP 800-171 Rev 3
NIST SP 800-53 Rev 5 and SP 800-53B	NIST	The source catalogue and moderate baseline. SP 800-171 is a tailored subset rewritten for nonfederal organizations; each requirement references its source controls.
NIST SP 800-171A Rev 3	NIST	Companion assessment procedures for each requirement, with determination statements, methods and objects.
NIST SP 800-171 Rev 2	NIST	Superseded predecessor with 110 requirements in 14 families, still named in DoD clauses and CMMC Level 2 as of the verification date.
NIST SP 800-172 Rev 3	NIST	Optional enhanced requirements an agency may select for CUI linked to critical programmes or high-value assets facing advanced persistent threats. A supplement, never a replacement.
CMMC (32 CFR Part 170)	US DoD	A verification programme for defence contractors. Level 2 reuses SP 800-171 (currently Revision 2) and adds scoring, assessment types and affirmations.
ISO/IEC 27001	ISO and IEC	An international management-system standard with certification. Overlaps strongly in controls, but does not by itself demonstrate SP 800-171 compliance; NIST publishes a mapping of SP 800-53 to ISO/IEC 27001.
NIST Cybersecurity Framework 2.0	NIST	A high-level outcomes framework for any organization. Useful for governance and communication; SP 800-171 supplies the specific requirements for CUI.
FedRAMP Moderate	US General Services Administration programme	Authorisation of cloud services based on the SP 800-53 moderate baseline. Customers often choose FedRAMP-authorised or equivalent clouds for CUI enclaves.

Revision 2 to Revision 3 in one view

If your organization already implemented Revision 2, the main differences are: the basic and derived distinction is gone; requirements are now worded closely to SP 800-53 and are more specific; organization-defined parameters appear in many requirements; the previous "NFO" category (controls assumed to be already in place in any nonfederal organization, which in practice were often skipped) has been eliminated, so items such as written policies and procedures are now explicit requirements; three families were added; and numerous requirements were merged, so numbers do not map one to one. NIST's change-analysis spreadsheet and CPRT mappings are the best tools for planning a transition.

Using one programme to serve several obligations

Many organizations hold several obligations at once: a defence contract naming Revision 2, a civilian grant naming Revision 3, and a commercial customer asking for ISO/IEC 27001. A practical approach is to implement to Revision 3 where it is stricter, keep a mapping to Revision 2 identifiers for defence reporting, and use a single control set and evidence library tagged for each framework. This avoids running parallel programmes while meeting the exact wording each customer requires.

Common pitfalls and best practices

Common pitfalls

Assuming the newest revision automatically applies: the contract names the revision, and defence contracts still name Revision 2 at the time of writing.
Scoping too broadly by default, or too narrowly on paper: a flat network or shared administrator accounts silently pull "out-of-scope" systems back in.
Leaving organization-defined parameters blank or inconsistent, so assessors cannot tell what the organization promised to do.
Writing an SSP from a template that describes an ideal system rather than the real one, which collapses at the first interview or test.
Treating the POA&M as a parking place for gaps with no owners or dates, or listing permanent limitations there instead of in the SSP.
Ignoring the three new families, especially supply chain risk management and unsupported components, when moving from Revision 2.
Believing that a cloud provider's compliance covers the customer's responsibilities, without a documented responsibility split.
Forgetting flow-down: subcontractors who receive CUI need the same requirements in their agreements.

Best practices

Start from the data: identify CUI with the customer and the CUI Registry, then map every route and storage place before buying tools.
Build a deliberate security domain for CUI, document its boundary and keep the number of in-scope users and components small.
Maintain one ODP register with values, sources, owners and justifications, and reference it from the SSP.
Use the SP 800-171A determination statements as your implementation checklist and evidence index, not only at assessment time.
Collect evidence continuously, such as log review records, access review sign-offs and test results, so the assurance case builds itself.
Have someone independent of the implementers perform the periodic self-assessment, and act on the findings quickly.
Design for both revisions where needed: implement to the stricter requirement and keep mappings for each customer's reporting.
Brief leaders on what they are affirming and keep compliance statements accurate and up to date.

Summary and key takeaways

NIST SP 800-171 Revision 3 (May 2024) is the current catalogue of security requirements for protecting the confidentiality of CUI in nonfederal systems; it becomes binding only through contracts and agreements.
Its 97 requirements in 17 families are a tailored subset of the SP 800-53 moderate baseline, produced with the CUI, NCO, FED, ORC and N/A tailoring criteria.
Scope covers only components that process, store or transmit CUI or protect them, so a well-separated security domain can greatly reduce cost.
Organization-defined parameters make requirements specific and testable; the agency may set them, otherwise the organization must set and document them.
The SSP records the real system and enduring exceptions, while the POA&M tracks temporary weaknesses and their remediation.
SP 800-171A Revision 3 assesses each requirement through determination statements, using examine, interview and test, with findings of satisfied or other than satisfied.
NIST does not certify; verification is defined by the contracting agency, and DoD clauses and CMMC still reference Revision 2 as of October 2026.
SP 800-172 Revision 3 adds optional enhanced requirements for high-value CUI and never replaces the baseline.

Reflection questions

Think of an organization you know that receives sensitive government information. Where would CUI enter, where would it be stored, and how could you separate it into a security domain?
Pick three requirements that contain organization-defined parameters. What values would you choose for your environment, and how would you justify each one to a customer?
A component in your environment cannot meet one requirement for technical reasons. How would you decide whether it belongs in the SSP as an enduring exception or on the POA&M, and what compensating measures would you describe?
If your organization holds one contract naming Revision 2 and another naming Revision 3, how would you organise controls and evidence so that a single programme serves both?
For one requirement of your choice, what evidence would you prepare for each of the three assessment methods, and who in your organization would an assessor need to interview?