Skip to content

CMMC collection · Understand CMMC

CMMC requirements: every control, explained

The 15 Level 1 safeguards, the 110 Level 2 controls across 14 families, the 320 assessment objectives, and the documentation assessors expect.

What are the CMMC requirements?
CMMC requirements are the security controls a defense contractor must implement and prove, set by the level in its contracts: 15 basic safeguarding requirements at Level 1, the 110 controls of NIST SP 800-171 at Level 2, and a further subset of NIST SP 800-172 at Level 3. They aren’t new inventions — they are existing federal requirements with verification attached.

How many controls are in CMMC?

  • Level 1 — 15 requirements from FAR 52.204-21, protecting Federal Contract Information (FCI). Verified by annual self-assessment.
  • Level 2 — 110 requirements from NIST SP 800-171, protecting Controlled Unclassified Information (CUI). Verified by a C3PAO assessment for most contracts.
  • Level 3 — 24 additional requirements from NIST SP 800-172, for the highest-priority programs. Assessed by the government (DIBCAC), on top of a Level 2 certification.

The practical unit of assessment is smaller than the control: NIST SP 800-171A breaks the 110 Level 2 requirements into 320 assessment objectives, and every objective must be met for its control to score as satisfied. “Mostly implemented” rounds down.

What are the 14 control families of Level 2?

The 110 controls group into 14 families. Here’s what each one actually governs, and the kind of evidence assessors ask for:

FamilyWhat it coversTypical evidence
Access Control (AC)Who can reach what — accounts, sessions, remote access, least privilegeAccount lists, access reviews, remote-access configs
Awareness & Training (AT)Staff know the threats and their responsibilitiesTraining records, role-based curricula
Audit & Accountability (AU)System activity is logged, protected, and reviewableLog configs, retention settings, review notes
Configuration Management (CM)Systems run known, hardened baselinesBaseline docs, change tickets, allow/deny lists
Identification & Authentication (IA)Users and devices prove who they are — including MFAMFA enrollment, password policy, identifier lifecycle
Incident Response (IR)Incidents get detected, reported, and handledIR plan, test records, reporting procedures
Maintenance (MA)Systems are maintained without opening new holesMaintenance logs, sanitized-media procedures
Media Protection (MP)CUI on media is marked, controlled, and destroyed properlyMarking examples, sanitization certificates
Personnel Security (PS)People are screened; access ends when they leaveScreening records, offboarding checklists
Physical Protection (PE)Physical access to systems and CUI is controlledVisitor logs, badge records, facility diagrams
Risk Assessment (RA)Risks and vulnerabilities are assessed and remediatedRisk assessments, scan results, remediation records
Security Assessment (CA)Controls are periodically assessed and gaps plannedSelf-assessment results, SSP, POA&M
System & Communications Protection (SC)Networks and CUI in transit/at rest are protected — including FIPS-validated encryptionNetwork diagrams, encryption configs, boundary rules
System & Information Integrity (SI)Flaws get fixed; malicious code gets caughtPatch records, AV/EDR configs, alert handling

What are assessment objectives — and why do they matter?

Each control decomposes into objectives that an assessor tests individually. Take multifactor authentication (3.5.3): the objectives separately verify that privileged accounts, network access, and local access are each covered. Implementing MFA “mostly” — say, for remote users but not local admins — fails the control. This is the single most common reason self-assessed scores collapse under third-party review: contractors score the sentence, assessors score the objectives.

What documentation is required?

  • System Security Plan (SSP) — the master document describing your environment, boundary, and how each control is met. The first thing every assessor reads.
  • Plan of Action & Milestones (POA&M) — the managed list of gaps, owners, and dates for anything not yet fully implemented.
  • Policies and procedures — written rules that match observed practice, family by family.
  • Evidence — the artifacts (configs, logs, records, screenshots) that prove each objective, ideally organized so any of the 320 can be answered on demand.

Frequently asked questions

Are written policies required for CMMC?

Effectively yes at Level 2. Assessment objectives repeatedly test whether requirements are 'defined' — which means documented — and assessors expect policies and procedures that match how you actually operate, not templates with your logo.

Can you inherit requirements from an MSP or cloud provider?

Partially. Providers can satisfy or support some controls, documented in a shared responsibility matrix — but the certification and the accountability stay yours, and assessors will test that you understand and manage what's inherited.

Does Level 1 require an SSP?

The CMMC rule doesn't require a formal System Security Plan for Level 1 self-assessment. It's still worth writing a lightweight one: it disciplines your scoping, and most Level 1 companies grow into Level 2 obligations.

Do the requirements change when NIST updates 800-171?

CMMC Level 2 currently assesses against NIST SP 800-171 Revision 2. DoD controls when the program moves to a newer revision through rulemaking — you certify against the revision in effect for your assessment, not whatever NIST published most recently.

Free 30-minute readiness call

Walk into your CMMC assessment ready.

Book a 30-minute readiness call with a Fortwise advisor. No high-pressure sales — just a clear read on where you stand and what it takes to certify.

  • Confirm which CMMC level your contracts actually require
  • Pinpoint the gaps most likely to fail your assessment
  • Leave with a clear, prioritized path to certification

One-on-one with a CMMC advisor · No obligation · We never store your CUI