Establish the system description first
Identify the system’s purpose, information handled, responsible organization, technical owners, users, locations, and relevant external relationships. Align the boundary with the inventory and network diagram. Give the document an owner and a review history so a reader can identify the current version.
For Level 2 scoping, consult 32 CFR 170.19 for asset-category treatment and provider requirements. Do not assume every asset has the same documentation or assessment treatment. The SSP should explain the actual decisions and relationships in a way that can be checked against the environment.
Write implementation statements in concrete language
For each requirement, explain what happens, where it happens, who performs it, and how the organization checks that it works. Name the relevant process or system at a level appropriate for the document’s audience and sensitivity. Reference supporting procedures and evidence rather than copying everything into the SSP.
Compare the statements these two approaches produce: a generic promise that access is controlled, or an explanation of who approves access, how permissions are configured, and how departures trigger removal. The second is easier to investigate and maintain. It still needs to match the facts and address the actual requirement.
Keep gaps visible during drafting
Do not turn future work into present-tense implementation simply because a template expects an answer. Identify the deficiency in the appropriate work record, assign an owner, and describe the current state accurately. Apply any assessment-specific rules governing POA&Ms before relying on them for a result.
When a gap is closed, verify the technical change and update the SSP if the implementation description changed. The connected-record guide explains the different roles of the SSP, supporting evidence, and remediation tracking. Their consistency matters more than whether they share a matching cover page.
Maintain it through change
Review the SSP when the system, provider arrangement, boundary, or implementation changes. Use the change process to identify which sections and linked records need revision. Ask a technical owner to verify the relevant description before considering the update complete.
NIST’s publication record notes that no single SSP format or specified level of detail is prescribed there; the required information still needs to be conveyed. A readable, accurate plan with maintained references is more useful than unnecessary volume. CMMC Level 2 remains tied to the revision incorporated in its governing requirements, so do not automatically substitute a newer NIST publication without checking applicability.
Sources & further reading
Published October 24, 2026. Government and company references were checked while preparing this page. General information and practical workflow suggestions; confirm the requirements and services that apply to your organization.
