Why Most SSPs Fail CMMC Assessments
A strong System Security Plan (SSP) is critical to CMMC Level 2 compliance. It documents how your organization implements each of the 110 controls in NIST SP 800-171 and helps assessors understand how you protect Controlled Unclassified Information (CUI).
The problem? Most SSPs fall short.
Many defense contractors treat the SSP as a checkbox. They fill in a template, reuse policy language, or hand it off to someone unfamiliar with their actual systems. But assessors don’t just check for the presence of an SSP. They evaluate its clarity, completeness, and how well it reflects operational reality.
Weak SSPs create assessment risk. They delay assessments, result in corrective actions, or lead to outright failures.
At MAD Security, we’ve reviewed dozens of SSPs and seen the same mistakes made repeatedly by otherwise capable teams. This post outlines the 10 most common SSP mistakes and offers practical guidance to help you avoid them. Whether you are preparing for your first CMMC assessment or strengthening existing documentation, this checklist will help you build a defensible, assessment-ready SSP.
Copying and Pasting Control Language
One of the most common ways SSPs fail is when organizations copy and paste control text directly from NIST SP 800-171 or a generic policy template. While this may seem like a shortcut, it creates serious problems during a CMMC assessment.
Assessors expect to see how your organization implements each control, not a restatement of the control requirement. If the text in your SSP could describe any company, that’s a red flag.
Here’s what this mistake often looks like:
Weak example: "System access is controlled based on least privilege principles."
|
|
This doesn’t explain who manages access, what process is followed, how it’s documented, or how often it’s reviewed. It sounds compliant but provides no verifiable detail. |
A stronger approach is to describe exactly how the control is implemented in your environment:
Stronger example:
|
"Access to systems is provisioned by the IT manager through the access request process in ServiceNow. Requests must include manager approval and are reviewed weekly by the security team. Logs are retained for 90 days and reviewed quarterly." |
This type of response shows the control is implemented, monitored, and mapped to real evidence.
What to do instead:
| Use plain language. Focus on who does what, when, how, and with what tools or processes. Write for clarity, not formality. |
Ignoring NIST SP 800-171A Assessment Objectives
Even when an SSP includes control descriptions, many fail to map those controls to the assessment objectives defined in NIST SP 800-171A. This is one of the most overlooked requirements in CMMC documentation. Each of the 110 controls in NIST SP 800-171 is broken down into one or more assessment objectives in NIST SP 800-171A.
These objectives define exactly what assessors will test. If your SSP doesn't address each objective, it creates gaps that can delay or derail your assessment.
For example, a single control might require:
| A documented policy | |
| A defined process | |
| A technical implementation | |
| Evidence of ongoing monitoring |
If your SSP only addresses one of these, it fails to meet the full objective.
What to do instead:| Break each control down into its assessment objectives and write a response to each one. If a control has three objectives, your SSP should have three specific answers. This structure helps assessors understand your implementation and gives you a checklist to validate your documentation. | |
| MAD Security uses this objective-based approach in all client SSPs. It removes guesswork, ensures full coverage, and aligns directly with how CMMC assessments are conducted. |
Leaving Shared Responsibilities Undefined
Many organizations rely on third-party vendors, managed service providers, or cloud platforms to help implement security controls. That is common and expected. The problem arises when the SSP does not clearly explain who is responsible for what.
CMMC assessors will not assume your MSSP, or cloud provider is handling a control unless it is documented. If your SSP says, “Handled by our MSSP,” but does not explain what actions they perform and what your internal team is responsible for, it will likely result in a finding.
This is especially important for hybrid controls where responsibilities are shared. For example, MAD Security might provide 24/7 log monitoring, but your internal team still handles onboarding users and configuring access control.
What to do instead: Use a Shared Responsibility Matrix to define each party’s role. For each hybrid or inherited control, describe:
| What your team does |
|
| What your provider does |
|
| How is that division validated or monitored |
This clarity helps the assessor, strengthens accountability, and ensures your SSP reflects your actual security operations.
Failing to Define the System Boundary
One of the first things an assessor will look for in your SSP is a clearly defined system boundary. This tells them what is in scope for CUI protection, which systems and users are covered, and where that boundary ends.
Too many SSPs skip this entirely or describe it in vague terms like “corporate network” or “production environment.” That’s not enough. Without a defined boundary, assessors cannot determine which assets, controls, or processes apply to the CMMC assessment.
This leads to confusion, wasted time, and documentation revisions during or after the assessment.
What to do instead: Your SSP should include:
| A clear description of the system boundary | |
| A list of in-scope components (hardware, software, users, cloud services) | |
| One or more diagrams that show network flow and how CUI travels |
Even a simple visual showing how your organization segments its environment helps establish scope and supports many of the access control, system monitoring, and assessment requirements in NIST SP 800-171.
MAD Security provides boundary templates and architecture review as part of our SSP support process to ensure no gaps exist before you face an assessor.
Using Outdated or Inconsistent Information
An SSP that includes outdated information is a red flag during any CMMC assessment. Assessors frequently encounter mismatched tool names, references to old policies, and control descriptions that no longer reflect how the organization operates.
This inconsistency signals a larger issue. If your documentation doesn’t match your environment, it’s unclear whether your controls are being implemented correctly. Even if your technical team is doing the right work, a stale or inaccurate SSP can cause delays or findings during your assessment.
Common signs of outdated SSPs include:
| Policy version numbers that don’t match what’s in effect |
|
| Diagrams that omit new systems or cloud components | |
| Control descriptions that refer to retired software |
What to do instead: Your SSP should be treated as a living document. Update it whenever:
| There are major system changes |
|
| Policies are revised | |
| Tools or vendors are replaced | |
| Roles or responsibilities shift |
Include a change log in the SSP to document when updates occur and who approved them. This shows assessors that your documentation is maintained and aligned with real-world operations.
Missing Evidence References
Even when an SSP includes accurate control descriptions, many fail to show how those statements are supported by evidence. If an assessor reads that a process exists but cannot verify it through logs, documents, or system output, the implementation may be considered unproven. Your SSP should do more than describe what you do. It should point directly to the artifacts that prove it.
For example, saying “user access is reviewed quarterly” is not enough. An assessor will expect to see:
| Review logs or tickets | |
| A checklist showing the reviewer’s name and date | |
| Screenshots or audit logs that confirm the review took place |
What to do instead: Include clear references in each control implementation to the source of evidence. This can include:
| Policy or procedure titles with version and date |
|
| Locations of logs or screenshots | |
| Ticketing system names and ticket IDs | |
| Report names and storage locations |
By linking each control to the right evidence, you eliminate guesswork and show that your SSP reflects real operational practices. MAD Security helps clients organize this evidence and map it directly to each control using our documentation framework.
Misusing “Not Applicable” Without Formal Justification
Some organizations attempt to mark NIST SP 800-171 controls as “Not Applicable” in their System Security Plan to simplify compliance. While there are rare cases where this may be appropriate, you cannot make that determination independently.
Under DFARS 252.204-7012, a control may only be marked “Not Applicable” if your organization receives written approval from the DoD CIO. Without this official authorization, assessors will treat the control as required and expect a full implementation or approved alternative.
Common mistakes to avoid:
| Marking controls as “N/A” without submitting a request to DoD CIO | |
| Providing no explanation or documentation | |
| Leaving the control response section blank |
What to do instead: If a control does not apply to your environment:
| Submit a formal exception request to the DoD CIO |
|
| Retain and reference the written approval in your SSP | |
| Include the rationale for the request and the scope it applies to |
|
| If no approval is granted, treat the control as required or document a compensating control |
Example of valid documentation: “This control is not applicable per written approval from the DoD CIO dated June 14, 2024. The decision is based on the absence of mobile device access to CUI in our environment.”
Controls cannot be marked “Not Applicable” without formal approval. Treat this process with the same rigor as you would any other compliance requirement.
Incomplete Status Tags for Each Control
CMMC assessments require that every control in your SSP has a status label indicating whether it is implemented, planned, hybrid, or inherited. Leaving this out or using it inconsistently creates confusion and undermines the credibility of your documentation.
When status tags are missing or inaccurate, assessors cannot determine which controls are in place today, which are pending, and which are covered by third parties. This leads to findings and follow-up requests that delay your assessment.
Common issues include:
| No status indicated at all |
|
| Using custom or undefined status terms | |
| Marking controls as “implemented” without supporting detail |
What to do instead: For every control in your SSP, include a status label and define it clearly. Use only the recommended options:
| Implemented: Fully in place and operating |
|
| Planned: Not yet in place, with an associated POA&M | |
| Hybrid: Shared responsibility between your organization and a provider | |
| Inherited: Fully provided by a third party (e.g., cloud provider) |
If a control is hybrid or inherited, it also specifies who is responsible for what is required. This builds trust with assessors and shows that you’ve done the work to document real accountability.
No Update or Change History
An SSP that looks static or untouched raises questions for assessors. If your plan was last updated two years ago or if there’s no indication of when it was reviewed or modified, it will likely be flagged during your CMMC assessment.
Assessors want to know if your SSP reflects the current state of your environment. Without a change of log or documented review of history, they have no way to tell if what they’re reading is accurate.
This problem is common in organizations that treat the SSP as a one-time deliverable. But compliance is not a project. It’s a continuous process.
What to do instead: Include a change log in your SSP. For each update, note:
| The date the change was made | |
| A brief description of what was updated | |
| The name or role of the person who reviewed or approved the change |
This not only satisfies the assessor's expectations but also helps your internal teams track how your documentation evolves alongside your environment.
No External Review Before Assessment
Even organizations with a complete and well-written SSP often fail to have it externally reviewed before a formal CMMC assessment. This is a missed opportunity to catch errors, close documentation gaps, and ensure the SSP aligns with how your security controls are implemented.
Without an outside perspective, it’s easy to overlook assumptions, reuse outdated language, or misrepresent shared responsibilities. In some cases, internal teams are too close to the environment to see where the documentation may fall short.
CMMC assessments are high stakes. One preventable documentation issue can lead to a delay in your contract eligibility or trigger corrective action.
What to do instead: Have your SSP reviewed by:
| A compliance professional with NIST SP 800-171 and CMMC expertise | |
| Your MSSP or documentation partner | |
| An independent readiness consultant |
At MAD Security, we perform SSP reviews as part of our compliance readiness services. We evaluate the structure, control responses, shared responsibilities, and evidence mapping against both NIST 800-171A and CMMC Level 2 expectations.
A third-party review can give you the confidence that your SSP is not only complete but also dependable.
How to Fix These Issues and Strengthen Your SSP
The good news is that most SSP problems are fixable. Whether your documentation is incomplete, inconsistent, or outdated, there are practical steps you can take to bring it in line with CMMC Level 2 expectations. Start with a self-assessment. Review your SSP against the top 10 mistakes outlined above. For each control, ask:
| Is the description specific to our organization? | |
| Does it address every assessment objective in NIST SP 800-171A? | |
| Does it point to real, current evidence? | |
| Are roles and shared responsibilities clearly defined? |
Next, build a plan to close gaps. This may include:
| Mapping each control to its assessment objectives |
|
| Updating outdated responses or status tags | |
| Organizing supporting evidence | |
| Revisiting system boundary definitions | |
| Scheduling an external review |
If your team is short on time or expertise, work with a partner that understands both the technical and compliance sides of CMMC documentation. MAD Security provides hands-on SSP development, reviews, and readiness support to help defense contractors document what they do and prove it under assessment.
Your SSP should be a reflection of your security program, not a liability during an assessment. A clear, accurate, and current SSP gives assessors confidence and sets your organization up for success.
Build an SSP That Withstands Scrutiny
A System Security Plan is more than a compliance requirement. It reflects how well your organization understands, implements, and documents its security program. A clear and accurate SSP can move your CMMC assessment forward with confidence. A vague or outdated one can bring it to a halt.
The most common SSP mistakes are avoidable. Weak control descriptions, missing roles, inconsistent updates, and poor evidence mapping are problems that can be fixed with the right structure and attention to detail.
MAD Security helps defense contractors build, review, and maintain assessment-ready SSPs that align with real operations and current requirements. We provide templates, tools, and expert guidance to help you document what you are already doing and prepare for what comes next.
Strong security deserves strong documentation. Let us help you get there.
Frequently Asked Questions (FAQS)
Do I need a System Security Plan for CMMC Level 2?
Yes. A complete and accurate SSP is required for CMMC Level 2 and DFARS 252.204-7012 compliance. You cannot pass a CMMC assessment without one. The SSP documents how your organization implements each of the 110 controls in NIST SP 800-171.
What is the difference between a policy and an SSP?
A policy describes what your organization intends to do. The SSP explains how your organization actually does it. Policies state expectations and rules. The SSP connects those rules to your systems, processes, and technical implementations.
What happens if I mark a control as “Not Applicable”?
Under DFARS 252.204-7012, you may only mark a control as “Not Applicable” if you have received written approval from the DoD Chief Information Officer (CIO). Simply writing “N/A” or providing a brief explanation is not sufficient.
If you believe a control does not apply, you must submit a formal exception request to the DoD CIO. Without this approval, assessors will expect the control to be fully implemented or addressed through a documented alternative. Unapproved “N/A” markings are a common cause of assessment findings.
Do I need to include diagrams in my SSP?
Yes. At minimum, your SSP should include a system boundary diagram that shows in-scope systems, data flow, and components involved in processing or protecting CUI. This helps assessors understand your architecture and apply controls correctly.
Can I write the SSP myself, or do I need outside help?
You can write it internally, but many organizations benefit from outside review. A third party can identify gaps, clarify shared responsibilities, and make sure your responses align with the assessor's expectations. MAD Security offers both guidance and reviews to support this.
How often should the SSP be updated?
At least once per year, or whenever there is a major change in your systems, staff, policies, or service providers. Your SSP should include a change log that tracks revisions over time.
How do I know if my SSP is ready for an audit?
Start by reviewing your SSP against the requirements in NIST SP 800-171 and the assessment objectives in NIST SP 800-171A. Confirm that each control is clearly described, assigned a status, and linked to supporting evidence. Make sure the system boundary is defined and that shared responsibilities are documented. If you are unsure, having an external expert review of your SSP can help identify issues before they become findings in a formal assessment.
Originally Published: October 28, 2025
By: MAD Security
