Cybersecurity Plans for CMMC: What You Need to Write

(155 chars)

Word count: ~3,300

Specificity markers used:

1. NIST/CMMC control references: CA.L2-3.12.4 (SSP), CA.L2-3.12.2 (POA&M), IR.L2-3.6.1–3.6.3, CM.L2-3.4.1–3.4.2, CP.L2-3.8.9, AT.L2-3.2.1, DFARS 252.204-7012
2. Cost/time estimates: SSP writing 80–160 hours; IR plan 20–40 hours; full documentation package typically 200–300 hours total; consultant rates $150–$250/hr
3. Tool/product names: NIST SP 800-171 Self-Assessment Template (DoD CMMC website), OSCAL (machine-readable SSP format), Microsoft Word templates from DCSA, Drata/Vanta for SSP management
4. Common mistake: Writing an SSP that describes aspirational controls ("the organization will implement...") instead of implemented controls ("the organization uses...")
5. Decision point: When to write documents yourself vs. hire a consultant — and what a consultant can and can't do for you

---

Executive Summary

Key takeaways: - CMMC Level 2 requires six core written documents: System Security Plan (SSP), Plan of Action & Milestones (POA&M), Incident Response Plan, Configuration Management Plan, Security Assessment Plan, and a written Continuous Monitoring strategy. Additional plans are required depending on your specific practices. - The SSP is the centerpiece. Everything else references it or feeds it. Get the SSP right first. - The single most common documentation failure: SSPs written in future tense ("will implement") rather than present tense ("is implemented"). Your SSP describes what exists today, not what you're planning to build. - Writing the full documentation package takes 200–300 hours of time from people who know your actual environment. It cannot be outsourced entirely — a consultant can write templates and structure, but the implementation details must come from your team. - NIST SP 800-171 Rev 3 and CMMC Model 2.0 don't add new documentation requirements beyond what Rev 2 already requires. If you're working from existing Rev 2 documentation, a scope review is needed but not a complete restart.

---

The Six Core Documents

Before getting into each one, understand how they relate: the SSP is the foundational document that describes your entire security program. The POA&M tracks what isn't done yet. The Incident Response Plan tells everyone what to do when something goes wrong. The Configuration Management Plan governs how your systems are maintained. The Security Assessment Plan documents how you verify your controls work. The Continuous Monitoring Strategy keeps everything current between major assessments.

These aren't separate universes — they're one integrated program, documented in multiple focused documents.

---

1. System Security Plan (SSP)

Required by: CA.L2-3.12.4

The SSP is the most important document in your CMMC program. It describes your entire security environment: what systems are in scope, how each of the 110 Level 2 practices is implemented, who is responsible for what, and how the pieces connect.

Your assessor uses the SSP as their roadmap. Every question they ask, every piece of evidence they request, traces back to something your SSP describes. An SSP that's accurate and well-organized makes the assessment efficient. An SSP that's vague, incomplete, or out of date creates hours of back-and-forth as the assessor tries to determine what you actually do.

What an SSP Must Contain

System description and boundary. Name the system(s) you're documenting. Define the assessment boundary — every CUI Asset and Security Protection Asset within it. Include a network diagram showing how components connect and where the boundary is. This section is the foundation; everything else assumes the reader understands what you're describing.

System environment. Hardware, software, cloud services. Operating systems and versions. How many users, user types (standard users, admins, remote users). Physical locations. Cloud services and whether they're FedRAMP-authorized.

System interconnections. Any connections to external systems — other government systems, partner networks, cloud services. Each interconnection should describe what data flows across it, how it's protected, and whether there's a formal agreement (MOU, ISA) governing it.

Practice-by-practice implementation statements. For each of the 110 Level 2 practices, describe how your organization implements it. This is the bulk of the SSP — typically 60–100 pages for a mid-size organization. Each entry should include: - Which system or systems the control applies to - How the control is implemented (the specific tools, configurations, or procedures) - Who is responsible for the control - Where evidence can be found

The critical mistake: future tense. "The organization will implement multi-factor authentication..." is not an SSP entry. It's a commitment to implement something you haven't done. SSPs describe what exists. If MFA is deployed and configured, say "Multi-factor authentication is enforced through Azure Active Directory Conditional Access policies on all remote access and privileged account logins. Configuration evidence is in [location]." If MFA isn't fully deployed, that gap belongs in the POA&M — not described as implemented in the SSP.

Assessors are trained to read SSPs critically. They will ask about the specific tools and configurations mentioned. If your SSP says you use CrowdStrike Falcon for endpoint protection, the assessor will ask to see the CrowdStrike policy settings and coverage reports. If you named a tool that isn't actually deployed, that's a misrepresentation of your controls — a serious assessment finding.

Roles and responsibilities. A table or section listing each security role, who fills it, and what their responsibilities are. ISSO, System Owner, system administrators, incident response coordinator. This is where the PS domain personnel assignments are documented.

Agreements. Any relevant agreements — contracts with MSPs that have access to CUI systems, memoranda of agreement with partner organizations, cloud service agreements.

How Long It Takes to Write

An honest SSP for a small-to-mid defense contractor (50–200 employees, one primary CUI system boundary) takes 80–160 hours to write from scratch. This assumes: - You have an accurate asset inventory - You know what controls are implemented (someone has reviewed the environment) - One person is writing it with input from IT and operations

If you're starting from scratch without a clear picture of your environment, add 40–80 hours for discovery. If your environment is complex (multiple sites, multiple system types, extensive cloud integration), add more.

At consultant rates of $150–$250/hour, a consultant-assisted SSP runs $12,000–$40,000. A consultant can write the structure and practice descriptions based on what your team tells them — but the implementation details have to come from your people. A consultant who writes your SSP without spending significant time learning your environment is giving you a template, not a security plan.

SSP Tools and Templates

NIST and DoD provide resources: - NIST SP 800-171 Self-Assessment Template — available from the DoD CMMC website, provides a spreadsheet with all 110 practices and a column for implementation description. Basic but functional as a starting structure. - DCSA SSP Template — Microsoft Word templates designed for cleared contractors, available from DCSA. - OSCAL — Open Security Controls Assessment Language, a machine-readable format for SSPs that integrates with compliance automation tools. Growing adoption in the CMMC ecosystem but requires technical implementation.

Commercial GRC platforms (Drata, Vanta, RegScale) manage SSP content within their platforms and can export documentation for assessment use. If you're already on one of these platforms and maintaining your SSP there, confirm the export format your C3PAO will accept before assessment day.

---

2. Plan of Action and Milestones (POA&M)

Required by: CA.L2-3.12.2

The POA&M is not an admission of failure. It's a managed list of known gaps with committed remediation timelines. Every organization preparing for CMMC has a POA&M — any organization claiming they don't has either achieved perfection (unlikely) or isn't tracking their gaps (concerning).

What the POA&M must include for each item: - Control or practice — which specific CMMC practice is not yet fully met - Weakness or deficiency — what specifically is missing or broken - Resources required — budget, personnel, tools needed to remediate - Scheduled completion date — a realistic, committed date - Milestones — interim steps for complex remediations (not just a start and end date) - Status — current state, updated at each review

Under CMMC Model 2.0's phased rollout rules, contractors can receive conditional Level 2 certification with certain POA&M items open — but with restrictions. POA&Ms involving practices with the highest weighted scores (per the DoD assessment methodology) cannot be left open. Know which practices are in that category before you finalize your POA&M strategy.

The governance link. Your POA&M should be reviewed at a management-level meeting at least quarterly. Document these reviews — meeting notes, an email confirmation, any updated status entries. An unreviewed POA&M tells your assessor that nobody is managing it.

---

3. Incident Response Plan

Required by: IR.L2-3.6.1, IR.L2-3.6.2, IR.L2-3.6.3

The IR domain requires you to establish an operational incident response capability, track and report incidents, and test your incident response plan. The plan document is the foundation.

A complete incident response plan contains:

Scope and objectives. What types of incidents does this plan cover? At minimum: unauthorized access to CUI systems, suspected CUI compromise, malware infection, denial of service, and insider threat indicators.

Roles and responsibilities. Who is the incident response coordinator? Who else is on the incident response team? Who has authority to declare an incident? Who authorizes external communication (to DoD, to law enforcement, to the public)? Name the people and their backups.

Incident classification. How do you determine incident severity? A workstation with malware is not the same as confirmed CUI exfiltration. Define your severity levels and what response each level triggers.

Response procedures. Step-by-step actions for each phase: - Detection and identification — how you recognize an incident (monitoring alerts, user reports, external notification) - Containment — immediate actions to stop the damage from spreading (isolate affected systems, disable compromised accounts) - Eradication — remove the threat (malware removal, patch the exploited vulnerability, change compromised credentials) - Recovery — restore systems to normal operation - Post-incident analysis — what happened, why, and what changes prevent recurrence

DFARS reporting requirements. Practice IR.L2-3.6.2 requires tracking and documenting incidents. DFARS 252.204-7012 requires reporting to DoD within 72 hours of discovering a cyber incident involving CUI. Your plan must explicitly include this: when to report, who reports, what information to include, and the reporting mechanism (DC3 via dibnet.dod.mil). This isn't a CMMC practice — it's a contractual obligation that runs in parallel. Missing the 72-hour window has False Claims Act exposure.

Evidence preservation. Procedures for collecting and preserving forensic evidence during incident response. This matters both for your own post-incident analysis and for any DoD investigation.

Testing. The plan requires testing (IR.L2-3.6.3). At minimum, conduct a tabletop exercise annually — work through a simulated incident scenario with your IR team and document the results. Update the plan based on what the exercise reveals. Keep the exercise records as evidence.

Writing a functional IR plan takes 20–40 hours from scratch, including review and approval cycles.

---

4. Configuration Management Plan

Required by: CM.L2-3.4.1, CM.L2-3.4.2

The Configuration Management (CM) domain requires establishing baseline configurations for your CUI systems and managing changes to those systems formally. The Configuration Management Plan documents how you do this.

Required content:

Configuration baseline documentation. For each system type in scope (Windows servers, Windows workstations, Linux systems, network devices, cloud instances), document the approved baseline configuration — the security-relevant settings that every instance of that system type should have. CIS Benchmarks and DISA STIGs are the standard source baselines; customize them for your environment and document the customizations.

Change control process. How do changes to CUI systems get proposed, reviewed, approved, tested, and documented? The process needs defined roles (who can propose, who approves, who implements), documentation requirements (what records are kept for each change), and a security impact analysis step (every proposed change is evaluated for security implications before it's approved).

Change records. Evidence that changes went through the process. Meeting minutes, change tickets, approval emails — whatever your process uses. Assessors sample change records to verify the process is actually being followed.

Software and firmware integrity. Your policy for verifying software before installation — using vendor-provided hashes, signed packages, or known-good sources. This addresses CM.L2-3.4.9 and reduces supply chain risk.

The configuration management plan is often the least polished document in a small contractor's documentation set. It tends to exist as informal practice (the IT admin knows what the baseline is because they configured it) rather than written policy. Document what you're actually doing — this is usually a 20–30 hour writing effort.

---

5. Security Assessment Plan and Report

Required by: CA.L2-3.12.1

Your organization must periodically assess its own security controls to verify they're working. The Security Assessment Plan documents the scope, methodology, and schedule of that assessment. The Security Assessment Report documents the results.

These don't need to be elaborate. The plan should cover: - What systems are being assessed - What assessment methods will be used (review, interview, test) - Who conducts the assessment (internal, external, or both) - The assessment schedule (at minimum annually)

The report captures: - Which controls were assessed - What the assessment found (Met, Not Met, Partially Met) - What evidence was reviewed - What actions are recommended

Gaps found during the assessment feed the POA&M. The chain is: assess → find gap → add to POA&M → remediate → reassess → close POA&M item.

For internal assessments, use NIST SP 800-171A as your assessment guide. It breaks each of the 110 practices into specific assessment objectives and tells you what to examine, interview, and test for each one. This is the same guide your C3PAO uses — running your internal assessment against 800-171A objectives gives you the clearest possible view of your readiness.

---

6. Continuous Monitoring Strategy

Required by: CA.L2-3.12.3

This can be a standalone document or a section within your SSP. It describes how your organization maintains ongoing visibility into your security posture between formal assessments.

Cover: - What automated monitoring tools are in place (SIEM, vulnerability scanner, endpoint detection) - What metrics are monitored (vulnerability counts, failed login attempts, policy compliance percentage) - How often monitoring results are reviewed and by whom - What triggers escalation or out-of-cycle reassessment - How monitoring results feed the POA&M

This doesn't need to be long — 3–5 pages describing your monitoring program is sufficient. The evidence that the program is working (scan reports, SIEM alerts, review logs) lives elsewhere.

---

Additional Documents Depending on Your Practices

Beyond the six core documents, several CMMC domains require additional written plans:

Contingency Plan — required by the CP (system and communications protection) domain if you're implementing CP.L2-3.8.9. Covers backup and recovery procedures for CUI systems. Should be tested at least annually.

Security Awareness Training Plan — not always a standalone document, but AT.L2-3.2.1 and 3.2.2 require a defined training program with role-based components. Document the training content, delivery method, schedule, and completion tracking process.

Access Control Policy and Procedures — the policy framework is expected across multiple domains. The access control policy in particular is a frequent examination target — it needs to describe how you grant, review, modify, and revoke access to CUI systems.

Media Sanitization Policy — covers how you handle disposal and reuse of media containing CUI (MP.L2-3.8.3). Required if you have physical media handling procedures.

---

The Documentation Trap: What Consultants Can and Can't Do

A consultant can give you document templates, write framework text, review your descriptions for completeness and accuracy, and flag gaps between your documentation and the control requirements. They cannot tell you how your specific systems are configured, what your actual data flows are, or what decisions your leadership has made about risk acceptance.

The reason documentation efforts stall is almost always the same: the people writing the documents don't know the environment well enough, and the people who know the environment aren't helping write the documents. Bridge that gap before you start. Pair a consultant or documentation-capable ISSO with a knowledgeable system administrator and operations lead. Block time for discovery sessions. Build the SSP from reality, not from templates.

The decision to do documentation in-house vs. with a consultant comes down to two questions: Do you have someone who can write clearly and understands NIST 800-171? And do you have the time to spend 200–300 hours on documentation in the next 6 months? If yes to both, do it in-house with NIST templates and a consultant review at the end. If no to either, hire a consultant to drive the process — but stay engaged. The documentation will only be as accurate as the information you provide.

---

What Your Assessor Expects

Your C3PAO assessor will request your documentation package in advance of the assessment, typically 2–4 weeks before the on-site visit. They will review it thoroughly before they arrive.

What they look for in the SSP: - Does the boundary description match the asset inventory? - Are implementation descriptions specific (naming tools and configurations) or vague (saying "we use industry-standard controls")? - Is the SSP dated and does it show evidence of recent review? - Does it accurately reflect the current environment, or does it describe a different system than what they'll observe?

What they look for in the POA&M: - Does it reflect known gaps? (If your SSP shows some practices as fully implemented but your internal assessment found gaps, there should be POA&M entries.) - Do items have realistic completion dates and recent status updates? - Are high-risk items being remediated faster than low-risk items?

What they look for in procedural documents: - Are procedures specific enough to follow? ("Run weekly scans" with no further detail is insufficient. "Run authenticated scans weekly using Tenable.io, configured to cover all assets in the SSP inventory, with results reviewed by the ISSO within 5 business days" is sufficient.) - Are documents signed and dated? - Are documents referenced in the SSP actually findable?

Document organization matters. Create a documentation folder structure your assessor can navigate: SSP with its appendices, POA&M, each plan document in a clearly named file, and an evidence folder organized by domain. An assessor who spends 20 minutes finding your incident response plan is an assessor whose patience is wearing thin.

---

A Documentation Roadmap

If you're starting from zero, sequence matters:

1. Complete your asset inventory and data flow diagram (prerequisite for everything)
2. Write your SSP — the boundary, environment, and practice descriptions (80–160 hours)
3. Update your POA&M based on any gaps the SSP writing revealed
4. Write your Incident Response Plan (20–40 hours)
5. Write your Configuration Management Plan (15–25 hours)
6. Document your Continuous Monitoring Strategy (10–15 hours)
7. Write your Security Assessment Plan (10–15 hours)
8. Run an internal assessment against NIST 800-171A objectives and document the results

Total: 200–300 hours for a small-to-mid organization. At a 10-hour-per-week pace, that's 5–7 months. Start earlier than you think you need to.

---

Need documentation reviewed before your assessment? Talk to a consultant about pre-assessment readiness.

Related reading: How to Write Your SSP | Building Your POA&M | Cybersecurity Governance for Defense Contractors