What Is NIST 800-171? The 110 Controls Federal Contractors Must Know

Federal contractors who handle Controlled Unclassified Information (CUI) operate under a specific set of cybersecurity requirements that many still misunderstand or underestimate. NIST 800-171, formally titled "Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations," defines 110 security controls organized into 14 families. If you're pursuing or maintaining a contract with the Department of Defense, you need to know these requirements cold—not just because they're mandatory, but because the CMMC assessment framework validates your implementation of them.

I've worked with dozens of defense contractors implementing NIST 800-171, and the pattern is consistent: organizations tend to focus on the technical controls they understand while glossing over the policy and process requirements that ultimately trip them up during assessments. The framework isn't optional guidance. It's a contractual obligation with compliance tracking through the Supplier Performance Risk System (SPRS) and validation through CMMC assessments.

Understanding the NIST 800-171 Framework

NIST Special Publication 800-171 was first published in 2015 and revised in 2020 (Revision 2). The framework derives from NIST 800-53, the control set used by federal agencies, but tailored for the non-federal organizations that work with them. Where 800-53 defines hundreds of controls appropriate for government systems, 800-171 distills these down to 110 requirements that balance security effectiveness with the operational realities of contractor environments.

The controls address 14 security families: Access Control, Awareness and Training, Audit and Accountability, Configuration Management, Identification and Authentication, Incident Response, Maintenance, Media Protection, Personnel Security, Physical Protection, Risk Assessment, Security Assessment, System and Communications Protection, and System and Information Integrity. Each family contains between three and 22 individual requirements, each with specific implementation expectations.

What makes NIST 800-171 particularly challenging is that it's written as a requirements document, not an implementation guide. The controls describe what you must achieve, but not specifically how to achieve it in your environment. This ambiguity is intentional—it allows for flexibility across different organizational contexts—but it also creates interpretation challenges that I see contractors struggle with repeatedly.

The Access Control Family: Where Most Organizations Start

The Access Control family contains 22 requirements, more than any other family, and addresses how you limit system access to authorized users, processes, and devices. This is typically where organizations begin their NIST 800-171 implementation, partly because access control feels intuitive and partly because the controls build on practices many already have in place.

Requirements like 3.1.1 (limit system access to authorized users) and 3.1.2 (limit system access to the types of transactions and functions authorized users are permitted to execute) seem straightforward until you start mapping them to actual systems. The challenge isn't establishing access controls on your primary CUI repositories—most organizations already protect their file servers and databases reasonably well. The challenge is identifying all the systems where CUI might flow or be processed, then implementing consistent access controls across that entire scope.

In my experience, contractors regularly miss CUI in collaboration platforms, project management systems, backup repositories, and development environments. You might have excellent access controls on your document management system while CUI freely circulates in Slack channels or SharePoint sites with overly permissive sharing settings. The Access Control family requires you to identify all locations where CUI exists and apply appropriate restrictions across all of them.

Least Privilege and Separation of Duties

Requirements 3.1.5 (employ the principle of least privilege) and 3.1.4 (separate duties of individuals) cause particular confusion. Least privilege doesn't mean "minimal access that prevents people from doing their jobs." It means granting only the access necessary to perform assigned tasks—no more, no less. This requires understanding job functions well enough to define appropriate access boundaries, then actually enforcing those boundaries rather than defaulting to broad permissions because it's administratively easier.

Separation of duties becomes challenging in small organizations where the same person might perform multiple roles. The requirement exists to prevent one individual from having complete control over critical transactions or security functions, but when you're a 15-person engineering firm, you may not have the luxury of separating the person who manages your network from the person who manages user accounts. NIST 800-171 doesn't provide small-organization exemptions, but assessors do consider compensating controls when separation isn't feasible—as long as you've documented why separation isn't practical and what alternative controls you've implemented.

Configuration Management and System Integrity

The Configuration Management family (nine requirements) and System and Information Integrity family (17 requirements) address how you establish and maintain secure system configurations, monitor for security issues, and remediate vulnerabilities. These families contain some of the most technically complex requirements in the framework, but also some of the most frequently failed controls during assessments.

Configuration management starts with establishing secure baseline configurations (3.4.1) and maintaining them throughout system lifecycles (3.4.2). This sounds basic, but requires documented configuration standards, change control processes, and actual verification that systems comply with those standards. I routinely see organizations with documented baseline configurations that nobody references and systems deployed with default settings that directly violate their own standards.

The flaw remediation requirement (3.14.1) specifies that you must identify, report, and correct system flaws in a timely manner. "Timely" isn't defined in the control, which creates anxiety for contractors who want a specific patching timeline. The reality is that "timely" depends on the severity of the vulnerability and the risk to your CUI. Critical vulnerabilities in internet-facing systems processing CUI need patching within days, not months. Lower-severity issues on isolated systems have more flexibility. What you can't do is simply ignore vulnerabilities or implement a "we'll patch when we get around to it" approach.

Malicious Code Protection

Requirement 3.14.2 mandates protection against malicious code at appropriate locations. Most organizations interpret this as "deploy antivirus software everywhere," which isn't wrong but misses the broader requirement. Anti-malware protection should exist at multiple layers—endpoints, email gateways, network boundaries, servers—and the protection mechanisms should be current, actively monitored, and actually generate alerts that someone responds to.

I've seen too many environments where antivirus is installed but not actively managed. Definitions are outdated, agents aren't reporting, alerts go to mailboxes nobody monitors. Having the software deployed isn't enough. You need evidence of active protection and response to detections, which means monitoring dashboards, reviewing alerts, and documenting actions taken when malware is detected.

The Controls That Trip Up Even Experienced Teams

Certain NIST 800-171 requirements consistently cause problems across organizations, regardless of size or sophistication. These aren't necessarily the most technically complex controls, but they're the ones where the gap between what organizations think they've implemented and what assessors expect to see is widest.

Audit and Accountability

The Audit and Accountability family contains 11 requirements focused on creating, protecting, and retaining audit records that enable security monitoring and incident investigation. Requirement 3.3.1 requires you to create audit records containing sufficient information to establish what events occurred, when they occurred, where they occurred, the sources of events, and the outcomes of events.

Most systems can generate logs. The question is whether you've configured them to capture the right events and whether those logs contain the information the requirement specifies. Too often, I see logging enabled at default settings that miss security-relevant events or don't capture enough detail to reconstruct what actually happened. You need to define what events are security-relevant in your environment, ensure those events are logged with sufficient detail, and verify that logs are actually being generated and retained.

Requirement 3.3.3 requires you to review and update logged events, which means you can't just set logging once and forget it. As your systems change and new threats emerge, the events you log should evolve. This should be part of your change management and risk assessment processes—not a separate annual task that gets documented in a policy but never actually performed.

Incident Response Reality

The Incident Response family contains eight requirements that define how you establish incident response capability, detect and report incidents, and respond to detected events. Requirement 3.6.1 requires you to establish an operational incident-handling capability including preparation, detection, analysis, containment, recovery, and user response activities.

Many organizations document incident response plans that describe ideal processes but have never actually tested whether those processes work. The requirement isn't satisfied by having a document in SharePoint. You need documented procedures, assigned roles, training for incident response personnel, and evidence that you've tested your capability. This doesn't necessarily require expensive tabletop exercises—though those help—but you need something beyond a plan that's never been validated.

Requirement 3.6.2 requires you to track, document, and report incidents to appropriate officials and authorities. The "appropriate" qualifier creates questions: who needs to be notified, under what circumstances, and within what timeframe? For DoD contractors, the answer includes reporting cyber incidents involving CUI to the DoD through the DIB Cyber Security/CS program portal within 72 hours. Many contractors don't realize this reporting obligation exists until they have an incident, which creates compliance issues on top of the security problem.

Media Protection and Data Handling

The Media Protection family's eight requirements address how you protect, control, sanitize, and dispose of system media—both physical and digital. This family causes confusion because "media" sounds like physical items (USB drives, backup tapes, hard drives) but the controls apply equally to cloud storage, SaaS platforms, and virtual environments.

Requirement 3.8.3 requires you to sanitize or destroy system media containing CUI before disposal or release for reuse. Organizations with physical hardware disposal processes often understand this requirement, but the same organizations struggle with sanitization in cloud environments. When you delete a file from SharePoint or end a cloud service contract, how do you verify that CUI has been properly sanitized? The requirement doesn't exempt cloud services—you need assurance that data is properly destroyed even when you don't control the underlying infrastructure.

I've worked with contractors who assume their cloud provider's data deletion processes satisfy the requirement without ever verifying what those processes actually entail. This creates risk during assessments and, more importantly, creates actual security exposure if your CUI persists in provider environments after you believe it's been deleted. You need documented processes for sanitization across all media types, including cloud storage, with verification that sanitization occurred.

Portable Media Controls

Requirement 3.8.7 requires you to control the use of removable media on systems. This control addresses the risk of data exfiltration and malware introduction through USB drives, external hard drives, and similar devices. The requirement doesn't mandate banning removable media entirely, but it does require controls that limit use to authorized purposes and users.

Technical controls like USB port blocking or device whitelisting provide strong enforcement, but they're not the only approach. If your operational requirements demand portable media use, you can implement procedural controls—authorized media with encryption, logging of media use, malware scanning of connected devices. What you can't do is simply allow unrestricted removable media use without any controls or documentation.

Personnel Security and Physical Protection

The Personnel Security family contains two requirements, while Physical Protection contains six. Together, they address the human and physical dimensions of security that purely technical controls can't solve.

Requirement 3.9.1 requires you to screen individuals prior to authorizing access to CUI, and 3.9.2 requires you to ensure that CUI is protected during and after personnel actions such as terminations and transfers. Background screening for federal contractor personnel isn't new—many positions require security clearances or public trust investigations—but NIST 800-171 requires screening appropriate to the risk and legal requirements for all individuals with CUI access, not just those with clearances.

For positions without clearance requirements, "appropriate screening" might mean employment verification, criminal background checks, and reference checks. The key is conducting screening that's commensurate with the level of access granted and the sensitivity of CUI the individual will handle. You also need to document your screening criteria and evidence that screening occurred.

Physical protection requirements address controlling physical access to systems and facilities where CUI is processed or stored (3.10.1), protecting and monitoring physical facilities (3.10.2), and controlling physical access to devices (3.10.5). Organizations with dedicated facilities often have these controls in place, but contractors working from home offices or shared coworking spaces face challenges implementing physical controls in environments they don't fully control.

If your staff works remotely handling CUI on laptops in home offices, you need physical security controls appropriate to that environment. This might include cable locks for devices, storing laptops in locked cabinets when not in use, and limiting where CUI can be accessed. These controls feel less sophisticated than datacenter access control systems, but they address the same requirement in a different operational context.

System and Communications Protection

The System and Communications Protection family contains 20 requirements focused on protecting information during transmission and at rest, establishing secure network boundaries, and implementing cryptographic controls. This family contains some of the most technically prescriptive requirements in NIST 800-171.

Requirement 3.13.8 requires you to implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. This is the "encrypt data in transit" requirement. For most organizations, this means implementing TLS for web communications, VPNs for remote access, and encrypted protocols for file transfers and email.

The "unless otherwise protected by alternative physical safeguards" clause creates confusion. It doesn't mean you can skip encryption because your network is physically secure—your building locks don't protect data transmitted over the internet. The clause addresses scenarios like physically isolated networks where data never leaves controlled spaces, which is rare in contractor environments. The practical interpretation for most organizations is to encrypt CUI in transit across all networks.

Boundary Protection

Requirements 3.13.1 through 3.13.5 address network boundary protection through managed interfaces, denial-by-default policies, network segmentation, and boundary protection devices. These requirements establish that you need defined network boundaries where CUI systems connect to external networks, and those boundaries need active protection through firewalls or similar devices configured to deny traffic by default and permit only specifically authorized communications.

The pattern I see is organizations implementing perimeter firewalls but failing to segment internal networks or control east-west traffic between systems. NIST 800-171 expects you to isolate CUI systems from non-CUI systems and from each other based on risk. A flat network where any compromised endpoint can reach any system doesn't satisfy the segmentation requirements regardless of how strong your perimeter controls are.

Network segmentation doesn't require complex microsegmentation or zero-trust architecture, though those approaches can satisfy the requirements. You can achieve effective segmentation through VLANs, firewall rules, and access controls that limit which systems can communicate with CUI repositories. The key is designing intentional boundaries and enforcing them technically rather than assuming physical network isolation provides sufficient protection.

Assessment, Continuous Monitoring, and Plans of Action

The Security Assessment family contains three requirements that specify how you assess security control implementation, develop and implement remediation plans, and monitor security controls on an ongoing basis. These requirements establish that NIST 800-171 compliance isn't a one-time achievement but an ongoing process of assessment and improvement.

Requirement 3.12.1 requires periodic assessments of security controls to determine if they're implemented correctly, operating as intended, and producing desired outcomes. The requirement doesn't specify assessment frequency—"periodic" is intentionally flexible—but annual assessments are common practice and align with CMMC assessment cycles. What matters is that assessments actually evaluate control effectiveness, not just verify that documentation exists.

When assessments identify deficiencies, requirement 3.12.2 requires you to develop and implement plans of action and milestones (POA&Ms) for remediation. POA&Ms aren't simply lists of things you intend to fix eventually. They're documented remediation plans with specific actions, responsible parties, target completion dates, and resources required. More importantly, POA&Ms need to show progress—they should be living documents that reflect actual remediation work, not static plans that never get executed.

I've seen contractors maintain the same POA&M items year over year with dates repeatedly extended but no actual progress toward remediation. This approach doesn't satisfy the requirement and creates significant risk during CMMC assessments where POA&Ms are scrutinized for both substance and progress. If you can't remediate a deficiency within a reasonable timeframe, you need to examine whether the issue is actually a POA&M item or a fundamental gap in your security program that requires different treatment.

Continuous Monitoring

Requirement 3.12.4 requires you to develop, document, and periodically review and update system security plans. This requirement establishes that your security program documentation needs to reflect current reality, not historical configurations or aspirational goals. When you make significant system changes, deploy new services, or modify your security architecture, your system security plan should be updated to reflect those changes.

Organizations frequently treat security plans as compliance documents produced for assessments rather than operational documentation used to guide security decisions. This creates plans that are outdated before they're finalized and that provide little value beyond satisfying documentation requirements. A useful system security plan describes your current security architecture, documents control implementations, identifies system boundaries and data flows, and serves as a reference for both your team and assessors. If your security plan doesn't help you understand and manage your security posture, it's probably not adequate for the requirement.

The Controls You Might Not Think About

Beyond the commonly discussed technical and process controls, NIST 800-171 includes requirements that organizations sometimes overlook until they're preparing for assessment. These aren't necessarily difficult controls, but they're easy to miss if you focus exclusively on network security and access control.

The Awareness and Training family contains three requirements mandating security awareness training for all users, role-based security training for personnel with security responsibilities, and training updates to reflect changes to systems or threats. Most organizations provide some form of security awareness training, but the requirement specifies training before authorizing access to systems and at least annually thereafter, with additional training when system changes or new threats require it.

Training needs to be documented—who received training, when it occurred, what content was covered—and the training content needs to be relevant to your organization's environment and the CUI your personnel handle. Generic cybersecurity awareness videos might provide baseline education, but they don't satisfy the requirement if they don't address the specific risks and requirements associated with CUI protection in your systems.

The Maintenance family contains six requirements addressing how you perform, control, and document system maintenance. Requirement 3.7.1 requires you to perform maintenance on systems and 3.7.2 requires effective controls on maintenance tools. These requirements address both routine maintenance and emergency repairs, both physical and remote maintenance, and both internal personnel and external service providers.

When external technicians need access to systems processing CUI for maintenance or support, you need controls governing that access—escorted access, monitoring of maintenance activities, sanitization of equipment after maintenance, and documentation of what maintenance occurred. Cloud service providers performing maintenance on systems hosting your CUI create similar requirements: you need to understand what maintenance activities occur, how those activities are controlled, and what access providers have to your data during maintenance.

Making NIST 800-171 Work in Your Environment

After working through what NIST 800-171 requires, the strategic question becomes how to implement these controls in your specific operational context without either under-securing CUI or implementing security that prevents your organization from functioning effectively.

Start by accurately scoping where CUI exists in your environment. You can't protect what you haven't identified, and you can't scope security controls appropriately if you don't know where CUI flows. Many contractors discover during this process that CUI has proliferated beyond their primary systems into collaboration platforms, personal devices, and third-party services that weren't part of their original security design. Once you know where CUI actually exists—not where you think it should be—you can scope security controls appropriately.

Prioritize controls based on your risk profile and assessment timeline. If you're facing a CMMC assessment in six months, you need to focus on high-risk gaps and controls that assessors scrutinize most carefully. If you're beginning implementation with more time, you can phase controls in a logical sequence that builds foundational capabilities before more advanced requirements.

The difference between CMMC Level 1 and Level 2 requirements matters for prioritization. Level 1 assessments validate 17 basic security requirements from NIST 800-171, while Level 2 assesses all 110 controls. If you're pursuing Level 1 certification initially, focus on those 17 requirements, but understand that you'll eventually need to implement the full control set if your contracts require Level 2 or higher.

Document everything, but make documentation useful rather than performative. Assessors will review your policies, procedures, system security plans, and control implementation documentation. This documentation needs to exist and needs to accurately reflect your actual implementations. But documentation that merely satisfies assessors without helping your team understand and maintain security controls becomes outdated and useless quickly. Document in a way that serves both compliance and operational needs—your team should be able to use your security documentation to understand how to perform security functions correctly, not just pull documents to show assessors.

Build assessment and monitoring into your regular operations rather than treating them as pre-certification activities. Organizations that conduct internal assessments only when preparing for external assessments miss opportunities to identify and remediate issues before they become compliance failures. Regular internal reviews—quarterly or semi-annually depending on your environment—help you maintain compliance continuously rather than scrambling before each assessment cycle.

The cybersecurity landscape for defense contractors has fundamentally shifted with CMMC enforcement. NIST 800-171 compliance is no longer something you can defer or superficially document. Contracts are already requiring CMMC certification, and that certification validates actual implementation of these controls. Organizations that invested in genuine security programs built on NIST 800-171 are passing assessments and winning contracts. Those that treated compliance as a documentation exercise are facing failed assessments and contract ineligibility.

If you're leading security or compliance for a defense contractor, your job is translating these 110 requirements into operational security that your organization can sustain. That means technical controls that actually work, processes that people can follow, and documentation that reflects reality. It means making decisions about control implementation that balance security effectiveness, operational impact, and assessment risk. And it means building a program that maintains compliance over time rather than achieving it once and hoping it holds.

The organizations that succeed with NIST 800-171 are those that treat it as a security framework rather than a compliance checklist—not because that sounds better, but because assessors evaluate whether controls actually protect CUI, not just whether you have documentation claiming they do. Build security that works, document what you've built, test that it functions as intended, and fix gaps as you find them. That's what NIST 800-171 compliance actually requires.