CMMC is the framework that decides whether your company can bid on Department of Defense contracts that involve Controlled Unclassified Information. The program replaced the older self-attestation model with third-party certification, which means an assessor from an accredited organization has to sign off before you can claim compliance. If your contracts mention Controlled Unclassified Information, Level 2 applies to you, and an assessment is in your future.
This guide is for executives at defense contractors preparing for a first Level 2 assessment, or coming up on their three-year recertification.
What CMMC actually is
CMMC stands for Cybersecurity Maturity Model Certification. It layers on top of an existing NIST standard, 800-171, which specifies the security requirements for protecting Controlled Unclassified Information on non-federal systems. For years, federal contractors self-attested to meeting 800-171. CMMC removed that trust-based model and replaced it with outside assessment.
There are three levels. Level 1 applies to contractors handling only Federal Contract Information, which is a lower category. Level 2 applies to contractors handling Controlled Unclassified Information, which is most defense contractors. Level 3 is reserved for the highest-risk programs.
For the rest of this guide, I am going to assume Level 2, since that is where most conversations happen.
Scoping is the first big decision
Most organizations cannot afford to bring their entire corporate environment into CMMC scope. The correct architecture for most contractors is a dedicated enclave where Controlled Unclassified Information lives, isolated from the general corporate network, with its own identity, its own devices, and its own applications. The 22 Access Control practices apply inside the enclave. Outside it, your regular corporate controls continue.
Getting scope wrong is the single most expensive CMMC mistake. Too broad, and your remediation cost balloons because every corporate application ends up in scope. Too narrow, and the assessor fails you for missing boundary enforcement.
The 22 Access Control practices you need to know
All 22 matter, but six do the heavy lifting. The rest are variations and supporting controls.
Limit access to authorized users, processes, and devices
Every account, service account, and device that reaches the enclave has to be on an inventory. Anything not on the inventory does not connect. This sounds basic. It is surprisingly hard to get right, because companies accumulate service accounts and connections over time.
Control how Controlled Unclassified Information moves
Information does not leave the enclave without controlled egress. No uploading to personal cloud storage, no forwarding to personal email, no downloading to unmanaged endpoints. Data loss prevention tooling is part of the answer, but the architecture is the heavier lift. If your enclave design lets data out through a dozen channels, you have a containment problem.
Least privilege, including for security functions
Standard least privilege rules apply to users. The twist for CMMC is that security functions themselves are subject to least privilege. Your security monitoring administrator cannot also hold production deployment rights. Your backup administrator cannot also approve changes to the backup configuration. Roles that give one person too much trust get flagged.
Control remote sessions with cryptographic mechanisms
Any session that reaches the enclave from outside it has to be encrypted, authenticated, monitored, and terminated after idle. A managed VPN or Zero Trust Network Access gateway with multi-factor, not a direct connection.
Control Controlled Unclassified Information on mobile devices
Mobile endpoints that touch the enclave have to be managed, encrypted, and configured to prevent data from landing in personal storage or personal applications. Bring-your-own-device fails this practice unless there is a strictly partitioned work profile.
Verify and control external system connections
Every connection from your enclave to a vendor, subcontractor, or partner system is documented, approved, and technically restricted. The assessor asks for the list of external connections and verifies a sample.
Process maturity and why Level 2 is different
This is where Level 2 differs from plain 800-171 compliance. The assessor does not just ask whether the practice is in place. The assessor asks whether the practice has been followed over time, documented consistently, and produces artifacts that a reviewer can inspect.
Practically, that means policies are versioned, trainings are tracked, incidents produce written response records, and reviews happen on a documented schedule. You cannot fake maturity in the weeks before an assessment. The evidence has to accumulate over time.
Where teams commonly fail
Four patterns show up in engagement after engagement.
Scope that quietly drags in the whole company. A shared helpdesk ticketing system that touches a single ticket about a Controlled Unclassified Information file pulls the whole helpdesk into scope. A shared identity provider that grants access to enclave applications pulls the identity provider into scope, which usually pulls HR, payroll, and every other corporate application along with it. Scoping has to be deliberate and enforced by architecture, not by policy statements.
No evidence of ongoing practice. Technical controls are in place but the paper trail that shows them being operated consistently does not exist. Policies exist but were written six months ago and never updated. Training records stop six months short of the assessment. These add up to a finding on maturity even when the technical side is sound.
Boundary between enclave and general information technology is leaky. The enclave is supposedly isolated, but a single administrator account can cross the boundary. Or a shared service account has access to both sides. Or the security monitoring tool pulls logs from the enclave into a general-purpose security tool that does not meet enclave controls.
Uncatalogued external connections. Vendors with VPN tunnels into the enclave that nobody inventoried. Subcontractors using legacy file transfer tools. API integrations from years ago that nobody documented. Assessors find these through network review and each one becomes a finding.
The executive playbook
Design the enclave before touching the controls
The first deliverable is always an architecture diagram and a scoping decision. What is in scope, what is out of scope, and what the boundary looks like in technical terms. Without this foundation the downstream work has no structure.
Dedicated identity for enclave access
People who work with Controlled Unclassified Information have a separate identity that only exists inside the enclave. That identity requires multi-factor, uses a managed device, and has no path to corporate resources. Scoping gets enforced at the identity layer, which makes the enclave easier to audit.
Configure the 22 practices as code
Every practice has a technical expression. Least privilege is enforced through identity provider group design. Session controls are enforced through operating system and application configuration. Mobile device controls are enforced through mobile device management. All of this goes into Terraform or an equivalent infrastructure-as-code tool with version control, so changes are reviewable and the state is reproducible.
Enforce data egress
Data loss prevention on the enclave. Restricted sharing policies on whatever file platforms are in scope. Encrypted, auditable paths for any Controlled Unclassified Information that has to leave the enclave, with approvals. This is the difference between "Controlled Unclassified Information is probably inside the enclave" and "Controlled Unclassified Information cannot leave the enclave without a log entry."
Build the maturity evidence as you go
Every policy gets versioned and reviewed quarterly. Every access review produces an artifact. Every incident produces a written response and a lessons-learned note. Maturity is not something you fabricate at assessment time. It accumulates as you operate.
External connection registry
Every vendor, subcontractor, and partner connection has an entry. Each entry names an owner, documents the technical restriction, links to the contract that authorized it, and gets reviewed annually. When the assessor asks for the registry, you hand it over and it is accurate.
What the assessment feels like
A Level 2 assessment takes a defined period, usually a week or two, with on-site or remote interviews combined with evidence review. The assessor covers every practice in scope. For each practice, they ask three questions. Is the practice documented. Is the practice followed. Can you show me the evidence.
Programs that have run the playbook above answer all three questions quickly because the documentation is current, the practice runs on autopilot, and the evidence is already instrumented. Programs that have not are scrambling for artifacts and negotiating scope through the entire assessment.
Where to go from here
If you are a defense contractor who needs Level 2 certification and you do not yet have an enclave, the Governance Buildout is the right engagement. It sets up the enclave architecture, the identity plane, the 22 Access Control practices, and the evidence instrumentation that makes maturity sustainable. For contractors with an enclave already in place who are preparing for a first assessment or a recertification, the Hardening Sprint targets the practices that most often produce findings.