Building a complete CMMC policy and procedure architecture from scratch.

The challenge in this engagement was not writing policy. It was building an architecture of documents that all reference each other coherently, all reflect how the organization actually operates, and all stand up to assessor scrutiny across three different verification methods. Industry data from the Redspin 2025 "Momentum, but Slow Movement" survey of 180 contractors illustrates the scale of the problem: 68 percent of surveyed contractors reported their CMMC preparation had already taken more than a year, and the dominant reason consistently cited is documentation work - building the artifacts that connect controls in practice to controls on paper.

Templates fail under assessor scrutiny for predictable reasons. A generic template was written for a generic environment. The specific personnel roles, the specific tools, the specific escalation paths, the specific data flows - none of those exist in a template. When a C3PAO assessor pulls a random staff member into an interview and asks "what is your role in incident response," and the staff member's title does not appear anywhere in the incident response playbook because the playbook was written for someone else's organization, the finding is unavoidable.

The incident response domain is especially exposed. CMMC requires not just an incident response policy but evidence of incident response capability. The framework expects documented playbooks for distinct incident types, defined notification thresholds (including the DFARS 252.204-7012 72-hour reporting requirement for cyber incidents involving covered defense information), defined roles and escalation paths, post-incident review procedures, and an annual review of the program itself. A single "Incident Response Policy" file, however well written, does not satisfy these requirements.

Operations Security procedures are the most under-built part of most CMMC documentation. Audit log review, change management, media sanitization, personnel onboarding and offboarding, and visitor escort are operational disciplines, not policy statements. They require documented procedures with named owners, defined cadences, and evidence of execution. The Cyber AB's published assessment guides confirm what assessors look for in this domain: not just the existence of a procedure, but evidence that it is being executed on schedule, by the right people, with the right outputs.

Shared Responsibility Matrices are a regulatory expectation, not a nicety. The 32 CFR Part 170 Final Rule and the supporting DFARS rule together require that External Service Providers - Managed Service Providers, Managed Security Service Providers, hosted email providers, hosted file sharing providers, and other vendors handling or supporting CUI on the contractor's behalf - be incorporated into the contractor's assessment scope. The mechanism for doing that is a Shared Responsibility Matrix per provider, documenting exactly which CMMC controls the provider is responsible for, which the contractor is responsible for, and which are shared. An assessor will ask for these. A contractor that cannot produce them is exposed regardless of how well its own internal controls are documented.

A CMMC documentation package is not five files. It is a hierarchy. At the top sits the Information Security Policies and Standards document - the authority that all other documents flow from. Beneath it sit the procedure-level documents: Incident Response playbooks, Operations Security procedures, Shared Responsibility Matrices, and the System Security Plan. Each document references the others. None of them is a generic template.

The organization went into the engagement with a healthy operational security posture and almost no formal documentation. It came out with a complete, coherent, custom-authored documentation architecture: a signed Information Security Policies and Standards document; five distinct Incident Response playbooks plus an Annual Review Memo and a DFARS 72-Hour Quick Reference card; an Operations Security Procedures Manual covering the five operational disciplines with named owners and defined cadences; Shared Responsibility Matrices for every CUI-relevant External Service Provider; and a System Security Plan that ties the entire architecture to the 110 NIST 800-171 Rev 2 controls.

Every document was authored against the organization's actual environment. Personnel roles, tools, escalation paths, vendors, and data flows reflect what is real, not what a template assumed. The documentation now functions as the company's operating reference for security - staff use it as a daily resource, not as a binder reserved for assessor visits. This is the test for whether documentation will hold up during the Interview phase: does the random staff member know about the document, and can they explain their role in it?

The implication for assessment readiness is direct. The organization's Examine phase exhibits exist, are current, and reference each other coherently. The personnel referenced in the documents can speak to their roles, because the roles match what they actually do. The Test phase, in which assessors verify that procedures produce the outputs the documentation claims, has a real chance of going well because the procedures were designed to produce assessable outputs from the start.

Every Consilien engagement maps to specific, citeable controls and publications. This is the regulatory and standards footprint of the work described above.

The Bass Berry & Sims analysis of the final CMMC rule highlights the same point Greenberg Traurig does: documentation has become a contractual condition of doing business with the Department of Defense. Self-attestation is being phased out for most Level 2 contractors. Annual affirmations require the affirming official to put their name on the company's compliance posture. The documentation is the substrate that those affirmations rest on. A weak documentation architecture creates personal exposure for the affirming official, not just regulatory exposure for the company.

If you are reviewing your own CMMC documentation right now, three quick diagnostics tell you whether you have a tailored architecture or a template package. First, does your incident response material have multiple playbooks differentiated by incident type, or just one generic file? Second, do your Operations Security procedures specify named owners and cadences, or do they describe generic activities? Third, do you have a Shared Responsibility Matrix for every external service provider that touches CUI on your behalf? If any of those answers is no, your documentation package is not yet at the level the framework expects.

Multiple authoritative analyses of CMMC assessment outcomes - including the legal alerts from Greenberg Traurig and Bass Berry & Sims cited above, and the Redspin 2025 readiness study based on data from 180 DoD contractors - consistently identify documentation and evidence gaps as the dominant deficiency category. With only approximately 1,000 organizations having achieved Level 2 certification across a DIB estimated at 80,000 contractors, the gap between contractor readiness and assessment standards is wide and well-documented. The fastest way to close that gap is not by buying more tools. It is by authoring the documentation architecture that translates the controls you already have into the artifacts an assessor can verify.