To begin building your CMMC SSP template, you first need to determine what compliance tier your organization must meet, based on the type of data you handle. Level 1 compliance applies to organizations processing federal contract information (FCI). This level requires an annual self-assessment and a formal affirmation that the organization has implemented 17 basic security practices. 

Level 2 is the standard for the vast majority of the defense industrial base (DIB), as it applies to any contractor that handles controlled unclassified information (CUI). This level aligns with the 110 security requirements of NIST SP 800-171. Level 2 SSPs are significantly more detailed, as they are the basis for a triennial assessment conducted by a CMMC third-party assessment organization (C3PAO). (In certain non-prioritized cases, a rigorous self-assessment is permitted.)

Level 3 is reserved for the most sensitive programs. In addition to the 110 requirements of Level 2, contractors must implement 24 selected requirements from NIST SP 800-172. These assessments are conducted directly by the Defense Industrial Base Cybersecurity Assessment Center (DIBCAC).

System boundaries and in-scope assets

The most critical step in developing an SSP for CMMC is defining the scope of the assessment. Inaccurately defined boundaries can lead to audit failure and significant cost overruns. To prevent this, categorize all assets based on their relationship with CUI.

• CUI assets: Systems, devices, and applications that store, process, or transmit CUI (e.g., servers hosting project data, employee laptops that access CUI repositories). 

• Security protection assets: Assets that provide security functions to the CUI environment, even if they do not hold CUI themselves (e.g., firewalls, security information and event management [SIEM] systems).

• Specialized assets and contractor risk managed assets (CRMA): Depending on the environment, organizations may also need to identify specialized assets (e.g., OT, IoT, test equipment) and CRMA, which are treated differently during assessment but must still be documented.

• Out-of-scope assets: Systems that are logically or physically separated from the CUI environment and have no interaction with sensitive data (e.g., HR payroll, marketing websites).

Documenting control implementation

The core of an SSP is the detailed description of how each of the 110 NIST SP 800-171 requirements is satisfied. This is where many organizations stumble, providing generic statements that don’t meet assessors’ "testable" standard. A comprehensive description answers the “reporter’s questions:” who, what, when, and how (where is implied).

• Who: The specific role or party responsible for the action.

• What: The specific security action or behavior being performed.

• When: The frequency or the trigger for the action.

• How: The specific tools, configurations, or technologies used.

Each control implementation description must be mapped to the 320 assessment objectives outlined in the companion document NIST SP 800-171A. The best CMMC SSP examples explicitly tie together how the tools, policies, and processes support controls, demonstrating a coherent security strategy.

Assessors don’t just take your SSP at face value—they use the IET (interview, examine, test) methodology to verify implementation. Any gaps between “paper security” and real-world behavior can raise red flags. Other common flaws include generic language, outdated information, unvetted inherited controls, and vague parameters. Discrepancies like these signal to assessors that an organization’s security program is "immature" and that the organization may not be taking its responsibilities seriously.

A CMMC system security plan serves as the assessor’s roadmap through your organization’s security environment. A transparent, thorough, and reliable guide earns trust and streamlines your path to certification.

1. Use plain, clear language

The SSP audience includes both technical staff and non-technical auditors. Descriptions should be clear and avoid unnecessary jargon. A good test is the "Reasonable Person" standard: could a person unfamiliar with your environment read the SSP and gain a fundamental understanding of how you protect CUI?

2. Update regularly and after significant changes

Review your SSP at least every year or whenever there is a "significant change" to the system or tooling. This might include moving to a new cloud platform, changing security vendors, or acquiring a new business unit that handles CUI.

3. Avoid generic or "idealized" language

Don’t simply copy descriptions from NIST 800-171—your SSP must demonstrate how your organization specifically meets requirements. It must also reflect your current environment, not what you plan to achieve in six months. Documenting an "ideal" state that doesn't exist yet can lead to severe legal penalties.   

4. Direct mapping to evidence

Every control implementation description should include a reference to the specific artifact that proves it. For example: "Account lockouts are enforced via Active Directory (See Screenshot: AD_Policy_Lockout.png) and monitored via Huntress SIEM (See Artifact: Monthly_Log_Review_Oct2025.pdf)". This makes the assessor's job easier and builds immediate credibility.

5. Collaborate across departments

Cybersecurity is not just an IT issue; it’s a cultural and operational requirement. Building a successful SSP requires input from IT, HR (for personnel security and onboarding), Legal (for contract review), and Operations (for physical security and CUI handling). 

An SSP is not a one-and-done. It’s a living document that evolves with the threat landscape and your organization's tech stack.

Huntress Managed SIEM centralizes logs across endpoints and identities, making it easier to document audit trails, monitoring practices, and incident detection workflows referenced in an SSP. 

Organizations working with Huntress are provided with a System Security Plan (SSP) Supplemental as part of Huntress' CMMC documentation package and “Evidence Collection Kit.” It is designed to help organizations and MSPs prepare for CMMC Level 2 by:

• Providing assessor‑ready language about Huntress for your SSP

• Documenting how Huntress maps to NIST SP 800‑171 / CMMC controls

• Reducing prep time and keeping documentation current

• Making C3PAO assessments smoother

The Huntress SSP Supplemental tells your C3PAO, “here’s exactly how Huntress works in our environment, which controls it supports, and why it remains a Security Protection Asset.” Focus your time on the rest of your CMMC program instead of writing and defending vendor language.

Explore how Huntress can help your organization stay secure and CMMC compliant.