Rewrite: system-security-plan-ssp-explained

Word count: ~1,650

Specificity markers: - ✅ NIST/CMMC control references (CA.L2-3.12.4, all 110 Level 2 controls) - ✅ Cost/time estimates (80-120 hrs initial writing, $5K-$15K consultant SSP development) - ✅ Tool/product names (NIST SP 800-171A SSP template, RegScale, Drata) - ✅ Common mistakes (writing an aspirational SSP, missing system boundary) - ✅ Decision point with guidance (when to write it yourself vs. hire help)

---

Every organization pursuing CMMC Level 2 needs a System Security Plan. It's required by CA.L2-3.12.4, it's the first document your C3PAO assessor reviews, and it frames everything else in your assessment. Get it right, and the rest of the process is verification. Get it wrong, and the assessor spends the engagement reconciling what you wrote against what actually exists.

Here's what an SSP is, what it has to contain, and what separates the documents that pass assessments from the ones that don't.

What the SSP Is

The System Security Plan is a document that describes your CUI environment and explains how your organization implements each of the 110 CMMC Level 2 security controls. It's not a policy document — policies describe rules. It's not a checklist — checklists show what's implemented or not. The SSP is a narrative: here's our environment, here's our boundary, here's how each control works in our specific context.

NIST SP 800-171A defines the required elements: system boundary, operational environment, implementation of security requirements, and relationships with external systems. The CMMC Assessment Process guide, available from the Cyber AB, adds specificity about what assessors review and test.

The SSP serves two audiences:

1. Your assessor — who uses it to understand your environment and plan the assessment
2. Your own team — who uses it as the authoritative reference for how security controls are operated and maintained

A good SSP is accurate enough that a new employee could read it and understand how the security program works. That's the right bar.

What the SSP Must Contain

System description: Name, purpose, and a brief description of the types of information processed (CUI categories, volume, sensitivity). Who uses the system and in what roles.

System boundary: The explicit definition of what's in scope — which servers, workstations, cloud services, and network segments are part of the CUI environment — and what's explicitly excluded. The boundary must be precise enough that someone can verify it against a network diagram. "All systems that handle CUI" is not a boundary definition.

Network and data flow diagrams: Appended to or embedded in the SSP. The network diagram shows your topology, system components, and connections. The data flow diagram shows how CUI enters, moves through, and exits your environment. Both are required.

System interconnections: Every external system your CUI environment connects to — cloud services, government portals, email providers, remote access services, backup systems. For each, document: who operates it, what data is exchanged, and what security controls govern the connection (encryption requirements, access restrictions, security agreements).

Control implementation descriptions: For each of the 110 Level 2 controls, a description of how your organization implements it. This is 80-90% of the SSP's length and 100% of its value. Each description should name the tool or procedure that implements the control, who's responsible, how it's maintained, and where evidence lives.

POA&M reference: Controls that are not yet implemented belong in the Plan of Action and Milestones, referenced from the SSP. The SSP documents what's in place. The POA&M documents what isn't.

What Good Control Descriptions Look Like

This is where SSPs succeed or fail. Vague descriptions don't give assessors anything to verify — and unverifiable claims default to Not Met.

Bad: "The organization implements access controls to protect CUI systems from unauthorized access."

Good: "CUI systems are accessible only to Active Directory accounts in the CUI-Users or CUI-Admins security groups. Access is provisioned via a formal request form (form AC-001) approved by the user's manager and the IT Security Manager. Account provisioning takes 1-2 business days. Quarterly access reviews are conducted by the IT Security Manager using the AD Users and Computers report — review records are maintained in the CMMC documentation folder on SharePoint. The last access review was completed [date]."

The good version gives the assessor specific things to examine: the AD group structure, the form, the approval workflow, the review records. They can verify all of it. The bad version gives them nothing.

For every control, your description should answer: - What tool or process implements this control? - Who is responsible for it? - How frequently is it reviewed or maintained? - Where does the evidence live?

How Long It Takes to Write

Writing an SSP from scratch for a small CUI environment (20-50 systems, 20-50 users) takes 80-120 hours. Larger environments take longer. The time breaks down roughly:

• Asset inventory and boundary definition: 10-20 hours
• Network and data flow diagrams: 10-20 hours (if starting from scratch)
• System interconnection documentation: 5-10 hours
• Control description writing: 50-80 hours (110 controls × 30-45 minutes each)

If you're using a GRC platform like Drata or RegScale that can pull configuration data from your environment and auto-draft some control descriptions, you can cut 30-50 hours from the drafting phase. But you still need to review every auto-generated description for accuracy and add the human context the tool can't supply.

Writing it yourself vs. hiring help: If you have staff who understand both your technical environment and NIST 800-171, writing internally works and costs less. If your IT team is strong but hasn't done CMMC before, a consultant who specializes in CMMC SSP development can cut your time-to-completion significantly. Consultant fees for SSP development typically run $5,000-$15,000 for a small-to-mid-size organization, depending on complexity. That's often worth it if it means the document is done correctly and your assessment doesn't fail on SSP quality.

Common SSP Mistakes

Writing what you want to be true, not what is. The most credibility-damaging SSP issue: describing controls as implemented when they're partially implemented or planned. When the assessor tests the control and finds the gap, they now question the accuracy of every other description in the document. Put incomplete implementations in the POA&M where they belong.

Missing or vague system boundary. If your boundary section says "the systems that process CUI" without naming them, the assessor defines your scope during the assessment — and they'll include anything they find that touches CUI. That's how assessments expand to cover systems you weren't ready to demonstrate.

Ignoring system interconnections. Contractors frequently document their internal systems but skip the cloud services: Microsoft 365, Dropbox, personal email used by employees, cloud backup services. If CUI can reach that system, it belongs in your interconnections section. Missing it is both an SSP finding and a potential scope expansion.

Not updating after environment changes. An SSP written at your last assessment may describe systems that no longer exist, miss systems that were added, and reference tools that were replaced. The version date matters. Assessors will check whether the SSP reflects your current environment.

Referencing policies and procedures that don't exist. "Per the Media Handling Procedure" is fine — if the Media Handling Procedure actually exists and matches what the SSP says. References to nonexistent documents are direct findings.

The SSP as a Living Document

Your SSP isn't finished when the assessment is done. It's maintained as your environment and program evolve.

Build a version history into the document from day one — version number, date, approved by. Designate someone (your ISSO, IT Security Manager, or equivalent) responsible for updates. Review the full document annually and update it whenever: - You add or remove systems from the CUI environment - You change a major technical control (new identity provider, new firewall, new cloud service) - You change a security-relevant procedure - Staff turnover affects named security roles

The annual affirmation requirement under DFARS 252.204-7021 means someone is signing their name each year to the claim that your security posture is maintained. That signature needs to be backed by a current, accurate SSP.

What Your Assessor Expects

Your C3PAO will review the SSP before any on-site or remote assessment activity begins. They're checking:

• Does the boundary make sense with the network diagram?
• Are control descriptions specific enough to generate test procedures?
• Are the described tools and configurations consistent with what the pre-assessment questionnaire suggested?
• Is the document current (reviewed within the last 12 months)?

The assessor references your SSP when conducting interviews — "your SSP says MFA is enforced via Conditional Access policies; can you walk me through how that's configured?" — and when testing — "your SSP says logs are retained for 12 months; I'd like to see logs from [date 11 months ago]."

When descriptions in the SSP don't match what the assessor observes, the gap becomes a finding — not just for that control, but for CA.L2-3.12.4 (the SSP maintenance requirement itself). Assessors are trained to flag documents that appear aspirational rather than descriptive. If your SSP was written before controls were fully implemented and never updated, the mismatches accumulate. Treat every update to your environment as a trigger to update the SSP within 30 days.

An accurate SSP makes those conversations easy. A vague or inaccurate one makes them difficult and expensive.

---

CTA: If you're starting your SSP from scratch, begin with the system boundary section and asset inventory — they form the foundation everything else builds on. NIST SP 800-171A includes a comprehensive SSP template available at csrc.nist.gov that maps directly to the 110 controls.