Rewrite: security-plans-required-for-cmmc

Word count: ~1,750

Specificity markers: - ✅ NIST/CMMC control references (CA.L2-3.12.4, CA.L2-3.12.2, IR.L2-3.6.1, AC.L2-3.1.1) - ✅ Cost/time estimates (80-120 hrs initial SSP writing, annual SSP review 20-40 hrs) - ✅ Tool/product names (RegScale, Drata, Microsoft Word for baseline documentation) - ✅ Common mistakes (conflating SSP with policy docs, missing CUI scope in SSP) - ✅ Decision point with guidance (what to include in SSP vs. what to reference as separate policy)

---

Two security planning documents are formally required for CMMC Level 2: a System Security Plan (SSP) and a Plan of Action and Milestones (POA&M). Both are required under NIST SP 800-171, both will be reviewed during your C3PAO assessment, and both need to be maintained throughout your three-year certification cycle.

Beyond the SSP and POA&M, your CMMC program will require several additional documents — policies, procedures, and plans — that support specific control domains. Some of these are explicitly called out in NIST 800-171; others are implied by the controls. Knowing what's required, what's optional, and what assessors look for prevents both under-documentation (failing for missing plans) and over-documentation (writing 40 policies nobody maintains).

The System Security Plan (SSP)

The SSP is the master document. It describes your CUI environment, the security controls you've implemented, and how each control is implemented in your specific organization.

What the SSP must cover:

CA.L2-3.12.4 requires a system security plan that describes the system boundary, operational environment, how security requirements are implemented, and the relationships with or connections to other systems.

That translates to: - System description: What the system is, its purpose, the type of information it processes (CUI, specifically what categories), and who uses it - System boundary: What's in scope — servers, workstations, cloud services, network infrastructure — and what's explicitly out of scope with justification - Network and data flow diagrams: Visual depiction of the CUI environment, including all connections to external systems - Security control descriptions: For all 110 Level 2 controls, how your organization implements them (or an explanation if they're not applicable, with justification) - System interconnections: Other systems that connect to your CUI environment, what data crosses those connections, and what protections govern the connections

What makes a good SSP vs. a template:

An SSP that passes assessment is specific to your environment. "Access control is implemented using industry-standard practices" tells the assessor nothing. "Access to CUI systems is controlled through Active Directory, with individual user accounts, MFA enforced via Azure AD Conditional Access policies, and role-based access groups defined and managed by the IT Security Manager" gives them what they need to verify.

Every control description in your SSP should answer three questions:

1. What technical or procedural mechanism implements this control?
2. Who is responsible for it?
3. Where can the assessor find evidence that it's working?

SSP length and format: For a small organization with 20-30 systems in scope, expect 40-80 pages. Mid-size environments (50-150 systems) typically run 80-150 pages. There's no mandated format — NIST provides an SSP template in NIST SP 800-171A and the DoD's CMMC assessment guides — but whatever format you use, it must address all 110 controls.

Writing your SSP from scratch takes 80-120 hours. Tools like RegScale or Drata can generate draft SSPs from your infrastructure data, saving 40-60 hours of initial drafting — but every control description still needs human review and customization to reflect your actual operations.

The Plan of Action and Milestones (POA&M)

The POA&M documents gaps — controls that aren't yet implemented or aren't fully implemented — along with a plan to close them. It's required under CA.L2-3.12.2.

What the POA&M must include for each gap: - The specific control that's partially or not implemented - Description of the gap (what's missing or not working) - Planned corrective action - Resources required (personnel, budget, tools) - Target completion date - Responsible party

The POA&M is not a shame document. Every organization has gaps — new systems don't get locked down immediately, organizational priorities shift, resources are finite. The POA&M is how you demonstrate that you know what you don't have and you're managing it. An assessment without a POA&M suggests either no gaps (unlikely) or no awareness of gaps (a problem).

During your C3PAO assessment: Assessors will review your POA&M. Open items on the POA&M don't automatically fail the assessment — the DoD's CMMC Assessment Process allows for conditional certification when gaps have documented remediation plans with realistic timelines. What assessors look for is that the POA&M reflects reality: the gaps are real, the timelines are credible, and the responsible party is identified.

What does fail the assessment: POA&M items that should have been closed months ago with no progress documented, or gaps that aren't on the POA&M at all.

Keep the POA&M current. Review it monthly. Close items with dates and evidence when you remediate them. Add items when new gaps are identified from vulnerability scans, internal audits, or system changes.

Additional Plans Required by Specific Controls

Beyond the SSP and POA&M, several CMMC Level 2 domains require standalone plans or procedures:

Incident Response Plan (IR.L2-3.6.1) Required. Your incident response plan documents how you detect, report, and respond to security incidents, including the 72-hour DoD reporting path via DIBNet. This can be a section within your SSP or a standalone document referenced from it. It must include: incident categories and severity levels, response team roles and contacts, escalation procedures, containment and recovery steps, and post-incident review process.

Contingency Plan / Business Continuity Plan (CA.L2-3.12.4 context, CP domain at higher tiers) NIST 800-171 doesn't explicitly require a separate contingency plan at Level 2, but your SSP must address continuity and recovery for CUI systems. At minimum, document your backup procedures, recovery time objectives, and what happens to CUI access during a system outage. This is commonly a section in the SSP rather than a standalone document.

Configuration Management Plan Not a standalone document requirement, but the CM domain (9 controls) requires documented baseline configurations, a change management process, and software/firmware authorization procedures. These are typically documented as CM policies and procedures referenced from the SSP.

Security Assessment Plan When you conduct internal security assessments (CA.L2-3.12.1), document the scope, methodology, and findings. This creates the evidence trail the assessor wants to see — that you're actually assessing controls and not just claiming they're in place.

The Policy Framework That Supports the Plans

Your SSP references policies and procedures for many controls. You don't need 40 separate policy documents — you need policies that cover the required topics and are actually maintained.

The core policies most CMMC programs need: - Acceptable Use Policy — covers user behavior, CUI handling, personal device restrictions - Access Control Policy — user accounts, least privilege, MFA, session management - Incident Response Policy — who does what, what gets reported and when - Configuration Management Policy — change control, baseline management, software authorization - Media Protection Policy — CUI marking, storage, transport, disposal - Physical Security Policy — CUI environment access controls, visitor management - Personnel Security Policy — screening, onboarding, termination procedures

These can be organized as separate documents or combined into fewer, longer documents — the format doesn't matter as long as they're current, accurate, and your people follow them. A five-page consolidated security policy that matches your actual operations is more defensible than a 60-page policy library that nobody's read.

Common Mistakes in Security Planning

SSP describes intended implementation, not actual implementation. Writing the SSP to describe how you plan to implement controls rather than how they currently work. Assessors test actual implementations against SSP descriptions. If your SSP says "MFA is enforced via Conditional Access policies" but your actual enforcement has exceptions for legacy apps, those exceptions are a finding.

Missing the system boundary in the SSP. The scope section must explicitly define what's in and what's out, with justification for anything excluded. "Our corporate network" is not a boundary definition. "The CUI enclave consisting of [list of systems] connected to the internet via [firewall] and separated from the corporate network by [VLAN/physical separation]" is a boundary definition.

Conflating policies with the SSP. Some contractors write a 150-page SSP that is actually a policy library with SSP elements mixed in. Others reference policies in their SSP but don't include any control implementation descriptions. The SSP should reference your policies but also explain how each control is implemented in your specific environment.

No version control on the SSP. Your SSP should have a version number, last-revised date, and approval signature. Assessors want to know they're looking at the current, approved version — not a draft from 18 months ago.

What Your Assessor Expects

On day one of your C3PAO assessment, the assessor will review your SSP to understand your environment before evaluating any individual controls. They're looking for:

• A system boundary that makes sense with your actual network topology
• Control descriptions specific enough to enable verification
• A POA&M that's current and reflects your actual gaps
• Referenced policies that actually exist and are accessible
• SSP version information showing this is a maintained document

The assessor will reference your SSP throughout the assessment. When they test a control, they compare what they find against what you documented. Inconsistencies aren't just findings — they raise questions about your overall program maturity. An SSP that accurately describes your environment, even with documented gaps in the POA&M, is more credible than a perfect-looking SSP that doesn't match reality.

---

CTA: Start your SSP with a boundary definition and asset inventory — these two elements take the least time to write and clarify everything that follows. The DoD's CMMC SSP template (available through the CMMC-AB and CMMC Accreditation Body resources) gives you a control-by-control structure to fill in.