Fortinetics
← Insights · CMMC · · 8 min read

CMMC Level 2: What assessors actually look for — and what they quietly ignore

A practitioner's read on the Level 2 assessment process. Which domains get drilled, the evidence that closes packages, the compensating controls assessors accept, and the five most common failure modes that sink otherwise-ready organizations.

The published CMMC Assessment Guide Level 2, version 2.13, tells you which controls will be assessed and what a passing implementation looks like for each. It does not tell you what happens in the room. It does not tell you which domains get drilled hard, which evidence forms actually close a control, or which compensating arrangements a C3PAO will accept without a fight. Those details matter — and they are the difference between a nine-month program that ends in a 110/110 score and a fifteen-month program that ends in a 90-something and a POA&M you did not plan for.

What follows is the practitioner’s read. It assumes you already know the framework structure — 14 domains, 110 practices, NIST 800-171 Rev 2 as the control catalog. If any of that is new, start with the Assessment Guide itself before this.

The domains that get drilled

Assessors have finite time and a standard approach. They prioritize domains that surface the most operational risk and that produce the most useful evidence about whether your program actually works end-to-end. In our experience, five domains receive disproportionate attention:

Access Control (AC). Assessors want to trace a user from onboarding to offboarding, across every system that handles CUI. They will ask to see privilege-assignment records, least-privilege enforcement in specific systems, remote access authorization, and — critically — session-termination evidence. A clean AC story requires your IAM tooling to produce assessor-consumable reports, not just technical enforcement.

Identification and Authentication (IA). Multi-factor authentication for privileged accounts and remote sessions is the first question. The second is how you prove MFA is in place across every CUI-handling system, including legacy ones. Password complexity, credential reuse prevention, and cryptographic-module attestations (FIPS 140-2 or 140-3 validated, not merely “compliant”) will be examined. “We use Okta” is the beginning of the conversation, not the end.

Audit and Accountability (AU). This is the domain where most organizations underinvest. Assessors want to see that you log the right events, that logs are protected from modification, that you review them on a documented cadence, and — this is the one that surprises people — that you can produce logs on demand during the assessment itself. A SIEM you cannot search in under five minutes is a failing implementation.

Configuration Management (CM). Baseline configurations, change control, software installation restrictions, and least-functionality enforcement. The assessor wants the baseline document, the variance log, the change-approval trail, and a walk-through showing that an unauthorized software install actually gets blocked. The most common failure here is documented policy without technical enforcement.

System and Communications Protection (SC). Boundary protection, cryptography, session integrity, and the specific controls around CUI transmission. This is where CUI enclave design either works or falls apart under questioning — we cover the recurring failure modes in seven CUI enclave architectural mistakes that survive through implementation.

Domains like Awareness and Training (AT), Physical Protection (PE), and Media Protection (MP) are still assessed, but they tend to go faster when documentation is clean. Organizations that prepare for the five drilled domains thoroughly tend to pass the others on rigor momentum.

Evidence artifacts that actually close controls

A control is not implemented because a policy says it is. A control is implemented because you can show the assessor three things: the policy that specifies what should happen, the technical enforcement that makes it happen, and the evidence of the technical enforcement operating as designed. We call this the three-part test.

For each control, prepare an artifact that satisfies all three. The strongest forms we’ve seen close controls on first presentation:

Policy excerpts with version, approval date, and signatory. Not “our Information Security Policy covers this” — the specific section, in PDF or screenshot form, with the approval metadata visible.

Configuration exports with timestamp. A JSON or CSV export from the enforcing system (your identity provider, endpoint manager, firewall, DLP tool), timestamped in the last thirty days, showing the setting in effect. Not a screenshot of a running UI — a data export that can be re-generated.

Sample log records. Three to five representative log events demonstrating the control firing. For audit and accountability controls, this is direct evidence. For access control, it’s a proof that the enforcement happens in practice.

Screenshots with EXIF data or timestamps. Where log records are inappropriate or unavailable, an annotated screenshot with a visible clock in the OS. Less strong than data exports but acceptable.

Sign-off records. For training, acceptable-use, and acknowledgement controls — a dated record of acknowledgment from the individual, preferably from your LMS or HR system rather than a shared-drive spreadsheet.

The package should be organized by control number, with a one-page cover sheet per control summarizing the three-part test for that control. Assessors who can navigate your evidence quickly move through the assessment quickly. Assessors who cannot tend to ask more questions — and ask the kinds of questions that surface follow-up gaps.

What assessors quietly accept

Compensating controls are permitted by the CMMC scoring methodology when you cannot meet the letter of a practice but can demonstrate equivalent risk reduction. In practice, two compensating patterns get accepted without much resistance:

Risk acceptance by senior leadership for narrow, documented scope. If you have a legacy system that cannot meet a control, a signed risk acceptance with a named authority, a specific compensating control, and a documented remediation plan is generally accepted. The risk-acceptance document needs to look like a risk-acceptance document — not like an apology.

Technical enforcement via a different tool than the policy names. If your policy says endpoint protection is Defender for Endpoint but you’ve migrated to CrowdStrike, the assessor doesn’t care — they care that endpoint protection is enforced. Update the policy before the assessment; that closes the loop.

What does not get accepted: “we’re planning to implement this” without a specific date, “we use this tool that has the capability” without evidence that the capability is configured and operating, or “this is handled by our IT MSP” without a written agreement showing the MSP’s scope and access boundaries.

Five most common failure modes

Retroactive evidence collection. Teams spend the month before the assessment scrambling to produce artifacts for operations that already happened. Evidence gathered retroactively often doesn’t match the original operation, and assessors notice. Build operations that produce evidence as a byproduct — audit logs that flow to a SIEM automatically, access reviews that generate dated approval records, training completions that log to a system of record.

CUI scope sprawl. If you’ve categorized every piece of data your organization touches as CUI, the assessor will apply Level 2 requirements to all of it — and you will not pass on all of it. Narrow the CUI scope to what is actually CUI. Use enclave architecture and data-labeling discipline to keep non-CUI data out of the CUI-handling boundary.

Shared identity with corporate. If your CUI environment uses the same Active Directory, the same Okta tenant, or the same SSO federation as the rest of your company — without strict boundary controls between them — you have effectively imported the corporate risk surface into the CMMC boundary. Federated identity with disciplined conditional-access policies can work, but the bar is high and the evidence burden is heavier than running a separate identity domain. For most mid-market teams, separate IAM is the cleaner answer.

Policy-technical divergence. The policy says one thing, the technical configuration does another. Assessors open the policy, compare it to the configuration, and find the gap. Every policy section needs a named control owner who confirms, before the assessment, that the implementation matches the policy.

No pre-assessment rehearsal. The first time anyone walks through the evidence package end-to-end should not be with the C3PAO in the room. Run a full pre-assessment — ideally with an independent reviewer — at least sixty days before the real one. Every gap you find in the rehearsal is a gap that was going to cost you points.

Evidence-generating operations

The meta-principle that separates teams that score well from teams that score poorly is whether the operation generates evidence as a byproduct, or whether evidence is a separate reconstructive activity. A team whose access reviews are conducted in Excel has to manually document those reviews for the assessor. A team whose access reviews are driven by a workflow tool, with approvals logged to a system of record, has the evidence without doing anything extra.

Every control in your scope should be analyzed this way: what operation makes this control happen, and what record does that operation produce by default? Where no record is produced, change the operation — not the documentation — so that it produces one. This is the foundation of an evidence posture that survives not just the first Level 2 assessment, but every surveillance audit, every re-certification, every new contract that asks to see your most recent package.

What comes next

If you’re inside the six-to-twelve-month window before a target contract award date, the question is not whether you will pass Level 2 — it’s whether you will pass with time to spare. A dry run eight weeks before the real assessment, driven by the assessor’s evaluation criteria rather than your own self-image, is among the highest-impact investments available. If the dry run reveals gaps that take six months to close, you would rather know in week eight than in week one of the real assessment.

Our CMMC 2.0 engagement model is built around this reality. We design, build, document, and dry-run alongside your team, then sit with you through the real assessment — a perfect 110/110 track record across multiple clients in six to nine months. If you want to see where you stand before committing to that, the CMMC Level 2 readiness quiz is the honest first step.