CMMC Level 2 Self-Assessment: A Practical 2026 Guide

Confirm the procurement says Level 2 Self

In 2026, the first task is to confirm that Level 2 Self is actually the requirement for the opportunity. Phase II has been suspended, but Phase I self-assessment remains active. That makes old rollout charts a poor substitute for the specific solicitation and the current CMMC program page.

DFARS 252.204-7025 distinguishes Level 2 (Self) from Level 2 (C3PAO). Capture the exact wording from the solicitation. Do not let an internal label such as 'we need Level 2' erase the assessment type, because the evidence path, cost, timing, and submission process can differ materially.

Also identify the system that will perform the work before anyone starts scoring controls. If the proposal uses the engineering enclave but the last assessment was built around a corporate tenant, the result may not answer the contracting question. Put the opportunity, system name, CAGE information, and relevant SPRS identifiers in the same bid-readiness record.

Build scope from CUI flows, not from the org chart

Trace CUI through intake, processing, storage, collaboration, remote access, backup, support, and disposal. Then classify the assets using the current Level 2 scoping guidance. CUI assets are obvious starting points, but security protection assets can matter because they provide security functions to the assessment scope. Specialized and contractor risk-managed assets need their own documented treatment.

External services belong in the conversation too. Identity providers, MSP administration, cloud storage, security monitoring, ticketing systems, and backup services can create dependencies even when users never open a CUI document in those systems. Record the function, administrative path, data exposure, and evidence owner for each service instead of treating 'SaaS' as automatically in or out.

Assess the current CMMC baseline consistently

The Department's current CMMC materials continue to describe Level 2 against the 110 requirements in NIST SP 800-171 Rev. 2 during this phase, even though NIST finalized Rev. 3 in 2024. Label the assessment baseline clearly. Mixing Rev. 3 identifiers, tailoring, or organization-defined parameters into a Rev. 2 CMMC worksheet can produce a record that is difficult to audit.

Use one assessment workbook or evidence index that connects each requirement to an implementation statement, the system component involved, and the evidence used to support the determination. Do not point every requirement to the same 100-page policy. An assessor — including your own internal reviewer — needs to see what specifically satisfies the requirement in this environment.

Use evidence that shows operation, not just intent

For access control, evidence might include group membership, approval records, and a recent access review. For configuration management, it could include a baseline plus a change ticket and a live configuration sample. For incident response, it may include the plan, an exercise record, and resulting corrective actions. The pattern is consistent: one artifact explains the design and another shows that people or systems actually follow it.

Screenshots can help, but context matters. Include the system name, date, relevant account role, and enough of the interface to understand what setting is shown. Avoid capturing passwords, private keys, or unnecessary personal information. Aim for reproducible proof, not a visually impressive evidence folder.

Handle gaps before they become representation problems

When a requirement is not met, record the finding precisely. Avoid vague items such as 'improve MFA' or 'fix logging.' Name the requirement, affected component, observed condition, root cause, owner, remediation action, target date, and what evidence will demonstrate closure. Then verify whether current CMMC rules permit the item on a POA&M; not every gap is deferrable.

A self-assessment creates risk when management treats the score as a target rather than a representation about an actual system. Require an independent internal review of a sample of high-impact controls and every NOT MET determination before submission. That review is cheap compared with discovering later that the evidence and the status do not match.

Close the loop in SPRS and on the calendar

After the assessment, complete the required government submission steps and verify the resulting record. Under the current Phase I description, Level 2 Self status is generally on a three-year assessment cycle with annual affirmation. Put both dates on the compliance calendar and name the person responsible for checking that the record remains current.

Finally, define change triggers. A cloud migration, identity redesign, new remote-access method, acquisition, major provider change, or enclave boundary change should prompt a review of scope and affected evidence even if the three-year date is far away. The strongest self-assessment program is not the one with the biggest binder; it is the one that notices when the environment stopped matching the binder.

Create a small review team that separates implementation from judgment. The system administrator can explain the configuration, but a second person should decide whether the evidence supports MET. For a very small company, that second person may be a security lead, operations manager with appropriate training, or an outside adviser who is not selling the control being evaluated.

Use the current assessment guide and assessment objectives as the evidence standard. For each requirement, write down what was examined, who was interviewed, and what was tested or demonstrated. A simple record of the methods used makes later re-performance possible and reduces the temptation to score a control from policy language alone.

Sample difficult areas more deeply: privileged access, log review, incident response, vulnerability remediation, configuration change, media handling, and external-provider responsibilities. These are areas where a company can have a good policy and a weak operating process. If evidence depends on one person saying 'we always do that,' look for an artifact or demonstration that can support the statement.

Before submission, hold a management review focused on NOT MET items, POA&M eligibility, material scope assumptions, and representations that will be made in SPRS. Do not spend the meeting reading every successful requirement. Management attention belongs on the claims that carry the most contractual risk.

Before submission, run a challenge review with someone who did not implement the sampled controls. For each selected requirement, that reviewer should be able to name the assessed system, retrieve the current evidence, explain why the implementation is MET or NOT MET, and identify any exception path that could make the conclusion false. Record the exceptions that survive the review instead of smoothing them out in prose; those are the items management needs to understand before the result becomes a government-facing record.

Common questions

Official sources used for this guide

Open the primary source before making a contract-specific decision. Regulations and program implementation can change.