Evidence, SSP & POA&M.

01What counts as evidence

Evidence, at Level 2, is not a folder assembled the week before an assessment. It is the ordinary paperwork and system output an organization already produces by operating the way its SSP says it does — a change ticket, a log-review note, a training roster, a sanitization certificate, a vulnerability scan with a date on it. An assessor examining a requirement is looking for that ordinary output, not a purpose-built demonstration staged for the occasion.

Every family page on this desk carries its own “What evidence may look like” section for exactly this reason: the proof is a side effect of doing the work, not a separate project layered on top of it. A shop that treats evidence as something to construct after the fact usually finds the construction is the hard part — the actual practices were already there.

02The SSP: the document everything else points to

CA.L2-3.12.4 requires a system security plan — a document describing the system boundary, its environment of operation, how each Level 2 requirement is implemented (or planned to be, where a gap is still open), and how the system connects to anything outside it: an ESP’s tooling, a prime’s portal, a cloud service. NIST prescribes no specific format or level of detail; what matters is that the information 3.12.4 requires is actually conveyed somewhere in the document, and kept current. See Security Assessment for the rest of the family this requirement belongs to.

The SSP is the document the rest of the program hangs on, because it is typically the first thing an assessor reads and the reference point every other requirement’s evidence gets checked against. It is also, on its own, categorically excluded from ever sitting on a POA&M — Section 03 covers why, and what that means in practice.

What an SSP typically contains

NIST mandates no format, but its non-mandatory CUI SSP template — and the way assessors actually read these documents — converge on the same handful of parts: system identification (what the system is called, who owns and operates it, the CAGE codes it maps to); the boundary, in prose and in a network diagram that matches reality; the environment of operation — on-premises, cloud services, an ESP’s tooling, and how they connect; requirement-by-requirement implementation statements for each of the 110, or the POA&M reference where a gap is still open — the part assessors spend the most time in; roles and responsibilities, including the customer responsibility matrix where an ESP is involved; and external connections — every path in or out, from a prime’s portal to the MSP’s remote access. Treat that as the shape reviewers expect to find, not a mandated outline: 3.12.4 requires the information, not the format. NIST SP 800-171 R2 §3.12.4; NIST CUI SSP template

03POA&M mechanics, in full

A Level 2 assessment does not have to land on a perfect score to reach a usable status. Conditional status exists for a small, bounded set of gaps, on a clock — not an open-ended allowance to defer work.

The six requirements excluded outright, whatever the score: AC.L2-3.1.20 (External Connections), AC.L2-3.1.22 (Control Public Information), CA.L2-3.12.4 (the System Security Plan — Section 02, above), PE.L2-3.10.3 (Escort Visitors), PE.L2-3.10.4 (Physical Access Logs), and PE.L2-3.10.5 (Manage Physical Access Devices). 32 CFR 170.21(a)(2)(iii)

What a POA&M entry typically carries

A POA&M is a small table doing a specific job: naming what is open, what closing it takes, and by when. An entry that can survive a closeout assessment usually carries the requirement ID and its point value; what specifically is not yet MET, at the assessment-objective level rather than just the requirement number; the remediation steps or milestones; an owner; the resources it needs; a target date inside the 180-day window; and its current status. Deficiency-tracking itself is a Level 2 requirement in its own right — 3.12.2 — so the habit outlives any single assessment. 32 CFR 170.21; NIST SP 800-171 R2 §3.12.2

04Affirmations: the annual promise

Every level carries the same ongoing obligation on top of the assessment itself: once a year, a senior official — the Affirming Official — submits an affirmation in SPRS stating that the organization continues to meet the security requirements behind its CMMC Status. This happens at Level 1, 2, and 3 alike, and again whenever a POA&M closes out (Section 03).

An affirmation is not a formality. It is a representation to the government, made by someone with the standing to know whether it is true, and it carries the exposure that comes with any representation made to secure a federal contract — the Department of Justice’s Civil Cyber-Fraud Initiative has pursued False Claims Act cases built on exactly this kind of misrepresentation. See the Glossary for the full Affirmation / Affirming Official entry, and The Levels for how affirmations sit alongside each level’s assessment path.

05How an assessor actually looks: examine, interview, test

NIST SP 800-171A — the companion document to the 110 requirements — defines three assessment methods an assessor applies against the evidence described above. Understanding the three helps explain why the same requirement might get checked by reading a document one day and watching a login attempt the next.

All three methods work toward the same goal — supporting a determination of whether a safeguard exists, functions, is correctly implemented, and is complete — and none is required for every requirement on every assessment. As SP 800-171A puts it plainly: there is no expectation that all assessment methods and all objects will be used for every assessment. An SSP that’s current and specific (Section 02) is frequently what makes the examine method fast; a shop with nothing written down forces more of the assessment onto interviews, which take longer and depend more on who happens to be in the room that day.

06At the shop

07Sources