Module 5: NIST SP 800‑171 Rev. 3 – Core Requirements for CUI

Step 1 – Where NIST SP 800‑171 Rev. 3 Fits in the CUI Story

You’ve already seen what CUI is (Module 3) and how impact levels work (Module 4). Now we connect those ideas to the main standard that tells nonfederal organizations how to protect CUI:

> NIST Special Publication 800‑171 Revision 3 – Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations.

Key current facts (relative to today – December 2025):

• Rev. 3 was finalized in May 2024, replacing Rev. 2 as the current guidance.
• It is the primary technical reference used by U.S. federal agencies (especially DoD) when they require contractors and IT/cloud providers to protect CUI.
• For DoD contractors, SP 800‑171 Rev. 3 underpins the updated CMMC 2.x / 3.0 ecosystem and will increasingly appear in contracts.

High‑level purpose:

• Translate the more complex NIST SP 800‑53 (federal systems) into a streamlined set of requirements for nonfederal systems (e.g., your company’s data center, your SaaS platform, or your MSP environment) that store, process, or transmit CUI.

Think of SP 800‑171 Rev. 3 as a security checklist plus design guide for:

• IT service providers hosting government data
• Cloud service providers (IaaS/PaaS/SaaS) supporting federal missions
• Defense contractors, research universities, and integrators with CUI in their networks

In this module you’ll learn:

1. When it applies to IT service providers
2. The 17 security requirement families in Rev. 3
3. What changed from Rev. 2 to Rev. 3 and why it matters
4. How organization‑defined parameters (ODPs) let you tailor the standard to your environment

Step 2 – Scope: When Does SP 800‑171 Rev. 3 Apply?

NIST SP 800‑171 Rev. 3 applies whenever a federal agency requires you to protect CUI on nonfederal systems.

Typical triggers for IT service providers and cloud providers:

• Your contract includes clauses like:
• FAR 52.204‑21 (basic safeguarding of covered contractor information systems) – baseline cyber hygiene
• DFARS 252.204‑7012 – Safeguarding Covered Defense Information and Cyber Incident Reporting
• CUI‑related clauses in other agency contracts that explicitly reference NIST SP 800‑171
• You host or process CUI in:
• Your cloud platform (e.g., a SaaS product used by a federal agency)
• Your managed services environment (e.g., MSP/MSSP monitoring networks that contain CUI)
• Your development, test, backup, or support systems that access CUI

Scope is system‑based, not company‑wide by default.

• The standard applies to the systems and environments where CUI is stored, processed, or transmitted.
• Many contractors create a “CUI enclave” – a logically or physically separated part of their infrastructure that handles CUI, so they don’t have to apply all requirements to the entire enterprise.

Connection to earlier modules:

• From Module 4, you know that data is categorized by impact levels (FIPS 199: low/moderate/high).
• SP 800‑171 assumes CUI is at most *Moderate* impact for confidentiality. (If it were High, SP 800‑53 controls or other overlays are usually required.)

Practical rule of thumb:

> If your system touches CUI and your contract mentions NIST SP 800‑171, you are expected to implement the Rev. 3 requirements (or demonstrate a path to get there).

Step 3 – Quick Scenario: Does SP 800‑171 Apply?

Read the scenarios and decide Yes/No: Does SP 800‑171 Rev. 3 likely apply? (Mentally answer before reading the explanation.)

1. SaaS bug tracking tool used internally by your company. No federal customers; only commercial clients.

• Your answer? Yes or No?
• Explanation: Likely No – if there’s no federal customer and no CUI is stored, processed, or transmitted, SP 800‑171 doesn’t apply.

1. Cloud‑hosted document management system used by a DoD program office. The contract says the system will store export‑controlled technical data and references DFARS 252.204‑7012.

• Your answer? Yes or No?
• Explanation: Yes – export‑controlled technical data is typically CUI. The DFARS clause triggers SP 800‑171 requirements for the system handling that data.

1. A managed security service provider (MSSP) that monitors a defense contractor’s network via logs and remote tools. Logs may include filenames and snippets of CUI.

• Your answer? Yes or No?
• Explanation: Yes – the MSSP’s systems now process or transmit CUI (even indirectly), so they fall in scope.

Use these examples when you’re trying to decide: “Is this system in or out of SP 800‑171 scope?”

Step 4 – Structure of SP 800‑171 Rev. 3: 17 Security Families

SP 800‑171 Rev. 3 organizes requirements into 17 security requirement families. Each family has:

• A high‑level security outcome (what you should achieve)
• Basic and sometimes Enhanced requirements
• Organization‑defined parameters (ODPs) you must fill in (e.g., time limits, roles)

Here are the 17 families in Rev. 3 (some renamed/realigned from Rev. 2):

1. Access Control (AC) – Who can access what, and under what conditions
2. Awareness and Training (AT) – Making sure people know how to handle CUI
3. Audit and Accountability (AU) – Logging, monitoring, and traceability
4. Configuration Management (CM) – Baseline configs, change control, secure builds
5. Identification and Authentication (IA) – User IDs, passwords, MFA, device identity
6. Incident Response (IR) – Detecting, reporting, and responding to incidents
7. Maintenance (MA) – Secure maintenance, including remote maintenance
8. Media Protection (MP) – Protecting CUI on physical and digital media
9. Personnel Security (PS) – Vetting and managing personnel with access to CUI
10. Physical Protection (PE) – Controlling physical access to systems and facilities
11. Planning (PL) – Security plans, system boundaries, and documentation
12. Risk Assessment (RA) – Identifying and prioritizing risks to CUI
13. Security Assessment and Monitoring (CA) – Ongoing assessment, POA&Ms, continuous monitoring
14. System and Communications Protection (SC) – Network security, encryption, segmentation
15. System and Information Integrity (SI) – Patching, malware protection, integrity checks
16. Program Management (PM) – Organization‑level governance of the CUI protection program
17. Supply Chain Risk Management (SR) – Managing risks from suppliers, cloud providers, and other third parties

What’s new compared to Rev. 2?

• PM and SR are more clearly integrated, emphasizing enterprise‑level governance and supply chain security.
• The structure is more outcome‑focused, aligning better with SP 800‑53 Rev. 5 while staying leaner for nonfederal systems.

Step 5 – Concrete Examples from 4 High‑Impact Families

Let’s look at four families that are especially important for IT and cloud providers, with Rev. 3‑style examples.

1. Access Control (AC)

Goal: Only authorized users and devices access CUI, and only as needed.

Rev. 3‑style requirements include:

• Limit access to CUI to authorized users, processes, and devices.
• Enforce least privilege and separation of duties.
• Control remote access and session timeout.

Example (cloud provider):

• Only members of the “Gov‑CUI‑Ops” group can access the CUI production database.
• Admin access requires MFA and is restricted to company‑managed laptops.
• Idle admin sessions disconnect after 15 minutes (an organization‑defined parameter).

---

2. Identification and Authentication (IA)

Goal: Prove who (or what) is accessing CUI systems.

Rev. 3‑style requirements include:

• Use unique IDs for users and devices.
• Enforce MFA for network and privileged access.
• Protect authentication secrets (passwords, tokens).

Example (MSP):

• Every technician has a unique account; no shared “admin” logins.
• Technicians use MFA (e.g., FIDO2 key + password) to access remote management tools that can reach CUI systems.

---

3. Audit and Accountability (AU)

Goal: Record and review events that could affect CUI.

Rev. 3‑style requirements include:

• Log security‑relevant events (logins, admin actions, changes to access, etc.).
• Protect logs from tampering.
• Regularly review and analyze logs.

Example (SaaS vendor):

• All access to CUI data is logged (user ID, timestamp, action, source IP).
• Logs are centralized in a SIEM with immutable storage.
• Security team reviews alerts daily and high‑risk events weekly.

---

4. Incident Response (IR)

Goal: Prepare for, detect, and respond to security incidents involving CUI.

Rev. 3‑style requirements include:

• Maintain an incident response plan covering CUI systems.
• Report incidents to the relevant federal agency (e.g., DoD reporting timelines under DFARS).
• Conduct post‑incident reviews and update controls.

Example (defense contractor):

• Has a documented CUI‑IR playbook with roles, contact lists, and timelines.
• If CUI is suspected to be exfiltrated, they:

1. Contain the incident (isolate systems)
2. Collect forensic data
3. Notify DoD within the contractually required timeframe
4. Update access controls and training based on lessons learned

Step 6 – Key Changes from Rev. 2 to Rev. 3 (Why 2024 Mattered)

NIST SP 800‑171 Rev. 3 (finalized in 2024) made important updates that affect contractors and cloud providers.

1. Better Alignment with NIST SP 800‑53 Rev. 5

• Rev. 3 re‑mapped and rewrote many requirements to align with the control language in SP 800‑53 Rev. 5.
• This helps large organizations that already use SP 800‑53 for other systems.

2. Fewer, Clearer Requirements

• Some overly detailed or redundant controls were removed or consolidated.
• The focus is on outcomes (what must be achieved) rather than prescribing one specific way.

3. Stronger Emphasis on:

• Supply Chain Risk Management (SR):
• You must assess and manage risks from your vendors, cloud providers, and sub‑contractors that may handle CUI.
• Program Management (PM):
• Requirements for a governance structure, policies, and assigned roles for protecting CUI across the organization.

4. More Use of Organization‑Defined Parameters (ODPs)

• Instead of hard‑coding values (e.g., “log review every 7 days”), Rev. 3 often says:
• “Review logs at an organization‑defined frequency.”
• This pushes organizations to think and justify their choices based on risk.

5. Clarified Nonfederal Focus

• Rev. 3 reinforces that it is for nonfederal systems, not for federal agencies themselves.
• It explicitly expects that organizations will tailor requirements to their environment, as long as the security outcomes are met.

For you as an IT or cloud provider in 2025, this means:

• You need to understand and document your tailoring decisions.
• You must manage third‑party risk more explicitly (e.g., your own cloud infrastructure providers, ticketing tools, support vendors).

Step 7 – Organization‑Defined Parameters (ODPs) and Tailoring

An important Rev. 3 concept is organization‑defined parameters (ODPs).

ODPs are blanks you must fill in within a requirement. For example:

• “Terminate user sessions after an organization‑defined period of inactivity.”
• “Review audit records at an organization‑defined frequency.”

This gives flexibility, but also creates responsibility:

1. You must choose values (e.g., 15 minutes, 24 hours, 7 days) based on risk.
2. You must document and justify your choices.
3. Your choices will be examined during assessments or audits.

Tailoring means:

• Deciding how you implement each requirement in your environment.
• In some cases, justifying why a requirement is not applicable (N/A) to a particular system without weakening security.

For IT service providers, tailoring often includes:

• Defining different ODP values for:
• Production CUI systems vs. internal non‑CUI systems
• High‑risk vs. lower‑risk CUI applications
• Using compensating controls when the exact wording of a requirement doesn’t fit your architecture (e.g., using a zero‑trust proxy instead of a traditional VPN).

Step 8 – Example: Documenting ODPs and Tailoring (Template)

Here’s a simple YAML‑style template you might use to document ODPs and tailoring decisions for SP 800‑171 Rev. 3 in an IT provider environment.

```yaml

system_name: "CUI-Prod-Cloud-Env"

impact_level: "Moderate Confidentiality" # From FIPS 199 / Module 4

control_family: "Access Control (AC)"

requirement_id: "AC-LIMIT-SESSION"

requirement_text: >

Terminate or lock user sessions after an organization-defined

period of inactivity.

organizationdefinedparameters:

inactivitytimeoutminutes: 15

rationale: >

15 minutes balances security with usability for administrators

managing production CUI workloads. Shorter timeouts were

tested and caused frequent disruptions during maintenance

windows.

implementation: >

Enforced via IdP session policies and OS-level screen locks

on all admin workstations. Central configuration managed via

configuration management system (Ansible).

assessment_evidence:

• screenshot: "IdP-session-policy-AC-LIMIT-SESSION.png"
• configfile: "ansible/roles/cuisession_timeout/tasks/main.yml"

status: "Implemented"

last_reviewed: "2025-09-15"

reviewed_by: "CUI Security Architect"

```

You don’t have to use YAML specifically; the key idea is to explicitly record:

• The ODP values you chose
• Why you chose them
• How you implemented them
• Evidence you can show assessors

Step 9 – Check Understanding: Scope and Families

Answer the question, then check the explanation.

Step 10 – Review Key Terms

Flip these mental flashcards (read the front, then try to recall the back before reading it).

Step 11 – Mini Design Exercise: Applying Rev. 3 to a Cloud App

Imagine you are the security lead for a multi‑tenant SaaS project‑management tool used by a civilian federal agency to manage projects that include CUI.

Your contract references NIST SP 800‑171 and says CUI may be stored in project files and comments.

Mentally work through these prompts (you can jot notes if you like):

1. Scope:

• Which components are in scope for SP 800‑171?
• Web front‑end? API? Database? Backups? Logging system? Support tools?

1. Three key families to prioritize first:

• From the 17 families, which three would you prioritize in the first 90 days, and why?

1. Example ODPs:

• Propose ODP values for:
• Session timeout for admin users
• Frequency of log review
• Time window for applying critical security patches

1. Supply chain considerations:

• List two third‑party services (e.g., cloud infrastructure, email support tool, logging SaaS) that might also touch CUI or metadata about CUI.
• How would you assess and manage their risk (e.g., contract clauses, security questionnaires, technical controls)?

Compare your answers to the ideas in previous steps. This is exactly the kind of reasoning expected from junior security engineers working with SP 800‑171 in real organizations.