Crafting Your CMMC Level 2 System Security Plan: A Practical Guide

Key Takeaways

• Cover All 320 Objectives: Each of the 110 CMMC Level 2 controls contains multiple objectives – every one must be addressed in the SSP to achieve compliance.
• Align Supporting Documents: Ensure network diagrams, data-flow maps, and asset inventories are consistent with the SSP to avoid assessor red flags.
• Define Shared Responsibilities: Clearly document which security objectives are handled by your organization versus external providers (CSPs, MSPs, etc.).
• Be Specific and Detailed: Replace vague statements with concrete implementation details – describe exactly how each requirement is met.
• Involve the Whole Organization: CMMC compliance extends beyond IT; leadership, HR, facilities, and staff training all play critical roles.

Think of the System Security Plan (SSP) as a roadmap for CMMC Level 2. It’s the formal document where an organization lays out how they protect Controlled Unclassified Information (CUI). In simple terms, an SSP provides an overview of security requirements and describes in detail how an organization meets, or plans to meet, the 320 security objectives for the 110 CMMC controls. The SSP should clearly explain the organization’s entire CUI environment – system boundaries, networks architecture, and everything in between.

Cover All 320 Objectives, Not Just 110 Controls

A big trap is to think the 110 controls are all there is to a CMMC Level 2 certification. In reality, those 110 controls are comprised of 320 objectives, each of which assessors will scrutinize. If any one of the objectives of a control are not met, the entire control will be not met. Explain exactly how the organization meets each objective; for example, if a control says, “encrypt CUI at rest,” the SSP should detail the specific encryption tools, key management, and processes the organization uses for that objective. The goal is for the assessor not to have to use their imagination to fill in the gaps which will result in questions that lead one down a rabbit hole.

Don’t Forget the Diagrams and Inventories

An organization’s SSP should reference and align with all the supporting documents and diagrams that describe their in-scope environment. This means including or citing:

• Network/system diagram of their CUI boundary – i.e., visually showing all systems and devices that process, store, or transmit CUI, and how they connect.
• CUI & Security Protection Data (SPD) data-flow diagram – a diagram of how CUI and SPD move through their network and systems.
• Categorized Asset inventory – a list of every asset in scope (hardware, software, etc.) that handles CUI and the CMMC category of the asset.
• Other plans or lists, like an incident response plan, contingency plan, and so on, each cross referenced to the SSP.

Each of these documents must agree with the SSP. For example, if one’s network diagram shows three servers in the CUI enclave, their SSP must discuss the controls on those three servers, and they should be referenced in their CUI data-flow diagram and listed in the asset inventory. Mismatches between these documents will raise red flags for assessors and trigger questions during the interview phase.

Map Out Shared Responsibilities

If an organization relies on cloud or managed services (CSPs, MSPs, MSSPs, etc.), their SSP must clearly explain who does what within their environment. The cloud or service providers should provide a Shared Responsibility Matrix (SRM) or Customer Responsibility Matrix (CRM) detailing who covers each security requirement. For each objective, note whether the organization is responsible, the provider is responsible (referred to as ‘inherited’), or if it is shared. If an entire control is inherited from a provider, then each objective of that control should either refer to the CRM for that provider or contain the text from the CRM which describes how the provider meets that objective. If it says that the objective is shared or the customer’s responsibility, clearly define how the organization meets the full or shared component of the objective.

Specificity Is Key

Avoid vague statements like “we use encryption” or “we have policies” with no detail. Each control entry should include an implementation statement explaining how one’s organization meets the requirement in their own environment. For example, don’t just say “data is backed up.” Instead, describe the backup system (what it backs up, how often, how it is encrypted, where it is stored) and link it to the relevant objective(s). This pays off during the assessor interview; if the SSP is full of fluff, assessors will probe every generic statement with questions. But if it’s specific, they’ll see the organization has thought it through.

CMMC Involves Everyone, Not Just IT

Finally, remember that CMMC is an enterprise effort, not an IT-only checkmark. A great deal of the 110 controls are not purely technical controls which only IT can answer. There are requirements which involve organization level policies, training, physical security, and leadership engagement. Please see our recent article, “Cybersecurity is Everyone’s Business,” that further discusses this aspect of cybersecurity operations.

To learn more about CMMC, be sure to visit our CMMC page, and don’t hesitate to contact Elaine Nissley or Mike Murray regarding our services.

About the Author

Related Services