Technical Guide #5: How to Write Your System Security Plan (SSP)

By Josh Hammer

Contractors often freeze when they hear “SSP.” They assume it is a specialized compliance document that must be written in legal language. It is not. An SSP is a technical description of your environment, written for a reader who has never seen your network.

This guide shows you how to structure and write one.

Before selecting a compliance automation platform or buying another security tool, follow the right sequence: audit your environment first, build a remediation plan second, and select tools third. A tool can organize your compliance process. It cannot replace the process.

What an SSP actually is

An SSP describes how your organization implements security requirements in its own environment. It must be specific enough that a reviewer can understand what happens, where it happens, who is responsible, and what evidence supports the statement.

Think of the SSP as a guided tour of your system.

A useful SSP answers questions such as:

• What systems process, store, or transmit CUI?
• Where are those systems located?
• How does CUI enter and leave the environment?
• Which users and administrators have access?
• What technology implements each security requirement?
• Who owns the control?
• What evidence demonstrates that the control is operating?
• What remains incomplete, and where is that gap tracked?

The SSP is a required artifact under the NIST SP 800-171 and DFARS 252.204-7012 framework. NIST SP 800-171 is also the framework assessed for CMMC Level 2.

As of September 2026, CMMC Phase II third-party assessments are paused. That pause affects the timing and method of independent CMMC verification. It does not remove the underlying DFARS and NIST SP 800-171 obligations. Your SSP still needs to describe the covered contractor information system accurately.

An SSP is also not:

• A policy library.
• A collection of security marketing statements.
• A list of tools you own.
• A place to state future intentions.
• A substitute for evidence.
• A document that can remain unchanged while the environment changes.

“We will implement multifactor authentication” is not an implementation statement. It describes an intention.

“Multifactor authentication is enforced through the identity provider for all privileged accounts accessing the CUI enclave. The security administrator reviews exceptions monthly. Evidence is the current identity policy and the monthly exception report” describes an implementation.

An SSP is a living document. If it has not changed in two years, one of two things is probably true: your environment is unusually static, or your SSP is out of date.

Start with the boundary

Before writing the SSP, revisit the boundary decision from Technical Guide #4. The SSP cannot be accurate until you know what is in scope.

The boundary should identify the systems, networks, locations, users, cloud services, and external connections that process, store, or transmit CUI. It should also explain why certain systems are outside the boundary.

A boundary statement might look like this:

The CUI environment includes the engineering file share, engineering workstations, identity services, endpoint management platform, backup service, firewall, and remote-access gateway used to process and transmit CUI. The accounting network is outside the CUI boundary because it does not receive, store, or transmit CUI and is separated from the engineering network by a managed firewall.

That statement is only useful if the architecture actually works that way. The diagram, inventory, configurations, and SSP must all tell the same story.

The required SSP structure

A practical SSP can be organized into the following sections.

1. System description and boundary

Start with a plain-language description of the system.

Explain:

• What the system does.
• What business functions it supports.
• Which locations are involved.
• Which systems are in scope.
• Which systems are outside the boundary.
• How the in-scope systems connect.
• What types of data they hold.

Do not write a generic description such as “The organization operates a secure hybrid IT environment.” That sentence tells the reviewer almost nothing.

Write something concrete:

The system consists of 42 Windows workstations, two Windows servers, one cloud-based document repository, an identity provider, an endpoint detection platform, a managed firewall, and a site-to-site VPN. The engineering department uses the system to receive, modify, store, and transmit CUI associated with federal construction projects.

If you use an external service provider, include it. A cloud service that stores CUI is part of the story even if you do not own the underlying servers.

2. Data flow description

The data flow section is where many SSPs become vague. Do not simply write, “CUI is encrypted in transit and at rest.”

Describe how CUI moves.

Answer these questions:

1. Where does CUI enter the organization?
2. Who receives it?
3. Through which system or service?
4. Where is it stored?
5. Which users or applications access it?
6. How is it transferred to another party?
7. How is it deleted, archived, or returned?

For example:

CUI enters the environment through the prime contractor’s secure file-transfer portal. The project manager downloads the files to the CUI project repository using an organization-managed workstation. Engineering personnel access the repository through the identity provider and are assigned access through project-based security groups. Revised drawings are uploaded to the prime contractor’s portal through the same managed workstation. Local downloads are retained only in the approved project directory and are removed according to the records-retention procedure.

That is a data flow. It identifies the entry point, systems, users, storage location, and exit point.

Your data flow diagram must agree with your network diagram. If the data flow says CUI moves through a secure portal but the network diagram shows a different service, resolve the discrepancy before finalizing the SSP.

3. System environment and inventory

List the components that make the environment work.

Include, as applicable:

• Servers and workstations.
• Network devices and firewalls.
• Operating systems.
• Identity and access management services.
• Cloud platforms and SaaS applications.
• Backup systems.
• Endpoint security tools.
• Logging and monitoring services.
• Industrial or facility-related control systems.
• Remote-access infrastructure.
• Mobile devices.
• External service providers.

For each asset, record its relationship to the boundary. A basic inventory table might include:

Do not list only products. Explain what each product does in your environment. “Microsoft 365” is not an implementation description. Identify which services are used, what information they handle, and how they connect to the boundary. For a practical example of the level of technical specificity an SSP narrative should contain, see configuring Microsoft 365 for compliance.

4. User roles and responsibilities

Name the roles responsible for the system and its controls.

At a minimum, identify:

• System owner.
• Security or compliance owner.
• Network administrator.
• Identity administrator.
• Endpoint administrator.
• CUI data owner.
• Incident response lead.
• Executive approver.
• External service provider contacts.

You do not necessarily need to name every employee in the SSP. You do need to make accountability clear.

For example:

The IT manager owns the CUI environment. The security administrator manages identity policies, reviews privileged access, and maintains authentication evidence. The engineering manager approves project-level access. The compliance owner maintains the SSP and POA&M. The executive sponsor approves material risk decisions.

A control without an owner is a control that may be missed.

5. The control-by-control implementation narrative

This is the core of the SSP.

Write one entry for every applicable requirement in the framework’s order. For a NIST SP 800-171 and CMMC Level 2 environment, that means addressing the requirements across all 14 families.

Each entry should include:

• Requirement identifier and title.
• Current implementation narrative.
• Implementation status.
• Responsible owner.
• Supporting policy or procedure.
• Evidence reference.
• POA&M reference, if applicable.

Use a fixed sentence pattern:

Requirement X is implemented by [mechanism] on [system]. The control is owned by [role]. Evidence is [artifact].

For example:

3.1.1 - Limit system access to authorized users: Requirement 3.1.1 is implemented by identity-provider accounts and role-based security groups controlling access to the CUI project repository. The control is owned by the identity administrator. Evidence is the current user-access export, group membership review, and repository access-control configuration.

Then add the operational detail needed to make the statement verifiable:

Project managers approve access requests through the service desk. The identity administrator assigns users to project security groups after approval. Group membership is reviewed quarterly by the engineering manager, and removed users are disabled through the employee offboarding process.

Avoid statements such as:

• “Access is restricted to authorized users.”
• “The organization uses industry-standard security.”
• “The system is monitored regularly.”
• “The company follows best practices.”

Those statements may be true, but they are not specific enough for a reviewer to verify.

Instead, identify the mechanism, location, owner, frequency, and evidence.

6. POA&M cross-reference

The SSP and the Plan of Action and Milestones must agree.

If a requirement is not fully implemented, the SSP should say so. The gap should then be linked to a POA&M entry that identifies:

• The unmet requirement.
• The deficiency.
• The remediation task.
• The responsible owner.
• The target completion date.
• Any dependencies or risk decisions.

A POA&M is not evidence that the requirement is already met. It is a remediation plan.

For CMMC Level 2, unmet requirements are tracked through the POA&M process subject to the applicable CMMC eligibility and scoring rules. The SSP must accurately reflect the current status rather than treating planned work as completed.

For CMMC Level 1, the rule is different: POA&Ms are not permitted. All 15 requirements must be met. You cannot use a POA&M to defer an unmet Level 1 requirement. If you need the practical sequence, see how to get CMMC Level 1.

Your SSP, POA&M, assessment results, and any associated score or attestation should describe the same condition.

7. Diagrams

Include at least:

• A network diagram.
• A CUI data flow diagram.

These are not decorative images. They are the artifacts that make your boundary reviewable.

A network diagram should show:

• Internet connections.
• Firewalls.
• Network segments.
• Servers and workstations.
• Cloud services.
• Remote-access paths.
• External service providers.
• Security monitoring components.

A data flow diagram should show:

• Where CUI enters.
• Where CUI is processed.
• Where it is stored.
• Who accesses it.
• How it leaves.
• What trust boundaries or encryption points exist.

Label the diagrams with a version and date. When the environment changes, update the diagrams and the SSP together.

How to actually write the SSP

Step 1: Do not start with the template

Start with the environment.

Walk through your network, cloud consoles, identity platform, endpoint management system, file repositories, backup service, and remote-access tools. Write down what exists.

If you begin with a template, you are likely to fill empty sections with generic language. If you begin with the environment, the SSP will describe reality.

Step 2: Write one requirement at a time

Use the framework’s order. Do not jump randomly between access control, incident response, and physical security.

For every requirement, answer:

1. What mechanism implements it?
2. On which system?
3. Who owns it?
4. How often does it operate or get reviewed?
5. What evidence proves it?
6. Is it fully implemented?

Use the fixed sentence pattern, then add enough detail to make the statement useful.

Step 3: Write for the reviewer

Assume the reader has never seen your network and cannot ask you a question.

Define internal terms. Identify systems by function. Explain abbreviations. Describe the relationships between systems instead of assuming the reader already knows them.

A good test is to give the draft to someone outside the IT team. Ask that person to explain how CUI enters, where it is stored, and who can access it. If they cannot, the SSP needs more detail.

Step 4: Make each statement falsifiable

A statement is falsifiable when someone can check it and determine whether it is true.

Weak:

Access to CUI is restricted to authorized users.

Stronger:

Access to the CUI file share is restricted by an Entra security group. The group is reviewed quarterly by the engineering manager. The last review occurred on [date], and the review record is stored in [artifact].

The second statement gives a reviewer something to verify.

Step 5: Match the SSP to reality

If a control is not implemented, say so and put it on the POA&M when the applicable framework permits one.

Do not write what you intend to implement. Do not mark a control complete because a product could support it. Do not describe a policy as though it proves the underlying technical control operates.

An SSP that overstates your security posture is the most dangerous document in your program because it is the representation others may rely on.

Step 6: Version and date the document

Every version should include:

• Version number.
• Effective date.
• Document owner.
• Approver.
• Summary of changes.
• Review date.

Maintain a change history. A reviewer should be able to determine what changed between versions and why.

Step 7: Review it on a schedule

Review the SSP at least annually and after meaningful changes.

Tie the review to the trigger events in Technical Guide #4, including:

• A new contract involving CUI.
• A new CUI type or project.
• A new cloud service or external provider.
• A network redesign.
• A major system replacement.
• A security incident.
• A significant assessment finding.
• A change in facility or control-system architecture.

Accuracy warning: your SSP is a representation

An SSP is not merely an internal planning document. It represents how your organization protects covered information.

In September 2026, Honeywell Aerospace agreed to pay $2,042,518 to resolve False Claims Act allegations that it failed to comply with NIST SP 800-171 controls on one network while submitting claims for payment. The allegations covered conduct from April 2020 through December 2023 and originated in a whistleblower complaint by a former employee. The settlement resolved allegations and did not constitute a determination of liability.

It is worth being precise about what that matter concerned. The government’s theory was a compliance and payment theory: that claims for payment were submitted under contracts the contractor allegedly was not complying with. It was not a false-affirmation case, and no false SPRS affirmation by a signer was alleged. An SSP that overstates your posture matters because it is the representation others may rely on - but the enforcement exposure in false-claims matters turns on knowingly submitting or causing to be submitted a false claim for payment, not on documentation quality alone.

The details of that case are specific to Honeywell. The broader lesson applies to every federal contractor: the gap between what your documentation claims and what your environment actually does is where legal exposure can develop. The remedy is unglamorous - describe the environment as it actually is, track gaps where they belong, and keep the evidence current.

Read the full Nixon Peabody alert on the Honeywell settlement.

Takeaway: The Honeywell matter was a compliance-and-payment False Claims Act case that resolved allegations only. It was not a false-affirmation case, and there was no admission or finding of liability.

Common SSP mistakes and the fix for each

Copy-pasted template language

Problem: The SSP describes no real systems, users, locations, or mechanisms.

Fix: Replace generic claims with system names, roles, frequencies, configurations, and evidence references.

Requirements marked implemented with no evidence

Problem: A control is marked complete because a policy or security product exists.

Fix: Ask what operating evidence proves the control works. If the evidence does not exist, change the status or create the missing process.

No data flow description

Problem: The SSP lists systems but never explains how CUI moves between them.

Fix: Trace one real CUI file from receipt through storage, use, transfer, retention, and deletion. Document that path.

Contradictory diagrams

Problem: The network diagram and data flow diagram show different systems or transfer paths.

Fix: Review both diagrams against live configurations and update them together.

SSP and POA&M disagree

Problem: The SSP says a requirement is incomplete while the POA&M omits it, or the POA&M lists a gap that the SSP calls complete.

Fix: Reconcile the two documents during every review.

No owner for individual controls

Problem: The organization is responsible in theory, but no role is accountable.

Fix: Assign an owner for every requirement and document that role in the control narrative.

The document exists on one laptop

Problem: The SSP depends on one employee and cannot be maintained if that person leaves.

Fix: Store it in an access-controlled, backed-up repository with multiple authorized maintainers and version history.

Written once and never updated

Problem: The SSP describes an old network, former employees, retired systems, or discontinued services.

Fix: Tie SSP updates to change management and the trigger events in Technical Guide #4.

Printable “Write Your SSP” checklist

1. Define the CUI boundary and document what is in scope and out of scope.
2. Inventory systems, software, cloud services, control systems, users, and external providers.
3. Trace how CUI enters, moves through, and leaves the environment.
4. Create a network diagram that matches the live environment.
5. Create a data flow diagram that matches the network diagram.
6. Assign owners for the system, compliance process, and individual requirements.
7. Write one implementation narrative for every applicable requirement.
8. Link each narrative to current evidence and the responsible role.
9. Reconcile the SSP with the POA&M, assessment results, and actual configurations.
10. Version, approve, and review the SSP after changes and on a defined schedule.

Sources

• Nixon Peabody alert: Honeywell settlement shows FCA risk for NIST SP 800-171 gaps
• NIST SP 800-171, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
• 32 CFR 170.15 - CMMC Status of Findings and POA&Ms
• 32 CFR 170.19 - CMMC Assessment Scope

Keeping the SSP current

The reason SSPs go stale is simple: they are often maintained manually while the environment keeps moving.

Read next in this series: Technical Guide #6: Configuring Microsoft 365 for Compliance, Technical Guide #4: How to Map Your CUI Boundary, and the free compliance readiness check.

Complynt is an enterprise compliance automation platform that supports control mapping, evidence collection, continuous monitoring, pre-built content packs, and policy-as-code across 150+ frameworks, including CMMC, NIST SP 800-171, NIST SP 800-53, RMF, SOC 2, HIPAA, and ISO 27001. It runs on FedRAMP High and DoD IL5 authorized infrastructure on Palantir’s federal cloud. H&V is EDWOSB certified.

H&V does not issue certification and cannot guarantee any assessment outcome. The right sequence remains audit first, plan second, tools third. If you want to assess your current position, start with the free compliance readiness check or visit hvfsusa.com.