CMMC Compliance for Defense Contractors: What to Do First

What this covers and who it is for

CMMC compliance for defense contractors means proving — to a Certified Third-Party Assessment Organization (C3PAO) or to the government directly — that your business handles Controlled Unclassified Information (CUI) the way NIST SP 800-171 Revision 2 says it must. That single sentence is the direct answer, and everything below is how to actually get there.

This hub is written for the people who get handed the problem: the IT manager at a 40-person machine shop outside Richmond that just won its first subcontract, the security lead at a Northern Virginia engineering firm with a dozen contracts already in flight, and the one-person compliance owner at a systems integrator who has to answer a prime contractor’s vendor questionnaire by Friday. Virginia matters here. The state’s defense-industrial base is dense and layered — primes, integrators, and small suppliers stacked on the same contract — and CUI flows down that chain. If your customer’s contract requires it, your company inherits the obligation regardless of your headcount.

What this hub is not: a legal opinion, a certification body, or a substitute for the contract language in front of you. It is a working map for practitioners who need to move from “we should probably look at CMMC” to a scoped, documented, assessable program.

The short version

If you read nothing else, read this:

• CMMC is a verification layer, not a new control set. The underlying security requirements come from NIST SP 800-171 Rev. 2 — 110 requirements across 14 control families (numbered 3.1 through 3.14). CMMC adds assessment, evidence, and an enforceable contracting mechanism on top of those requirements.
• If you touch CUI, the 110 requirements apply. This is true whether or not DFARS 252.204-7012 is cited in your own contract — it typically is cited in the prime’s contract, and flows down through the supply chain.
• CMMC Level 2 is the operative target for most contractors. Levels 1 and 2 exist; Level 1 (17 practices) covers Federal Contract Information only. CUI requires Level 2.
• The document set is the project. A System Security Plan (SSP), a Plan of Action and Milestones (POA&M), a scoping diagram, an inventory, and a policy suite you can actually point an assessor at. Without these, the controls are invisible.
• Start with scope, not with tools. Every dollar spent securing systems outside your assessed boundary is a dollar that does not count.

Key concepts you need first

CUI, FCI, and why the distinction drives everything

Controlled Unclassified Information is unclassified information the government requires to be protected under law, regulation, or policy. It is not a classification level — it is a handling designation. Practically, for defense contractors, it looks like drawings, technical data, test results, vulnerability reports, export-controlled items, and contractual performance data. Federal Contract Information (FCI) is the weaker category: information provided by or generated for the government under a contract that is not public.

The distinction matters because it decides your level. Level 1 protects FCI with 17 practices. Level 2 protects CUI with the full 110 NIST SP 800-171 Rev. 2 requirements. Get the label wrong at the start and every subsequent decision is wrong.

The assessment path

At Level 2, how you get assessed depends on the contract’s size and the DoD’s stated requirements. Smaller annual revenue thresholds trigger a self-assessment path; larger ones require a C3PAO-led assessment and a certificate. Rather than memorize thresholds that shift with rulemaking, read the solicitation clause and your customer’s flow-down language directly and confirm which path your contract names. Own that answer before you budget anything.

The SSP is not paperwork theater

NIST SP 800-171A gives assessors the assessment objectives — what “satisfied” looks like for each requirement. The System Security Plan is where you write down how each of the 110 requirements is met in your environment, referencing which system does it. When a requirement is not yet met, it belongs in the POA&M with a milestone and an owner. The SSP is the difference between “we have MFA” and “we satisfy 3.5.3 by requiring FIDO2 hardware tokens for all VPN and administrative access to the CUI enclave, evidenced by Azure AD Conditional Access logs retained 90 days.”

Control families you will feel the most

• 3.1 Access Control — least privilege, role separation, media restrictions.
• 3.3 Audit and Accountability — logging that survives tampering and is retained long enough to be useful.
• 3.5 Identification and Authentication — MFA (3.5.3), session locking (3.5.10), identifier management.
• 3.8 Media Protection — USB restrictions, sanitization, transport handling.
• 3.11 Risk Assessment — a real assessment cadence, not a one-time questionnaire.
• 3.12 Security Assessment — vulnerability scanning (3.12.1) and remediation timelines (3.12.2), which is where most contractors quietly fail.
• 3.13 System and Communications Protection — boundary protection (3.13.1), data-in-transit protection (3.13.8), and FIPS-validated cryptography (3.13.11).
• 3.14 System and Information Integrity — flaw remediation (3.14.1) and updating malware protection (3.14.4).

Two more that deserve their own line: 3.4.1 requires configuration baselines for CUI systems, and 3.7.5 requires multi-factor authentication for maintenance sessions on CUI assets. Both are common gaps because both are invisible until someone asks for the evidence.

How to apply this

Step 1: Determine your scope in writing

List every contract that might carry CUI obligations. For each, identify the CUI category and where it actually lands in your infrastructure — a folder on the file server, an engineering workstation, an email thread, a SharePoint tenant. Then define your CUI boundary.

Most practical path for a small contractor: build a dedicated CUI enclave. A single virtual network segment, a separate Active Directory instance (or at minimum a hardened organizational unit with its own Group Policy), dedicated file shares, dedicated endpoints, and no domain trust to the business network. The enclave model reduces the assessed scope dramatically compared to the alternative of hardening everything and calling it all in scope.

Write it up: a one-page boundary diagram, an asset inventory of every device in scope, and a data flow showing where CUI enters, lives, and exits. That document becomes your assessment map.

Step 2: Build the SSP skeleton before you fix anything

Create a table with 110 rows — requirement number, requirement text, how you meet it, evidence location, and status. Fill in the status column honestly on day one. You will discover that maybe a third of requirements are already met and a third need work. The remaining third are the ones nobody has ever thought about. Drafting the SSP first forces that conversation early, when changes are cheap.

Step 3: Work the gaps by risk and by evidence cost

Prioritize requirements that are both high-impact and cheap to evidence. MFA on administrative and remote access (3.5.3) usually comes first: it is a hard requirement, it is highly visible, and identity providers make it a configuration change rather than a project. Then vulnerability scanning (3.12.1) and time-bound remediation (3.12.2), because those generate the evidence an assessor wants to see repeated over months. Then 3.13.11 FIPS-validated crypto — check what your VPN, disk encryption, and TLS terminators actually offer, because “FIPS mode available” and “FIPS mode enabled” are different answers.

Step 4: Run the program, not the project

CMMC is a steady-state obligation. Build the calendar: monthly vulnerability scans, quarterly access reviews, periodic risk assessments, an annual review of the SSP, and a change process that updates the boundary diagram when systems enter or leave scope. An assessment that closes with a POA&M requires you to keep working the items; a program with no recurring evidence cycle will fail the next look.

Worked example: a 60-person Virginia supplier

A subcontractor with 60 staff, two buildings, and an on-premises file server gets a flow-down clause from its prime requiring Level 2 protection of CUI. Their first instinct is to harden the whole company.

Instead, they scope. The CUI consists of two things: customer engineering drawings stored on a shared folder, and performance reports emailed between three project managers. They build a CUI enclave of eleven devices and one file server, protected by a hardware firewall with no inbound ports and a site-to-site tunnel to the prime. Access requires FIDO2 tokens — satisfying 3.5.3 — and every enclave login writes to a central log with a write-once store, which addresses 3.3.1 and 3.3.8. USB mass storage is blocked by Group Policy on enclave endpoints, satisfying 3.8.1 and 3.8.2, with a documented exception process for two engineers who need removable media and use organization-issued encrypted drives logged in a register.

Their vulnerability scanning tool runs weekly against the enclave, and they commit to remediating critical findings within a defined window — the schedule they document in the SSP for 3.12.2. The engineering drawings never leave the enclave, so the business network, marketing laptops, and the guest Wi-Fi stay out of scope entirely. Their assessed boundary is a fraction of what it would have been, and the SSP is short enough that the owner can actually keep it current.

That is the shape of a workable program: small scope, documented boundary, hard controls at the chokepoints, and evidence that accumulates automatically rather than being assembled the week before an assessment.

Scope creep is the single largest cost driver in CMMC. Boundary discipline is not a shortcut — it is the control.

Where people get this wrong

• Claiming compliance on a self-assessment questionnaire alone. A signed SPRS submission is a score, not a program. If the underlying SSP does not describe real configurations, the score is fiction and will not survive scrutiny.
• Treating the POA&M as a permanent parking lot. Items sit there for years with no owner and no milestone. Assessors read the POA&M closely; so do primes auditing their supply chain.
• Scope by org chart instead of by data. Contractors declare the whole company out of scope because “only the engineering team touches CUI,” then discover CUI in a salesperson’s mailbox and a shared drive nobody owned.
• Ignoring the boring requirements. Media protection, physical access to the enclave, and configuration baselines generate fewer headlines than MFA but fail assessments just as thoroughly. 3.4.1 and 3.8.1 are habitual ankle-biters.
• Buying tools before defining the boundary. A SIEM deployment spanning the entire company is expensive and, if the boundary is a ten-device enclave, mostly irrelevant to the assessment.
• Assuming the prime’s paperwork is your compliance. A supplier questionnaire answered by the sales team is not an assessment artifact. Build your own evidence trail.
• Skipping the internal review. Requirement 3.12.1 covers vulnerability scanning; 3.12.3 covers the assessment process itself. Contractors scan but never document findings, decisions, and remediation — the assessment asks for the record, not the tool.

Where to go next

Pick the branch that matches where you are today.

• You need the full working walkthrough — scoping, SSP drafting, POA&M structure, and assessment prep end to end: CMMC Compliance for Defense Contractors: A Working Guide.
• You want the practitioner-level overview of how the levels, the assessment paths, and the document set fit together: CMMC Compliance for Defense Contractors: The Practical Hub.
• Your patch and flaw-remediation program is the weak spot — the most common failing area behind 3.12.1, 3.12.2, and 3.14.1: Zero to Patch: A Practical Patch Management Checklist and Patch Management Software Compared: A Practical Buyer’s Guide.
• You need to justify spend to ownership by showing what prioritization actually looks like when you cannot fix everything at once: Beyond CVSS: Contextual Vulnerability Prioritization and Automating Vulnerability Management: Tools and Strategies for Continuous Security Assessments.
• You are building the incident side of the program — DFARS 252.204-7012 incident reporting obligations need a rehearsed plan, not a wiki page: Building a Robust Incident Response Playbook, Incident Response Retainer Explained: What You Are Paying For, and Ransomware Response Playbook: A Copy-Paste Template.
• You want endpoint visibility inside a small enclave so 3.3 and 3.14 evidence is collected automatically: Velociraptor vs osquery vs GRR: Which One Should You Deploy? and Step-by-Step Guide to Installing and Configuring Velociraptor for Digital Forensics and Incident Response.
• You are a small business with no security staff at all, starting from zero: Security for SMBs: What It Is and How to Do It Right and Digital Security for SMBs: Tailoring Solutions for Small and Medium-Sized Businesses.
• You need a repeatable wireless and network audit to evidence boundary protection (3.13.1) and rogue device detection: How to Audit Wireless Networks: A Practical Methodology and Kismet: Wireless Recon and Rogue Access Point Detection.

Start with scope. Write the boundary down, count the assets inside it, and open the 110-row SSP today — even if half the rows say “not met.” A documented gap is a plan. An undocumented gap is what an assessor finds instead.