By The Defense Compliance Report Editorial Team · Last verified August 21, 2026 By The Defense Compliance Report Editorial Team Last verified: August 21, 2026
The CMMC 14 domains list is the set of 14 categories that organize every CMMC security requirement. Under 32 CFR § 170.14(b), the CMMC Model "consists of domains that map to the Security Requirement Families defined in NIST SP 800-171 R2." All 14 are populated at Level 2, which holds 110 security requirements. Level 1 uses only six of them.
That last sentence is the part almost nobody tells you, and it is the reason so many contractors waste their first month.
Here is the list.
| Abbr. Domain Level 2 requirements | ||
|---|---|---|
| AC | Access Control | 22 |
| AT | Awareness and Training | 3 |
| AU | Audit and Accountability | 9 |
| CM | Configuration Management | 9 |
| IA | Identification and Authentication | 11 |
| IR | Incident Response | 3 |
| MA | Maintenance | 6 |
| MP | Media Protection | 9 |
| PS | Personnel Security | 2 |
| PE | Physical Protection | 6 |
| RA | Risk Assessment | 3 |
| CA | Security Assessment | 4 |
| SC | System and Communications Protection | 16 |
| SI | System and Information Integrity | 7 |
| Total | 110 |
Source: DoD CIO, CMMC Model Overview, Version 2.13, September 2024 (DoD-CIO-00001), §§ 2.3–2.4; 32 CFR § 170.14. Counts are ours, taken requirement by requirement from the official model.
You now have the list. What you probably don't have is the thing that actually determines how your next six months go: these 14 domains are wildly unequal. One holds 22 requirements. One holds two. One carries 54 points of scoring weight. One carries eight. And three of them contain zero requirements you are allowed to be late on.
We built the map that shows all of it. Keep reading.
Use this page if — and when to go somewhere else
This page is for you if you need to:
- Confirm the correct 14 domain names and abbreviations against the current rule
- Understand why some pages say 17 and yours says 14
- See which domains actually apply at your level
- Figure out which domain to start with, and who in your company should own it
- Build the section structure for a System Security Plan or an evidence folder
Go somewhere else if you need to:
- Read all 110 requirements one by one, with point values and POA&M treatment. That is a different job and we have a different page for it. → NIST 800-171 110 controls list
- Find out which CMMC level applies to your contract. A domain list cannot answer that. Your contract clause and your actual FCI/CUI handling do. → CMMC levels explained and CMMC scoping guide
- Figure out whether you even handle CUI. Stop here. That question comes first and everything on this page depends on the answer. → What is CMMC?
The Defense Compliance Report is the independent trade publication and decision resource for CMMC and Defense Industrial Base compliance — explaining the CMMC Final Rule with primary-source citation on every claim and mapping a contractor's level, CUI scope, assessment type, and timeline to the right provider category, so DIB contractors choose the right CMMC path before they spend six figures.
What are the 14 CMMC domains?
CMMC has 14 domains: Access Control, Awareness and Training, Audit and Accountability, Configuration Management, Identification and Authentication, Incident Response, Maintenance, Media Protection, Personnel Security, Physical Protection, Risk Assessment, Security Assessment, System and Communications Protection, and System and Information Integrity. They correspond one-to-one with the 14 security requirement families in NIST SP 800-171 Revision 2, and together they organize the 110 requirements that make up CMMC Level 2.
A domain is a category. That is all it is. It is not a separate certification, not a separate assessment, not a product you buy, and not a document you are required to write.
We say that plainly because the most expensive early mistake we see is a small contractor treating the list of 14 as a list of 14 projects — hiring against it, buying against it, or producing 14 policy binders nobody will ever read. The rule does not ask for that. What it asks for is that the individual requirements inside each category are implemented and can be evidenced.
Here is what each domain actually governs, in plain terms:
| Domain Abbr. The job it does | ||
|---|---|---|
| Access Control | AC | Who and what can get into your systems, what they're allowed to do once inside, and how CUI moves across remote, wireless, mobile, and external connections |
| Awareness and Training | AT | Whether your people understand the risks in their own roles and can recognize insider-threat indicators |
| Audit and Accountability | AU | What gets logged, how logs are protected and retained, and how activity is traced back to a specific person |
| Configuration Management | CM | What your systems are supposed to look like, how changes are approved, and how unnecessary or unauthorized software and services are kept out |
| Identification and Authentication | IA | Proving that users, devices, and processes are who they claim to be — including multifactor authentication |
| Incident Response | IR | How you prepare for, handle, report, and actually test your response to a security incident |
| Maintenance | MA | How system maintenance is performed and controlled, including remote sessions run by outside technicians |
| Media Protection | MP | Protecting CUI on media — digital and paper — through storage, marking, transport, encryption, and destruction |
| Personnel Security | PS | Screening people before access, and protecting systems when people leave or change roles |
| Physical Protection | PE | Controlling physical access to systems and facilities, including visitors and alternate work sites |
| Risk Assessment | RA | Assessing risk, scanning for vulnerabilities, and remediating what you find |
| Security Assessment | CA | Assessing your own controls, planning remediation, monitoring continuously, and maintaining the System Security Plan |
| System and Communications Protection | SC | Protecting boundaries and communications — segmentation, encryption in transit and at rest, cryptographic key management |
| System and Information Integrity | SI | Patching flaws, stopping malicious code, monitoring for attacks, and detecting unauthorized use |
Two of the abbreviations don't match their names, and this trips people up constantly.
PE is Physical Protection, not "PP." CA is Security Assessment, not "SA." Both are inherited from NIST SP 800-53, where the equivalent family is called "Assessment, Authorization, and Monitoring (CA)." The CFR points derived requirements back at SP 800-53 Revision 5 at § 170.24(c)(2)(i)(B), which is where the lettering comes from. If you have been searching for the "CMMC SA domain" and finding nothing — that is why. It's CA.
The CMMC 14-Domain Responsibility and Evidence Map
Each CMMC domain has an operational center of gravity — a function in the business that is best positioned to own it, a first artifact worth inventorying, and a dependency that should be resolved before the work starts. The regulatory columns below come from 32 CFR Part 170 and the official CMMC model. The owner, evidence, and dependency columns are The Defense Compliance Report's editorial guidance, not government requirements.
This is the part we built because nothing else on the internet had it.
Every list page will give you 14 names. None of them tell you the two things that actually stall a CMMC project inside a small company: who is supposed to do this, and what does "done" look like in a folder.
So we combined the regulatory data with a responsibility layer. Two tables. Read them together.
Table A — The count and weight matrix
| Domain Abbr. L1 reqs L2 reqs L3 additions L2 assessment objectives L2 maximum-deduction points Can go on a POA&M | |||||||
|---|---|---|---|---|---|---|---|
| Access Control | AC | 4 | 22 | 2 | 70 | 54 | 11 |
| Awareness and Training | AT | 0 | 3 | 2 | 9 | 11 | 1 |
| Audit and Accountability | AU | 0 | 9 | 0 | 29 | 19 | 6 |
| Configuration Management | CM | 0 | 9 | 3 | 44 | 33 | 3 |
| Identification and Authentication | IA | 2 | 11 | 2 | 25 | 27 | 7 |
| Incident Response | IR | 0 | 3 | 2 | 14 | 11 | 1 |
| Maintenance | MA | 0 | 6 | 0 | 10 | 18 | 2 |
| Media Protection | MP | 1 | 9 | 0 | 15 | 23 | 4 |
| Personnel Security | PS | 0 | 2 | 1 | 4 | 8 | 0 |
| Physical Protection | PE | 2 | 6 | 0 | 16 | 14 | 1 |
| Risk Assessment | RA | 0 | 3 | 7 | 9 | 9 | 1 |
| Security Assessment | CA | 0 | 4 | 1 | 14 | 13 | 0 |
| System and Communications Protection | SC | 2 | 16 | 1 | 41 | 42 | 9 (+1 conditional) |
| System and Information Integrity | SI | 4 | 7 | 3 | 20 | 31 | 0 |
| Total | 15 | 110 | 24 | 320 | 313 | 46 (+1) |
Sources and method: Requirement counts at all three levels are our count from the DoD CIO CMMC Model Overview v2.13, §§ 2.3–2.4, taken requirement by requirement. Point values are from 32 CFR § 170.24(c)(2)(i)(B), which lists every 5-point and 3-point requirement by ID; we read that subparagraph in full on August 21, 2026 and assigned the remainder per subparagraph (3). Assessment objective counts are our count from NIST SP 800-171A and the official CMMC Level 2 Assessment Guide, published on our 110-requirement checklist. POA&M eligibility is derived from 32 CFR § 170.21(a)(2).
Table B — Likely owner and starter evidence
Editorial guidance from The Defense Compliance Report. The rule does not assign responsibility to a job title. This is where we would start, based on where the work actually lives.
| Domain Likely accountable owner First evidence to inventory Resolve this dependency first | |||
|---|---|---|---|
| AC | IT / identity administrator | Account and service-account inventory, access matrix, remote-access configuration | CUI scope, identity source of truth |
| AT | HR with the security lead | Training content, completion roster, role-based training records | Defined roles and responsibilities |
| AU | Security operations / IT | Log-source inventory, retention settings, review records | Time synchronization and identity |
| CM | IT operations or engineering | Hardware and software inventory, approved baselines, change tickets | A complete asset inventory and system boundary |
| IA | Identity administrator | Account lifecycle records, MFA configuration, credential settings | HR joiner/mover/leaver process |
| IR | Security lead with leadership | Incident response plan, contact tree, tabletop or test record | Logging and reporting obligations |
| MA | IT or OT maintenance owner | Maintenance tickets, remote maintenance procedure, tool controls | Vendor and MSP access agreements |
| MP | Security, records, and facilities | Media inventory, markings, sanitization and destruction records | Knowing where CUI physically exists |
| PS | HR with the security lead | Screening records, transfer and termination checklist | Identity and access lifecycle |
| PE | Facilities or physical security | Authorized access list, visitor logs, badge and key inventory | Personnel authorization records |
| RA | Risk or security lead | Risk assessment, vulnerability scan output, remediation records | Accurate scope and asset inventory |
| CA | GRC owner or security leadership | SSP, self-assessment record, POA&M, monitoring records | Inputs from every other domain |
| SC | Network and security architecture | Boundary diagram, data-flow diagram, firewall rules, encryption evidence | CUI flow and external service providers |
| SI | IT operations and security | Patch records, endpoint protection settings, advisories, monitoring alerts | Configuration inventory and logging |
One caveat we want to be direct about: a single artifact does not prove a domain. A CMMC Level 2 finding is made at the individual requirement level, after an assessor evaluates every applicable assessment objective using the examine, interview, and test methods described in the official assessment guidance. The "first evidence" column is where to start a folder, not a shortcut to a finding.
Notice how many of these owners are not in IT. HR owns two domains outright. Facilities owns one. That is the real reason CMMC stalls in a hypothetical 40-person machine shop: the work was handed to one IT person who has no authority over hiring records, visitor logs, or training rosters.
🔻 Turn the list into a work plan
You now have the map. The next step is short, free, and takes about ten minutes.
Turn the domain list into a real readiness plan. Use the 32-point CMMC readiness checklist to identify the gaps that can block an assessment before you start buying tools or booking an assessor.
Do not enter CUI, drawings, credentials, network details, or contract information. Use internal reference labels only — "Ticket CM-014," not the artifact itself.
Why do some CMMC lists show 17 domains instead of 14?
CMMC currently has 14 domains. A "17" figure usually comes from one of three places: the retired CMMC 1.0 model, which had 17 domains and five levels; NIST SP 800-171 Revision 3, which reorganizes the standard into 17 families and is not the CMMC Level 2 baseline; or a mapping artifact in the Level 1 requirement tables. All three are real. None of them changes the current answer, which is 14.
That third one deserves a moment, because we think it is the actual source of a specific error you will see repeated on page one of any search engine.
The mapping artifact nobody explains
You will find current, well-known pages stating that CMMC Level 1 has 17 practices. Level 1 has 15. The rule is unambiguous: 32 CFR § 170.14(c)(2) sets Level 1 as the safeguarding requirements at 48 CFR 52.204-21(b)(1)(i) through (b)(1)(xv). That's fifteen.
So where does 17 come from? We went and looked.
In the official CMMC model matrix, one Level 1 requirement maps to three separate NIST SP 800-171 Revision 2 requirements. PE.L1-b.1.ix — escort visitors and monitor visitor activity; maintain audit logs of physical access; and control and manage physical access devices — is a single FAR safeguard containing three distinct obligations. The model matrix maps it to NIST 3.10.3, 3.10.4, and 3.10.5, on three lines.
Fifteen requirements. Seventeen mapping rows. Somebody counted the rows.
That is not a trivial distinction. If you build a Level 1 self-assessment against 17 line items instead of 15, you are self-assessing against a structure the rule does not use, and your affirmation is describing something that doesn't match the clause.
The number decoder
Here is every number you will encounter on this topic and what it actually refers to. Print this if you need to argue with a vendor's slide deck.
| Number What it actually means | |
|---|---|
| 14 | Current CMMC domains, mapped to the NIST SP 800-171 Revision 2 security requirement families |
| 15 | Current CMMC Level 1 security requirements, from FAR 52.204-21(b)(1)(i)–(xv) |
| 17 (domains) | Retired. CMMC 1.0, superseded when 32 CFR Part 170 took effect December 16, 2024 |
| 17 (families) | NIST SP 800-171 Revision 3 — a real 17, just not the one CMMC Level 2 uses today |
| 17 (mapping rows) | The Level 1 mapping artifact above. Fifteen requirements, seventeen rows |
| 24 | Selected NIST SP 800-172 requirements codified as CMMC Level 3 additions, per § 170.14(c)(4) |
| 110 | CMMC Level 2 security requirements — identical to NIST SP 800-171 Revision 2 |
| 134 | 110 Level 2 requirements plus the 24 codified Level 3 additions |
| 313 | Total SPRS point weight at risk across the 110 Level 2 requirements (our computation — see below) |
| 320 | Level 2 assessment objectives — the individual determinations behind the 110 requirements |
We will also say the uncomfortable part out loud, because it affects whether you should trust any list you find: some currently ranking pages publish a domain list that mixes retired CMMC 1.0 domain names into a Revision 2 list. We found lists that still total 14 but include categories that no longer exist in the model, while omitting ones that do. If you are checking your list against a blog post, check it against the DoD CIO model document instead. It is free, it is 42 pages, and § 2.3 is the whole answer.
Do all 14 CMMC domains apply at Levels 1, 2, and 3?
No. The three CMMC levels use the 14 domains very differently. Level 1 has requirements in only six domains. Level 2 populates all 14 with 110 requirements. The codified Level 3 model adds 24 selected NIST SP 800-172 requirements across ten domains, on top of a maximum Level 2 score.
This is the single most useful thing on this page for anyone who is not certain which level applies to them.
| Level Information protected Requirements come from Domains used Count | ||||
|---|---|---|---|---|
| Level 1 | Federal Contract Information (FCI) | FAR 52.204-21(b)(1)(i)–(xv) | 6 of 14 | 15 |
| Level 2 | Controlled Unclassified Information (CUI) | NIST SP 800-171 Revision 2 | All 14 | 110 |
| Level 3 | CUI, against advanced persistent threats | Level 2 plus selected NIST SP 800-172 (Feb 2021) | 10 of 14 | 110 + 24 |
At Level 1, eight domains are empty
Level 1's fifteen requirements sit in Access Control (4), Identification and Authentication (2), Media Protection (1), Physical Protection (2), System and Communications Protection (2), and System and Information Integrity (4).
These eight domains have zero Level 1 requirements: Awareness and Training, Audit and Accountability, Configuration Management, Incident Response, Maintenance, Personnel Security, Risk Assessment, and Security Assessment.
If you handle FCI only, and someone hands you a 14-domain checklist, more than half of it does not apply to you. We have watched contractors spend weeks writing audit logging policy for a Level 1 obligation that contains no audit logging requirement.
There's a detail in that Level 1 set worth knowing. Level 1's only media requirement — sanitize or destroy media containing FCI before disposal or reuse — is the same control that is worth five points at Level 2, where it appears as MP.L2-3.8.3. The one media rule an FCI-only company has is also one of the heaviest at Level 2. If you ever step up, you already own it.
At Level 3, the model inverts
Four domains add nothing at Level 3: Audit and Accountability, Maintenance, Media Protection, and Physical Protection. NIST says so in SP 800-172 itself — those families contain no enhanced security requirements.
But the more interesting change is the shape.
Access Control is the largest domain at Level 2 with 22 requirements. At Level 3 it drops to two. Meanwhile Risk Assessment goes from three requirements to seven — nearly a third of the entire Level 3 set, and the largest Level 3 domain by a wide margin.
Read that as a statement of intent. Level 2 asks whether you control access to CUI. Level 3 asks whether you understand the threat coming at it — threat intelligence, threat hunting, supply chain risk, security solution effectiveness. That is the actual difference between the levels, and you can see it in the counts before you read a single control.
One more Level 3 rule that catches people: under § 170.24(c)(3), a maximum score on the Level 2 certification assessment is required to be eligible to initiate a Level 3 certification assessment. No partial credit, no carryover gaps. Level 3 also scores flat — every requirement is worth exactly one point.
The right provider category depends on your situation, not on this list
The right CMMC provider isn't the same for every contractor — the category you need (a C3PAO, an RPO, an MSSP, a GRC platform, or a CUI enclave) depends on your required CMMC level, whether you handle FCI or CUI, your assessment type, your cloud and IT environment, and your contract timeline. The contract clause sets your level, not a checklist. Because a general answer can't resolve those for you, use The Defense Compliance Report's Find My CMMC Path tool to map your situation to the right provider category before you request quotes — and do not submit CUI, drawings, or sensitive contract details.
Definitions, since we just used five acronyms: a C3PAO is a CMMC Third-Party Assessment Organization, authorized to conduct formal Level 2 certification assessments. An RPO is a Registered Practitioner Organization, which provides readiness and implementation help — and an RP is a Registered Practitioner, the individual credential. An MSSP is a Managed Security Service Provider. A GRC platform is governance, risk, and compliance software for tracking evidence and control status. A CUI enclave is a segmented environment built to hold CUI so the rest of your network stays out of scope.
Which CMMC domains carry the most scoring weight?
Access Control carries the most CMMC scoring weight at 54 points, followed by System and Communications Protection at 42, Configuration Management at 33, and System and Information Integrity at 31. Point values are assigned by 32 CFR § 170.24(c)(2)(i)(B), which weights each requirement at 5, 3, or 1 point according to how severely DoD judges the consequence of not implementing it. The Supplier Performance Risk System (SPRS) is the government database where contractors post their self-assessment scores.
Here is the part that changes how you sequence work: domain size does not predict domain weight.
| Rank By requirement count By points at risk By assessment objectives | |||
|---|---|---|---|
| 1 | Access Control (22) | Access Control (54) | Access Control (70) |
| 2 | System & Comms Protection (16) | System & Comms Protection (42) | Configuration Management (44) |
| 3 | Identification & Authentication (11) | Configuration Management (33) | System & Comms Protection (41) |
| 4 | Audit & Accountability (9) | System & Information Integrity (31) | Audit & Accountability (29) |
| 5 | Configuration Management (9) | Identification & Authentication (27) | Identification & Authentication (25) |
| 6 | Media Protection (9) | Media Protection (23) | System & Information Integrity (20) |
Look at System and Information Integrity. It is the seventh-largest domain by requirement count and the fourth-heaviest by points. Seven requirements, 31 points — an average of 4.43 points per requirement, the highest density in the entire model against an overall average of 2.85.
Audit and Accountability runs the other way: nine requirements, 19 points, 2.11 points each — the lightest domain in the model.
So "start with the biggest domain" is bad advice. It's also the advice every list page implies by putting Access Control first.
The arithmetic that proves the point values
We are showing our work here because you should not take a number like "54 points" on faith from any website, including ours.
``` 42 requirements × 5 points = 210 14 requirements × 3 points = 42 2 requirements × 5 points = 10 ← partial-credit maximum 51 requirements × 1 point = 51 1 requirement × 0 points = 0 ← the SSP gate ────────────────────────────────────── 110 requirements 313 total points at risk
110 − 313 = −203
```
−203 is the published floor of the SPRS scoring range. The fact that our point assignments produce exactly that number is a check on the whole dataset. If we had miscounted a single requirement anywhere in the 14 domains, the arithmetic would not land.
It also settles a question the CFR never answers directly: CA.L2-3.12.4, the System Security Plan requirement, carries no point value at all. If it carried even one point, the floor would be −204. Under § 170.24(c)(2)(i)(5), the absence of a current SSP doesn't cost you points — it produces a finding that the assessment could not be completed. It isn't a scored requirement. It's a gate.
The two partial-credit exceptions are named in the rule: IA.L2-3.5.3 (multifactor authentication — three points off if you've implemented it only for remote and privileged users, five if not at all) and SC.L2-3.13.11 (FIPS-validated cryptography — three points off if you encrypt but the cryptography isn't FIPS-validated, five if you don't encrypt). Those are the only two.
The number that tells you where the work is
Points measure score risk. Assessment objectives measure evidence work. They rank the domains differently, and the gap is where budgets get blown.
| Domain Objectives (share of 320) Points (share of 313) What it means | |||
|---|---|---|---|
| Configuration Management | 44 (13.8%) | 33 (10.5%) | Heavy evidence lift relative to score |
| Audit and Accountability | 29 (9.1%) | 19 (6.1%) | The widest effort-to-score gap in the model |
| Physical Protection | 16 (5.0%) | 14 (4.5%) | Roughly proportional |
| System and Information Integrity | 20 (6.3%) | 31 (9.9%) | Light evidence lift, heavy score consequence |
| Maintenance | 10 (3.1%) | 18 (5.8%) | Small domain, disproportionate score |
| Personnel Security | 4 (1.3%) | 8 (2.6%) | Four determinations. Double the score share |
Configuration Management alone carries more assessment objectives (44) than Personnel Security, Awareness and Training, Maintenance, and Risk Assessment combined (32).
The practical read: if you're budgeting hours, plan against objectives. If you're budgeting score risk, plan against points. Configuration Management is the clearest case — it is the second-heaviest evidence lift in the model and only the third-heaviest scoring domain. Nobody has put those two numbers next to each other before, because it required two separate counts against two separate documents.
One thing objective density is not: an official difficulty rating. It is a count of determinations, not a measure of how hard your specific environment makes them. A shop with one cloud tenant and 12 laptops will find Configuration Management easier than a manufacturer with 30 years of legacy CNC equipment, no matter what the count says.
Which CMMC domains can't go on a POA&M?
Personnel Security, Security Assessment, and System and Information Integrity contain zero POA&M-eligible requirements. Every requirement in those three domains must be met at the time of assessment. This follows from 32 CFR § 170.21(a)(2)(ii), which bars any requirement worth more than one point from a Plan of Action and Milestones — and those three domains contain almost no one-point requirements.
A POA&M is the mechanism that lets you close a gap after an assessment instead of before it. It is the difference between "we'll fix that in Q1" and "we can't bid."
Here is how thin that margin actually is, by domain:
| Domain L2 requirements Can be deferred Cannot be deferred | |||
|---|---|---|---|
| Access Control | 22 | 11 | 11 |
| Awareness and Training | 3 | 1 | 2 |
| Audit and Accountability | 9 | 6 | 3 |
| Configuration Management | 9 | 3 | 6 |
| Identification and Authentication | 11 | 7 | 4 |
| Incident Response | 3 | 1 | 2 |
| Maintenance | 6 | 2 | 4 |
| Media Protection | 9 | 4 | 5 |
| Personnel Security | 2 | 0 | 2 |
| Physical Protection | 6 | 1 | 5 |
| Risk Assessment | 3 | 1 | 2 |
| Security Assessment | 4 | 0 | 4 |
| System & Comms Protection | 16 | 9 (+1 conditional) | 6 |
| System & Information Integrity | 7 | 0 | 7 |
| Total | 110 | 46 (+1) | 63 |
Physical Protection is nearly as tight as the three zeroes. It has four one-point requirements — but three of them (PE.L2-3.10.3, 3.10.4, 3.10.5) are named exclusions in § 170.21(a)(2)(iii), which lists six specific requirements that cannot be deferred regardless of point value. That leaves exactly one deferrable requirement in the whole Physical Protection domain.
Now the consequence, which is the most expensive fact on this page:
A single unmet requirement in Personnel Security, Security Assessment, or System and Information Integrity removes your Conditional status at any score.
Work the math two ways.
- Company A meets 109 of 110. The one gap is a 5-point requirement in System and Information Integrity. Score: 105 out of 110 — 95%. Conditional status: not available.
- Company B meets 88 of 110. All 22 points of gap are in one-point requirements that qualify for a POA&M. Score: 88 — exactly the threshold. Conditional status: granted.
The company scoring 95% is the one that can't take the contract. The company scoring 80% can, and has 180 days from its Conditional status date to close the POA&M.
That inversion is not intuitive, it is not on any competing page we found, and it is the reason "what's our score?" is the wrong first question. The right one is "where are our gaps?"
🔻 Find out exactly where your gaps sit
The domain view tells you which categories have no margin. The requirement view tells you which specific controls are costing you points and which ones qualify for a POA&M.
Open the complete 110-requirement checklist →
Every Level 2 requirement, its domain, its point value, its assessment objective count, and whether it can go on a POA&M — sourced to 32 CFR § 170.24 and § 170.21.
Are CMMC domains the same as NIST SP 800-171 control families?
They correspond one-to-one, but they are not identical objects. 32 CFR § 170.14(b) says the CMMC Model "consists of domains that map to the Security Requirement Families defined in NIST SP 800-171 R2." There are 14 of each and the names align. The difference is what they hold: a NIST family contains only NIST SP 800-171 requirements, while a CMMC domain can contain requirements drawn from three different source documents.
Concretely: Access Control as a NIST family holds 22 requirements. Access Control as a CMMC domain holds 28 — four from FAR 52.204-21 at Level 1, 22 from NIST SP 800-171 Revision 2 at Level 2, and two from NIST SP 800-172 at Level 3.
That is why the requirement identifiers look the way they do. Section 2.4 of the CMMC Model Overview defines the format as DD.L#-REQ — two-letter domain, level number, source requirement number.
| Identifier Domain Level Source document | |||
|---|---|---|---|
AC.L1-b.1.i | Access Control | 1 | FAR 52.204-21, paragraph (b)(1)(i) |
AC.L2-3.1.1 | Access Control | 2 | NIST SP 800-171 Rev. 2, § 3.1.1 |
AC.L3-3.1.2e | Access Control | 3 | NIST SP 800-172, § 3.1.2e (the "e" means enhanced) |
The identifier tells you which rulebook the requirement came from. Once you see that, the whole model becomes readable, and you stop mixing Level 1 and Level 2 obligations in the same spreadsheet.
While we're being precise about vocabulary:
| Term What it means | |
|---|---|
| Domain | The CMMC category, mapped to a NIST family |
| Family | NIST's category for related security requirements |
| Security requirement | One of the 110 numbered Level 2 items. The formal term used by the rule |
| Control | Common industry shorthand for a security requirement. Not the rule's word, but everyone uses it |
| Practice | Legacy CMMC 1.0 vocabulary. If a document says "practices," check its date |
| Assessment objective | An individual determination statement evaluated during assessment. There are 320 across the 110 |
| Evidence | What an assessor examines, asks about, or tests |
Do not tell your leadership there are "14 controls." There are 14 domains containing 110 security requirements and 320 assessment objectives. Those three numbers answer three different questions, and conflating them is how a project gets scoped at a tenth of its real size.
Does CMMC use NIST SP 800-171 Revision 2 or Revision 3?
CMMC Level 2 uses NIST SP 800-171 Revision 2. 32 CFR § 170.14(c)(3) states that the Level 2 security requirements are identical to the requirements in NIST SP 800-171 R2, which the rule incorporates by reference. NIST withdrew Revision 2 on May 14, 2024 and superseded it with Revision 3, but a NIST publication update does not amend a federal regulation. Revision 2 remains the CMMC baseline until the rule changes.
This looks like a contradiction and it isn't one. NIST publishes standards. DoD regulates. When a regulation incorporates a specific edition of a standard by reference, that edition stays binding until the regulation is amended — regardless of what the standards body does afterward.
Practically: if you build to Revision 3 right now and score yourself against it, you will show unmet requirements against a standard nobody is assessing you on. Different family structure, different requirement numbering, different objectives. Track Revision 3 for planning. Don't score against it.
Here's the part we can't tell you
We don't know how long this list stays at 14.
The Department of War has a rulemaking on its regulatory agenda — RIN 0790-AM01 — that would move CMMC from Revision 2 to Revision 3. Revision 3 reorganizes the standard into 17 families. If that rule publishes as written, the answer to "how many CMMC domains are there" changes.
It was targeted for July 2026. It has already slipped past its own date. As of August 21, 2026, no interim final rule has published. Any page telling you the domain count changes on a specific date is guessing, and we'd rather say we don't know than give you a fake date to plan against.
But here is why it matters less than it sounds.
Revision 3 doesn't delete the 14 subject areas you're organizing around. It keeps them and adds three — planning, system and services acquisition, and supply chain risk management. Nothing you build against a domain today gets thrown away. You would be adding sections to a structure, not rewriting one.
So the correct move is not to wait. Organize your System Security Plan, your evidence folders, and your ownership map around these 14 now. If the rule lands, you add three folders.
If you want the full picture on which revision binds you and by what instrument — including the class deviation that pinned Revision 2 in place twelve days before Revision 3 published — we mapped every instrument in play:
→ Which NIST 800-171 revision binds you, and by what instrument → NIST 800-171 Rev. 2 vs Rev. 3: what actually changes
What does each of the 14 CMMC domains cover?
Below is each domain with its counts, its scoring weight, and one detail from the source documents that we think changes how you'd approach it. We've deliberately kept these short. If you need every requirement inside a domain, the 110-requirement checklist has them.
Access Control (AC)
22 requirements · 70 objectives · 54 points · 11 deferrable · Level 1: 4 · Level 3: 2
The largest domain by every measure. Controls who gets in, what they can do, and how CUI moves across remote, wireless, mobile, and external connections.
Here's what's counterintuitive: despite being the heaviest domain, Access Control is also the most forgiving. Thirteen of its 22 requirements are worth one point, and 11 of those qualify for a POA&M. It carries the most weight and the most flexibility at the same time. (Likely owner: IT or identity administration.)
Awareness and Training (AT)
3 requirements · 9 objectives · 11 points · 1 deferrable · Level 1: 0 · Level 3: 2
Three requirements — role-based risk awareness, role-based training, and insider threat awareness training.
Two of the three are 5-pointers. That is the highest five-point concentration of any small domain in the model. Awareness and Training carries the same total weight as Incident Response with the same number of requirements, and most companies treat it as a checkbox. (Likely owner: HR with the security lead.)
Audit and Accountability (AU)
9 requirements · 29 objectives · 19 points · 6 deferrable · Level 1: 0 · Level 3: 0
Logging, retention, protection of audit records, and tracing activity to individuals.
The lightest domain in the model at 2.11 points per requirement — and simultaneously the fourth-heaviest evidence lift at 29 objectives. If you are looking for the domain where effort most outruns score, this is it. Level 3 adds nothing here. (Likely owner: security operations.)
Configuration Management (CM)
9 requirements · 44 objectives · 33 points · 3 deferrable · Level 1: 0 · Level 3: 3
Baselines, change control, least functionality, and control of user-installed software.
Six of its nine requirements are worth 5 points, and it has zero 3-point requirements. That makes Configuration Management the densest five-point domain in the entire model. Combined with 44 assessment objectives, it is the domain most likely to be underestimated at the planning stage. (Likely owner: IT operations or engineering.)
Identification and Authentication (IA)
11 requirements · 25 objectives · 27 points · 7 deferrable · Level 1: 2 · Level 3: 2
Identifying and authenticating users, devices, and processes — including multifactor authentication and credential handling.
Contains IA.L2-3.5.3, one of only two requirements in the entire model eligible for partial credit. Implement MFA for remote and privileged users only and you lose three points instead of five. That partial credit is written into § 170.24(c)(2)(i)(B)(4) and it is worth knowing about when you're triaging. (Likely owner: identity administration.)
Incident Response (IR)
3 requirements · 14 objectives · 11 points · 1 deferrable · Level 1: 0 · Level 3: 2
Incident handling capability, incident reporting, and testing that capability.
Small at Level 2, but it nearly doubles at Level 3, which adds a 24/7 security operations center capability and a cyber incident response team deployable within 24 hours. If Level 3 is anywhere in your future, this is the domain where the jump is most operationally expensive. (Likely owner: security lead with leadership.)
Maintenance (MA)
6 requirements · 10 objectives · 18 points · 2 deferrable · Level 1: 0 · Level 3: 0
How maintenance gets done, who does it, and how tools, media, and remote sessions are controlled.
Four of these six describe work an outside technician or MSP performs — and 16 of the domain's 18 points cannot be deferred. In this domain your provider's behavior is scored as your compliance. (Likely owner: IT or OT maintenance.) → Full breakdown of the Maintenance domain
Media Protection (MP)
9 requirements · 15 objectives · 23 points · 4 deferrable · Level 1: 1 · Level 3: 0
Protecting CUI on media through storage, access, marking, transport, sanitization, and destruction.
The only domain whose requirement text explicitly covers paper. MP.L2-3.8.1 says "both paper and digital." That single word is why no cloud tenant, enclave, or FedRAMP shared-responsibility matrix can carry this domain for you. (Likely owner: security, records, and facilities.) → Full breakdown of the Media Protection domain
Personnel Security (PS)
2 requirements · 4 objectives · 8 points · 0 deferrable · Level 1: 0 · Level 3: 1
Screening individuals before granting access, and protecting systems during terminations and transfers.
The smallest domain in the model — and neither requirement can go on a POA&M. Four assessment objectives total, one for screening and three for personnel actions. Small does not mean optional. (Likely owner: HR with the security lead.) → Full breakdown of the Personnel Security domain
Physical Protection (PE)
6 requirements · 16 objectives · 14 points · 1 deferrable · Level 1: 2 · Level 3: 0
Physical access to systems, equipment, and operating environments, including visitors and alternate work sites.
Three of its four one-point requirements are named exclusions in § 170.21(a)(2)(iii), leaving exactly one deferrable requirement in the domain. Also the source of the Level 1 mapping artifact described earlier. (Likely owner: facilities.) → Full breakdown of the Physical Protection domain
Risk Assessment (RA)
3 requirements · 9 objectives · 9 points · 1 deferrable · Level 1: 0 · Level 3: 7
Assessing risk, scanning for vulnerabilities, remediating according to risk.
The biggest jump in the model. Three requirements at Level 2 becomes seven additions at Level 3 — threat-informed risk assessment, threat hunting, advanced risk identification, security solution rationale and effectiveness, and two supply chain risk requirements. Nearly a third of all Level 3 additions land here. (Likely owner: risk or security lead.)
Security Assessment (CA)
4 requirements · 14 objectives · 13 points · 0 deferrable · Level 1: 0 · Level 3: 1
Assessing your own controls, operational plans of action, continuous monitoring, and the System Security Plan.
Zero deferrable requirements, and it contains the SSP gate — the requirement that carries no points but stops an assessment entirely if it's missing or out of date. Security Assessment consumes output from all thirteen other domains, which is why it can't realistically be finished first even though it's often started first. (Likely owner: GRC or security leadership.)
System and Communications Protection (SC)
16 requirements · 41 objectives · 42 points · 9 deferrable (+1 conditional) · Level 1: 2 · Level 3: 1
Boundary protection, segmentation, encryption in transit and at rest, key management, mobile code, VoIP.
Second-largest domain, second-heaviest in points. Contains SC.L2-3.13.11, the other partial-credit requirement: encrypt without FIPS-validated cryptography and you lose three points instead of five. That one requirement is also the only conditional POA&M candidate in the entire model. (Likely owner: network and security architecture.)
System and Information Integrity (SI)
7 requirements · 20 objectives · 31 points · 0 deferrable · Level 1: 4 · Level 3: 3
Flaw remediation, malicious code protection, security alerts, monitoring for attacks, detecting unauthorized use.
The heaviest domain in the model per requirement — 4.43 points each — with zero deferrable requirements. Five of its seven are 5-pointers and the other two are 3-pointers. There is no soft landing anywhere in this domain, and it's the one most often assumed to be "handled" because the company already runs endpoint protection. (Likely owner: IT operations and security.)
Do I need a separate policy for each CMMC domain or requirement?
No source requires one policy per domain or one policy per requirement. NIST SP 800-171 does not prescribe a format or level of detail for the System Security Plan, and 32 CFR Part 170 does not mandate a document structure. What matters is that your documentation accurately describes how each applicable requirement is implemented, and that it connects to procedures and evidence an assessor can examine.
We are answering this because it is one of the most common and most expensive misreads in the whole program. Contractors routinely produce 110 policy documents, or 14, because a template told them to.
You don't need either. You need coverage.
Some companies organize policy by domain because it maps cleanly to assessment structure. Some organize by business process, because that's how the work actually happens — an onboarding procedure naturally covers Personnel Security, Identification and Authentication, Access Control, and Awareness and Training at once. Some organize by system.
Any of those can work. What doesn't work is a binder full of documents that describe an environment you don't have.
One rule worth internalizing from the scoring methodology, § 170.24(b)(1): evidence must be "in final form and not draft." The rule specifically names working papers, drafts, and unofficial or unapproved policies as unacceptable. A policy your leadership never approved is not evidence. It's a document.
What order should you work through the 14 CMMC domains?
Neither 32 CFR Part 170 nor NIST SP 800-171 prescribes an implementation order. The numbering follows NIST's family order, not a project plan. The sequence below is The Defense Compliance Report's editorial guidance, built on two things we can verify: which domains depend on outputs from other domains, and which domains contain requirements that cannot be deferred.
Most sequencing advice you'll find is dependency-based — do scope first, then identity, then data. That's correct as far as it goes. But it ignores the scoring reality: some domains have no POA&M path at all, which means being late on them isn't an option even if the dependency logic says they can wait.
So we've overlaid both. Dependency sets the order. Deferrability sets the urgency inside each phase.
Phase 1 — Establish the boundary and the source of truth
Security Assessment (0 deferrable) · Risk Assessment (1 deferrable) · Configuration Management (3 deferrable)
Start the System Security Plan, define the boundary, and build the asset and software inventory. Almost every other domain becomes guesswork without knowing what's inside scope.
Urgency note: Security Assessment has zero deferrable requirements and holds the SSP gate. Configuration Management is the densest 5-point domain in the model.
Phase 2 — Control people and access
Personnel Security (0 deferrable) · Identification and Authentication (7 deferrable) · Access Control (11 deferrable) · Physical Protection (1 deferrable)
Connect employment status to digital and physical access. Establish authoritative identities. Close unmanaged pathways.
Urgency note: Personnel Security has zero deferrable requirements and only four assessment objectives — this is the cheapest zero-margin domain to finish, and it usually takes a week. Physical Protection has exactly one deferrable requirement.
Phase 3 — Protect the data and the boundary
System and Communications Protection (9 deferrable) · Media Protection (4 deferrable)
Map how CUI flows. Secure boundaries, transfer channels, storage, removable media, and backups.
Urgency note: this is the phase where FIPS-validated cryptography usually surfaces as a real project. SC.L2-3.13.11 gets partial credit — three points instead of five if you encrypt without FIPS validation — which makes it one of the few places a partial win is worth taking.
Phase 4 — Build visibility and integrity
Audit and Accountability (6 deferrable) · System and Information Integrity (0 deferrable)
Generate usable logs. Detect attacks and unauthorized use. Build patch and vulnerability evidence.
Urgency note: System and Information Integrity has zero deferrable requirements and the heaviest point density in the model. If you defer one phase, do not defer this one.
Phase 5 — Operationalize
Incident Response (1 deferrable) · Maintenance (2 deferrable) · Awareness and Training (1 deferrable)
Exercise the response plan. Control recurring maintenance and vendor access. Train the people who operate the system.
Urgency note: these are last by dependency, not by importance. Two of Awareness and Training's three requirements are 5-pointers, and Maintenance can't defer 16 of its 18 points.
The phases overlap in practice. Training can't realistically wait until month nine. Boundary protection often has to be in place before the SSP is finished. Treat this as a sequence of dependencies, not a Gantt chart.
🔻 Assign the work before it disappears between departments
The most common failure mode we see isn't technical. It's that four domains sat unassigned for five months because everyone assumed IT had them, and IT doesn't run HR records or visitor logs.
Assign owners in the 14-Domain Planner →
One accountable owner and one backup per domain, status per domain, exportable for a leadership review. Nothing leaves your browser. Do not enter CUI or contract details — use internal reference labels only.
What evidence should you collect for each CMMC domain?
CMMC Level 2 assessments evaluate individual assessment objectives using three methods: examine, interview, and test. Evidence therefore has to show both how a requirement is designed and how it actually operates. A policy document alone does not satisfy a requirement, and no single artifact proves an entire domain.
The starter table in the Responsibility and Evidence Map above is where to begin a folder. Here is what actually makes evidence hold up.
Three tests, not one. A written procedure survives "examine." It does not survive "test." If your access control procedure says accounts are disabled within 24 hours of termination, an assessor can pull a termination date and an account disable timestamp and compare them. Design without operation is a finding.
Final form, not draft. § 170.24(b)(1) is explicit that working papers, drafts, and unapproved policies are unacceptable evidence. This catches more companies than any technical control does — the policies exist, they were never formally approved, and the whole binder is inadmissible.
Retention. Assessment artifacts must be retained for six years from the CMMC Status Date. Build the folder structure with that in mind rather than reconstructing it later.
Two instruments, different jobs. A POA&M is what you file at assessment for something that isn't done. An operational plan of action is what § 170.24(b)(1)(ii) describes for a temporary deficiency you're actively correcting between assessments — and a requirement handled that way is assessed as MET, not NOT MET. Those are different instruments with different consequences, and confusing them costs points.
If you organize evidence by domain, you'll match the structure your assessor, your SSP, and your findings report all use. That's the practical argument for the domain view: it isn't just a taxonomy, it's the shared filing system for the entire program.
Did the July 2026 suspension change the 14 CMMC domains?
What's unchanged: the domains, the requirement counts, the point values, the POA&M rules, self-assessment obligations, SPRS posting, annual affirmations, and DFARS 252.204-7012 (the contract clause requiring safeguarding of covered defense information and incident reporting).
What's paused: the requirement that a C3PAO conduct a certification assessment as a condition of award under the previously scheduled milestone. Existing C3PAO and DIBCAC — Defense Contract Management Agency's Defense Industrial Base Cybersecurity Assessment Center, the government team that assesses contractors and C3PAOs — requirements are being removed from active solicitations, and from awarded contracts at the next option exercise or scheduled administrative modification. Until your contract is modified, the clause on it is still the clause on it. Confirm the status of your specific awards in writing rather than assuming a requirement has been read out.
A CMMC Reform Task Force has 60 days to deliver recommendations to the DoW CIO, placing its report around mid-September 2026. A public Request for Information closed August 14, 2026.
The July 2026 pause removed Level 2 C3PAO and Level 3 DIBCAC designations from new procurement requirements during the review; it did not erase existing contract language or bar every government-led assessment.
Knowingly false cybersecurity representations can create False Claims Act risk. The risk depends on the facts, materiality, the contractor's knowledge, and the claim for payment; entering an SPRS score is not automatic liability.
Which means the domain structure is now the only map you have. And three of these domains have no margin for error at all.
What we actually verified for this page
We think you should be able to check us. Here's exactly what we read, when, and what we calculated ourselves.
What we verified against primary sources — August 21, 2026
| What Where | |
|---|---|
| The definition of a CMMC domain | 32 CFR § 170.14(b), read at eCFR |
| All 14 domain names and abbreviations | DoD CIO, CMMC Model Overview v2.13 (DoD-CIO-00001), § 2.3 |
| Every requirement identifier at all three levels | CMMC Model Overview v2.13, § 2.4 and Appendix A, counted requirement by requirement |
| Level 1 = 15 requirements from FAR 52.204-21(b)(1)(i)–(xv) | 32 CFR § 170.14(c)(2) |
| Level 2 = identical to NIST SP 800-171 Revision 2 | 32 CFR § 170.14(c)(3) |
| Level 3 = 24 selected NIST SP 800-172 requirements | 32 CFR § 170.14(c)(4) |
| Every 5-point and 3-point requirement, by ID | 32 CFR § 170.24(c)(2)(i)(B)(1)–(2), read in full |
| The two partial-credit requirements | 32 CFR § 170.24(c)(2)(i)(B)(4) |
| Evidence must be in final form, not draft | 32 CFR § 170.24(b)(1) |
| Level 3 flat scoring and the maximum-Level-2-score prerequisite | 32 CFR § 170.24(c)(3) |
| POA&M eligibility and the six named exclusions | 32 CFR § 170.21(a)(2) |
| Phase II suspension and Phase I continuation | Department of War memoranda, July 13, 2026 |
What we calculated ourselves
- Requirement counts per domain at each level (reconciling to 15, 110, and 24)
- SPRS point weight per domain (reconciling to 313 total, which produces the published −203 floor)
- POA&M-eligible counts per domain (46, plus 1 conditional)
- Points per requirement, and the objectives-to-points comparison
- Assessment objective counts per domain (320 total), published on our 110-requirement checklist
What is editorial judgment, not regulation
- Likely accountable owner per domain
- First evidence to inventory
- Dependencies to resolve first
- The five-phase implementation sequence
- Which internal resource you should use next
What we could not verify
The CMMC Reform Task Force report had not published as of August 21, 2026. Neither had the interim final rule under RIN 0790-AM01. We've described both as expected or pending, not as settled.
Corrections: If something here is wrong, tell us and we'll fix it. Include the domain or requirement ID, the primary source, and the proposed correction. → Corrections policy · Methodology · Editorial standards
CMMC 14 domains list: frequently asked questions
How many domains are in CMMC?
Fourteen. They correspond to the 14 security requirement families in NIST SP 800-171 Revision 2, per 32 CFR § 170.14(b).
Does CMMC have 14 or 17 domains?
Fourteen. A 17 figure comes from the retired CMMC 1.0 model, from NIST SP 800-171 Revision 3 (which has 17 families but is not the current CMMC Level 2 baseline), or from a Level 1 mapping table where one FAR requirement maps to three NIST requirements across three rows.
How many CMMC Level 2 controls are there?
110 security requirements. "Controls" is industry shorthand; 32 CFR Part 170 and NIST both use "security requirements."
Which CMMC domain has the most requirements?
Access Control, with 22 requirements, 70 assessment objectives, and 54 maximum-deduction points. It's also the most deferrable domain — 11 of its 22 requirements qualify for a POA&M.
Which CMMC domain carries the most scoring weight per requirement?
System and Information Integrity, at 4.43 points per requirement across seven requirements and 31 points. The model average is 2.85.
Does CMMC Level 1 use all 14 domains?
No. Level 1's 15 requirements sit in six domains: Access Control, Identification and Authentication, Media Protection, Physical Protection, System and Communications Protection, and System and Information Integrity. The other eight have no Level 1 requirements.
Does CMMC Level 3 add requirements to all 14 domains?
No. Level 3 adds 24 requirements across ten domains. Audit and Accountability, Maintenance, Media Protection, and Physical Protection receive no Level 3 additions.
Can I put an entire CMMC domain on a POA&M?
No. POA&M eligibility is evaluated at the individual requirement level. Under § 170.21(a)(2)(ii), any requirement worth more than one point is ineligible, and three domains — Personnel Security, Security Assessment, and System and Information Integrity — contain no eligible requirements at all.
How many assessment objectives are behind the 110 requirements?
320, based on our count from NIST SP 800-171A and the official CMMC Level 2 Assessment Guide. Access Control alone accounts for 70.
Do I need a separate policy for every CMMC domain?
No. Neither the rule nor NIST prescribes a document structure or count. Your documentation needs to accurately describe how each applicable requirement is implemented and connect to procedures and evidence.
Does CMMC use NIST SP 800-171 Revision 2 or Revision 3?
Revision 2. 32 CFR § 170.14(c)(3) incorporates Revision 2 by reference. NIST withdrew Revision 2 in May 2024, but withdrawing a NIST publication does not amend a federal regulation.
Must I implement the domains in the order they're listed?
No. The order follows NIST's family numbering, not a required project plan. Any sequence you see, including ours, is guidance.
Did the July 2026 CMMC suspension remove the 14-domain requirement?
Where can I download the CMMC 14 domains list?
Our count matrix is available as a CSV and a printable one-page reference from the 14-Domain Planner. The authoritative source document is the DoD CIO CMMC Model Overview, published free at dodcio.defense.gov.
The bottom line
Fourteen domains. 110 requirements at Level 2. Six domains at Level 1, ten at Level 3. 313 points of scoring weight distributed anything but evenly, and three domains where you get no second chance.
If you take one thing from this page, take this: the list is not the work. The list is fourteen names. The work is knowing which of those fourteen apply to you, which ones carry weight you can't defer, and who in your building is actually going to own each one.
That's the gap this page exists to close.
Need help deciding what type of CMMC provider you need? Tell us your level, scope, and timeline, and we'll match you with source-checked CMMC provider options.
Get matched with provider categories that fit your situation →
Do not submit CUI, drawings, credentials, network details, or sensitive contract information.
Disclosure and limitations
Disclosure: The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We may receive compensation for qualified introductions, sponsorships, or partner referrals when disclosed. Compensation does not control our regulatory analysis, provider-category recommendations, or Cyber AB status verification.
No affiliation: The Defense Compliance Report is not affiliated with the Cyber AB, the Department of War, the Department of Defense, DCMA DIBCAC, NIST, or any U.S. government agency.
Not advice: This is educational research, not legal, contractual, or compliance advice. Confirm scope and applicability with a CMMC Registered Practitioner or Registered Practitioner Organization and, where contract interpretation is involved, a qualified federal-contracts attorney. Your written contract requirement and your actual FCI and CUI handling govern — not a general checklist.
No named providers appear on this page. That is deliberate. This is a reference page for readers who are still orienting, and a provider recommendation here would be premature regardless of who was paying us.
Last verified: August 21, 2026 · By The Defense Compliance Report Editorial Team
Still unsure what kind of help belongs next? Find My CMMC Path takes about two minutes and routes the decision by level, scope, current evidence, and the kind of provider you actually need. It does not does not guarantee certification or award or replace the contract.
CMMC Level 2 Self Assessment vs. a DFARS Basic Assessment: Which SPRS Record Do You Need?
They are not interchangeable. A CMMC Level 2 Self Assessment and a NIST SP 800-171 DoD Basic Assessment can begin with the same 110-requirement scoring methodology, but they exist under different authorities, carry different record fields, and satisfy different contractual checks.
| Question | CMMC Level 2 Self Assessment | NIST SP 800-171 DoD Basic Assessment |
|---|---|---|
| Governing authority | 32 CFR Part 170 and, when included in the contract, DFARS 252.204-7021 | DFARS 252.204-7019 and 252.204-7020 using the DoD Assessment Methodology |
| What it establishes | A current CMMC Level 2 Self status for the defined CMMC assessment scope | A current Basic Assessment score for the covered contractor information system |
| Core scoring basis | Start at 110 and apply the one-, three-, and five-point deductions incorporated by 32 CFR § 170.24 | Start at 110 and apply the DoD Assessment Methodology |
| SPRS record | CMMC status, scope, associated CAGE code or codes, score, POA&M status where applicable, CMMC UID, affirmation, and other required status data | Summary-level Basic Assessment information required by DFARS 252.204-7019 and 252.204-7020 |
| Affirmation | Required under the CMMC rule; the affirming official takes responsibility for continuing compliance | The clauses require a current assessment record; do not treat that record as the CMMC affirmation |
| Can one be assumed to replace the other? | No | No |
The practical rule is simple: read the solicitation and contract, then confirm which record the contracting officer is checking. A contractor can have a current Basic Assessment in SPRS and still lack the CMMC status required by DFARS 252.204-7021. The reverse assumption is dangerous too. The two records may draw from the same environment and evidence, but the legal purpose and required data are different.
Use the SPRS score guide when the record itself is the problem. Use the CMMC Levels guide when you are still determining which CMMC status the contract requires.
Which NIST Revision Controls CMMC Right Now?
NIST SP 800-171 Revision 2 remains the controlling Level 2 requirement set under the current CMMC rule. NIST withdrew Revision 2 after publishing Revision 3, but a NIST publication action does not amend 32 CFR Part 170. The rule still identifies the Revision 2 requirement set and the June 2018 SP 800-171A assessment procedures for Level 2 unless DoD changes the governing rule or otherwise lawfully changes the contractual baseline.
That does not make Revision 3 irrelevant. Revision 3 reorganizes the baseline into seventeen families, changes requirement language and numbering, introduces organization-defined parameters, and is paired with different assessment procedures. Contractors can monitor and map to Revision 3, but they should not silently substitute it for the Revision 2 CMMC baseline in an assessment package.
The same incorporation point matters at Level 3. NIST withdrew the February 2021 edition of SP 800-172 on May 13, 2026, but 32 CFR § 170.14(c)(4) still identifies the selected requirements from that edition. A later NIST publication does not automatically rewrite the rule’s incorporated Level 3 set.
Decision rule: build and assess the current CMMC package against the version named by the governing rule and contract. Maintain a separate Revision 3 crosswalk so a future transition becomes a controlled gap analysis—not a last-minute rebuild disguised as “three more folders.”
See the Revision 2 vs. Revision 3 comparison for the migration question. The list on this page remains a Revision 2 CMMC domain list.
What Changed During the 2026 CMMC Phase Pause?
The fourteen-domain model did not change. Phase I began November 10, 2025. Its original one-year window ran through November 9, 2026, but DoD paused the transition to Phase II before the planned November 10, 2026 start while it reviewed implementation.
Under the July 13, 2026 direction, new procurement designations during the pause may use Level 1 Self or Level 2 Self rather than newly designating Level 2 C3PAO or Level 3 DIBCAC requirements. DoD also reserved the ability to conduct select government-led assessments. The pause changed the rollout mechanics; it did not repeal 32 CFR Part 170, replace the Revision 2 domain set, cancel DFARS 252.204-7012 obligations, or automatically rewrite an existing solicitation or contract.
Your controlling document is still the written procurement instrument. A policy memorandum can direct contracting activity, but the requirement a contractor must satisfy is the one in the solicitation, award, task order, or modification. Ask the contracting officer to resolve any conflict between current implementation direction and the document in front of you.
Read the current CMMC implementation update before relying on an old phase chart. Then return to this list to build the environment that the applicable assessment will actually test.
What Evidence Must Be Retained?
Keep the evidence that supports the assessment result for at least the period required by the rule, and do not treat a folder of screenshots as the whole evidence strategy. For a Level 2 self-assessment, 32 CFR § 170.16(c)(4) governs retention of the evidence used for the assessment. For a Level 2 certification assessment, § 170.17(c)(4) separately governs assessment evidence and includes artifact-integrity requirements such as hashing and associated identifying information.
The operational implication is bigger than “keep files for six years.” Evidence needs provenance: what system produced it, which requirement and objective it supports, who collected it, when it was collected, and whether it still represents the assessed environment. A screenshot without scope, date, source, or owner is a picture—not durable assessment evidence.
The owner-and-evidence matrix above is editorial guidance, not a regulatory assignment chart. Use it to establish the first accountable owner, then map each artifact to the applicable requirement and assessment objective in your evidence index.
How Do Cyber AB Independence Rules Affect Who You Hire?
Do not assume the person who helped implement the environment can later assess that same work. The Cyber AB’s public role guidance states that an individual who holds both implementation and assessor designations may not participate as an assessor for an organization that individual previously helped prepare.
That public rule is narrower than a claim that every consulting firm is barred for three years. A contractor can still choose a stricter separation policy—and DCR does for commercial routing—but editorial policy must not be presented as Cyber AB law. Before signing, ask the C3PAO to identify the proposed assessment team and confirm the current conflict review in writing.
Use Who to Hire First when sequencing the work. Use CMMC Provider Categories when you need to separate an RPO, Registered Practitioner, MSP/MSSP, C3PAO, and other provider roles. Verify claimed ecosystem status independently through the Cyber AB Marketplace.
Primary Sources and Verification
Regulatory and technical claims on this page were checked against these primary sources on August 21, 2026:
- 32 CFR Part 170 — Cybersecurity Maturity Model Certification Program
- CMMC Program Final Rule, 89 Fed. Reg. 83092
- DFARS 252.204-7012, 252.204-7019, 252.204-7020, and 252.204-7021
- NIST SP 800-171 Revision 2, NIST SP 800-171A, June 2018, and NIST SP 800-172, February 2021
- DoD CMMC documentation and implementation materials
- The Cyber AB and its public ecosystem-role and Marketplace materials
- Supplier Performance Risk System
The requirement counts are taken from the rule-incorporated source sets. The 320 Level 2 assessment-objective total and the domain-by-domain owner, starter-evidence, dependency, scoring-exposure, and POA&M columns are DCR calculations and editorial synthesis from those primary sources. They are not separate requirements created by DoD, NIST, or the Cyber AB. See our Methodology, Editorial Standards, and Corrections Policy.
Editorial and Commercial Disclosure
The Defense Compliance Report is an independent educational publisher. We are not affiliated with, endorsed by, or acting on behalf of the Department of Defense, the Cyber AB, NIST, DIBCAC, SPRS, or any contracting agency. This page is educational research, not legal advice, contractual advice, an official compliance determination, or a guarantee of certification or award eligibility.
DCR may receive compensation from clearly disclosed sponsorships, advertising, or provider referrals. Commercial relationships do not change the regulatory source set, scoring calculations, editorial conclusions, or the order in which providers are explained. No provider is recommended merely because it pays DCR. Verify provider status independently, read the engagement terms, and make the final decision based on your contract, scope, conflicts, evidence, and risk.