Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
Your System Security Plan (SSP) is the document an assessor reads before they walk through your assessment. It becomes the baseline for their questions. If your SSP says you have Active Directory with multi-factor authentication and the assessor finds you still use local user accounts with no MFA, that gap is worse than never having claimed the control at all.
The SSP is not a compliance checkbox. It’s a working document that describes your actual system: what you’re protecting, where it lives, who uses it, how you’ve implemented controls, and what systems depend on you or you depend on. When your environment changes, your SSP changes.
What the assessor is actually evaluating
The assessor is checking whether you have a current, accurate written description of your system and how it’s secured. Specifically:
Does the SSP describe your actual system boundary (what systems and data are in scope)?
Does it explain your environment of operation (on-premise, cloud, hybrid, who operates each part)?
Does it contain implementation statements for each security control, written in your own words about your own environment?
Does the SSP match what the assessor finds when they look at your systems?
When did you last update it? Does the update date match major changes you’ve made?
This is a high-difficulty practice because it requires accurate understanding of your own environment and the discipline to keep the document current. Contractors often underestimate how much the assessor relies on the SSP as a roadmap for the entire assessment.
What your SSP should contain
System Boundary and Environment: A clear description of what you're protecting. Example: "Our system consists of three Windows 10 workstations and one Windows Server 2019 domain controller located in our office. These systems handle CAD files and technical drawings for aircraft development. One part-time remote user connects via VPN. We also use cloud-based Sharepoint for project documentation."
System Relationships: Any connections to external systems. Example: "Our engineering team receives design specifications from our customer's FTP server twice weekly. Our finance system uploads invoices to our customer's accounting portal. We do not store customer data; we process it and return results weekly."
Implementation Statements: For each control, a plain-language statement about what you do. Example for CA.L2-3.12.4 itself: "We maintain this System Security Plan as a living document describing our environment, controls, and system boundaries. We review and update the SSP at least annually in January, or whenever significant changes occur. Changes are tracked with a revision date and summary of modifications. The plan is stored in our shared drive and is accessible to authorized personnel involved in system administration and security."
Update History: A log showing when the SSP was reviewed and what changed. Example: "Updated March 2026: Added description of new Azure AD integration and retired local Active Directory. Updated January 2026: Added two additional workstations. Last reviewed October 2025: No changes."
The SSP doesn’t need to be a huge book. Length varies, and there’s no minimum page count. What matters is that everything is clearly covered in writing with precise, accurate language. The assessor reads every word. If your SSP says “we enforce MFA on all endpoints” and one laptop doesn’t have it, that’s a credibility problem that colors the rest of the assessment.
The SSP is not a template with your company name filled in. An assessor can spot that immediately. They’ll ask questions like “Tell me about your system boundary” and if your SSP says one thing and your actual environment says another, you’ve given the assessor a reason to look deeper at everything else.
A second critical point: your SSP should describe what you actually have, not what you aspire to have. If multi-factor authentication is on your roadmap for next quarter, don’t describe it in the SSP yet. If you’ve decided on a configuration but haven’t implemented it yet, don’t include it. The SSP is a snapshot of your current state.
How to present your evidence
Bring your SSP to the assessment. The assessor will have read it beforehand. They may ask you to walk through it or explain specific sections.
Bring your SSP and any update logs or version history that shows you’ve reviewed and maintained it over time. This might be:
A revision history section in the document itself
Timestamps showing when the document was last modified
Meeting notes from your annual review showing who reviewed it and what was checked
Change records showing what was updated when
If you use a tool to manage your SSP (a shared drive, a compliance management system, a Google Doc with version history), show the assessor the tool. They want to see that this is a living document you actually use, not something written once and filed away.
If your environment has changed recently, walk the assessor through those changes. Example: “In September 2025 we migrated from on-premise Exchange to Microsoft 365. We updated the SSP in October to reflect this. Here’s the change we made.” This shows you understand your environment and maintain your documentation.
Common failures
SSP hasn’t been updated in years. The creation date is 2022, the last update is 2023, and it’s now 2026. Your environment has definitely changed. You’ve added systems, upgraded software, hired people, or moved to the cloud. The assessor will find these changes and wonder why your SSP doesn’t reflect them. This signals that you don’t actively manage your security program.
Template language left in the document. Sections like “The organization implements role-based access control in accordance with industry best practices” without saying what you actually do. Or descriptions of controls you claim to have but don’t actually operate. When the assessor asks to see your implementation, you can’t produce evidence.
SSP describes the wrong environment. You say you have on-premise Active Directory managing user access, but you switched to Azure AD two years ago. Your SSP says you use specific firewall rules to control network traffic, but you’ve moved to a cloud environment with different network controls. This creates credibility problems immediately.
No implementation statements tied to actual controls. The CMMC framework has 14 practices at level 2. Your SSP should have at least 14 sections describing how you implement each one. Generic descriptions or one-paragraph overviews aren’t enough. The assessor needs to understand your specific approach to each control.
SSP is disconnected from system boundary definition. Your SSP describes “all systems in the organization” as in scope, but your actual boundary (defined under SC.L2-3.13.1) is more narrowly defined. Or vice versa. The SSP and your boundary protection practice need to align.
If you use an MSP or MSSP
If a managed service provider operates part of your environment, the MSP may maintain the SSP documentation for their portion. You should still review it, understand it, and be able to explain it to the assessor.
If an MSSP is managing your compliance program, the best ones have a proprietary SSP template they’ve refined through multiple assessments. They’ll work through it with you section by section, filling in your environment details, your specific controls, and your actual processes. This is one of the strongest reasons to work with an MSSP that has assessment room experience. They know what language assessors expect and what level of detail satisfies each practice.
You remain responsible for accuracy. The assessor will ask you questions about the SSP, and you need to be able to answer them from actual knowledge, not just reading what the MSSP wrote. But having an MSSP who has built dozens of SSPs means your starting point is already tested against real assessments.
If you outsource part of your system (cloud hosting, payroll processing, email), the SSP should describe the service you use and how it fits into your overall system boundary. Example: “We use AWS for hosting our web application. The application runs on EC2 instances in a VPC. Database backups are stored in S3. We manage access control for our development team’s AWS accounts through IAM roles.”
Assessment room tips
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Q&A: What the assessor asks and what good answers sound like
Tell me about your system. What's in scope and what's out of scope?
[Pull up SSP Section 1, system boundary diagram] Our CUI boundary covers three Windows workstations used by the engineering team, one project management server, and Microsoft 365 GCC High for email and file storage. Personal devices are out of scope. Here's the boundary diagram.
Your SSP says you reviewed it in January 2026. Walk me through what changed since the last review.
We confirmed all three workstations are still in use, verified systems are on supported OS versions, and updated the access control section because we removed a departing employee. No new systems were added. The review notes are in Appendix B with the date and who participated.
You describe multi-factor authentication in your SSP. Show me how you've implemented it.
[Pull up Entra ID Conditional Access] Here's the policy requiring MFA for all users. It applies to every cloud app in our tenant. [Show a test login] Watch, it prompts for the authenticator app after the password. Every user is enrolled.
What's your system's connection to external systems?
We have a VPN connection to our prime contractor's portal for deliverable uploads. [Pull up SSP Section 7] It's documented here with the protocol, frequency, and what data flows through it. We also connect to our MSSP's SIEM for log forwarding. Those are the only two external connections.
Who's responsible for updating the SSP when changes happen?
Our IT director and our MSSP's compliance lead review it together. Any infrastructure change goes through a ticket, and the SSP gets updated as part of closing that ticket. We also do a full review at least annually.
Disclaimer: This page describes CMMC practices based on the NIST SP 800-171 security control framework. This is not official DoD guidance. Assessments are conducted by C3PAOs. For official CMMC requirements and documentation, visit the Cybersecurity Maturity Model Certification program resources.
New practice breakdowns and assessment tips every week. Follow on Substack to stay current as the November 2026 deadline gets closer.