CMMC Documentation Requirements Explained Simply (Level 1 vs Level 2)

If you’re a small business trying to sell into the DoD supply chain, CMMC documentation requirements can feel like a stack of paperwork designed for huge primes. You hear terms like SSP, POA&M, “objective evidence”, and suddenly it sounds like you need a full-time compliance team.

I don’t see it that way. Documentation is just written proof plus real-world records. It’s the “show your work” part of security. When I help clients prepare, I focus on keeping it lean, accurate, and tied to what they actually do in Microsoft 365, endpoints, and cloud services.

In this post, I’ll separate what’s required vs what’s commonly expected, explain Level 1 vs Level 2, walk through the core document set (SSP, policies, procedures, evidence, POA&M, inventory and scope), how assessors review it, and finish with a simple checklist plus mistakes I see all the time.

CMMC 2.0 documentation in plain English (what it is, and why it matters)

CMMC 2.0 is about proving you protect the type of data in your contracts. For most small businesses, that means Level 1 (FCI) or Level 2 (CUI). CMMC isn’t just “buy security tools”. It’s “prove the tools and processes are working, consistently”.

Good documentation does three practical things:

• It forces you to define scope, so you’re not trying to secure everything you own.
• It turns security into repeatable habits, so you’re not relying on one hero admin.
• It gives assessors a clear trail from “requirement” to “how we do it” to “here’s proof”.

Quick CMMC 2.0 refresher for small businesses: Level 1 vs Level 2

Level 1 focuses on protecting Federal Contract Information (FCI). It’s 17 practices aligned to FAR 52.204-21, and it’s typically an annual self-assessment. Documentation is lighter, but it still has to match real behavior.

Level 2 covers Controlled Unclassified Information (CUI) and aligns to 110 requirements from NIST SP 800-171 (see the source standard at NIST SP 800-171 Rev. 2). Many contracts will require a C3PAO assessment, and documentation becomes more formal because the control set is much larger.

Also, the rollout has been moving into contracts in phases starting in late 2025, so waiting usually makes the scramble worse.

What “documentation” means (and what it doesn’t)

Here’s the simplest way I explain it:

• Policy is the rule.
• Standard is the minimum bar (the “how strong”).
• Procedure is the steps (the “how to”).
• Evidence is the receipt.

Documentation includes planned items (SSP, policies, procedures) and proof items (logs, tickets, reports, screenshots, training records). A five-page policy that nobody follows doesn’t help. A one-page policy that matches your real process, plus clean evidence, usually does.

What documents you need for CMMC documentation requirements (required vs commonly expected)

Think in two layers: the core set (what you build) and the evidence habit (what you keep collecting). If you do that, most assessments become a controlled review, not a guessing game.

Level 1 documentation: the light version that still has to be real

For Level 1, I aim for short, clear documents that map to the 17 practices and the systems that touch FCI (often email, file sharing, endpoints, and basic network gear).

At minimum, I want to see:

Scope and inventory (FCI-focused)
A basic boundary statement, a list of in-scope devices/users, and where FCI is stored or shared (SharePoint site, Teams channel, a file server, etc.).

Short policies that cover the basics
Acceptable use, passwords and MFA, access basics (least privilege), incident reporting, and basic physical security. Clarity matters more than length.

A few simple procedures
User onboarding/offboarding, patching cadence, lost device steps, and how staff reports a suspected incident.

Basic evidence (easy wins in Microsoft 365)
MFA settings screenshots, endpoint protection status, patch reports, security awareness completion list, and vendor contracts if IT is outsourced.

Level 1 still needs to be organized. If you can’t find evidence quickly, it creates doubt.

Level 2 documentation: the formal set that maps to NIST 800-171

Level 2 is where the System Security Plan (SSP) becomes your anchor. It describes your environment, your CUI boundary, and how each requirement is met. Assessors often follow the SSP like a map.

Your Level 2 core set should include:

1) SSP (System Security Plan)
I structure it so each NIST 800-171 requirement points to the control approach, the system component (M365, endpoint tool, firewall), and where evidence lives. The DoD’s CMMC Assessment Guide for Level 2 is helpful for understanding how this gets evaluated.

2) Policies and standards
Policies set the rules. Standards define the minimum settings (MFA required, password rules, encryption requirements, log retention targets, device hardening baseline).

3) Procedures and playbooks
Access requests, admin changes, patching, vulnerability scanning, incident response steps, backup restore tests, and log review.

4) Evidence and artifacts (ongoing)
This is where small teams struggle. I build an evidence library by control family or control ID. Screenshots and exports are fine if they’re dated and tied to a requirement.

5) POA&M (Plan of Action and Milestones)
A POA&M tracks gaps, owners, target dates, and closure proof. Current guidance has allowed conditional outcomes in some cases, but it comes with strict limits and short timelines, so I treat POA&M items like a sprint, not a parking lot.

6) Inventory and scope docs
Asset inventory, user inventory, data flow diagrams, system boundary, and where CUI is stored, processed, or transmitted.

Commonly expected extras (not always “required,” but often requested) include change records, vendor management notes, and a basic monitoring plan. If you’re in Microsoft 365, these usually translate into documented roles, a ticket trail, and repeatable reports.

If you want a quick crosswalk view between CMMC and NIST 800-171, I’ve found this CMMC vs NIST 800-171 mapping overview useful for explaining the relationship to non-security leaders.

How assessors use your documentation, plus a simple checklist and common mistakes

An assessment is not a literature contest. It’s more like a home inspection. The assessor checks what you claim, then looks for proof, then verifies it’s repeatable.

In plain steps, most reviews follow this flow:

1. Document review (SSP, policies, procedures, inventories, POA&M)
2. Interviews (IT, security, HR, leadership, sometimes facilities)
3. Requests for objective evidence (artifacts that prove the practice)
4. Observation or demos (showing settings, logs, workflows, and access controls)

What assessors look for: “objective evidence” that matches your SSP

Objective evidence is anything that proves a control is operating, not just written down. Examples I’ve used in real assessments:

• User access list plus an offboarding ticket showing access removal
• MFA enabled screenshots, conditional access policy exports
• Patch report plus matching remediation tickets
• Vulnerability scan output plus a closed fix record
• Incident ticket plus a short lessons learned note
• Training completion report
• Visitor log or door access record (if physical controls apply)

The fastest way to lose time is inconsistency. If your SSP says “we review logs weekly,” then you need a weekly record that you actually did it.

Simple checklist: document types, examples, owners, and review cadence (plus common mistakes)

Document type	Example items	Typical owner	Review cadence
SSP	Boundary, system description, control implementation notes	IT/Security	Quarterly, after major changes
Policy set	Access control, incident response, acceptable use	Security/Leadership	Annual
Standards	MFA standard, device baseline, encryption requirements	IT/Security	Annual, after major changes
Procedures/playbooks	Onboarding, patching, IR steps, backup restore test	IT	Quarterly
Asset and user inventory	Device list, admin accounts, service accounts	IT	Monthly
Data flow and scope docs	CUI/FCI locations, diagrams, boundary statement	IT/Security	Quarterly, after major changes
Training records	Completion reports, new-hire training	HR/Security	Quarterly
Logs and monitoring records	Log review notes, alerts, SIEM reports	IT/Security	Weekly
Vulnerability scan reports	Scan exports, remediation tickets	IT	Monthly
Incident reports	Incident tickets, post-incident notes	IT/Security	After incidents, annual review
POA&M	Gap list, owners, due dates, closure evidence	IT/Security	Weekly until closed
Vendor management docs	MSP scope, cloud provider responsibilities	Procurement/IT	Annual, after vendor changes

Common mistakes I see (and quick fixes that work for small teams):

• Copied SSP: Rewrite in your words, tie it to your real tools.
• Unclear scope: Define the boundary first, then document only what’s in it.
• Tools without proof: Add a monthly evidence routine (exports, screenshots, tickets).
• Stale docs: Put review dates on calendars, update after major changes.
• Messy evidence: Create folders by control family/control ID, name files by date.
• Hiding gaps: Track them openly in the POA&M, close them fast.
• Outsourced IT confusion: Put responsibilities in writing (who patches, who reviews logs, who responds to incidents).

Conclusion

CMMC documentation requirements aren’t mysterious once you see the pattern: clear documents plus ongoing proof. When I build this with clients, we start with scope and inventory, then write the SSP, then keep policies and procedures short, and finally set a simple evidence routine that fits weekly work.

If you’re using Microsoft 365 and cloud tools, you already have a lot of the proof, it just isn’t organized. If you want help, I can run a readiness review, tighten your core document set, and set up an evidence library that’s easy to maintain so your next assessment is about facts, not panic.