How to Write a System Security Plan (SSP) for CMMC

The System Security Plan is the single most important document in your CMMC assessment. If your SSP doesn’t match your actual environment, the assessment doesn’t go well. Assessors compare what your SSP describes against what they observe, interview, and test. Discrepancies become findings.

Most SSP failures aren’t caused by missing security controls. They’re caused by documentation that describes an organization that no longer exists, policies that don’t match practice, or control descriptions so generic they could apply to any company in any industry.

This guide covers what an SSP must contain, how to structure it for CMMC Level 2, the sections assessors scrutinize most, common mistakes that produce findings, and how to maintain the document as a living artifact rather than a point-in-time snapshot.

What an SSP Is and Why It Matters

An SSP describes your information system, its security boundaries, the security controls you’ve implemented, and how those controls operate in your specific environment. It’s the document that tells an assessor: here is our system, here is how we protect it, and here is how each of the 110 NIST 800-171 security requirements is addressed. The SSP is mandated by NIST 800-171 requirement 3.12.4 (CA.L2-3.12.4): “Develop, document, and periodically update system security plans.”

The SSP serves three purposes:

Assessment anchor. The C3PAO assessment team uses your SSP as the starting point for evaluation. They read it before arriving on-site. They compare it against your actual environment throughout the assessment. Every control evaluation begins with what the SSP says and tests whether reality matches.

Operational reference. A well-written SSP functions as the authoritative record of how your security program works. When a new employee needs to understand CUI handling procedures, or when a system change requires evaluating compliance impact, the SSP is the reference document.

Compliance continuity. Between triennial assessments, your SSP documents the baseline against which changes are evaluated. When your annual affirmation requires a senior official to confirm ongoing compliance, the SSP is what they’re affirming still reflects reality.

What Your SSP Must Include

NIST SP 800-171 and the CMMC Assessment Guides establish what an SSP should cover. The specific sections below represent the content areas assessors expect to find.

System Description and Boundary

Describe the information system covered by the SSP. This includes:

System name and identifier. A clear, unique designation for the system being assessed.
System purpose and function. What the system does in the context of your business and DoD contracts.
System boundary. The explicit perimeter of what’s in scope. Every asset, network segment, and connection point that falls within the CMMC assessment boundary must be identified.
CUI categories and types. What categories of CUI are present in your environment, as defined in the CUI Registry.
Information flow. How CUI enters, moves through, is processed, stored, and exits your environment. This includes data flows between internal systems, flows to and from external parties (primes, subs, government systems), and flows through cloud services.

Network Architecture

Provide current network diagrams that show:

Network topology, including segmentation between CUI and non-CUI environments
IP addressing schemes for in-scope segments
Firewalls, routers, switches, and security appliances at boundary points
Wireless networks and their relationship to wired CUI segments
Remote access paths and VPN termination points
Cloud service connections and their integration with on-premises systems
Connections to external systems (prime contractor networks, government portals)

Network diagrams must match the actual environment at assessment time. An outdated diagram is one of the most common findings. If you added a new server, changed a firewall rule, or restructured a VLAN since the diagram was drawn, update it before the assessment.

Asset Inventory

Catalog every asset within the assessment boundary, categorized per the CMMC Scoping Guide:

CUI Assets. Systems that directly store, process, or transmit CUI.
Security Protection Assets. Tools and systems that provide security functions for CUI assets (firewalls, SIEM, endpoint protection, IAM platforms, vulnerability scanners).
Contractor Risk Managed Assets. Assets that are not intended to, but are capable of, processing, storing, or transmitting CUI because of the security policy, procedures, and practices in place.
Specialized Assets. IoT devices, OT systems, government-furnished equipment, and test equipment with limited or no ability to enforce security controls.
Out-of-Scope Assets. Assets that cannot process, store, or transmit CUI and are excluded from the assessment boundary. Document the rationale for each exclusion.

For each asset, document: asset name, type, function, operating system, location, and owner. Note which asset category it falls into.

Control Implementation Descriptions

This is the core of the SSP and where most organizations fall short. For each of the 110 NIST 800-171 security requirements, describe:

How the control is implemented in your specific environment. Not what the control requires in general. Not language copied from the NIST standard. A description of what you actually did, on what systems, using what tools, configured how.

For example, for AC.L1-3.1.1 (Limit information system access to authorized users, processes acting on behalf of authorized users, or devices):

Weak: “The organization limits system access to authorized users.” (This restates the requirement without describing implementation.)

Strong: “Access to CUI systems is managed through Azure Active Directory with conditional access policies enforced on all endpoints. User accounts are provisioned through a documented onboarding process that requires manager approval and HR verification. Accounts are disabled within 24 hours of termination notification through an automated workflow triggered by the HR system. Privileged accounts are managed separately with additional MFA requirements and quarterly access reviews conducted by the IT manager.”

The strong version tells the assessor exactly what tools are used, how the process works, and how it’s maintained. The weak version tells them nothing they couldn’t already read in NIST SP 800-171.

Across the SSPs we review, the majority of control descriptions restate the requirement language rather than describing what’s actually implemented. This is the single fastest way to trigger deeper scrutiny from an assessor.

Who is responsible. Name the role (not necessarily the individual) responsible for implementing and maintaining the control.

What evidence supports it. Reference the specific evidence artifacts that demonstrate the control is operational. Don’t embed the evidence in the SSP. Reference it so the assessor knows where to find it.

External Service Provider Relationships

Document every external service provider that operates within your assessment boundary:

Provider name and services provided
Whether the provider processes CUI, Security Protection Data, or both
For Cloud Service Providers (CSPs) that process, store, or transmit CUI: FedRAMP Moderate authorization or FedRAMP Moderate equivalency, per DFARS 252.204-7012. For other external providers: document the service provided, in-scope responsibilities, and how control ownership is allocated and monitored.
Documentation of how security responsibilities are divided between your organization and each in-scope provider. A customer responsibility matrix is required by the CMMC scoping guidance for all in-scope ESPs.
How provider compliance is monitored and verified

Roles and Responsibilities

Define the security roles within your organization:

Who has overall responsibility for the security program
Who manages day-to-day security operations
Who handles incident response
Who conducts access reviews
Who manages the relationship with external service providers
Who maintains the SSP and supporting documentation

For small organizations, one person may fill multiple roles. That’s acceptable. What matters is that responsibilities are defined and someone is accountable for each function.

How to Structure the Document

There’s no mandatory SSP format prescribed by the CMMC program. The structure should be whatever makes the document usable and assessable. A common approach:

Section 1: System Identification. System name, purpose, boundary description, CUI categories.

Section 2: System Environment. Network architecture diagrams, asset inventory, physical locations, connection points.

Section 3: External Dependencies. Service providers, cloud services, CRM references.

Section 4: Roles and Responsibilities. Security organization, key personnel, accountability assignments. Assessors use this section to determine who to interview, so vague role definitions here create problems that ripple through the entire assessment.

Section 5: Control Implementation. Organized by NIST 800-171 control family (AC, AT, AU, CM, IA, IR, MA, MP, PE, PS, RA, CA, SC, SI). For each security requirement, include the implementation description, responsible role, and evidence reference. This is the section assessors spend the most time in, and where generic language triggers the deepest scrutiny.

Section 6: POA&M Summary. Cross-reference to your Plan of Action and Milestones for any requirements not yet fully implemented.

Appendices. Network diagrams (full-size), asset inventory tables, interconnection agreements, CRM documents.

What Assessors Look for First

Assessors have limited time and a lot of controls to evaluate. Based on common assessment patterns, they tend to scrutinize these areas first:

Consistency between the SSP and the real environment. Does the network diagram match the actual network? Does the asset inventory include everything in scope? Do the control descriptions match what’s actually configured on the systems?

Specificity of control descriptions. Generic language that restates the requirement without describing implementation is a signal that the organization may not have fully implemented the control. Assessors probe these areas harder.

(If you want a rough litmus test: read a control description out loud without saying your company name. If it could apply to literally anyone, the assessor will notice too.)

CUI boundary clarity. Is the boundary well-defined? Can the organization clearly articulate what’s in scope and what’s out? Is there CUI in systems that aren’t documented in the SSP?

External service provider documentation. Are all ESPs identified? Is there a CRM for each? Does the SSP account for the controls the ESP is responsible for?

Currency. When was the SSP last updated? Does it reflect recent changes to the environment? Are there obvious gaps between the document date and current reality?

Common SSP Mistakes That Produce Findings

Copy-paste from templates. Generic SSP templates are starting points, not finished products. Assessors recognize template language immediately. If your SSP reads like everyone else’s, it doesn’t describe your environment.

Stale network diagrams. The environment changed. The diagram didn’t. This is probably the single most frequent documentation finding in CMMC assessments. In SSPs we’ve reviewed during readiness assessments, the network diagram is typically over a year old. In that time, most organizations have added systems, changed providers, or restructured network segments without updating the drawing. Update diagrams every time you make a network change, or implement a process that keeps them current automatically.

Missing ESP documentation. The SSP describes the organization’s internal controls but doesn’t address the cloud provider, the MSP, or the backup service that handles CUI. Every ESP in scope needs to be documented with a CRM.

Aspirational descriptions. The SSP describes how the control should work or will work rather than how it actually works today. Assessors test current-state implementation. “We plan to implement MFA by Q3” is a NOT MET finding, not a control description.

No evidence references. The SSP describes controls but doesn’t point to evidence. The assessor has to ask where to find proof for every control, slowing the assessment and creating the impression that evidence may not exist.

Orphaned controls. Controls described in the SSP that reference systems no longer in the environment, or procedures no longer followed. This happens when the SSP isn’t updated after organizational changes.

Building your SSP from scratch or need to update one that’s gone stale? Start with a free readiness check to see which controls need the most attention.

Keeping Your SSP Current

An SSP that’s accurate only at the moment it’s written has a short shelf life. Environments change. People leave. Systems are added. Configurations drift. A current SSP requires a maintenance process.

Define update triggers. Any of these events should trigger an SSP review and potential update: new system deployment, network architecture change, personnel change in a security role, new or changed external service provider, policy revision, or significant configuration change to an in-scope system. Among contractors on our platform, those who define explicit SSP update triggers average 3-4 updates per quarter. Those without defined triggers average less than one update per year — and the gap shows up during assessment.

Assign SSP ownership. One person must be responsible for maintaining the SSP. Not a committee. Not “the IT team.” A named owner who ensures updates happen when triggers occur.

Version control. Track every change. Date every revision. Maintain a change log that records what changed and why. Assessors may ask about changes between the last assessment and the current one.

Align with evidence management. When the SSP is updated, the supporting evidence should be refreshed too. A new control description without updated evidence creates inconsistency.

The organizations that maintain their SSP with the least friction are those that use a system, rather than a static document, to manage it. When the system of record tracks your assets and controls alongside the evidence, updating the SSP becomes a matter of reflecting the current state rather than manually rewriting a Word document.

From Static Document to Living System

The traditional SSP is a Word document or PDF that gets written once, filed in a shared drive, and pulled out when an assessment approaches. That model doesn’t survive continuous compliance. The document is outdated within weeks of being written because environments don’t hold still.

Deep Fathom approaches the SSP differently. Instead of generating a static document, the platform maintains a living system of record. Your controls and evidence stay synchronized with your actual environment. When something changes, the SSP reflects it. When the assessor asks about a control, the evidence is already linked. When your annual affirmation comes due, the document describes the organization as it exists today.

If you’re building your SSP from scratch, or rebuilding one that’s gone stale, check your readiness or talk to our team.

Related reading: