Most of the companies I meet believe they're roughly 80% of the way to CMMC. Almost none of them are wrong about the 80%. They're wrong about which 80%.

On paper the confidence makes sense. The policies are written. MFA is on. Endpoint protection is deployed. Everyone did their annual awareness training. There's a System Security Plan, a NIST SP 800-171 self-assessment, and a score sitting in SPRS. That's real work and I don't dismiss it.

But having security controls and being able to demonstrate that those controls are implemented correctly, consistently, and inside the right scope are two very different things. That gap is where CMMC readiness quietly falls apart — and it doesn't announce itself until someone outside your company starts asking questions.

Program status

Where the program actually stands right now

I need to address this first, because it's changed the conversation in every room I've been in since July.

On 13 July 2026 the Department of War suspended Phase 2 of CMMC — the milestone that would have made third-party C3PAO certification a condition of award for most Level 2 contractors starting 10 November 2026. Phases 3 and 4 went into the same pause. A CMMC Reform Task Force was stood up with 60 days to bring back recommendations, and the public RFI window closed on 14 August.

Here's the part people skip: this happened through two memoranda, not a rule. 32 CFR Part 170 is unamended. DFARS 252.204-7021 is still on the books. Nothing about your existing contractual cybersecurity obligations went away.

In force

• 16 Dec 2024

  Program rule effective

• 10 Nov 2025

  Phase 1 begins

• 13 Jul 2026

  Phase 2 suspended

Under review

• 14 Aug 2026

  RFI closes

• ~Sep 2026

  Task force reports

• Next

  Rulemaking TBD

So what do I tell clients? Keep going. If anything, this is the cheapest preparation window you'll ever get: you can fix scoping and evidence problems now without an assessor's calendar dictating your pace. And a completed certification hasn't lost value — under 252.204-7021 a higher status satisfies a lesser designation, and primes have their own memories about who was ready.

The suspension paused the verification mechanism. It did not pause the obligation, and it certainly didn't pause the adversary.

Operations

The difference between having a control and operating a control

Access control is the clearest example.

An organization has a policy saying access is granted according to job responsibilities. Active Directory groups exist. MFA is deployed. Accounts get disabled when people leave. All genuinely good practices. Then I start asking how it actually works:

• Who approves access to systems holding Controlled Unclassified Information?
• Who reviews privileged accounts, and how often?
• What happens when someone transfers between departments rather than leaving?
• Who verifies that terminated users lost access to the cloud apps IT doesn't manage?
• Where are those reviews documented, and how would you show they've been done consistently?

That's the moment a control moves from policy into operations. "We review user access regularly" is a statement. Showing me the procedure, naming the owner, producing the completed reviews, walking me through a corrective action and explaining how exceptions were handled — that's an operating control.

Scoping

Scoping is still one of the biggest readiness problems

Before anyone spends a month collecting screenshots or rewriting policies, the organization has to know where CUI actually lives. That sounds obvious until you start tracing the data.

CUI arrives through email, a customer portal, secure file transfer, engineering documentation, drawings, technical specifications, contract paperwork, collaboration platforms. From there it moves to workstations, file servers, cloud tenants, backup systems, shop-floor systems, and third parties. You need the whole lifecycle.

Entry

• Contract & email
• Customer portal
• Secure file transfer
• Drawings & specs

↓

In scope — where it lives and moves

Process

workstations · apps · ERP

Store

file servers · M365 · backups

Transmit

VPN · email · partner links

Assessment boundary

↓

End of life

• Archive or destroy

Paths that rarely make the diagram

• Engineer's local copy
• Unmanaged SaaS
• Supplier inbox
• Legacy backup tape

I'd caution against assuming your Microsoft 365 tenant, your firewall, or your enclave automatically defines the boundary. Technology helps establish boundaries. The actual flow of CUI has to support the conclusion. I've watched a single sentence from a design engineer — "well, I usually download the drawing to review it offline" — undo a network diagram that took two weeks to draft. Those discoveries are the point. Better now than in an assessment. This is the piece we work through first in a readiness engagement.

Third parties

Third-party providers don't transfer responsibility away from you

Almost everyone relies on managed service providers, MSSPs, cloud platforms, external SOC teams, backup vendors, specialized security tooling. There's nothing wrong with that model. It often improves security materially.

The problem starts when an organization assumes that because a provider manages the technology, the provider also owns the CMMC responsibility attached to it. Take logging. Your MSSP may run the SIEM and watch alerts. You still need to know what sends logs, what events are collected, how long they're retained, what happens when an alert fires, who investigates, how it escalates, and what evidence shows the process worked. Same story for identity, EDR, backups, vulnerability scanning, firewalls and cloud security.

Document responsibility at the control level — a proper customer responsibility matrix, requirement by requirement: what you perform, what the provider performs, what's shared. If nobody can explain that relationship in plain language, there's a readiness gap hiding behind it. Every time.

Evidence

Evidence needs to show more than a screenshot

A screenshot can be useful. A screenshot by itself rarely demonstrates that a requirement operates effectively. Showing MFA is enabled is a start — but an assessor may need to understand where it applies, which users are covered, how privileged accounts are handled, which authentication methods are permitted, and whether anything sits outside that implementation.

• Policywhat should happen
• Procedurehow it happens, and who does it
• Configurationthat it is technically implemented
• Operational recordsthat people actually followed it
• Interviewsthat the owner understands it

↑ A screenshot covers the configuration layer only

Documentation

Your SSP should describe the environment you actually have

The System Security Plan deserves more attention than it usually gets. I've seen SSPs treated as templates to be filled in, which misses the purpose entirely. An SSP should let a stranger understand your boundary, environment, architecture, requirements, responsible parties, and how protections are implemented.

When the SSP says one thing and the environment does another, the document stops being evidence and becomes a liability. This happens because environments change faster than documentation does:

• A new cloud service gets introduced mid-quarter.
• An MSP picks up a security function.
• A server migrates. Remote access changes.
• A new CUI workflow appears. An application is retired.
• Privileged access gets redesigned.
• The SSP stays exactly as it was.

By the time an assessment starts, the documentation describes an environment that no longer exists. So readiness has to include configuration and documentation management — not just initial document creation. Put SSP review on the change management checklist and you've solved most of it.

Remediation

POA&Ms should not become a parking lot for security problems

A Plan of Action and Milestones is a good tool for tracking legitimate deficiencies. It is not a place to move every hard requirement indefinitely. CMMC restricts which requirements are POA&M-eligible, and conditional status carries a limited remediation window — worth understanding before you assume you can walk in with a long list of open items.

More useful than the list itself is the pattern. If the same findings sit open quarter after quarter, the problem usually isn't technical. It's ownership, resourcing, prioritization or governance. I'd rather spend twenty minutes on why a finding is still open than two hours reading the spreadsheet. The answer tells me more about readiness than the document does.

People

CMMC is not a one-time technical project

Treating this as an IT project with an end date is one of the more expensive mistakes I see. IT is critical, obviously. But a large share of requirements depend on people and processes outside it. HR owns onboarding and termination. Facilities owns physical access. Contracts identifies CUI requirements. Procurement manages external providers. Engineering decides where technical data lives. Executives approve risk. Security handles monitoring and incidents. Administrators implement configurations.

When those groups don't know their responsibilities, IT ends up trying to own controls it cannot operate. That's where readiness gets fragile — not in the tooling, in the org chart. The same governance question shows up in AI governance work, for what it's worth: the technology is rarely the hard part.

Standards

NIST SP 800-171 is evolving — prepare against the right version

NIST published Revision 3 in May 2024, moving closer to SP 800-53 Rev 5 and introducing organization-defined parameters and a restructured requirement set. It's a meaningful change in how requirements are expressed.

But you need to separate the latest NIST publication from what's currently incorporated into the CMMC program. As of today, CMMC still leverages Revision 2 and its associated assessment procedures — and during the Phase 2 suspension the Department has been explicit that it's enforcing baseline compliance with Rev 2 through self-assessment and selected government-led assessments.

Prepare against the requirements in your current contracts. Build a program that can adapt rather than a checklist that has to be rewritten every time the standard moves. Organizations that did the former will handle whatever the Reform Task Force recommends; organizations that did the latter will start over.

Self-assessment

What I look for: the 12-question readiness reality check

When I evaluate CMMC readiness, I'm not especially interested in a folder holding 100 policies. I want to know whether the organization understands its own environment. Answer these honestly — the ones you hesitate on are your roadmap.

Those twelve questions expose readiness problems very quickly. They're also, not coincidentally, the questions an assessor gets to eventually. Better that you ask them first — and if you'd rather not ask them alone, get in touch.

FAQ

Questions I get asked every week

Is CMMC cancelled?

No. Phase 2 was suspended on 13 July 2026 through two memoranda — a CIO policy memo and an implementation memo — not a rule change. 32 CFR Part 170 is unamended and DFARS 252.204-7021 stands. Phase 1 self-assessments, DFARS 252.204-7012, SPRS scores and annual affirmations all continue.

Should we pause our Level 2 preparation?

I wouldn't. The security obligation didn't move, government-led assessments continue, and False Claims Act exposure for inaccurate representations is unchanged. Use the window to fix scope and evidence instead of buying an assessment date.

Do we prepare against Rev 2 or Rev 3?

Rev 2, because that's what's incorporated into the program and what you'll be scored against. Read Rev 3 to understand direction, and avoid designing controls so narrowly that they'd need rebuilding under a restructured standard.

Our MSP handles security. Aren't we covered?

Partly at best. The provider can operate the technology; you still hold the requirement. Get a control-level responsibility matrix and confirm you can explain, without calling them, what they do and what you do.

How much evidence is enough?

Enough that policy, procedure, configuration, records and the people involved describe the same control. If a reasonable outsider can follow that chain without you narrating it, you're close.

Does an existing C3PAO certification still mean anything?

Yes. Certificates issued before the suspension remain valid, a higher status satisfies a lesser designation under 252.204-7021, and it continues to matter to primes and in diligence.

This brief reflects program status as of 19 August 2026. The Reform Task Force recommendations were expected around mid-September 2026; check the current DFARS clause text in your contracts before making decisions, and confirm the status of specific awards in writing rather than assuming a requirement has been read out.