NIST 800-171: All 14 Control Families Explained

Executive Summary

Key takeaways: - NIST SP 800-171 Rev 2 has 110 security requirements across 14 control families — CMMC Level 2 maps to all 110 - The 14 families are not equal in complexity. Access Control (22 requirements), System and Communications Protection (16), and Identification and Authentication (11) account for nearly half the total - Personnel Security (2 requirements) and Incident Response (3 requirements) are the smallest families — but they generate findings disproportionate to their size because contractors treat them as administrative afterthoughts - Some families have hard dependencies: you can't satisfy Audit and Accountability without infrastructure that Identification and Authentication provides; you can't satisfy Configuration Management without the inventory that System and Information Integrity's scanning produces - This article covers Rev 2, which is the version CMMC Level 2 is built on. Rev 3 exists but isn't in CMMC yet

NIST SP 800-171 was designed to protect Controlled Unclassified Information (CUI) on non-federal systems. It's organized into 14 control families — the same structure as NIST SP 800-53, compressed to the requirements most relevant to contractors rather than federal agencies.

If you're working toward CMMC Level 2, you're implementing all 110 requirements in all 14 families. There's no tiering within Level 2 — either all 110 are met, or you have a POA&M. Understanding each family well enough to sequence your implementation and brief your assessor is a basic competency requirement for anyone running a CMMC program.

Here's each family, with control count, what it covers, what assessors actually look for, and where contractors most often stumble.

1. Access Control (AC) — 22 Requirements

Access Control is the largest family and the one assessors spend the most time on. It covers who can access what, under what conditions, and through what mechanisms.

The 22 requirements address: limiting system access to authorized users and processes (3.1.1, 3.1.2), enforcing least privilege (3.1.5, 3.1.6), separating duties (3.1.4), controlling remote access (3.1.12–3.1.14), managing wireless access (3.1.16, 3.1.17), and controlling information flow (3.1.3).

What assessors focus on: Access control lists showing who has access to what CUI systems and why. Evidence of regular access reviews. MFA enrollment for remote access and privileged accounts. Session lock configurations (15-minute inactivity timeout is the standard benchmark). Network diagrams showing where CUI data flows.

Most common findings: - Shared accounts ("the engineering login") on CUI systems - Admin accounts used for daily work rather than dedicated privileged accounts - No documentation of the access review process, or reviews that exist only on paper - Remote access allowed without MFA

Implementation note: Budget $20,000–$80,000 for identity infrastructure if you're starting from scratch — Microsoft Entra ID (formerly Azure AD) with Intune-managed devices is the most common path for Microsoft shop contractors. The investment buys you centralized identity management that satisfies multiple AC and IA requirements simultaneously.

2. Awareness and Training (AT) — 3 Requirements

Three requirements: security awareness training for all users (3.2.1), role-based training for personnel with security responsibilities (3.2.2), and insider threat awareness training (3.2.3).

Small family, but assessors verify it through interviews, not just documentation. Training completion records are necessary but not sufficient — assessors will ask employees whether they understand CUI handling procedures, how to report an incident, and what the insider threat indicators are. If employees can't answer basic questions, it's a finding regardless of whether they clicked through a training module.

What assessors focus on: Training completion records with dates, content descriptions, and employee acknowledgments. Evidence that the training specifically covers CUI — not just generic security awareness. Separate records for privileged users who received role-specific training.

Most common findings: - Annual training with no record of what the training covered - Generic security awareness training that doesn't mention CUI, DoD requirements, or insider threats - No training records for executives and managers (they're users too)

Implementation note: Dedicated security awareness platforms — KnowBe4, Proofpoint Security Awareness Training, SANS Security Awareness — handle delivery and tracking. Budget $15–$30/user/year. Whatever platform you use, customize the content to include CUI identification and handling procedures specific to your contracts.

3. Audit and Accountability (AU) — 9 Requirements

Audit and Accountability covers the creation, protection, retention, and review of audit logs. You need to be able to answer: what happened on your CUI systems, when, and by whom?

The nine requirements cover: creating audit records (3.3.1), ensuring users are accountable for their actions (3.3.2), reviewing and analyzing logs (3.3.4, 3.3.5), reporting audit findings (3.3.6), protecting audit records (3.3.8), managing audit record capacity (3.3.7), using synchronized timestamps (3.3.3), and limiting access to audit management functions (3.3.9).

What assessors focus on: Centralized log collection covering all CUI systems. Retention period (minimum one year, with at least three months immediately available). Evidence that logs are actually reviewed — not just stored. Protection of log integrity (logs can't be modified by regular users).

Most common findings: - Logs stored only on the systems that generate them (no centralized collection) - Retention under one year - No evidence of log review — logs collected but never looked at - Log timestamps not synchronized (NTP not enforced), making incident reconstruction impossible

Implementation note: Splunk and Microsoft Sentinel are the enterprise SIEM options most common in CMMC environments. Microsoft Sentinel integrates cleanly with M365 and Azure, which matters if your CUI environment is cloud-based. For smaller organizations (under 200 employees), a simpler centralized log server with defined review procedures may satisfy the requirements without a full SIEM deployment — the control says to review logs, not to have a SIEM.

4. Configuration Management (CM) — 9 Requirements

Configuration Management requires you to establish, document, and maintain secure baseline configurations for all CUI systems, and to control changes to those configurations.

The nine requirements cover: establishing baseline configurations (3.4.1, 3.4.2), enforcing security configuration settings (3.4.3), change control processes (3.4.4, 3.4.5), least functionality — disabling unnecessary services and ports (3.4.6, 3.4.7), restricting and controlling user-installed software (3.4.8, 3.4.9).

What assessors focus on: Documented baseline configurations for each system type in scope. Evidence that the actual systems match the documented baselines. A formal change control process with records of approved changes. Systems with no unnecessary open ports or running services.

Most common findings: - Baseline configurations documented but never compared against actual system state - No change control process — configuration changes happen ad hoc without approval or documentation - Default software installations left in place (unneeded services running, default accounts enabled) - No process for controlling user-installed software on workstations

Implementation note: CIS Benchmarks and DISA Security Technical Implementation Guides (STIGs) are the standard sources for secure baseline configurations. Use one of them — don't write your own from scratch. For Windows systems, the CIS Benchmark for Windows Server and Windows 10/11 are well-documented starting points. Configuration compliance scanning tools (Tenable.io, Qualys, Microsoft Defender for Cloud) can continuously verify your systems against the baseline.

5. Identification and Authentication (IA) — 11 Requirements

IA covers how users and devices prove their identity to your systems. It's closely tied to Access Control — IA establishes that you are who you say you are; AC establishes what you're allowed to do.

The 11 requirements cover: unique user identification (3.5.1, 3.5.2), password complexity and management (3.5.7–3.5.10), multi-factor authentication for network access (3.5.3) and privileged access (3.5.4), device identification (3.5.5, 3.5.6), and reauthentication when conditions change (3.5.11).

What assessors focus on: No shared accounts anywhere. MFA enforced for all remote access to CUI systems and all privileged accounts. Password policy in place and enforced technically (not just in policy documentation). Authenticator management (provisioning, revoking access when someone leaves).

Most common findings: - MFA deployed but not enforced — it's set up but users can bypass it - Password policy exists in a Word document but isn't technically enforced through Group Policy or identity provider settings - Generic/shared service accounts with no owner

Implementation note: MFA requirement (3.5.3) is non-negotiable. TOTP authenticator apps (Microsoft Authenticator, Google Authenticator) and hardware tokens (YubiKey) are both acceptable. SMS-based MFA is accepted by the requirement text but is technically weaker and assessors increasingly note it. For an organization running Microsoft 365, Entra ID with Conditional Access policies is the cleanest path to enforcing MFA across all remote access scenarios.

6. Incident Response (IR) — 3 Requirements

Three requirements: establish an incident response capability (3.6.1), track, document, and report incidents (3.6.2), and test the incident response capability (3.6.3).

Small family, big operational importance. The DFARS 252.204-7012 clause that drives most contractors into NIST 800-171 also has a 72-hour reporting requirement for cyber incidents. Your IR capability has to be fast enough to make that window.

What assessors focus on: A documented incident response plan that defines roles, responsibilities, and escalation paths. Evidence that the plan has been tested (tabletop exercises at minimum). A log of reported incidents — even if it's just "no incidents to report this period," assessors want to see that you're tracking. For contractors with DFARS 7012 in their contract, evidence that you know the reporting mechanism (DIBNet portal) and have tested it.

Most common findings: - Incident response plan that exists as a document but has never been tested - No designated incident response coordinator - No log of incidents or near-misses (contractors who say "we've never had an incident" without any records to support it)

Implementation note: ServiceNow (if you already use it) handles incident tracking for larger organizations. For smaller shops, a shared ticketing system or even a structured spreadsheet with defined fields satisfies the tracking requirement. Run a tabletop exercise annually and document it — date, participants, scenario, outcomes, and any process changes identified.

7. Maintenance (MA) — 6 Requirements

Maintenance covers the tools and processes used to perform maintenance on CUI systems, including who performs it and how they access the systems.

The six requirements cover: performing maintenance on CUI systems (3.7.1), providing controls on maintenance tools (3.7.2, 3.7.4), ensuring maintenance personnel are authorized (3.7.3), checking maintenance tools for malicious code (3.7.5), and managing remote maintenance (3.7.6).

What assessors focus on: Who performs maintenance on CUI systems, whether they're authorized, and how remote maintenance is conducted. Remote maintenance (remote desktop, vendor support sessions) must be supervised and logged.

Most common findings: - Third-party vendors performing remote maintenance without supervision or logging - No process for checking maintenance tools (USB drives, diagnostic software) for malware before use on CUI systems - Maintenance records that don't capture what was done, by whom, or whether the system was left in a secure state

Implementation note: Most organizations get this domain in shape by adding a maintenance log (even a simple spreadsheet) and formalizing the process for vendor access. Document remote maintenance sessions — start time, end time, purpose, who supervised, what was done.

8. Media Protection (MP) — 9 Requirements

Media Protection covers all forms of media containing CUI — digital and physical — from storage through disposal.

The nine requirements cover: protecting system media (3.8.1), limiting access to media (3.8.2), sanitizing or destroying media before disposal or reuse (3.8.3), marking media with CUI designations (3.8.4), controlling access to portable storage (3.8.7, 3.8.8), protecting media during transport (3.8.5, 3.8.6), and controlling removable media (3.8.9).

What assessors focus on: Evidence that CUI documents are marked. Media sanitization records for any disposed equipment. Policy on removable media (USB drives). Encryption of CUI on mobile devices and laptops.

Most common findings: - CUI documents that aren't marked (even when the marking policy exists) - No records of media sanitization prior to equipment disposal - USB drives allowed without controls — contractors who "have a policy" but no technical enforcement

Implementation note: NIST SP 800-88 Guidelines for Media Sanitization is the reference document for disposal procedures. For hard drives: cryptographic erase (if the drive supports it) or physical destruction. For SSDs: verify the device supports cryptographic erase; otherwise, physical destruction is the safest path. Keep a disposal log with device serial numbers, date, method, and who performed the sanitization.

9. Personnel Security (PS) — 2 Requirements

Two requirements: screen individuals prior to granting access to CUI systems (3.9.1) and ensure CUI is protected during and after personnel actions like terminations (3.9.2).

Two requirements. Contractors routinely underestimate this family because it looks simple. It generates findings because the operational controls around termination are often informal or inconsistent.

What assessors focus on: Background check records for employees with CUI access. Documented termination procedures that include revoking system access — and evidence that the procedure is followed (terminated employees' accounts disabled within a defined timeframe, typically same-day or within 24 hours for voluntary terminations, immediately for involuntary).

Most common findings: - No background check records — the contractor did background checks but can't produce the records - Former employee accounts still active weeks after departure - No defined termination procedure or no evidence it's followed consistently

Implementation note: Background checks for federal contractor positions run $50–$200 per person depending on depth and provider. Keep records — not just a note that checks were done. For account terminations, hook the process into HR: when a termination is initiated in HR systems, it should automatically trigger an IT ticket to disable accounts. This is a process problem, not a technology problem.

10. Physical Protection (PE) — 6 Requirements

Physical Protection addresses access to facilities and systems where CUI is processed, stored, or transmitted.

The six requirements cover: controlling physical access to CUI systems (3.10.1), controlling visitor access (3.10.2, 3.10.3), managing physical access devices (keys, badges, combinations) (3.10.4, 3.10.5), and protecting systems from environmental hazards and unauthorized access (3.10.6).

What assessors focus on: Physical access controls on the space where CUI systems are located (locked rooms, badge readers, keypads). Visitor logs. Evidence that physical access is reviewed periodically. Working areas where screens displaying CUI aren't visible to unauthorized visitors.

Most common findings: - Shared office spaces where employees working on CUI can be observed by visitors - Badge access that works but no log of who accessed the CUI area and when - Physical access control list never updated — people who left the company still have badge access

Implementation note: The PE domain doesn't require a vault. It requires that CUI systems are in a space that limits access to authorized personnel. A locked server room, a badge-controlled area, or even a dedicated locked office can satisfy this requirement depending on your environment. The key is that access is controlled, logged, and reviewed — not just locked.

11. Risk Assessment (RA) — 3 Requirements

Three requirements: conduct risk assessments (3.11.1), scan for vulnerabilities in organizational systems (3.11.2), and remediate vulnerabilities in accordance with risk assessments (3.11.3).

What assessors focus on: Documented risk assessments with identified risks, likelihood, impact, and mitigations. Vulnerability scan results and evidence that findings are remediated. The scan must cover the CUI environment, not just a subset.

Most common findings: - Risk assessments done once (for a proposal) and never updated - Vulnerability scans run but findings never addressed — a year-old scan with critical unpatched vulnerabilities is worse than no scan, because it shows you knew and did nothing - No defined remediation timelines for identified vulnerabilities

Implementation note: Qualys, Tenable (Nessus), and Rapid7 InsightVM are the standard enterprise vulnerability scanners. Authenticated scans (the scanner logs in to the system rather than just probing from outside) give significantly more complete results. Define your remediation SLAs in your vulnerability management policy: critical vulnerabilities within 30 days, high within 60, medium within 90 is a common benchmark.

12. Security Assessment (CA) — 4 Requirements

Security Assessment covers the periodic evaluation of your security controls to verify they work as intended.

The four requirements cover: periodically assessing security controls (3.12.1), developing and implementing plans of action to address deficiencies (3.12.2), monitoring security controls on an ongoing basis (3.12.3), and developing, documenting, and maintaining a system security plan (3.12.4).

The SSP is arguably the most important artifact in your CMMC compliance program. It's not a compliance document — it's the document that tells your assessor how every one of the 110 requirements is implemented in your specific environment. It has to be accurate, current, and specific.

What assessors focus on: A current, detailed SSP. An active POA&M for any identified gaps. Evidence of ongoing monitoring (not just a one-time assessment). Evidence that the SSP is maintained as the environment changes.

Most common findings: - SSPs that describe planned implementations rather than current state - POA&Ms with no completion dates or no evidence of progress - SSPs last updated during the proposal phase and not touched since

13. System and Communications Protection (SC) — 16 Requirements

SC is the second-largest family and covers network architecture, encryption, and the protection of information in transit and at rest.

The 16 requirements address: monitoring and controlling communications at network boundaries (3.13.1), protecting CUI in transit using cryptography (3.13.8) and at rest (3.13.11), network segmentation (3.13.3), managing denial-of-service risks (3.13.9, 3.13.10), protecting wireless communications (3.13.4, 3.13.15, 3.13.16), session termination (3.13.13, 3.13.14), and protecting organizational communications (3.13.12).

What assessors focus on: FIPS 140-3 validated encryption for all CUI — at rest and in transit. Network segmentation that actually isolates the CUI environment. Boundary protection with logging. Wireless security (WPA2/WPA3 Enterprise with 802.1X).

Most common findings: - Encryption that isn't FIPS-validated. The requirement is specific: the cryptographic module must be on the NIST CMVP validated modules list. Standard AES-256 isn't enough — the implementation of AES-256 must be validated - "Segmentation" that's a VLAN without firewall rules enforcing the boundary - CUI transmitted over unencrypted channels between systems ("it's internal, so it's fine" — it's not)

Implementation note: For encryption validation, look up your specific product version at csrc.nist.gov/projects/cryptographic-module-validation-program. BitLocker is FIPS-validated in specific Windows versions; the certificate number changes by version. Keep that certificate number in your SSP.

14. System and Information Integrity (SI) — 7 Requirements

SI covers the integrity of your systems and information — detecting and correcting flaws, protecting against malware, and monitoring for security threats.

The seven requirements cover: identifying and correcting system flaws (3.14.1 — patch management), providing protection from malicious code (3.14.2 — anti-malware), monitoring security alerts (3.14.3), updating malware protection (3.14.4), performing system scans (3.14.5), monitoring for unauthorized use (3.14.6, 3.14.7).

What assessors focus on: Evidence that anti-malware is deployed and centrally managed on all in-scope systems. Patch history. Monitoring capability. Alert management processes.

Most common findings: - Anti-malware not centrally managed (can't demonstrate coverage or signature currency) - Patches applied to some systems but not others — especially servers and systems that "can't be rebooted" - No one reading security alerts (tools deployed, alerts generated, nothing acted on)

Sequencing Your Implementation

Not all 14 families are independent. Some create the foundation that others build on:

Start here (foundation): 1. AC and IA — identity infrastructure enables almost everything else. You can't log meaningful audit events without knowing who the users are 2. CM — baseline configurations must exist before you can meaningfully assess deviation from them 3. AU — once identity is established and baselines are set, centralized logging captures the state you're protecting

Mid-phase: 4. SI — malware protection and patch management 5. SC — encryption and network segmentation 6. MP — media protection, including marking and disposal

Later (often administrative): 7. PS, PE, MA — important but don't block the technical work 8. IR — plan, test, refine 9. RA — risk assessments get more meaningful after you've implemented controls 10. CA — SSP is an ongoing document, but completing it is easier after implementation is done 11. AT — train on the implemented controls once they're in place

What Your Assessor Expects

C3PAO assessors evaluate each of the 110 requirements against three methods: examine (review documentation), interview (talk to personnel), and test (verify controls work). NIST 800-171A specifies which methods apply to each requirement — many require all three.

The most heavily scrutinized families are typically AC, IA, SC, and SI — they cover the most requirements and the highest-risk attack surfaces. But assessors pay attention to PS and PE disproportionately to their control count because failures there tend to indicate an organization that's implementing CMMC on paper rather than in practice.

Come to your assessment with: - A current SSP with implementation descriptions specific to your environment (not copied from a template) - Evidence packages organized by domain: configuration screenshots, access logs, training records, scan results, policies with version dates - Personnel who can speak to how controls actually work in daily operations — not just read from the SSP

For a focused deep-dive on any of these control families — or to work through your current gap state against the full 110 — schedule a working session with our CMMC consulting team.

Related reading: The Regulatory Stack: How CMMC, DFARS, NIST, and FAR Fit Together — understanding why these 110 requirements have force of contract.

Got specific questions about CMMC? Our expert is available around the clock — no waiting, no sales pitch.

Got Questions? Ask our CMMC Expert →

Prefer email? Reach us at ix@isegrim-x.com