Writing a System Security Plan That Survives Assessment

Every assessment of an environment handling Controlled Unclassified Information (CUI) starts in the same place: the System Security Plan (SSP). Requirement 3.12.4 of NIST SP 800-171 requires organizations to develop, document and periodically update a plan that describes the system boundary, the environment of operation, how each security requirement is implemented, and how the system connects to other systems.

In practice, the SSP is much more than a checkbox. It is the map an assessor uses to plan interviews, pick samples and decide where to test. A clear, accurate SSP makes an assessment efficient. A vague one makes it long, uncomfortable and expensive.

What assessors do with your SSP

Assessors treat each statement in an SSP as a claim to be verified. If your SSP says "multifactor authentication is enforced for all remote access through the corporate VPN," the assessor will ask to see the VPN configuration, the identity provider policy, and a user signing in. If the SSP says "access is controlled according to policy," the assessor has nothing specific to test, and will dig until they understand what actually happens.

The lesson: specific statements are easier to defend than general ones.

The anatomy of a strong SSP

1. System identification and boundary

State what the system is, what mission or business function it supports, and who owns it. Then draw the boundary: which networks, enclaves, cloud tenants and facilities are in scope. Include a network diagram showing where CUI is processed, stored and transmitted, and the connections that cross the boundary.

2. Asset inventory and categorization

List the in-scope assets and categorize them. Under CMMC Level 2 scoping, that means CUI assets, security protection assets, contractor risk managed assets and specialized assets. The inventory in the SSP should match what an assessor can find on the network.

3. Data flows

Describe how CUI enters, moves within and leaves the environment: email, file transfer, collaboration platforms, removable media, printing. Data flows explain why controls exist where they do.

4. Roles and responsibilities

Name the positions responsible for system ownership, administration, security monitoring, incident response and approvals. Assessors will want to interview these people.

5. Requirement-by-requirement implementation

This is the heart of the SSP. For each of the 110 requirements, describe:

• How it is implemented, naming the technology, setting or process
• Where it applies (which systems or components)
• Who operates or reviews it
• What evidence demonstrates it, such as a policy section, a configuration export or a review log

A good implementation statement for account review might read: "Access for all CUI enclave accounts is reviewed quarterly by the system owner using the identity provider's access report. Review results and removals are recorded in the IT ticketing system under the category Access Review."

6. Inherited and shared controls

If a cloud provider, managed service provider or parent organization implements part of a requirement, say so, name the provider, and reference the documentation that shows their responsibility, such as a customer responsibility matrix. Assessors will check that you have covered your share.

7. Interconnections and external services

List systems and services that connect to the environment, the purpose of each connection, and how it is protected.

8. Open gaps

Requirements that are not fully met should say so, and reference the Plan of Action and Milestones (POA&M) item that tracks the fix. Honesty here builds credibility; an assessor who finds an undisclosed gap will question everything else.

Common SSP mistakes

• Copying policy language. Policy says what should happen; the SSP must say how it happens in this system.
• Describing the future. "We will implement" is a POA&M statement, not an implementation statement.
• Inconsistent inventories. The SSP, the asset inventory and the network diagram should tell the same story.
• Missing the people. Controls that depend on reviews or approvals need a named role and a record.
• Forgetting the boundary edges. Remote users, cloud services and managed service providers are frequently omitted.
• Letting it go stale. An SSP last updated two years ago rarely survives contact with the current environment.

Keeping the SSP true

The only sustainable way to maintain an SSP is to connect it to change management. When a change request touches the boundary, a security tool, an identity system or a data flow, include "update the SSP" in the change's completion criteria. Review the whole document at least annually, and whenever the environment changes significantly.

Store evidence references alongside the SSP so they can be refreshed as part of the same review. Many organizations keep an evidence index with a folder for each requirement.

A quick self-test

Pick three requirements at random and ask the person responsible to show you, live, what the SSP describes. If they can, your SSP is doing its job. If the demonstration and the document disagree, fix one or the other before an assessor finds the difference.

Before and after: implementation statements

The difference between a weak and a strong SSP shows most clearly in individual statements.

Requirement 3.1.1, limit system access to authorized users:

• Weak: "Access is limited to authorized users in accordance with company policy."
• Strong: "All users of the CUI enclave authenticate through the enclave identity provider. Accounts are created only after a ticketed request approved by the program manager and the IT manager, and are provisioned into role-based groups that grant access to specific file libraries. Access is reviewed quarterly by the system owner (evidence: quarterly review tickets)."

Requirement 3.3.1, create and retain audit logs:

• Weak: "Audit logging is enabled on all systems."
• Strong: "Windows security, identity provider sign-in and file access logs from all enclave systems forward to the enclave log platform, where they are retained for one year. Logging configuration is enforced by Group Policy (evidence: GPO export, log platform source list)."

The strong versions tell an assessor exactly what to examine, whom to interview and what to test.

Frequently asked questions

How long should an SSP be? Long enough to describe how every requirement is implemented, and no longer. Clarity matters more than length; a concise, specific SSP is easier to assess and maintain.

Can we use a template? Templates help with structure, but the content must describe your environment. Assessors quickly recognize generic language.

Who should write it? The people who know the system, supported by someone who understands the requirements. An SSP written only by a compliance specialist, without the administrators, tends to describe an idealized system.

How CDT can help

CDT writes and remediates System Security Plans as part of our CMMC and NIST SP 800-171 readiness and RMF and ATO engagements. We build the SSP from the environment itself, so every statement can be demonstrated.

Sources

• NIST SP 800-171 Rev. 2, requirement 3.12.4
• NIST SP 800-18 Rev. 1, Guide for Developing Security Plans for Federal Information Systems