System Security Plan (SSP)

A System Security Plan is the document that describes how an organization implements security controls to protect federal information. For defense contractors, the SSP is the primary document a CMMC or DIBCAC assessor reads. It maps each of the 110 NIST SP 800-171 requirements to your specific implementation. If your SSP is unclear, vague, or out of date, the assessment will be rough. If it's accurate and well-organized, the assessment goes much faster.

glossary
What an SSP Contains

What an SSP Contains

System description: what the system does, who uses it, what data flows through it.
System boundary: what is in scope and what is not. This is the CMMC Assessment Boundary for Level 2.
Architecture and data flow diagrams: accurate pictures of networks, authentication paths, and external connections.
System inventory: hardware, software, services, and cloud tenants in scope.
Control implementation: for each NIST SP 800-171 requirement, how you implement it (or plan to).
Responsibility assignment: who owns each control.
Related documents: POA&M, policies, incident response plan, contingency plan, configuration management plan.

What Assessors Look For

The SSP tells the assessor what to expect. If your SSP says MFA is enforced for remote access via Azure AD Conditional Access, the assessor will test that. If your SSP says 'we use MFA' without specifics, the assessor will have questions and you will spend time answering them. Specificity in the SSP reduces assessment friction.

Writing Controls That Pass Assessment

For each NIST 800-171 requirement, describe three things: the policy (what your organization requires), the procedure (how it's implemented), and the evidence (where an assessor can see it working). 'Audit logs are reviewed weekly by the security team' is a policy statement. 'Audit logs from Azure Sentinel and CrowdStrike Falcon are reviewed every Tuesday by the SOC lead, with review summaries in ServiceNow ticket CTRL-0032' is implementation. The latter is what an assessor wants to see.

Keeping the SSP Current

The SSP is not a write-once document. Update it when you add or remove systems from scope, change cloud providers or major infrastructure, modify network architecture, introduce new security tools, or have staff turnover in control ownership roles. At minimum, review the full SSP annually. An outdated SSP causes more assessment findings than almost anything else.