Before diving into specific controls, it's worth understanding how assessors evaluate your evidence. CMMC is a standardized framework, but assessments are conducted by humans who apply professional judgment. Two terms that assessors are formally trained on are sufficient and adequate — and understanding the difference is critical.

• Sufficient means there is enough evidence — in quantity and coverage — to support a finding. Think of it as the "how much" question.
• Adequate means the evidence is the right kind — relevant, quality, and directly tied to the control being assessed. Think of it as the "is this the right stuff" question.

The goal isn't just to check a box. It's to make your implementation defensible. An assessor needs to be able to conclude that a practice is implemented correctly, operating as intended, and producing the desired outcome. That's the bar you're being held to.

When preparing your evidence package, approach it from three angles simultaneously: build it as if someone skeptical is reviewing it, someone technical is testing it, and someone completely unfamiliar with your environment is trying to understand it. The more work you put into making your evidence clear and comprehensive upfront, the less likely you are to be pulled into a live test — where unexpected findings can surface.

This is one of the most commonly misunderstood requirements in CMMC. Many organizations assume that using strong encryption like AES-256 is sufficient — it isn't. CMMC requires FIPS-validated cryptography, meaning the specific cryptographic module must be validated through NIST's Cryptographic Module Validation Program (CMVP) and have an active certificate to prove it.

Every form of cryptography used to process, transmit, or store CUI must meet this standard. That includes your endpoints, servers, network devices, and even SaaS platforms. A common mistake is assuming that because a product uses FIPS-capable hardware, it's running in FIPS mode — it may not be. FIPS mode must be explicitly enabled and documented.

With FIPS 140-2 now fully sunset as of September 21, 2025, organizations must be operating on FIPS 140-3. It's also worth noting that CMVP certificates expire after five years, so even if you've done this work before, it's worth auditing your certificates to make sure none have lapsed. Some products — like certain Apricorn drives — may still only carry FIPS 140-2 certification, which is now expired.

What assessors specifically want to see:

• Where cryptography is in place, documented in your SSP and network/data flow diagrams
• The FIPS validation status of each module — the CMVP certificate, not just the product name
• Proof that FIPS mode is actively running (e.g., a GPO screenshot showing the setting applied across endpoints)
• A cryptography inventory that maps CUI locations to the encryption in use and the corresponding CMVP certificate

Least privilege is one of those concepts that organizations often feel confident about — until they're in front of an assessor. The most common misconception is that least privilege simply means users aren't admins. In reality, assessors are looking for documented and enforced control over what actions users are permitted to perform within your systems.

This goes well beyond whether someone has an admin account. It covers specific transactions and functions such as creating users, exporting data, running scripts, viewing audit logs, and — critically — deleting audit logs. The question isn't just "does this person have access?" It's "have you defined what they're allowed to do with that access, and can you prove it's enforced?"

Common reasons organizations fail these controls:

• Roles exist in Active Directory but are not mapped to specific, defined allowed actions
• SaaS platforms (like Microsoft 365) running on default roles that are overly permissive
• MSPs or external service providers with admin rights and no shared responsibility matrix defining what they're authorized to do
• Privileged users logging into their admin accounts for everyday tasks like email and web browsing

What assessors want to see is a Role-Based Access Control (RBAC) matrix — a document that maps each role (basic user, power user, privileged user, contractor, service account) to its permitted day-to-day and security functions. This doesn't have to be a complex tool. A simple table in a Word document or spreadsheet that clearly defines what each role can and cannot do will satisfy the intent of controls 3.1.2, 3.1.5, 3.1.6, and 3.1.7 — multiple controls with one artifact.

Beyond the matrix, assessors also want to see that privileged users have separate standard accounts for daily use, that there's a formal approval process for granting privileged access, and that your SIEM is configured to alert on privileged actions. If you can provide this evidence proactively, you reduce the likelihood of being asked to perform a live test — where something unexpected could derail your assessment.

Printers are the bane of every system administrator's existence — and it turns out, they're also a surprisingly complex area in CMMC assessments. Many organizations overlook printers entirely in their compliance preparation, only to find that they introduce a wide range of control considerations that are difficult to fully address.

The recommended categorization for printers is as a CUI asset, which means applicable CMMC controls apply. Assessors are generally expected to be reasonable about what can and can't be enforced on a printer — for example, it's widely understood that applying multi-factor authentication directly to a printer isn't feasible in most environments. But that doesn't mean printers get a free pass.

Key areas to address:

• Transmission protocols: If you're still using legacy protocols like LPR, LPD, or Port 9100, you may be transmitting print jobs in cleartext. Switch to IPP (Internet Printing Protocol), which uses HTTPS/443 for encrypted communications.
• Processing: Use a print spooling server so that all job processing happens on a FIPS-capable Windows or Linux server — not on the printer hardware itself. This eliminates the need for FIPS-validated cryptography on the printer.
• Storage: Multifunction devices (MFDs) are often configured out of the box to store print, copy, and scan jobs. Disable this. Stored jobs on an MFD represent a data exposure risk that assessors will flag.
• Paper media: Once a document is printed, it becomes physical media. Have a clean desk policy, establish a process for tracking when CUI is printed, and ensure staff know how to properly handle and destroy printed CUI.
• Media marking: Consider whether printers authorized to print CUI should be labeled as such — and whether you can demonstrate control over which printers CUI is allowed to be sent to.

System baselines are one of the most commonly failed controls — not because organizations aren't doing the work, but because they're confusing having configurations with having a controlled baseline. Those aren't the same thing.

A baseline is a formally documented standard that defines your known good system state. It includes hardware, software, firmware, and security configurations. The intent of this control is to establish that known good state and then maintain it over time — meaning you can prove that what's deployed today still matches what you documented, and that any deviations are approved and tracked. Without a baseline, change management is essentially impossible, and identifying potentially malicious behavior becomes far harder.

A complete baseline covers:

• Security configurations — your hardening standards, such as CIS benchmarks or DISA STIGs, applied across endpoints, servers, and network devices
• System configurations — OS settings, running services, open ports, and logging configurations
• Application baselines — approved software and version lists
• SaaS and cloud configurations — often missed entirely, but increasingly scrutinized by assessors

Common reasons organizations fail this control:

• Saying "we follow CIS benchmarks" without formally documenting CIS as your defined standard
• Inconsistent deployment — the baseline exists on paper but isn't uniformly applied
• Exceptions that were made but never documented or approved
• System drift over time with no monitoring process to catch it
• Incomplete inventories — particularly missing firmware versions (at minimum, BIOS) and SaaS/cloud platform configurations
• Assuming the MSP is tracking this — without confirming that they are

One forward-looking note: with CMMC Revision 3 on the horizon, the DoD's Organizational Defined Parameters (ODPs) are expected to require alignment with either CIS benchmarks or DISA STIGs. Future-proof yourself now by aligning to one of those two standards, so you won't need to make changes when the new revision arrives.