May 6, 2025
Documentation for CMMC L2 assessment
Bad documentation -- inadequate, irrelevant, incomplete, inaccurate -- is the most common problem we see in contractors that have good security and think they are ready for official assessment. Let's talk about what good documentation looks like.
System Security Plan Your SSP is the single most critical piece of documentation you need to prepare, and it is often the most misunderstood. Let's look to the control for the description:
CA.L2-3.12.4 – SYSTEM SECURITY PLAN
Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
In CMMC, "periodically" means "at least annually." So once you have your initial SSP written, you need to review it at least once a year, and after any significant changes to your information system have been made. Each time you review it, sign and date it. That's your record that you have met this part of the requirement. If you review it but there's no record of review, it didn't happen.
The second most common problem we see is an SSP that doesn't describe "how security requirements are implemented." Simply pointing to another document isn't sufficient. Restating the control isn't enough. Addressing a few assessment objectives (AOs) but not all of them will result in failure. Remember that a control can only be assessed as MET when every single one of its associated AOs has been MET. Your SSP needs to say "This is what we do, and this is how we do it."
Outside the SSP, I find that people really don't understand the proper form and use of policy and procedure documents. A policy document is a high level statement of intent (e.g., "This policy enforces procedures for authorizing users, providing access to protected information, separation of duties, the principle of least privilege, remote access and related controls. For implementation details, see Access Control Procedures."). It only needs to be a few pages long, and it must be signed by someone in authority. Most orgs really only need two policies: an information security policy that describes (in general terms) what the organization will do, and an acceptable use policy that outlines what employees must do. Everything else will go into procedure docs.
A procedure document describes how you will fulfill the intent of your policy. In this example, we would have a procedure for authorizing users (e.g., HR determines the permissions required for a new hire, records it in the HRIS, then asks IT to create a new user account with those permissions.) That general description of the procedure is appropriate to put in the SSP. It would then point to the procedure document which outlines the specific steps in determining which permissions are required and how the account creation process is conducted. Procedure documents are often accompanied by task lists and checklists, which further drill down into the details of implementation.
For a CMMC L2 assessment, you need both policy and procedure documents. In fact, most controls need to be addressed by both.
As one of my assessor friends likes to say, "If you haven't written it down, how am I supposed to assess it?"
Need help? Documentation is my super power! Let's chat.
Sincerely,
Glenda R. Snodgrass, CCP/CCA/Lead CCA
grs@theneteffect.com
The Net Effect, LLC
www.theneteffect.com
251-433-0196 x107

