Writing Your SSP: Section by Section

What Makes a Good SSP

The System Security Plan (SSP) is the central document of your CMMC program. It is not a checkbox — it is the authoritative description of your environment and your security implementation. During a C3PAO assessment, assessors use your SSP as the baseline for every interview, observation, and evidence review they conduct. If your SSP says you do something, they will look for proof. If your SSP omits something you actually do, that creates confusion. If your SSP describes something you don't actually do, that is a finding.

A well-written SSP is accurate, specific, and environment-specific. Generic boilerplate text — describing industry-standard practices that are not actually implemented in your environment — is the single most common cause of C3PAO assessment failures. Write what is true, not what sounds good.

Section 1: System Overview

The system overview introduces your environment to any reader — including an assessor who has never seen your organization before. It must be specific enough that the reader understands exactly what system they are evaluating.

What It Must Contain

• System name and abbreviation — the official name used throughout the SSP and by your organization
• System purpose — what the system does in operational terms, and why CUI exists in it
• CUI categories handled — specific categories from the NARA CUI Registry (e.g., Technical Data, Export Controlled, Procurement and Acquisition) with a brief description of how each enters the environment
• Federal contracts supported — a list of contract numbers or programs whose CUI flows through this system (you do not need to include classified contract identifiers)
• System categorization — the sensitivity level of the CUI handled, based on your organization's CUI inventory
• Assessment date — when this version of the SSP was last reviewed and approved

What Assessors Look For

Assessors want to confirm that the system you've described matches the system they're observing. They will ask: Does the stated purpose align with what personnel actually use the system for? Are all CUI categories accounted for? If engineers are also using this system to handle ITAR-controlled technical data but the SSP only mentions "Procurement CUI," that is a scope gap — and it invalidates much of your control documentation.

Common Mistakes

• Vague system names: "Company IT Systems" is not a system name. If you have scoped your SSP to a specific environment — a CUI enclave, a set of workstations and servers — name that environment precisely and consistently throughout the document.
• Incomplete CUI categories: Organizations frequently list only the CUI categories they're most familiar with and miss others. Do a complete CUI inventory using the NARA registry before drafting this section.

Section 2: System Boundary & Authorization Boundary

The system boundary defines what is inside the scope of your SSP and what is outside. This is arguably the most important section, because it determines which systems and controls are subject to assessment. A boundary that is too broad makes compliance harder; a boundary that is too narrow — that excludes systems that actually handle CUI — is a finding.

What It Must Contain

• A written boundary statement describing what is in scope: which buildings, networks, systems, cloud environments, and user populations are covered
• What is explicitly out of scope and why — for example, an HR system that never touches CUI, or a guest Wi-Fi network that is physically isolated from CUI systems
• A high-level network boundary diagram showing the perimeter of the authorization boundary: where CUI enters, where it exits, and how internal zones relate to each other
• A statement about sub-enclaves or separate environments if your organization uses multiple network segments

What Assessors Look For

Assessors will compare your boundary diagram against what they observe in your environment — firewall rules, Active Directory organizational units, cloud account structures, and physical access logs. They are particularly focused on whether any CUI can flow to systems outside the defined boundary without controls you've documented. An email gateway that forwards external messages to personal email, a backup system that replicates to an uncovered cloud account, or a contractor VPN that bypasses your documented controls are all boundary violations.

Common Mistakes

• Omitting cloud services: If personnel access CUI using Microsoft 365, Google Workspace, a cloud storage service, or a SaaS application, those services are inside your boundary unless you can demonstrate CUI never enters them. "We told employees not to put CUI in Dropbox" is not a boundary control.
• Boundary diagrams that don't match reality: Diagrams are often drawn once and never updated. The diagram in your SSP must reflect your current network architecture, not the one from three years ago.

Section 3: System Environment

The system environment section is your hardware, software, and cloud services inventory — a factual accounting of every component within the authorization boundary.

What It Must Contain

• Hardware inventory: Servers (physical and virtual), workstations, laptops, networking equipment (switches, routers, firewalls, WAPs), printers, and any other endpoint within the boundary — with make, model, and operating system
• Software inventory: All operating systems, applications, and utilities installed on in-scope systems — including version numbers
• Cloud services: Every SaaS, PaaS, or IaaS service used within the boundary, with provider name, service name, and the CUI handling purpose
• System interconnections summary: A brief reference to Section 8 for detailed interconnection information
• Baseline configuration reference: A pointer to your secure baseline configuration documentation (Configuration Management)

What Assessors Look For

Assessors will spot-check your inventory against what they discover during technical review. If they find systems that aren't in your hardware inventory, or software that isn't in your software inventory, this is a Configuration Management (CM) finding. Your inventory must be current — not a snapshot from your last annual review.

Common Mistakes

• Missing cloud services: Cloud services — especially SaaS tools adopted informally by employees — are routinely omitted. Conduct a thorough discovery, including DNS query logs and IT purchasing records, before finalizing this section.
• No version numbers: An inventory that lists "Windows 10" without build numbers, or "Apache" without a version, is insufficient. Assessors need to verify patch currency, and you can't do that without versions.

Section 4: Operational Environment & CUI Flow

This section describes how CUI actually moves through your environment — how it arrives, how it's processed, where it's stored, and how it departs. It establishes the trust zones that form the foundation of your security architecture.

What It Must Contain

• Data flow diagrams: Visual representations of how CUI enters the environment (email, secure file transfer, vendor portals), moves between internal systems, and exits (outbound transmissions, contractor sharing, archival)
• Trust zone definitions: A description of each network zone — CUI enclave, administrative network, DMZ, guest network — with the security controls applied at each zone boundary
• CUI storage locations: A specific list of where CUI at rest resides: file servers, databases, SharePoint sites, cloud storage, email systems, endpoint local drives
• CUI transmission methods: How CUI moves in transit — encrypted email, SFTP, VPN tunnels, secure web portals — and what encryption standards are applied
• CUI disposal: How CUI is destroyed or sanitized when no longer needed

What Assessors Look For

Data flow diagrams must be technically accurate at the protocol level. Assessors will follow CUI through your environment during the assessment — tracing an actual email from external receipt through internal processing to storage — and compare what they observe against your diagram. Trust zone boundaries must be enforced by actual technical controls (firewall rules, VLAN configurations, access control lists), not just policy statements.

Common Mistakes

• Omitting email as a CUI flow: Email is frequently the primary channel through which CUI enters a contractor environment. If your data flow diagram shows CUI only arriving via a secure portal but assessors find that program managers routinely receive CUI attachments via standard SMTP, your diagram is inaccurate.
• Trust zones without enforcement: Stating that your CUI systems are on a separate VLAN means nothing unless you can demonstrate that the VLAN configuration is actually enforced and that there is no uncontrolled path between the CUI VLAN and general-use network segments.

Section 5: Roles & Responsibilities

This section identifies who is accountable for security within your environment and what each role is responsible for. CMMC assessors want to see that security responsibilities are assigned to named individuals or defined positions — not left undefined or assumed to belong to "IT."

What It Must Contain

• System Owner: The individual with authority and accountability for the system — typically a senior executive. The System Owner approves the SSP and is responsible for ensuring controls are implemented.
• Information System Security Officer (ISSO): The individual who manages day-to-day security operations of the system. For small organizations, this may be the same person as the IT lead, but the role must be defined.
• System Administrator(s): Those with privileged access who manage hardware, software, and configurations within the boundary
• General Users: The population of non-privileged users who access CUI within the system
• Authorizing Official (AO): For CMMC purposes, this is typically the senior official who signs the SPRS attestation
• Role-specific security responsibilities: For each role, a list of specific security duties — not generic statements like "follows security policies" but specific actions: "reviews audit logs weekly," "approves access requests for privileged accounts," "conducts annual security training"

What Assessors Look For

Assessors will interview personnel in these roles. If the System Owner cannot describe their security responsibilities, or if the ISSO cannot explain how they monitor security controls, that is a finding — regardless of what the SSP says. The roles and responsibilities section must reflect actual organizational practice, with actual named individuals who understand what they're supposed to do.

Common Mistakes

• Leaving roles vacant or undefined: An SSP that says "ISSO: TBD" or assigns security responsibilities to a role that doesn't exist in the organization is unacceptable. Every defined role must have a named individual or, at minimum, a named position currently filled by an identified person.
• Assigning all responsibilities to one person: While small organizations may have limited staff, concentrating all security roles in a single individual creates both a practical risk and a documentation problem. If your sole IT person is the System Owner, ISSO, and System Administrator simultaneously, document how segregation of duty conflicts are mitigated.

Section 6: Control Implementation Statements

This is the core of your SSP — and the section that receives the most scrutiny during assessment. For each of the 110 NIST SP 800-171 Rev 2 requirements, you must write a specific statement describing exactly how your organization implements that requirement.

What It Must Contain

For each requirement, your implementation statement must address:

• What you do: The specific technical or procedural control implemented (not what NIST says to do — what you actually do)
• How you do it: The specific tools, configurations, procedures, or mechanisms used
• Where it applies: Which systems, locations, or user populations the control applies to within the boundary
• Who is responsible: Which role owns the implementation and ongoing maintenance of the control
• Evidence of implementation: A reference to the artifact or evidence that demonstrates the control is in place (policy document, configuration screenshot, audit report, training record)

What Assessors Look For

Assessors cross-reference each implementation statement against observed evidence. For an Access Control requirement like AC.1.001 ("Limit information system access to authorized users"), an assessor will look for Active Directory or IAM configuration showing that only authorized accounts exist, that accounts are reviewed periodically, and that terminated employees are removed promptly. If your SSP says "access is reviewed quarterly" but no quarterly review records exist, the control is deficient.

For high-value requirements — those weighted 3 or 5 points in the DoD Assessment Methodology — assessors apply additional scrutiny. The following families carry disproportionate SPRS weight and must have especially detailed, evidence-backed implementation statements:

• Access Control (AC) — 22 requirements, many with 3–5 point weights
• Identification & Authentication (IA) — MFA requirements carry the highest individual weights
• System & Communications Protection (SC) — encryption and network boundary requirements
• Audit & Accountability (AU) — logging requirements are frequently deficient and heavily weighted

Common Mistakes

• Copying NIST requirement text as the implementation statement: Writing "We limit system access to authorized users, processes acting on behalf of authorized users, and devices" verbatim from NIST tells an assessor nothing about what you actually do. Your statement must describe your specific implementation.
• Writing aspirational statements: "Access will be reviewed periodically" is not an implementation statement. "The IT administrator reviews Active Directory user accounts against the HR termination report on the last business day of each quarter; records are maintained in the Access Review SharePoint folder" is. Write what you do, not what you intend to do.

Section 7: Inheritance & Shared Responsibility

When your organization uses cloud services or other external providers, some security controls may be partially or fully implemented by those providers rather than by your organization directly. This is called control inheritance, and it must be explicitly documented.

What It Must Contain

• A list of all cloud and external service providers within the authorization boundary, including service names and account identifiers
• For each provider: which NIST 800-171 requirements are fully inherited, which are shared, and which remain solely your organization's responsibility
• The provider's authorization status: Is the provider FedRAMP Authorized? At what impact level? If the provider is not FedRAMP authorized, how have you validated their security posture? (A SOC 2 Type II report, contractual security requirements, or a provider security assessment may be relevant.)
• Responsibility matrix: A table mapping each provider to the specific controls for which they bear responsibility

What Assessors Look For

Assessors will look for inherited control documentation — typically a FedRAMP package summary, customer responsibility matrix (CRM), or equivalent document from the provider. They want to see that your organization understands which controls are your responsibility and has implemented them. Saying "Microsoft handles security for Office 365" without specifying which controls Microsoft covers and which you must configure yourself is insufficient.

Common Mistakes

• Assuming all cloud controls are inherited: Cloud providers operate on a shared responsibility model. Physical security, infrastructure, and hypervisor-level controls may be inherited — but identity configuration, access control policies, audit logging, and data classification are almost always your responsibility, even in a cloud-hosted environment.
• No documentation of provider authorization: If your cloud provider is FedRAMP authorized, include the package identifier. If they're not, document how you assessed and accepted the risk of using a non-authorized service for CUI.

Section 8: Interconnections & External Systems

Every external system that your in-scope environment exchanges data with — whether CUI is transmitted or not — must be documented here. An interconnection is any point where your authorization boundary connects to a system outside your control.

What It Must Contain

• For each interconnection: the external system name, owner, and purpose of the connection; the data types exchanged (including whether CUI is transmitted); the technical method (VPN, API, SFTP, HTTPS, email relay); the security controls governing the connection; and who authorized the interconnection
• Interconnection Security Agreements (ISAs): References to any formal agreements governing the security requirements of each connection
• Government systems: Any connections to DoD or other federal agency systems — DISA systems, government-furnished equipment networks, prime contractor systems
• Third-party service provider connections: Managed service providers, IT support firms with remote access, or subcontractors with system-to-system connections

What Assessors Look For

Assessors compare your interconnection list against firewall logs, network flow data, and DNS records to find undocumented connections. An unmanaged remote access connection — a technician using a personal laptop with a remote desktop tool to access in-scope systems — is an undocumented interconnection and an access control finding. VPN configurations, remote monitoring tools, and any "phone home" software on in-scope systems are all subject to review.

Common Mistakes

• Omitting managed service provider connections: If an MSP manages your infrastructure and has remote access to your systems, that is an interconnection. It must be documented, and the MSP's security practices must be addressed — either through a contractual requirement, an ISA, or a security assessment of the MSP's environment.
• Listing connections without security details: "VPN to Prime Contractor" is not sufficient. Document the VPN protocol, the encryption standard, who on each end can initiate and terminate the connection, what data types are transmitted, and what access controls are in place at the termination point on your side.

Section 9: Attachments

The attachments section pulls together all the supporting artifacts that evidence your implementation. A well-organized attachment package transforms your SSP from a text document into a verifiable compliance record.

What It Must Contain

• Network architecture diagrams: Detailed topology diagrams showing all in-scope systems, their IP ranges, network segments, firewall locations, and interconnections — current as of the SSP date
• Hardware inventory: The complete asset inventory from Section 3, formatted as a table with system name, make/model, OS, IP address, location, and custodian
• Software inventory: Complete list of approved software with versions and the systems on which each is installed
• Policy and procedure documents: References or copies of all security policies cited in control implementation statements — Acceptable Use Policy, Access Control Policy, Incident Response Plan, Configuration Management Plan, etc.
• User roster: A current list of authorized users with their roles, access levels, and MFA enrollment status
• POA&M cross-reference: A table mapping any not-yet-implemented requirements to their POA&M entries

What Assessors Look For

Attachments must be current. Diagrams dated two years ago, policies that haven't been reviewed in three years, or hardware inventories with systems that no longer exist all signal that your SSP is not actively maintained — which itself is a Security Assessment (CA) finding. Every attachment should carry a "last updated" date.

Common Mistakes

• Policies that are referenced but don't exist: Implementation statements frequently cite policies by name — "per the Acceptable Use Policy" or "per the Incident Response Plan" — but no such document exists in the attachment package or document management system. Every cited policy must exist and must be producible on demand.
• Diagrams at the wrong level of detail: A high-level "boxes and arrows" diagram that doesn't show IP ranges, VLANs, firewall rules, or trust zone boundaries gives an assessor very little to work with. Assessors need enough detail to evaluate your network segmentation and boundary protection controls — which means Layer 2/3 topology, not just application-layer architecture.

Authoritative Standards for SSP Development

After Your SSP: Maintaining and Improving It

An SSP is not a one-time deliverable. CMMC requires that your SSP be reviewed and updated at least annually, and whenever significant changes occur to your system, environment, or security posture. Every change to your authorization boundary, every new cloud service adopted, every organizational change affecting security roles — all of these require an SSP update.

Treat your SSP as a living operational document, not a compliance artifact filed away after submission. Organizations that maintain accurate, current SSPs consistently perform better in assessments because their documentation reflects reality.