Your SSP Is Not a Policy Binder. It Is a Map an Assessor Has to Navigate.

This is not a theoretical failure mode. Cybersecurity Dive reported this week on survey data showing only about one third of defense contractors believe they are at least 80 percent prepared for a CMMC assessment, and roughly 1 percent consider themselves fully ready. Separately, practitioner commentary published this week made the same observation from the assessor side: contractors keep treating an assessment as a volume exercise, producing policies and screenshots, rather than a demonstration exercise. The SSP is exactly where that gap becomes visible.

What Does CMMC Actually Require the SSP to Contain?

The requirement is CA.L2-3.12.4, drawn from NIST SP 800-171. It obligates you to develop, document and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and relationships with or connections to other systems.

Read that list again, because it is a checklist and most SSPs only satisfy the third item, and often only partially:

1. System boundaries. What is in scope and what is not, named specifically.
2. Environment of operation. Where it runs. On premises, cloud, hybrid, remote endpoints, contractor laptops, a mix.
3. How security requirements are implemented. Not what the policy says should happen. What the system does.
4. Relationships and connections to other systems. External service providers, VPN tunnels, managed service provider access, partner connections, enclave to corporate network links.

CMMC Level 1 does not carry an SSP requirement. Level 1 is the 15 requirements derived from FAR 52.204-21, for example AC.L1-b.1.i on limiting system access to authorized users, and it is self assessed with an annual affirmation. That said, if you are a Level 1 organization who expects CUI to arrive in a future contract, writing a lightweight SSP now is cheap insurance. You will need it eventually and the boundary work is the hard part.

Why Do Most SSPs Fail on the Assessor's First Read?

Because they are written from the control list down instead of from the environment up. The author opens the 110 requirements in a spreadsheet, writes a sentence next to each one, and produces a document that is internally coherent and externally unverifiable.

The four recurring failures:

It restates the control instead of describing the implementation. “The organization limits system access to authorized users” is a restatement of AC.L2-3.1.1. It contains zero information. An assessor cannot examine, interview or test against it.

It describes an intended state, not the current one. The SSP says multifactor authentication is enforced for all privileged accounts under IA.L2-3.5.3. The assessor pulls the conditional access policy and finds three service accounts excluded. That is now a finding and a credibility problem for every other statement in the document.

It has no named systems. “Endpoint protection is deployed on all workstations” tells the assessor nothing. Which product. Which console. Which policy. Which machines are enrolled and how do you prove the count matches your asset inventory.

The boundary is asserted rather than drawn. The SSP claims a CUI enclave exists. There is no diagram, no VLAN list, no data flow, no statement about how CUI is prevented from leaving the enclave. The assessor now has to assume the boundary is the whole company, which is the most expensive possible outcome.

How Do You Describe Scope So an Assessor Can Verify It?

Scope is the single highest leverage section in the document, and it is the one most often written last and fastest. Invert that.

Under the CMMC Level 2 scoping guidance in 32 CFR Part 170, assets are categorized as CUI Assets, Security Protection Assets, Contractor Risk Managed Assets, Specialized Assets and Out of Scope Assets. Your SSP needs to make that categorization explicit and defensible. Note that Contractor Risk Managed Assets are documented but not assessed against the full requirement set, unless the assessor concludes your risk based decisions are insufficient, at which point they can be assessed. That conditional is worth understanding before you lean on the category.

Practically, the scope section should contain:

• An asset inventory that maps every item to one of the categories above, with a stated rationale for the categorization.
• A network diagram showing the CUI boundary as a drawn line, with the devices and segments on each side of it.
• A data flow diagram tracing CUI from the point it enters your environment (email, contract portal, customer SFTP, physical media) through processing, storage and transmission, to disposal under MP.L2-3.8.3.
• A list of external service providers touching CUI or providing security protection, with what each one does and how responsibility is split.

If someone with no context about your company can read that section and correctly predict which laptop in your office is in scope, you have written it properly.

What Does a Usable Control Implementation Statement Look Like?

Write to the assessment objectives, not to the requirement text. NIST SP 800-171A decomposes each requirement into discrete objectives, and an assessor evaluates every one of them using examine, interview and test methods. Every objective has to be met for the requirement to be met. There is no partial credit at the requirement level.

Take AC.L2-3.1.2, limiting system access to the types of transactions and functions authorized users are permitted to execute. A weak statement says access is role based. A usable statement names the role structure, the directory or platform enforcing it, the specific groups mapped to CUI resources, who approves membership changes, where those approvals are recorded and how often membership is reviewed.

A workable structure for each of the 110 entries:

• What is implemented. The specific technical or procedural mechanism.
• Where. The named systems, platforms or locations it applies to, tied back to your inventory.
• Who. The role responsible for operating and maintaining it.
• How it is evidenced. The artifact an assessor can examine, and the configuration a technical person can test.
• Any exception. State it here rather than letting the assessor discover it.

That last bullet is the one people fight. State the exception. An assessor who finds an undocumented gap now discounts your entire document. An assessor who reads a documented gap that is already tracked treats you as an organization that knows its own environment.

How Should the SSP Handle POA&M Items and Shared Responsibility?

Openly, and with a linkage to CA.L2-3.12.2, which requires plans of action to correct deficiencies and reduce or eliminate vulnerabilities. Your SSP and your POA&M should reference each other by requirement ID. If AU.L2-3.3.1 is partially implemented, the SSP entry should say so and point directly at the POA&M line item.

Two things to understand before you plan around a POA&M. Under the DoD Assessment Methodology, requirements carry weights of 1, 3 or 5 points against a base of 110. And under 32 CFR 170.21, conditional Level 2 status requires a minimum score of 88. A short named list of requirements is excluded from POA&M eligibility outright, including the SSP requirement itself under CA.L2-3.12.4 and several access control and physical security requirements. Separately, POA&M items are capped at 1-point-value requirements, so any 3 or 5 point requirement is off the table by that rule alone, which is what actually rules out multifactor authentication under IA.L2-3.5.3 and FIPS validated cryptography under SC.L2-3.13.11, both 5-point requirements. FIPS crypto has one narrow exception worth knowing: if CUI encryption is already in place and the gap is only that the module is not yet FIPS validated, that specific shortfall can go on a POA&M at reduced point value. POA&M items must be closed within 180 days. So a POA&M is a narrow instrument, not a general purpose deferral.

Shared responsibility deserves its own section. If a managed service provider or a cloud service provider implements part of a requirement, the SSP must say which part is theirs, which part is yours, and what you hold to demonstrate their side. A customer responsibility matrix from the provider is a supporting artifact, not a substitute for your own statement of how you consume and verify that service.

How Do You Keep the SSP From Going Stale the Day After You Sign It?

CA.L2-3.12.4 says periodically update. It does not define a cadence, so you define one and then meet it. Annual review is the common floor. What matters more is triggering an update on change: new CUI contract, network re-architecture, new external service provider, an MSP transition, an office move, a significant configuration baseline change under CM.L2-3.4.1.

Build the review into something that already happens. Tie SSP review to your annual affirmation cycle, to your asset inventory reconciliation or to your change management process. An SSP that is updated only when an assessment is scheduled will always be a reconstruction exercise rather than a record.

One note on timing. The CMMC phase in is being implemented through the acquisition rule and the phase structure has been subject to change, with Phase 2 currently suspended. Treat any specific certification date you hear as unsettled until it appears in a contract clause you are actually bidding against. That is an argument for having the SSP ready and current, not for waiting.

If you have not settled the base categories yet, start with our guide to scoping CUI assets versus Security Protection Assets, and our breakdown of the 180-day POA&M deadline, before you build out the implementation statements above.

Frequently Asked Questions

Is a system security plan required for CMMC Level 1?

No. CMMC Level 1 covers the 15 requirements derived from FAR 52.204-21 and does not include an SSP requirement, which sits at Level 2 under CA.L2-3.12.4. Level 1 organizations perform an annual self assessment and submit an affirmation. Documenting your environment anyway is still sound practice, particularly if CUI may enter your business under a future contract.

How long should a CMMC system security plan be?

There is no required length and page count is not a quality signal. The document must cover system boundaries, environment of operation, implementation of each requirement, and connections to other systems, per CA.L2-3.12.4. A tightly scoped enclave can be documented in far fewer pages than a sprawling corporate network, which is itself a strong argument for enclaving.

Can an assessor reject an SSP outright?

An assessor does not grade the SSP as a standalone artifact, but an SSP that fails to define scope or describe implementations makes the assessment unworkable and can prevent it from proceeding productively. In practice, the SSP determines what gets assessed and how efficiently. A vague boundary tends to expand scope rather than reduce it.

What is the difference between an SSP and a policy?

A policy states organizational intent and requirements. An SSP describes how those requirements are actually implemented in a specific system, in a specific environment, at a specific point in time. Assessors examine both, but only the SSP tells them where to look and what to test.

Should the SSP include POA&M items?

Yes. Requirements that are not fully implemented should be stated as such in the SSP and cross referenced to the corresponding item under CA.L2-3.12.2. Be aware that not every requirement is POA&M eligible: a short named list of requirements, including the SSP requirement itself and several access control and physical security requirements, is excluded outright under 32 CFR 170.21, and separately, POA&M items are capped at 1-point-value requirements, which is what actually excludes higher weighted requirements such as multifactor authentication and FIPS validated cryptography. FIPS crypto has a narrow partial-implementation carve-out rather than a full exclusion. A minimum assessment score also applies for conditional status, and POA&M items carry a 180 day closeout.

Who should write the SSP?

Someone with direct knowledge of the environment, working from the network outward, not a template filled in from the control list. The people who administer the identity platform, the network and the endpoints have to contribute the implementation detail. Consultants can structure and edit the document, but implementation statements that no one internally can defend under interview will not survive an assessment.

Sources

• Cybersecurity Dive, “Defense contractors still struggling with basic CMMC readiness” (cybersecuritydive.com)
• BTCPA, “What Defense Contractors Most Commonly Get Wrong in CMMC Assessments” (btcpa.net)
• NIST SP 800-171 Rev. 2, requirement 3.12.4 (system security plan) and 3.12.2 (plans of action) (csrc.nist.gov)
• NIST SP 800-171A, assessment objectives and the examine, interview and test methods (csrc.nist.gov)
• 32 CFR Part 170, CMMC Program final rule, including 170.19 (scoping) and 170.21 (assessment scoring and POA&M conditions) (ecfr.gov)
• DoD Assessment Methodology, NIST SP 800-171, scoring construct of 110 points with 1, 3 and 5 point weights (dodcio.defense.gov)
• FAR 52.204-21, basic safeguarding of covered contractor information systems (acquisition.gov)