Cybersecurity Maturity Model Certification (CMMC) 2.0 Level 2 in 2026: Timeline, Requirements, and a 4-Step Plan

For a comprehensive overview, see our CMMC compliance guide.

CMMC 2.0 Level 2 is designed to raise the baseline for protecting Controlled Unclassified Information (CUI) across the Defense Industrial Base—yet many teams still treat it like a paperwork exercise. The result is predictable: late starts, unclear scoping, expensive “tool-first” decisions, and assessments that fail on fundamentals like asset inventory, access control, and evidence quality.

This operating playbook exists to help you plan a realistic 2026 certification path—grounded in requirements, assessment mechanics, and the work that actually takes time (scoping, remediation, and evidence). If you follow the steps below, you’ll have a defensible system boundary, an implementable control plan, and an assessment-ready evidence set.

Prerequisites: What you need before you start

Before you begin the 4-step plan, assemble the minimum inputs and decision-makers. You do not need a perfect program on day one—but you do need clarity on scope, ownership, and data flows.

People and roles

• Executive sponsor (can unblock budget and policy decisions)
• Compliance/security lead (drives the plan; owns System Security Plan (SSP)/Plan of Action and Milestones (POA&M))
• IT operations lead (identity, endpoints, network, logging)
• System/data owner(s) (contracts, programs, engineering, PMO)
• Vendor management/procurement (flow-downs and supplier evidence)

Artifacts and information to gather

• List of DoD contracts and whether they involve CUI
• Current National Institute of Standards and Technology (NIST) SP 800-171 implementation status (even if informal)
• Existing policies/procedures (access control, IR, change mgmt, etc.)
• Network diagrams (even rough), asset lists, identity provider details
• Security tooling inventory (EDR, SIEM, MDM, email security, backup)

Tools you’ll likely need (not necessarily new purchases)

• Centralized identity (SSO/MFA), endpoint management, vulnerability scanning
• Central log retention and review process (SIEM optional, but evidence is not)
• Ticketing/work tracking for remediation and change control

Warning: If you can’t clearly identify where CUI is created, stored, or transmitted, you’re not ready to set a certification timeline. Scoping errors are the #1 cause of rework.

Step 1 — Build your 2026 timeline backward from assessment readiness

What to do (action)

Create a 2026 plan that works backward from the point you want to be assessed. Use a phased schedule with explicit gates:

• Gate A: Scope locked (CUI boundary and enclaves defined)
• Gate B: Control implementation complete (technical + procedural)
• Gate C: Evidence complete (mapped to each requirement)
• Gate D: Mock assessment passed (internal or third-party)
• Gate E: Assessment scheduled and executed

A practical timeline for many mid-sized contractors (adjust to complexity):

• Months 0–1: scoping + CUI data flow mapping
• Months 1–3: gap assessment vs. NIST SP 800-171 (110 requirements)
• Months 2–6: remediation sprint(s) + policy/procedure finalization
• Months 5–7: evidence collection + SSP/POA&M hardening
• Months 7–8: mock assessment + close findings
• Months 8–9: schedule/execute assessment (buffer for assessor availability)

Why it matters (context)

CMMC Level 2 is closely aligned to NIST SP 800-171. Most delays come from:

• Underestimating process maturity (not just tools)
• Late discovery of CUI sprawl (email, SharePoint, endpoints)
• Evidence that exists “in someone’s head” but not in repeatable artifacts

Planning backward forces you to allocate time to the work that cannot be rushed: scoping, remediation, and evidence.

How to verify (success criteria)

• A dated project plan with owners for each requirement family
• A defined assessment window in 2026 with a 60–90 day buffer
• A written definition of “assessment-ready” (Gate C + D criteria)

What to avoid (pitfalls)

• Buying tools before scoping (you may tool the wrong boundary)
• Assuming a “documentation sprint” at the end will fix missing controls
• Scheduling an assessment before you can pass a mock assessment

Command examples (for planning hygiene)

• If you track work in Jira, create epics per NIST 800-171 family:
• Access Control (AC), Audit & Accountability (AU), Incident Response (IR), etc.
• If you track in Git, store policies and SSP in version control:

mkdir -p compliance/{policies,procedures,evidence,ssp,poam}
git init compliance

Step 2 — Define Level 2 scope: CUI boundary, enclaves, and shared services

What to do (action)

Perform a scoping exercise that results in a defensible CMMC Level 2 system boundary.

1) Identify CUI

• Review contracts and markings; confirm CUI categories with program owners
• List systems where CUI is:
• Created (engineering tools, document authoring)
• Stored (file shares, SharePoint/Teams, endpoints, cloud drives)
• Transmitted (email, portals, SFTP, APIs)

2) Map data flows

• Create a simple diagram showing sources, destinations, and trust boundaries
• Include third parties: MSPs, cloud providers, subcontractors

3) Choose a scope strategy

• Enterprise-wide scope (harder, but simpler long-term)
• CUI enclave (narrower boundary; requires strict segmentation and process)

4) Document shared services

• Identity provider, email, endpoint management, logging, ticketing
• Decide whether shared services are in-scope or isolated from CUI

Why it matters (context)

Level 2 certification is only meaningful if the boundary is real. In 2026, assessors will focus heavily on whether:

• CUI is actually contained to the defined environment
• Controls apply to all in-scope assets (including admin workstations)
• External dependencies are managed with enforceable agreements and evidence

How to verify (success criteria)

• A written boundary statement: “CUI is only processed within X systems…”
• An asset inventory tagged in-scope vs out-of-scope
• Data flow diagram reviewed and approved by IT + program leadership

What to avoid (pitfalls)

• Declaring an enclave but allowing CUI in corporate email or unmanaged endpoints
• Forgetting admin paths (domain admins, break-glass accounts, jump boxes)
• Treating SaaS as “out of scope” while storing CUI there

Warning: If CUI can reach an out-of-scope system (even occasionally), assume that system is in scope until you implement and prove containment.

Command examples (asset and access discovery)

• Export device inventory from Microsoft Intune (example via Graph):

# Pseudocode / example flow
# 1) Acquire token, 2) query managedDevices
curl -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices" \
  | jq '.value[] | {deviceName, operatingSystem, userPrincipalName, complianceState}'

Step 3 — Implement Level 2 requirements (NIST SP 800-171) with evidence in mind

What to do (action)

Build your implementation plan around the 110 NIST SP 800-171 requirements, organized by control families. Focus first on the families that most commonly fail assessments due to missing proof.

High-impact implementation checklist (practical priorities)

• Access Control (AC)
• Enforce MFA for all in-scope access (users and admins)
• Least privilege and role-based access; remove shared accounts
• Session lock, remote access controls, and network segmentation
• Audit & Accountability (AU)
• Centralize logs for critical systems (identity, endpoints, servers)
• Define log review frequency and document findings
• Configuration Management (CM)
• Standard secure baselines; change control with tickets
• Restrict admin tools; manage exceptions explicitly
• Identification & Authentication (IA)
• Strong password policy + MFA + privileged access controls
• Manage service accounts; rotate credentials
• Incident Response (IR)
• Document IR plan; run tabletop exercises; keep records
• Risk Assessment (RA) & Security Assessment (CA)
• Scheduled vulnerability scanning; track remediation
• Maintain SSP and POA&M with ownership and due dates
• System & Communications Protection (SC)
• Encrypt CUI in transit and at rest where applicable
• Boundary protections, secure remote admin, and secure protocols
• System & Information Integrity (SI)
• Patch SLAs, malware protection, alert handling, and reporting

Evidence-first approach (do this as you implement) For each requirement, collect:

• A policy/procedure reference (what you say you do)
• A technical artifact (what the system shows)
• An operational record (what you actually did over time)

Examples:

• MFA requirement evidence:
• Policy: Access Control Policy
• Artifact: IdP conditional access screenshot/export
• Record: monthly access review report or sign-off

Why it matters (context)

CMMC Level 2 is assessed against implemented practices, not intentions. Teams often “have the tool” but fail because they can’t demonstrate:

• The setting is enabled for the entire scope
• Exceptions are controlled and documented
• The control is performed routinely, not once

How to verify (success criteria)

• A requirements matrix mapping each of the 110 requirements to:
• Owner
• Implementation method
• Evidence location (link/path)
• Status (implemented / partial / not started)
• SSP reflects the real environment (not a template)
• POA&M contains only allowable gaps with dates and mitigation plans

What to avoid (pitfalls)

• Writing policies that don’t match reality (assessors will test)
• Treating vulnerability scanning as a scan report with no remediation workflow
• Logging everything but reviewing nothing (no operational evidence)

Command examples (vuln and patch verification)

• Quick Windows patch status checks (example via PowerShell):

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

• Linux patch posture (Debian/Ubuntu example):

apt update && apt list --upgradable

Step 4 — Prepare for the 2026 assessment: SSP/POA&M, mock audit, and scheduling

What to do (action)

Turn your implemented controls into an assessment-ready package.

1) Finalize SSP and POA&M

• SSP: system boundary, components, control implementations, roles
• POA&M: remaining gaps, milestones, compensating measures (where allowed)

2) Build an evidence library

• Use a consistent folder structure by control family:
• evidence/AC/, evidence/AU/, etc.
• For each requirement, store:
• Screenshot/export
• Procedure
• Record (ticket, report, sign-off)

3) Run a mock assessment

• Use an internal team not responsible for implementation, or a third party
• Timebox interviews; test sampling (devices, accounts, logs)

4) Schedule and execute the assessment

• Confirm assessor availability well in advance
• Freeze major changes during the assessment window
• Prepare staff for interviews (admins, HR, program owners)

Why it matters (context)

Even strong implementations fail if evidence is scattered, inconsistent, or not attributable to the in-scope boundary. A mock assessment is where you discover:

• Missing operational records (reviews, approvals, incident exercises)
• Scope drift (new systems handling CUI)
• Misalignment between SSP narrative and actual configuration

How to verify (success criteria)

• Mock assessment results show only minor findings with clear fixes
• Evidence is retrievable in minutes, not days
• SSP/POA&M are version-controlled and approved

What to avoid (pitfalls)

• Waiting until the last month to write the SSP
• Letting the assessment become the first time staff explain processes aloud
• Making large infrastructure changes during evidence collection

Warning: If your SSP says “we review logs weekly,” you must produce weekly review records. Align the SSP to what you can sustain.

Common mistakes (and how to fix them)

• Mistake: Treating Level 2 as a one-time project
• Fix: Implement recurring activities (log review, access reviews, vuln remediation) with calendar cadence and recorded outputs.
• Mistake: CUI appears in email, chat, or personal cloud storage
• Fix: Define approved CUI handling paths; enforce DLP/labels where feasible; train staff; audit for violations.
• Mistake: “We have MFA” but admins bypass it
• Fix: Require MFA for privileged roles, enforce conditional access, and restrict legacy auth.
• Mistake: Asset inventory is incomplete
• Fix: Establish a single source of truth (MDM/CMDB), reconcile monthly, and tag in-scope assets.
• Mistake: Policies copied from templates
• Fix: Rewrite policies to match your environment and actual routines; cross-link to tools and tickets.
• Mistake: Evidence is screenshots with no dates or context
• Fix: Add timestamps, exports, and “who/when” records (tickets, approvals, reports) tied to the requirement.

Next steps: Turn this into your 2026 execution plan

Use this checklist to move from reading to execution:

• This week
• Identify CUI contracts and owners
• Draft a boundary hypothesis (enterprise vs enclave)
• Start an in-scope asset inventory
• This month
• Complete a NIST SP 800-171 gap assessment
• Create a remediation backlog with owners and due dates
• Stand up your evidence library structure
• Next 60–90 days
• Implement top-priority controls (MFA, logging, patching, access reviews)
• Draft SSP/POA&M based on real configurations
• Run a mock assessment and close findings

If you want a smoother certification experience in 2026, focus on two themes: scope discipline and evidence quality. Tools help—but repeatable operations and provable outcomes are what get you across the line.

CTA: If you’d like, Cabrillo Club can help you scope your CUI boundary, run a NIST SP 800-171 gap assessment, and build an assessment-ready evidence kit for CMMC Level 2.