// The body of evidence
CMMC Documentation: the Body of Evidence Behind Level 2
Every page below is a recreated sample — the real thing is what we build for you.
Ask what CMMC actually examines and the answer is documents and the records behind them: a System Security Plan an assessor reads line by line, policies your people are interviewed against, and the operational evidence that proves it all runs. CLOUD2E holds CMMC Level 2 as an organization — this page shows, in recreated sample pages, what a complete documentation set looks like and why each piece exists.
A note on the images: nothing here is a screenshot of a real deliverable. Each specimen was rebuilt from scratch with fictional content and a watermark, because our actual documentation describes a real, certified security architecture — and that belongs in front of clients and assessors, not on the open internet. The compliance checklist covers the order of operations; this page covers what the finished body of evidence contains.
What documents are required for CMMC Level 2?
CMMC Level 2 does not publish a one-page packing list — the requirement is NIST SP 800-171, and the documentation follows from its 110 requirements and their assessment objectives, which assessors verify through examine, interview, and test procedures. In practice, two decades of federal assessment habit have settled on a recognizable body of evidence. These are the ten artifact groups a C3PAO expects to see, and the ten we build and maintain for clients (and built for ourselves — CLOUD2E holds CMMC Level 2 as an organization):
System Security Plan (SSP)
The anchor document: scope, boundary, data flows, and an implementation statement for every one of the 110 requirements. Assessments are conducted against it.
Policy manual
One policy per NIST SP 800-171 family — fourteen in all — stating what the organization requires, who is responsible, and what happens when it is not followed.
Procedures manual
How the policies actually get done: account management, hardening, monitoring, incident response — each procedure naming its owner, steps, and the records it produces.
Plan of Action & Milestones (POA&M)
The honest list of what is not done yet, with owners and dates — kept within the limits the CMMC rule allows and closed out on the clock it sets.
Risk assessment records
A dated, repeatable assessment of threats and vulnerabilities with a ranked register and treatment decisions, feeding the POA&M.
Incident response plan + test records
The IR plan and the proof it has been exercised — tabletop after-action records with findings and improvement items.
User agreements package
Signed acceptable-use, rules of behavior, CUI non-disclosure, privileged-access, telework, and offboarding agreements for every in-scope user.
Shared Responsibility Matrix (SRM)
Where an external provider performs or shares controls, the split is documented per requirement — assessors ask for this by name.
Training records
Awareness and role-based training completions, insider-threat content included, current for everyone inside the boundary.
Operational records
The living evidence layer: access reviews, change tickets, log-review notes, restore tests, maintenance records — produced by operations, not for the audit.
// Sample 01 · 02
The CMMC SSP — where assessments are won
The System Security Plan is the document the assessment is conducted against: system identification, the CUI data flows, the network and assessment boundary, and an implementation statement for each of the 110 requirements — with its status, its responsible role, and the evidence that backs it. A strong SSP reads like the specimen here: specific, verifiable, and wired to named artifacts. A weak one reads like the requirement restated with “we comply” in front of it.
The boundary figure matters as much as the control pages. Ours follow the enclave pattern — CUI concentrated in a government community cloud tenant with managed endpoints and monitoring around it — the architecture covered in our enclave guide and, where export control rides along, our GCC High practice.
// Sample 03 · 04
CMMC policies and the procedures that make them real
Policies state the organization’s rules — one per requirement family, fourteen in all, each with the three sections an assessor looks for: who is responsible, what happens on non-compliance, and when it gets reviewed. Procedures translate the rules into steps with owners. The convention that separates mature documentation from shelfware is visible in the specimen: every procedure ends by naming the records it produces and the controls it satisfies, so evidence accumulates as a by-product of operations instead of a quarterly scramble.
This is also where an MSP relationship earns its keep: most of those records — access reviews, hardening baselines, log-review notes, restore tests — fall out of the operational work we already do for managed IT clients, pre-mapped to the controls they serve.
// Sample 05 · 06
Proof you think about risk — and proof you practice
Two artifact families prove a program is alive rather than printed. The risk assessment shows leadership looked at threats against the actual boundary, ranked them, and made treatment decisions — dated, signed, and feeding the POA&M. The tabletop exercise record shows the incident response plan has been walked under pressure: scenario, injects, the 72-hour DoD reporting decision made correctly, and findings that turned into fixes. Assessors read both as character evidence for the whole program.
If an incident ever stops being hypothetical, the same records become your first hour’s playbook — the subject of our incident response practice and a standing part of every compliance engagement’s calendar.
// Sample 07
The Shared Responsibility Matrix — the MSP question, answered in writing
The moment an external provider touches your environment, the CMMC program rule expects the division of labor to be documented: which requirements the provider performs, which you retain, and which are shared. This is the document that keeps an assessment from stalling on “so who actually reviews the logs?” — and the one to demand from any provider before you sign. Ours is standard issue for every compliance client, kept in lockstep with the SSP.
It is also the honest test of a provider’s claims: an MSP that cannot produce an SRM mapped to the 110 requirements is guessing. The questions in our guide to choosing a CMMC partner and the ND-ISAC questionnaire we answered publicly both exist to surface exactly that.
CMMC templates vs. a tailored body of evidence
Template packs are everywhere, and we will say the honest thing about them: structure helps, and a good template saves hours of formatting. But an assessment is not a document review — it is an interview against your documents. When the SSP says quarterly access reviews and no review export exists, when the policy names a role nobody holds, when three documents describe three different boundaries, templates become evidence against you. The expensive part of CMMC documentation was never the Word files; it is making the words true.
Our approach: the structure is standardized — it is the one that passed our own assessment — and every statement in it is written against your actual environment, then kept true by operations. That is also why the samples on this page are watermarked illustrations rather than downloads: a body of evidence you did not implement is a liability with a table of contents. If you want the real thing walked through page by page, we do that under NDA, in a working session.
The CMMC artifacts list, in assessor vocabulary
Assessors talk about "artifacts" — the tangible items collected against each assessment objective. A useful rule of thumb as you inventory your own: most objectives want two kinds of artifact, something that says you do it (policy, plan, procedure) and something that shows you did it (record, export, ticket, log). The catalog above maps cleanly onto that split: the first eight groups mostly say, the last two mostly show, and a mature program produces the showing kind automatically.
- Say-artifacts: SSP, policies, procedures, IR plan, agreements, SRM, POA&M.
- Show-artifacts: risk assessment records, TTX after-action records, training completions, access-review exports, change and maintenance tickets, log-review notes, restore-test results.
- Where they live matters too: our clients keep the registry, self-assessment, and evidence exports organized in the CLOUD2E CMMC Tracker — deployed in their own tenant, assessor-ready on demand.
// Documentation FAQ
Asked about CMMC documentation
What documents are required for CMMC Level 2?
At minimum: a System Security Plan, policies and procedures covering all fourteen NIST SP 800-171 families, a POA&M within the rule’s limits, risk assessment records, an incident response plan with test records, signed user agreements, training records, a Shared Responsibility Matrix for any external provider, and the operational records that prove the controls run. The catalog on this page is that list in practice.
Do we need a separate policy for every control family?
The rule requires the requirements to be met, not a particular binder layout — but one policy per family is the layout assessors read fastest, and it makes the control-mapping index almost mechanical. We structure manuals that way for a reason: findings hide in clever organization.
How often does CMMC documentation have to be updated?
On a declared cadence (annual review is the common floor), after significant system changes, and after incidents that touch the subject matter — with the review itself logged. An SSP with no revision history reads as shelfware, and assessors notice.
Can’t we just buy a template pack and fill it in?
You can buy structure; you cannot buy truth. Templates accelerate formatting, but every statement still has to match your environment, your roles, and your records — because the assessment interviews your people against the text. Most of our documentation engagements begin by reconciling an optimistic template pack with reality.
Will CLOUD2E show us its actual certified documentation?
Yes — under NDA, in a working session, which is where real documents belong. What we publish here are recreated, watermarked specimens with fictional content, on purpose: our body of evidence describes a real security architecture, and real security architectures are not marketing assets.
Ready to build yours? Start with the CMMC Level 2 requirements, work the checklist, and budget with the cost guide — or have our team build the body of evidence with you .
See the real body of evidence — walked through under NDA
Tell us where you are today — we'll map the fastest, safest path and show you exactly what it takes.