The Challenge of Documentation: CMMC 2.0

Vincent Scott
Jul 23
6 min read

Updated: 6 days ago

A long-time requirement for any auditable process or standard has been documentation. It makes you wonder if early cave paintings quickly moved from art to “documenting your hunting process” for future audits. Perhaps it did not start quite that long ago, but we certainly have extensive documentation programs aligned with our many compliance requirements today.

We are going to start a short series of posts on documentation and things to consider. Starting out; CMMC - The majority of the work is Documentation.

CMMC, or the Cybersecurity Maturity Model Certification, is no different. As the new DoD standard for cybersecurity, it could be expected to have documentation requirements. Any auditable standard will require documentation and any government-led standard doubly so. CMMC is 70% documentation. Most companies working on their DoD cyber compliance and CMMC focus on technical implementation. This has cybersecurity in the name so the principal focus has to be information technology (IT) technical controls right? Actually not, the documentation required for CMMC is most of the work, and leaving documentation to later is an error in our view. Integrate documentation building and maintenance into your CMMC program from the ground up.

Recommendation: Don't put off writing documentation until the end. We see organizations do this a fair amount and then they are caught short getting documentation in place. Technically, under the standard, if things are not documented then they are “Not Met.”

Aspirational, fluffy clouds documentation is a mistake.

Many of the modern cyber standards are simply restacking the well known security control blocks in different groups and orders. There is some differentiation, but in actual implementation, little difference. CMMC though, and its corresponding assessment requirements are very specific. The normal approach of writing high-level, high-sounding, ‘we do everything policies,’ without too much detail that can lead to accountability will not work for CMMC. The assessment objectives for CMMC as contained in NIST 800-171A are very specific and assessors will be looking for answers to those very specific questions. Pro tip: You must run your CMMC program and supporting documentation through the lens of these 320 assessment objectives, not simply the 110 controls. Failure to address, specifically, each assessment objective will also result in assessment failure. We have seen a number of companies achieve negative scores when they thought they were 110/110 because they did not know they needed to pay attention to the assessment objectives.

Recommendation: Write to each assessment objective in your SSP under each control. Treat each objective as a question to be answered. Don’t just list them, write to each one. For example, the 3.1.1 assessment objective [a] is “authorized users are identified.” We normally write that as something like, “authorized users are identified as all employees listed in the corporate HR PAYCOM database, and the contractor authorized user list.”

Our top 5 documents that we don’t think you can pass CMMC without.

Policies, Procedures, Manuals, Plans. What documentation do we need?

It really does not matter what you call your documents. Have 100 documents four pages long or one 400-page document, regardless an assessor is looking for documentation where documentation is required. Now having said that, there are some general parameters we recommend following. Have at least one Policy document; high level covering the big picture. Many chose to create a series of many policy documents, for example one for each domain. That is completely compliant.

Recommendation: Ruthlessly attempt to combine and eliminate separate documents. Every document (like 14 policies one for each domain, instead of 1 policy covering all 14 domains) has overhead associated with it. It has to be managed. It has to be updated annually. Because it is a separate document, it requires additional work. That work may be small, but when you think in terms of 100 separate documents for CMMC compliance to be managed and updated annually that means that you are updating 2-3 documents every week throughout the year. If it only takes you 2 hours per document to review it, make sure it is up to date, and run it through your approval process, and you should have an approval process that is 200 hours per year in just updating documents. We see 100+ documents as way too many documents. Fewer is better.

Here are our top 5 documents for CMMC.

Cybersecurity Policy. NIST 800-171 does have a couple places in the controls and assessment objectives that explicitly call for policies. In appendix E, NIST also put a listing of controls that they assumed were so common that they did not have to be assessed. Policies is one of those assumptions. We recommend, as mentioned above, one overarching Cybersecurity Policy that covers all 14 domains.

System Security Plan. This is the primary core document. No SSP, and you are not even making it into an assessment. Technically, you are not even allowed to self-assess without an SSP. Most people start with the template posted to the 171 Rev 2 website.

Plan of Action and Milestones (POAM). You are required to have one, and it is required that all POAMs be fully resolved prior to a certification assessment. The POAM is the place where you list any controls you are not meeting, and what your plan is to fix that. Managing your POAM is another blog in itself.

Incident Response Plan. This is not directly stated as a requirement. A combination of factors, including the Incident Response domain controls, leads us to this conclusion. Could you combine it with something else? Maybe. Don’t. This is a long standing industry cybersecurity practice for good reason. Have an incident response plan, and test it at least annually (and generate evidence of the test). It is a CMMC requirement.

Operational Plan of Action. What the heck is an Operational Plan of Action or OPA? We already covered POAM. It is not something that has gotten a lot of coverage in blogs and best practices, but it is in the final CMMC rule. We pointed out to the DoD that having and managing a Plan of Action was one of the controls in 171. NIST understood that things break and need to be fixed, and planned for that. In our own program, we had been running with a separate document for this from the POAM for years. In the final 32CFR170 rule DoD formalized and acknowledged that with the creation of the Operational Plan of Action. They then used it to close one of the technical inconsistencies: FIPS Validated encryption. There are several blogs worth of material on OPA and FIPS. For the sake of the documentation discussion, because DoD, in 32CFR170, used FIPS as the example of what should be on an OPA, we think everyone should have one, and have all of their FIPS validated modules on there. It is also possibly a good tool for other reasons Controls previously implemented, but now degraded for some reason, can go on the OPA and are evaluated as Met during an assessment.

Governance. How do we write policy?

Governance is not mentioned anywhere in the CMMC canon, but we think it is really important. This is about how we execute command and control over the organization. Policy sits at the top of that hierarchy, and in an academic setting, you would likely see a Policy, Standards, Procedures, and Guidelines hierarchy of directive documents used to “govern” the processes across the organization. More practically, we view governance as the policy for having a policy. Sounds dumb, but actually needed. What is a policy? Who signs it? How is it approved? How do we make sure everyone has access? What is a procedure? Who writes it? Who approves it? Where do we put that so the people who need it, have access? Etc. What is my hierarchy of documentation and how are we doing that? This does not have to be War and Peace. Straightforward approach to what is our process for doing policy. Write that down. Have that plan in place. Pro Tip: Generally, we recommend under that process, approved policies and procedures should be signed to indicate they are approved. This is not required, per se, but it is an easy way to prove to an assessor that a particular document is approved and in force.

Recommendation: Write down how you are going to manage your documentation process somewhere. Either in something like a Policy for Policy or include Governance as a section in the overarching cybersecurity policy to limit the number of independent documents.

Level 1 - You still need documentation

CMMC Level 1 is equivalent to the Federal Acquisition Regulation (FAR) clause 52.204-21 Basic Safeguarding of Covered Contractor Information Systems. It does not contain any of the CMMC “Maturity Level” requirements that call for documentation explicitly, but if you are going for a Level 1 self-assessment, then you should have at least a cybersecurity policy that covers the 15 requirements/controls. In the final CMMC rule, even if at Level 1 you will be self-assessing, and self-affirming (the equivalent of a legal oath by the named Affirming Official) you must retain evidence of your self-assessment for six years, as the regulation states, “at the request of the Department of Justice.” So you need documentation of your self-assessment and evidence that supports your conclusion that all of these controls are met. At the very least, you need a policy to support that and probably a good deal more.

Recommendation: Although no specific documentation requirements exist for Level 1, not even a System Security Plan, document how you meet these controls. You need that for retained evidence at a minimum. Our recommendation: write a Policy and an SSP anyway.

Future parts of The Challenge of Documentation: CMMC 2.0 will be posted on the DCG Linkedin and updated here.