Policy vs Procedure vs Evidence in CMMC

Why Assessors Care About the Distinction

Under NIST SP 800-171A, every control practice is decomposed into assessment objectives. Each objective is evaluated using three methods: Examine (review documents and configurations), Interview (ask personnel about their knowledge and actions), and Test (observe or execute the control in practice). These three methods map directly to three layers of documentation — and if any layer is missing, the objective cannot be scored Met.

The most common documentation failure in CMMC assessments is not the absence of documentation. It is the presence of one layer with the absence of another. Contractors invest heavily in policy documents — sometimes hundreds of pages — and then cannot demonstrate that a single policy is executed through a repeatable procedure with dated evidence. The policies exist. The compliance does not.

What Belongs in Policy

A policy is an organizational decision. It declares what the organization will do, who it applies to, and under what authority. A policy does not describe how to configure a firewall, how to review logs, or how to provision a user account. Those are procedures. A policy sets the rules that procedures implement.

For CMMC, every control family requires at least one organizational policy. NIST SP 800-171A explicitly lists policy documents as examination objects for the first assessment objective in each family. If the policy does not exist, the entire family starts with a deficit.

A well-constructed CMMC policy includes:

What Belongs in Procedure

A procedure is the operational implementation of a policy. It describes the specific steps, tools, configurations, and workflows that carry out the policy's requirements. Where a policy says "what must happen," a procedure says "how it happens, who does it, and what tools they use."

Procedures are evaluated during the Interview phase of the assessment. The assessor will ask a staff member to walk through the procedure — not read it from the document, but describe it from their operational experience. If the person cannot describe the procedure without consulting the document, the assessor may conclude the procedure is documented but not operationalized.

A well-constructed procedure includes:

• Trigger — What initiates the procedure: a schedule (weekly, monthly), an event (new vulnerability published, user reports incident), or a condition (account lockout threshold exceeded).
• Steps — The specific actions, in order. Detailed enough that a trained replacement could execute them. Not so detailed that they become brittle when a tool updates its interface.
• Responsible role — Who performs each step. Named by role, not by individual.
• Tools — Which systems or platforms are used. "Microsoft Purview Compliance Portal" is a tool. "The compliance tool" is not specific enough.
• Output / artifact — What the procedure produces: a completed checklist, a ticket, a report, a configuration change. This artifact becomes the evidence that the procedure was executed.
• Escalation path — What happens when the procedure encounters an anomaly or exception. Who is notified. What the next step is.

What Counts as Implementation Evidence

Evidence is the proof that a control is implemented and operating. It is the layer that assessors spend the most time evaluating — because it is the layer that cannot be fabricated retroactively. A policy can be written the week before an assessment. A procedure can be drafted from memory. But evidence of consistent operation over the past 90 days either exists or it does not.

CMMC evidence falls into three categories:

Why Screenshots Cannot Replace Process

Screenshots are the most common evidence artifact in CMMC assessments — and the most overused. A screenshot of a conditional access policy proves the policy exists at the moment the screenshot was taken. It does not prove the policy was in effect last month. It does not prove anyone reviewed its effectiveness. It does not prove it was not temporarily disabled during a troubleshooting session and never re-enabled.

Assessors know this. That is why they do not accept screenshots alone for controls that require ongoing operation.

The rule of thumb: a screenshot proves a point-in-time state. Logs, records, and dated reports prove continuous operation. For any control that requires ongoing execution — log review, vulnerability scanning, patch management, access reviews, training — a screenshot is the starting point, not the finish line. The assessor will ask: "This shows the configuration. Now show me that it ran last month."

How to Avoid Contradictions Across Documents

The most damaging documentation failure is not a missing document. It is a contradiction between documents that already exist. When the policy says one thing, the procedure says another, and the evidence shows a third, the assessor cannot score the control as Met — because the organization has not demonstrated a coherent implementation. It has demonstrated confusion.

Common contradictions that assessors find:

The prevention is straightforward but requires discipline: every time a technical configuration changes, review the policy and procedure that reference it. Every time a policy is updated, verify that the corresponding procedures and SSP descriptions still align. Build a cross-reference table — each policy section links to the procedure that implements it and the evidence artifact that proves it. When any element changes, the cross-reference flags what else must be updated.

A Simple Mapping Model from Requirement to Proof

The most effective documentation strategy for CMMC is a four-column mapping table that connects every NIST SP 800-171 practice to its policy source, its implementing procedure, and its evidence artifact. This table becomes the master index for the assessment — the assessor can trace any control from requirement to proof in a single view.

This mapping table serves three purposes. First, it is a gap-finding tool during preparation — any empty cell is a gap that must be closed. Second, it is a navigation tool during the assessment — when the assessor asks about a control, you can point them to the exact policy section, the exact procedure document, and the exact evidence artifact. Third, it is a maintenance tool after certification — when anything changes, the table shows which other documents must be updated to prevent contradictions.

The Bottom Line

A CMMC assessment evaluates three layers of documentation — policy, procedure, and evidence — and all three must be present, consistent, and current for every control practice. A policy without a procedure is an intent without an implementation. A procedure without evidence is a claim without proof. Evidence without a policy and procedure is an ad hoc action that cannot be sustained or repeated.

The contractors who fail assessments rarely fail because they have no documentation. They fail because the documentation they have describes a compliance posture that does not match what the assessor finds in the live environment. The policy says one thing. The system does another. Nobody updated the procedure when the configuration changed. The evidence was never collected because the procedure never defined an output artifact.