CMMC Won’t Fail on Controls. It Will Fail on Proof.

Most of the conversation on the Cybersecurity Maturity Model Certification (CMMC) has been about controls: Do you have multi-factor authentication (MFA)? Is your controlled unclassified information (CUI) encrypted at rest? Have you deployed endpoint detection and response (EDR) across your endpoints? These are the right questions for a compliance implementation. But they are the wrong questions for a compliance verification regime. And CMMC, as it is currently designed and being assessed in the field, is a verification regime.

Under a traditional compliance framework, a company earns credit for having a policy, a plan and a documented intent. Under CMMC’s verification requirements, documentation is not evidence — it is merely a claim. The assessor’s job is to determine whether that claim is true. And the only way to do that is to examine the proof.

This distinction — between claiming a control exists and proving it exists — is where most defense contractors are unprepared. It is also where the bottleneck in CMMC acquisition timelines will ultimately emerge.

From frameworks to first principles: Risk, control, evidence

The purpose of a security compliance program is not to satisfy a framework. It is to manage risk. Every framework — the National Institute of Standards and Technology’s Special Publication 800-171, the International Standards Organization’s 27001 and Systems and Organization Control 2 — exists to help organizations identify their risks, implement controls to address them and demonstrate those controls are working. The framework is a scaffolding. The actual structure underneath is: Risk → control → evidence.

Most contractors approach CMMC as a checklist exercise — they map NIST 800-171’s 110 requirements, assign owners and document policies. But NIST 800-171 is not your security program. It is a reference architecture for thinking about your security program. NIST control 3.5.3 requires MFA. Your organizational control should be specific: “We require MFA for all administrative access to cloud-hosted systems containing CUI, enforced through Azure Conditional Access policies, verified monthly.” The NIST requirement is a prompt. Your control is the implementation decision you made in response to your actual environment and risk posture.

Critically, this is not a one-to-one relationship.  A single well-designed organizational control often satisfies multiple NIST requirements simultaneously — a control governing access provisioning workflows can address requirements spanning access control, identification and audit accountability domains at once. The relationship runs the other direction too: Some requirements are best addressed by two or three controls working together. This many-to-many mapping between your controls and framework requirements is a feature, not a complication. Most organizations face more than one compliance obligation — CMMC alongside SOC 2, or NIST 800-171 alongside ISO 27001. A corporate control tied to continuous evidence can satisfy requirements across multiple frameworks at once, making compliance sustainable rather than additive.

When organizations author their own controls — grounded in actual risk posture and expressed with operational specificity — the evidence question becomes tractable. You know exactly what you need to prove because you designed the control around what could be proven.