CMMC Level 2 is not a binder you finish the week before an assessment. It is an operating discipline for protecting Controlled Unclassified Information, or CUI, across the systems, people, and suppliers that touch it. The organizations that move fastest are not the ones with the longest policy library. They are the ones that can define their boundary, explain who owns each control, and produce trustworthy evidence from normal operations.
As of September 2026, the Department of Defense identifies Level 2 with 110 security requirements from NIST SP 800-171 Revision 2. The DoD's current CMMC guidance also says Phase II requirements originally scheduled for November 10, 2026 have been suspended while the program is reviewed; Phase I self-assessment requirements and the obligation to safeguard CUI under DFARS 252.204-7012 remain in place. That makes preparation more important, not less. A pause in a milestone is not permission to pause security work.
Start with the CUI boundary, not the checklist
The first readiness question is simple: where does CUI enter, move, live, and leave your environment? Answer it with a data-flow map before scoring controls. Include the users who handle CUI, endpoints and servers, Microsoft 365 or other cloud tenants, file shares, remote-access tools, backups, printers, mobile devices, and vendors or subcontractors that receive the information.
DoD's Level 2 Assessment Guide allows an assessment scope to cover an entire enterprise network or a defined enclave. That choice changes the size of the evidence problem, the remediation cost, and the number of systems that must stay aligned over time. An enclave can reduce scope when it is real and enforceable; it is not a diagram that excludes a shared identity platform, administrator workstation, backup system, or remote-management path still capable of reaching CUI.
Write down the boundary in plain language. Record which assets are in scope, which are out of scope, why they are excluded, and what technical controls enforce the separation. When the boundary changes, update the asset inventory, network diagram, System Security Plan, and evidence register together.
Translate 110 requirements into owned outcomes
A control list becomes manageable when every requirement has an owner, an implementation statement, a test method, and an evidence location. Avoid assigning ownership to “IT” as a group. Name the role that can make the change, verify the result, and explain an exception to leadership.
- Access and identity: demonstrate least privilege, strong authentication, controlled remote access, and timely account changes. Evidence can include role assignments, MFA coverage, privileged-access reviews, joiner-mover-leaver tickets, and samples of terminated accounts.
- Configuration and vulnerability management: maintain approved baselines, track changes, scan for weaknesses, prioritize remediation, and verify that fixes reached the affected systems. A ticket closed as “patched” is weaker than a version check or authenticated scan that confirms the vulnerable component is gone.
- Audit and accountability: define the events that matter, protect the logs, review them on a schedule, and record what happened when a review found an issue. Keep the review output, not only the logging configuration.
- Incident response: document roles, reporting paths, escalation thresholds, and testing. A tabletop attendance record, decisions made during the exercise, and follow-up actions show that the plan is operational.
- Media, physical, and personnel protection: connect device disposal, removable-media handling, facility access, visitor records, screening, and personnel changes to the CUI boundary. These controls are easy to overlook when the program is treated as an endpoint project.
- Security assessment and planning: keep the SSP current, maintain a time-bound POA&M when permitted, and monitor the controls after the initial review. A document that describes last year's environment is not evidence of today's implementation.
Use a one-page control register to make the work visible. Recommended fields are requirement ID, plain-language outcome, owner, in-scope assets, implementation status, evidence link, last test date, open risk, and next review date.
Build evidence as a by-product of operations
Assessors and customers do not need a pile of screenshots; they need evidence that is final, attributable, current, and tied to the requirement. Design the evidence workflow at the same time as the control. When a change is approved, capture the change record and the validation result. When access is reviewed, capture the population reviewed, the reviewer, the decisions, and the remediation tickets.
Use four tests for every artifact. First, traceability: can a reviewer connect the artifact to a specific requirement and in-scope system? Second, recency: does the date prove the control is operating now? Third, integrity: is the document approved or exported from a system of record rather than an editable draft? Fourth, repeatability: can the team produce the same kind of evidence next month?
Keep evidence in a controlled repository with version history and defined permissions. Name files consistently, preserve the collection date, and record the person or system that generated each item. Do not hide gaps by collecting a screenshot that shows a desired setting while the authoritative configuration says otherwise. If a requirement is not met, document the gap honestly, assign an owner, and link the corrective action to the POA&M or risk decision.
Sequence remediation over 90 days
A practical readiness sprint starts with the controls that reduce both security risk and assessment rework. In days 1 through 30, confirm the CUI map, inventory assets and identities, identify administrative paths, protect privileged accounts with multifactor authentication, and verify that backups include the systems inside the boundary. Resolve any internet-facing exposure that can be fixed quickly, and write down the exceptions that require a business decision.
In days 31 through 60, make the program repeatable. Establish patch and vulnerability cadences, formalize onboarding and offboarding, document remote access, configure centralized logging for high-value systems, and review vendor or subcontractor access. Draft the SSP from the environment that actually exists, not from a generic template. Each statement should point to an owner and evidence.
In days 61 through 90, test the operating model. Run a sample access review, validate a vulnerability fix, restore a representative backup, inspect log-review records, and conduct an incident-response tabletop. Ask a person who did not write the procedure to follow it. The friction they encounter is a useful readiness finding, not an inconvenience to hide.
Leadership should review the top unresolved risks monthly. The decision log should state what is being funded, what is being accepted temporarily, who owns the action, and when the next proof is due. This keeps a POA&M from becoming a parking lot for indefinite exceptions.
Plan for change without losing the current baseline
NIST published SP 800-171 Revision 3 in May 2024, and it reorganizes the material into 17 families with 97 requirements. That future-facing work matters, but current CMMC Level 2 guidance remains based on Revision 2. Do not replace your live SSP, SPRS work, or assessment evidence with an assumption that a later revision is already the operative contract baseline.
Use two clearly separated tracks. Keep the live compliance program aligned to the baseline named in the contract and current DoD guidance. In a planning file, map likely Revision 2-to-Revision 3 changes, review the new Planning, System and Services Acquisition, and Supply Chain Risk Management families, and note which vendor or architecture decisions could create future work. When DoD publishes an effective transition rule, you will have a mapped project instead of a restart.
The strongest CMMC program is therefore not the one with the most documents. It is the one that can answer three questions without delay: what CUI do we handle, which systems and people are in scope, and what evidence shows our controls operate? PTG helps growing organizations turn those answers into a defensible boundary, a managed remediation plan, and repeatable security operations.
