StealthTech
There’s a version of CMMC preparation that treats the 110 controls in NIST SP 800-171 as a flat checklist — 110 items, each equal in weight, each requiring the same level of attention. Work through them in order, document each one, and you’re done. That approach produces a compliance program that looks complete on paper but misses the operational logic underneath the framework.
NIST SP 800-171 was not designed as a flat list. It was designed as a layered set of security practices, and within those 14 domains, certain controls carry disproportionate weight — either because they underpin the effectiveness of other controls, because they represent the attack surfaces most frequently exploited against defense contractors, or because assessors pay particular attention to them when evaluating whether a compliance program is genuinely functional versus superficially documented.
Understanding which controls are critical — and why — is what separates a compliance program built to pass an assessment from one built to actually protect controlled unclassified information. This guide walks through the domains and practices that deserve the most attention, and why.
How NIST SP 800-171 Is Structured and Why It Matters for CMMC
NIST SP 800-171 organizes its 110 security requirements across 14 families, each addressing a distinct dimension of information security. These families range from Access Control (the largest, with 22 requirements) to Physical Protection (6 requirements) and touch everything from how users authenticate to how audit logs are managed to how incidents get reported.
CMMC Level 2 maps directly to these 110 requirements — one-to-one in most cases, with the CMMC practice identifiers corresponding to the NIST control numbers. When a C3PAO assessor evaluates a Level 2 organization, they are working through these 110 requirements and determining, for each one, whether it is fully implemented, partially implemented, or not implemented. That determination feeds directly into the organization’s score and its certification outcome.
The full text of NIST SP 800-171 Revision 2 is publicly available and should be in the hands of anyone running a CMMC compliance program. But knowing the framework exists and knowing which parts of it carry the most operational weight are different things. The sections below focus on the latter.
Access Control: The Domain With the Most Requirements and the Most Assessment Scrutiny
Access Control (3.1.x) is the largest domain in NIST SP 800-171 and consistently one of the most scrutinized in C3PAO assessments. Its 22 requirements cover who can access what, under what conditions, and through what mechanisms. The reason it receives so much attention is straightforward: most successful intrusions against defense contractors ultimately succeed because of access control failures — compromised credentials, over-privileged accounts, inadequate separation between sensitive and general-purpose systems.
Several requirements within this domain are particularly critical.
3.1.1 and 3.1.2 — Authorized Access and Limiting Access to Authorized Transactions: These foundational requirements establish that system access is limited to authorized users, processes, and devices, and that those users can only perform the transactions and functions their role requires. The principle of least privilege lives here, and its implementation requires more than an access policy — it requires that actual system configurations, user accounts, and permission sets reflect what the policy says. Assessors will look at both the documentation and the operational reality, and they won’t treat a well-written policy as evidence of a well-implemented control.
3.1.12 — Monitor and Control Remote Access Sessions: Remote access to CUI systems is one of the primary attack vectors against defense contractors, and this requirement addresses it directly. Organizations that allow remote access without defined session controls, without monitoring, and without documented authorization are consistently among the most vulnerable in the industrial base. If your workforce or your managed IT services provider accesses your CUI environment remotely, this control needs to be fully implemented and evidenced — not just acknowledged.
3.1.20 — External Connections: This requirement addresses connections between your CUI systems and external systems or networks. Every such connection is a potential ingress point for a threat actor, and every one of them needs to be documented, authorized, and controlled. This connects directly to third-party vendor relationships — as we covered in our piece on how MSPs, cloud providers, and software partners affect your CMMC compliance — and organizations without a current, complete inventory of external connections frequently find gaps here that weren’t on their radar.
Identification and Authentication: Where Most Assessments Find Their First Findings
Identification and Authentication (3.5.x) covers 11 requirements focused on ensuring that users, processes, and devices are who and what they claim to be before being granted system access. This is the domain most directly tied to the multi-factor authentication (MFA) requirements that have become a baseline expectation across all of federal cybersecurity.
3.5.3 — Multi-Factor Authentication: This is arguably the single most operationally impactful control in the entire framework. Requiring MFA for access to organizational systems containing CUI — particularly for privileged accounts and remote access — eliminates a significant portion of the credential-based attacks that targeting defense contractors. CISA’s guidance on multi-factor authentication consistently identifies MFA as the control with the highest return on investment for protecting against account compromise. Yet it remains incompletely implemented across a surprising portion of the defense industrial base.
The implementation nuance that assessors focus on: MFA needs to be enforced at the system level, not just available or recommended. An organization that offers MFA as an option but doesn’t require it hasn’t implemented the control. An organization that requires MFA for some accounts but not for service accounts, shared accounts, or privileged users has a partial implementation that will generate a finding.
3.5.10 — Cryptographically Protected Passwords: Password storage and transmission needs to use cryptographic mechanisms that prevent the recovery of plaintext passwords. This is a technical requirement that some organizations satisfy without realizing it (most modern directory services and applications handle this by default) and others violate unknowingly through legacy systems or custom applications that store credentials insecurely.
Audit and Accountability: The Controls That Prove Everything Else Is Working
Audit and Accountability (3.3.x) covers nine requirements related to generating, protecting, and reviewing audit logs. These controls are critical for two reasons: they provide the evidence trail that an organization needs to detect and respond to incidents, and they provide the documented evidence that assessors need to verify other controls are functioning.
3.3.1 — Audit Log Generation: Systems containing CUI must generate audit logs that capture user activity, system events, and security-relevant actions. This requirement sounds basic, but its implementation requires decisions about what gets logged, at what granularity, and where logs are stored. Organizations that rely on default logging settings often find they’re capturing some events but missing others — insufficient activity for the level of audit coverage the requirement expects.
3.3.2 — User Actions Traceability: Audit logs need to be sufficient to trace actions back to individual users. Shared accounts, application-level service accounts that act on behalf of multiple users, and systems without adequate session logging all create traceability gaps that this requirement is designed to prevent.
3.3.5 — Correlating Audit Log Review with Reporting: This is where many organizations fall short not in the technical implementation but in the operational practice. Logs are being generated and stored, but nobody is reviewing them on a defined schedule. NIST 800-171 expects review, not just collection. A cybersecurity program that includes regular log review — whether through an internal SOC function, a SIEM with alert workflows, or a managed security service — satisfies this requirement in a way that passive log storage does not.
Configuration Management: The Domain That Prevents Drift
Configuration Management (3.4.x) addresses nine requirements focused on establishing and maintaining secure configurations for systems, applications, and network devices. This domain is operationally significant because configuration drift — systems that were secure at deployment gradually becoming insecure through undocumented changes and missed patches — is one of the most common ways that technically implemented controls stop functioning over time.
3.4.1 — Baseline Configurations: Organizations must establish and document baseline configurations for their information systems. A baseline isn’t just a snapshot — it’s a documented standard that new systems are built to and existing systems are measured against. When a system deviates from its baseline, that deviation needs to be noticed, evaluated, and either corrected or formally authorized.
3.4.2 — Establishing and Enforcing Security Configuration Settings: This requirement extends beyond baseline documentation to the enforcement of security settings — disabling unnecessary services, removing default accounts, configuring applications to operate at minimum necessary privilege. The CIS Benchmarks and NIST’s National Vulnerability Database both provide reference points for what secure configuration settings look like across common platforms.
3.4.6 and 3.4.7 — Least Functionality: Systems should be configured to provide only the capabilities required for their function. Unnecessary ports, protocols, services, and software increase the attack surface without adding operational value. These requirements are frequently underimplemented because the effort of auditing and removing unnecessary functionality gets deprioritized against operational demands.
Maintaining configuration management across a dynamic environment — where systems change, applications get updated, and new devices get added regularly — requires integrating compliance review into the change management process, as we discussed in our guide on building a continuous compliance program.
Incident Response: The Controls That Determine What Happens When Things Go Wrong
Incident Response (3.6.x) covers three requirements, but their operational weight far exceeds what the count suggests. A defense contractor that experiences a CUI-related incident without a functioning incident response capability faces both the security consequences of the incident and the compliance consequences of demonstrating that the organization was unprepared.
3.6.1 — Incident Handling Capability: Organizations must establish an operational incident response capability covering preparation, detection, analysis, containment, recovery, and user activities. That’s a substantial operational requirement, not just a document. An incident response plan that was written during assessment preparation and never tested is not a functional incident response capability. Assessors will ask about tabletop exercises, about how the plan has been updated based on lessons learned, and about who is responsible for each phase of the response process.
3.6.2 — Incident Reporting: Incidents involving CUI must be reported to appropriate authorities. Under DFARS 252.204-7012, the reporting timeline is 72 hours from discovery. That clock is unforgiving, and organizations that discover an incident and spend the first 48 hours figuring out their reporting obligations rather than executing a pre-planned process consistently miss the window. Knowing who to call, what to report, and how to report it before an incident occurs is what this requirement actually demands.
Risk Assessment: Understanding Your Environment to Protect It
Risk Assessment (3.11.x) covers three requirements that are foundational to the logic of the entire framework. You can’t prioritize security investment, configure controls appropriately, or make defensible decisions about residual risk without a documented understanding of what risks your environment faces.
3.11.1 — Periodic Risk Assessments: Organizations must periodically assess the risk to organizational operations, assets, and individuals from the operation of organizational systems containing CUI. The word “periodically” is intentional — risk assessment isn’t a one-time exercise done during initial compliance preparation. Threats evolve, environments change, and risk profiles shift. An annual risk assessment cadence is the commonly accepted minimum; organizations undergoing significant change should assess more frequently.
3.11.2 — Vulnerability Scanning: Systems must be scanned for vulnerabilities periodically, and newly identified vulnerabilities must be remediated or mitigated. This is the technical complement to the broader risk assessment process — it’s the mechanism by which an organization discovers the specific weaknesses in its deployed systems before threat actors find them first. Vulnerability scanning needs to produce documented results, and those results need to connect to a remediation process with defined timelines. Scanning without remediation isn’t vulnerability management; it’s vulnerability documentation.
System and Communications Protection: Securing How Data Moves
System and Communications Protection (3.13.x) is the second largest domain with 16 requirements, covering how data is protected in transit, how network boundaries are controlled, and how communication channels are secured against interception and manipulation.
3.13.1 — Boundary Protection: Organizations must monitor, control, and protect communications at the external boundary of the system and at key internal boundaries. This is the network segmentation requirement that underpins effective scope management — the ability to define a CUI environment and keep it separated from general corporate systems depends on functioning boundary controls. Our earlier discussion of how to scope your CMMC environment correctly explains how boundary architecture directly affects compliance costs.
3.13.5 — Public Access Systems Separation: Systems accessible to the public must be implemented in a way that prevents unauthorized access to internal CUI systems. The web server hosting your public website and the file server storing your CUI need to be separated by more than a policy statement.
3.13.8 — Transmission Confidentiality: CUI must be protected during transmission using cryptographic mechanisms — in practical terms, using encrypted protocols for any communication that carries CUI. Unencrypted email, FTP transfers, and unprotected web applications that handle CUI fail this requirement regardless of how strong the controls at rest are.
The Controls That Assessors Focus On First
Based on patterns across CMMC and NIST 800-171 assessments, certain controls consistently appear in findings — not because they’re technically complex, but because they require ongoing operational discipline that point-in-time compliance preparation doesn’t build.
High-Frequency Assessment Findings
- MFA not enforced for all users accessing CUI systems (3.5.3)
- Audit log review happening at assessment time but not on a documented recurring schedule (3.3.5)
- Vulnerability remediation SLAs not documented or not followed (3.11.2)
- Baseline configurations documented but not enforced or updated after system changes (3.4.1)
- Incident response plans not tested through tabletop exercises (3.6.1)
- Access reviews not conducted on a defined schedule — former employees or vendors retaining access (3.1.1)
- System Security Plan not updated to reflect current environment state (documentation requirement across multiple domains)
Controls That Are Easy to Satisfy but Often Overlooked
- 3.14.1 — Malicious Code Protection: Endpoint protection deployed but definitions not auto-updating or coverage not confirmed across all in-scope endpoints
- 3.4.9 — User-Installed Software: Policy exists prohibiting unauthorized software installation, but enforcement mechanism (application whitelisting or similar) is not implemented
- 3.2.1 and 3.2.2 — Awareness Training: Training occurred during compliance preparation but hasn’t recurred annually as required
Putting It Together: A Domain-by-Domain Priority Framework
For organizations building or maturing their CMMC compliance program, working through all 14 domains simultaneously isn’t always practical. Resource constraints require sequencing, and sequencing requires knowing which domains create the most risk if left incomplete.
A practical priority sequence, based on both assessment finding frequency and downstream dependency:
Tier 1 — Foundation controls (implement first because other controls depend on them): Access Control (3.1), Identification and Authentication (3.5), Configuration Management (3.4). These control who gets in, verify that who they claim to be is accurate, and ensure the systems they access are configured securely.
Tier 2 — Detection and response controls (implement second to catch what Tier 1 misses): Audit and Accountability (3.3), Incident Response (3.6), System and Communications Protection (3.13). These controls detect when something goes wrong and ensure the organization can respond.
Tier 3 — Governance and sustainability controls (implement third to maintain what Tier 1 and 2 build): Risk Assessment (3.11), Security Assessment (3.12), Configuration Management ongoing processes (3.4), Awareness Training (3.2).
For manufacturing and engineering organizations, operational technology systems create additional complexity in the configuration management and system protection domains — where standard IT security tooling often doesn’t apply cleanly to industrial control systems or design environments.
A vCIO or compliance partner who understands both the framework and your specific environment can help translate this priority sequence into a realistic remediation roadmap with timelines and resource requirements that leadership can plan against. The CyberAB marketplace lists qualified CMMC assessors and consultants who can assist with this analysis.
Documenting Controls: What Evidence Actually Looks Like
One of the most common misconceptions about NIST 800-171 and CMMC is that implementation equals compliance. Implementation is necessary but not sufficient. Assessors need evidence that controls are implemented and operating as intended — and that evidence takes different forms for different types of controls.
For technical controls, evidence typically includes configuration screenshots, system-generated reports, tool outputs, or logs demonstrating that the control is active. For process controls, evidence includes written procedures, training records, meeting minutes from review activities, or audit outputs showing the process was followed. For policy controls, evidence includes the signed, dated policy document and some form of attestation or record showing relevant personnel were trained on it.
Building an evidence library as implementation happens — rather than scrambling to produce evidence during assessment preparation — is one of the clearest markers of a mature compliance program. It also makes the ongoing work of a co-managed IT arrangement more effective, since the partner has documented baselines to maintain against rather than reconstructing the state of controls from scratch at each review cycle.
Conclusion: Know the Controls That Carry the Most Weight
NIST SP 800-171’s 110 requirements are not created equal. Some are technically simple and procedurally straightforward. Others require sustained operational discipline, documented evidence of ongoing activity, and integration with the way the organization actually runs. The critical controls — multi-factor authentication, access control enforcement, audit log review, vulnerability management, incident response capability, configuration baselines — consistently determine whether a compliance program is genuinely functional or just well-documented.
Building a compliance program that treats these high-weight controls as operational priorities rather than documentation checkboxes is the difference between organizations that pass C3PAO assessments cleanly and organizations that spend the month before assessment closing POA&M items they should have remediated months earlier.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at 617-903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
