The System Security Plan is the document that will be examined more thoroughly during your CMMC Level 2 assessment than any other artifact you produce. Many contractors treat it as a control-level document. They have one paragraph per control, one signature per family, on to the next. That treatment fails review by a C3PAO.
The SSP that survives review is not a control-level document. It is an objective-level document, paired with an evidence matrix that tells the assessor exactly where to look. If you get those two things right, the assessment becomes a guided tour. If you get them wrong, the assessor is reconstructing your environment from interviews while the clock ticks.
Control-level vs objective-level SSP — the difference at a glance
What the rule says about the SSP
NIST SP 800-171 Revision 2, requirement 3.12.4, requires the OSC to “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.”
That is the floor, not the ceiling. The Level 2 CMMC Assessment Guide and 32 CFR layer additional expectations on top: the SSP must document the use of External Service Providers (ESPs) and Cloud Service Providers (CSPs), reference the Customer Responsibility Matrix, and align with the lettered assessment objectives in NIST SP 800-171A.
The Pre-Assessment Form review under CAP v2.0 Phase 1 explicitly evaluates SSP completeness. A weak SSP gets surfaced before the C3PAO ever walks the environment or begins the remote assessment. While the C3PAO may continue the assessment process, they can generally gauge the organization’s maturity and readiness by reviewing the SSP.
Why the control-level SSP fails
When you write your SSP at the control level (i.e. one statement per requirement, paragraph-style) you produce text that reads cleanly to a security professional and incoherently to an assessor. The assessor’s job, per NIST SP 800-171A and the CAP, is to evaluate each objective. AC.L2-3.1.1 has six objectives, lettered [a] through [f], for example. Each one must be Met for the control to score. If your SSP says “We limit system access to authorized users in accordance with AC.L2-3.1.1,” the assessor cannot tell whether you have implemented [a] (authorized users identified), [b] (processes acting on behalf of users identified), [c] (devices identified), [d] (system access limited to users), [e] (system access limited to processes), or [f] (system access limited to devices). They have to infer or dig deeply into your systems.
What an objective-level SSP looks like
Break every implementation statement out by objective. For AC.L2-3.1.1, you do not write one paragraph. You write six.
(The following is just an example and should not be taken as guidance.)
AC.L2-3.1.1[a] — Authorized users are identified. We maintain a master user list in Microsoft Entra GCC High. The list is owned by the IT Operations Team, reviewed quarterly per AC.L2-3.1.5, and updated within 1 business day of any HR-driven personnel action per PS.L2-3.9.2.
AC.L2-3.1.1[b] — Processes acting on behalf of authorized users are identified. Service accounts, automated authenticated scripts, and scheduled tasks running on in-scope systems are inventoried in the SA group in entra. Each process is associated with the user account on whose behalf it acts. These are reviewed quarterly.
AC.L2-3.1.1[c] — Devices authorized to connect to the system are identified. Endpoint inventory is maintained in Intune in GCC High. Conditional Access policies in Entra (GCC High) enforce device-based access. Devices in Intune are reconciled monthly against the list of company-managed devices.
AC.L2-3.1.1[d] — System access is limited to authorized users. Authentication is enforced through entra in GCC High. RBAC and group-based access controls implemented in Entra GCC High and Windows 365 Cloud PCs. The authentication process is tested annually per CA.L2-3.12.1.
AC.L2-3.1.1[e] — System access is limited to processes acting on behalf of authorized users. Service accounts are provisioned with least-privilege scopes per AC.L2-3.1.5. Process execution is restricted to approved automated workflows defined in [change management system].
AC.L2-3.1.1[f] — System access is limited to authorized devices. Conditional Access blocks unmanaged devices. Device compliance is enforced through Intune and verified at every authentication.
That structure is verbose and it is also exactly what the assessor needs. Each objective has a standalone statement, the implementation is specific (named systems, named owners, named cadences), and the additional cross-references to other controls (AC.L2-3.1.5, PS.L2-3.9.2, CA.L2-3.12.1) build the audit trail the assessor can follow.
The evidence matrix that pairs with the SSP
The second half of an assessor-grade SSP is the evidence matrix. We recommend it be a separate document, or an appendix, that tells the assessor exactly which artifact to examine for each objective. This is not the Customer Responsibility Matrix (the CRM is about who owns what; the evidence matrix is about where the evidence lives).
The evidence matrix has at minimum five columns:
A sample row for AC.L2-3.1.1[a]:
Every row is specific enough that the assessor reading it cold can find the artifact, dated within twelve months, and confirm the implementation statement is true. That is the bar.
How DIBFI handles this
DIBFI builds the SSP at the objective level by default and produces the evidence matrix as a live artifact — every objective tied to its evidence, dated, exportable in C3PAO-acceptable formats. No spreadsheet drift between SSP and evidence locker.
What else the SSP must include (per the rule and the guide)
Beyond the implementation statements, the SSP must document:
- System boundaries. What is in scope, what is out of scope, the rationale for each per the Scoping Guide – Level 2.
- System environments of operation. Cloud (which cloud – GCC High, AWS GovCloud, etc.), on-prem, hybrid, the specific tenants and their FedRAMP authorization status.
- External Service Provider relationships. Per 32 CFR: the use of the ESP, the relationship to the OSA, the services provided, and a reference to the ESP’s service description and Customer Responsibility Matrix. MSPs and CSPs both fall under this.
- Network diagram. Required at the pre-assessment to show the CMMC Assessment Scope. Cross-references back to the asset inventory.
- Data flows. How CUI enters the environment, where it lives, who touches it, where it leaves. This drives the scoping decision.
- Access control architecture. Identity provider, MFA enforcement, conditional access policies, privileged access workstation discipline.
- Cryptographic implementation. Specific FIPS-validated modules in use, with CMVP certificate references for SC.L2-3.13.11.
- Incident response plan. Cross-referenced with IR.L2-3.6.1 through 3.6.3 implementations.
- POA&M reference. If you have open POA&M items at assessment, the SSP references them and the closure plan.
How long is a defensible SSP?
For a small contractor with a contained CUI scope, the SSP is often over 75. The bulk is the objective-level implementation statements. There’s no magical number as to how long your SSP should be, but generally, anything under 30 pages is almost certainly under-documented. Anything over 250 pages for a small contractor is usually padding that obscures the implementation rather than describing it. There is a sweet spot!
Common SSP failures
Three we see repeatedly:
Marketing language. “Robust security controls protect our environment” is a sentence that makes a board feel good and an assessor’s eyes roll back. The SSP is an evidence document, not a brochure.
Cross-reference rot. The SSP references a tool that was replaced six months ago. The implementation paragraph is correct in concept but the named system no longer exists. Update on every architectural change.
Implementation statements that describe intent, not state. “We will implement quarterly access reviews” is intent. “Quarterly access reviews are conducted by the Compliance Lead and documented in /evidence/access-reviews/” is state. The SSP should describe state.
Frequently Asked Questions
Does the SSP need to be at the objective level, or can it be at the control level? The rule (NIST SP 800-171 R2 § 3.12.4) does not strictly require objective-level documentation. The CMMC Assessment Process v2.0, however, evaluates each objective. An objective-level SSP makes the assessor’s Examine work straightforward. A control-level SSP forces interpretation and lengthens the assessment.
Is the evidence matrix required? The CMMC rule does not require a separate evidence matrix by name, but the Pre-Assessment Form and CAP Phase 1 effectively require you to identify evidence per objective. A standalone evidence matrix is the cleanest way to satisfy that — and the easiest artifact for the assessor to walk during Phase 2 Examine activities.
How often does the SSP need to be updated? Per NIST SP 800-171 R2 § 3.12.4: “periodically.” In practice, annual review is the floor, with updates on any significant change to the environment per the Scoping Guide.
Who signs the SSP? The senior official designated for CMMC affirmation per 32 CFR § 170.22 is typically the signatory. This is also the official who attests to the annual affirmation under federal contracting rules.
Does the C3PAO keep a copy of the SSP? No. Per the Scoping Guide and CAP v2.0, the C3PAO reviews the SSP during Phase 1 and during Phase 2 Examine activities, but does not retain a copy. The SSP stays under your control.
Closing thought
Looks like the contractors whose SSPs survive review are the ones who treated the document as a 320-objective contract with the assessor, not as a security narrative. Every objective named, every implementation specified, every artifact pointed to. The SSP that reads like a brochure fails. The SSP that reads like a deposition holds up. So when you next open your draft, can you find the implementation statement for AC.L2-3.1.1[a] in under sixty seconds — and the evidence that proves it?
A³ Vallum builds objective-level SSPs and evidence matrices for defense contractors preparing for CMMC Level 2 assessment. If your draft is at the control level and you need a CCA’s read on what to break out, reach out.
About DIBFI
DIBFI is a guided CMMC readiness platform that takes contractors from scoping through certification on a phased, gated journey — real-time guidance, all 320+ Level 2 objectives tracked, an interactive SSP Builder, and “Ask an Assessor” when you need a CCA’s read on a specific control.
Sources
- NIST SP 800-171 Revision 2 § 3.12.4 — System Security Plan requirement
- NIST SP 800-171A — assessment objectives (~320 lettered objectives)
- 32 CFR Part 170 — particularly § 170.19(c)(2) (ESP documentation in SSP) and § 170.22 (affirmation)
- CMMC Assessment Process (CAP) v2.0, December 2024, The Cyber AB — Phase 1 (Pre-Assessment) and Phase 2 (Examine)
- CMMC Assessment Scope – Level 2, v2.13 (September 2024), DoD CIO (DoD-CIO-00006)
- CMMC Assessment Guide – Level 2, v2.13 (September 2024), DoD CIO (DoD-CIO-00003)
- DFARS clause 252.204-7012
