If you work in the world of Cybersecurity Maturity Model Certification (CMMC), you already know the buzzwords: System Security Plan (SSP), Plan of Action and Milestones (POA&M), Assessment Objectives (Aos), evidence, and assessment week. What many organizations miss is the difference between having an SSP and having an SSP that actually does its job.
In other words, your SSP is not a homework assignment. It’s your operating manual (and assessors can tell the difference).
In a recent presentation given by IntelliGRC Founder & CEO Ozzie Saeed, Managed Service Providers (MSPs), defense contractors, and compliance professionals received a necessary refresher on how to write SSPs that withstand scrutiny. In this guide, we’ll break down how to write a SSP that is operational, defensible, and assessment-ready.
The SSP Is Your Script: Write It Like You Use It
An SSP isn’t just a compliance requirement; it’s the document your team should be able to operate from, point to, and prove during an assessment.
The best SSPs serve as:
- The playbook for assessment week
- The reference source for engineers, Virtual Chief Information Security Officer (vCISO) staff, and Security Operations Center (SOC) teams
- The documentation of exactly what tools and processes you use, not what you wish you used
If your service catalog says you deliver Identity Provider (IDP), Managed Detection and Response (MDR), Endpoint Detection and Response (EDR), backups, SIEM (Security Information and Event Management), or Microsoft 365 hardening, the SSP should show where and how those services actually enforce 800-171 controls.
What You’re Really Documenting: Tech, Facilities, People
Every control touches at least one of these three domains:
- Technology: Entra ID, Intune, Group Policy Objects (GPOs), EDR, SIEM, backup platforms, Remote Monitoring and Management (RMM) tools
- Facilities: CUI-authorized offices, data closets, SOC rooms, co-lo cages
- Personnel: general users, admins, SOC analysts, MSP engineers, subcontractors
For each Assessment Objective (AO), ask the most important scoping question: “Which people, which tech, and which facilities are actually in play for this requirement?”
This framing alone eliminates most vague or incomplete SSP writing.
The Two-Layer Writing Method: Practice vs. Assessment Objective (AO) Statements
- Practice-Level Statements = The Story
This is a high-level narrative of how you meet the requirement as a whole. These are labeled [a], [b], [c]… and should touch:
- Policy definitions
- How implementation works across platforms
- Monitoring and upkeep
- AO-Level Statements = The Receipts
This is where the real writing happens. Each AO should clearly answer:
- Who does the action
- What they do
- When it’s done
- Where it occurs (system, platform, environment)
- How it’s performed (tools, baselines, methods)
- Evidence that proves it
A perfect AO statement follows this pattern: “[Who] performs [What] on [Where] [When] using [How]. Evidence: [artifact list].”
If you can’t instantly provide the screenshot or log that proves it, the statement isn’t finished.
Stop Paraphrasing the Controls, Start Describing Reality
Most weak SSPs rely on empty phrases:
- “as appropriate”
- “as needed”
- “regularly”
- “industry best practice”
An assessor won’t accept these. They need behavior and mechanism.
Strong SSPs describe what actually happens, such as:
- “Enforced via Group Policy Object (GPO) Controlled Unclassified Information (CUI) CUI_DefaultDomainPolicy”
- “Reviewed monthly using Intune compliance reports”
- “Alerts forwarded to SIEM and triaged by SOC Tier 1”
This shifts the mindset from “checkbox” language to “operational” language that cuts rework dramatically and builds credibility.
Organizational Defined Parameter (ODPs) + Organizational Defined Value (ODVs) = The Secret Weapon of Scalable Writing
Two concepts simplify everything:
- ODP (Parameter): what you measure, including password length, retention, frequency
- ODV (Variable): your actual value, such as, 14 characters, 365 days, quarterly
Put the ODVs in policy, reference them in the SSP, then enforce them in tools.
For example: “Lockout after [ODV] failed attempts in [ODV] minutes, defined in Access Control Policy §4.2.9 and enforced via Entra ID/AD GPO.”
This keeps SSPs consistent, accurate, and low-maintenance.
One Control, Many Platforms: Document It Honestly
An important point to remember: if implementation varies by platform, state that explicitly.
For example:
- Windows: enforced via GPO
- Software as a Service (SaaS) apps: enforced via Entra Conditional Access
- macOS/Linux: enforced via configuration scripts using pam_pwquality.so
Avoid thinking everything works the same way everywhere. It doesn’t, and assessors know this, too.
Use Your Customer Relationship Management (CRM)/ Professional Services Automation (PSA) to Drive SSP Scope
Your CRM/PSA holds gold-standard truth about:
- What services clients purchased
- What environments you actually manage
- Which assets are in scope
- Whether CUI is present
- Whether Main Distribution Frame (MDF) closets or cloud-only services are used
If the CRM says no physical hosting, that doesn’t describe an on-premises data center.
If the CRM says MDR + Endpoint Detection and Response (EDR), the SSP must show which controls those services satisfy.
This alignment avoids inconsistent implementation claims, a common assessment failure.
Evidence Strategy: Avoid Both Extremes
Great SSP writers avoid:
- “Trust me, bro” statements with no evidence
- Evidence dumps of 50 screenshots with no context
Every AO should map cleanly: Statement → Tool → Artifact
Examples of valid evidence:
- SIEM log extracts
- Backup job reports
- Restore test tickets
- GPO/Intune baseline audits
- Visitor logs
- LMS training reports
If the evidence doesn’t naturally flow from the SSP, the SSP needs to be rewritten.
Assessment Week Tips
A few practical reminders about assessment week:
- Use the exact version of the SSP that assessors have.
- Answer using your AO statements first, then show mapped evidence.
- Give one example, then ask, “Would you like another?”
- Don’t improvise new commitments, stick to your documented truth.
With this approach, assessment week becomes a script, not a scramble.
Final Takeaway: Write the SSP You Actually Operate
The biggest and final message: stop trying to impress the assessor; describe what you truly do, using real tools, real people, and real processes.
If you follow:
- ODP/ODV
- Who/What/When/Where/How
- Platform-specific accuracy
- CRM/PSA-driven scoping
- Evidence mapping
…your SSP becomes both assessment-ready and operationally useful.
And that’s the whole point.
Still confused? We would love to chat! We have members on our team, as well as some amazing partners, who are eager to help you reach your goals!
