A Working System Security Plan Template For NIST 800-171 And CMMC 2.0 Level 2
Your System Security Plan is the foundation of NIST 800-171 and CMMC 2.0 Level 2 compliance. A well written SSP makes assessments faster, reduces Plan of Action and Milestones work, and gives your leadership a clear map of where you stand. Petronella Technology Group supports DIB contractors, their subcontractors, and the broader regulated community with SSP development and ongoing maintenance built on real NIST 800-171 Revision 3 and CMMC 2.0 Level 2 requirements.
What Is A System Security Plan And What Is It Not?
Terms matter. Before looking at a template, understand what the SSP is supposed to do.
A System Security Plan (SSP) is a written document that describes how a specific system handles security requirements. For NIST 800-171 Revision 3 and CMMC 2.0 Level 2, the SSP is required. It is not a policy document, not a penetration test report, not a risk assessment, and not static. NIST Special Publication 800-18 Revision 1 provides the authoritative guidance on structure.
The System Security Plan (SSP) is a written document that describes how a specific system handles security requirements. For NIST 800-171 Revision 3 and CMMC 2.0 Level 2, the SSP is required. It is not optional, and a generic placeholder document will not pass assessment. NIST Special Publication 800-18 Revision 1 provides the authoritative guidance on SSP structure, and NIST Special Publication 800-171A Revision 3 provides the underlying assessment objectives the SSP must address.
An SSP is not a policy document. Your written information security policies (acceptable use, incident response, access control, and so on) live in separate documents and are referenced from the SSP. The SSP is the system specific implementation document that says, for this specific system, here is how each required security requirement is actually satisfied, including technology in use, procedures followed, and the people responsible.
An SSP is not a penetration test report. It is not a risk assessment, although a risk assessment informs it. It is not a SOC 2 Type 2 attestation. These are related documents in a compliance program, but the SSP is the specific foundation document for NIST 800-171 and CMMC. It is what the assessor reads first, and what Plan of Action and Milestones entries get written against.
An SSP is not static. It is a living document that updates as your environment, your controls, and the requirements themselves change. NIST 800-171 Revision 3 was published in May 2024 and CMMC 2.0 Level 2 assessments follow their own interpretive guidance. Organizations that write an SSP once and forget it fail assessments.
Which Sections Does A Working SSP Template Need To Pass A CMMC Assessment?
A structure that aligns with NIST SP 800-18 Revision 1 and meets CMMC 2.0 Level 2 assessor expectations.
System identification, system description, system environment, CUI handling and boundary, control implementation (all 320+ NIST 800-171 Revision 3 assessment objectives), plan of action and milestones, configuration management references, incident response references, and a revision history. Each section has to map to the specific evidence an assessor asks for.
Section 1: System Identification. System name, unique identifier, responsible organization and individual, system category per FIPS 199 (low, moderate, high), system type (major, general support, minor application), and operational status. For DIB contractors, this section typically also specifies the relevant DFARS contract clauses and the scope of CUI handling.
Section 2: System Description. Purpose, business function, users and user groups, information types processed, data flows, and system boundaries. For CMMC, defining your CUI boundary with precision is essential. Everything inside the boundary is in scope for the assessment. Everything outside is not.
Section 3: System Environment. Hardware inventory, software inventory, network topology, cloud services, supporting technology stack, and physical locations. Diagrams (network, data flow, authentication flow) are strongly recommended in this section.
Section 4: System Interconnections. External systems, third party services, data sharing agreements, and the security controls governing each connection. Microsoft 365 GCC, AWS GovCloud, Azure Government, or other cloud tenants are documented here with their FedRAMP authorization levels.
Section 5: Related Laws, Regulations, And Policies. NIST 800-171 Revision 3, CMMC 2.0 Level 2, DFARS 252.204-7012, any sector specific laws (HIPAA, state privacy laws) that also apply, and pointers to your organization's policy library.
Section 6: Information Types And Categorization. CUI categories handled (Basic, Specified), individual information types and their categorization, and handling requirements (CUI Law Enforcement, CUI Export Controlled, etc.). For many DIB contractors this is where the scope of the SSP is effectively narrowed to only the CUI enclave.
Section 7: Security Requirements Implementation. The heart of the document. Every security requirement from NIST 800-171 Revision 3 (97 requirements in 14 families for Revision 3, updated from 110 in Revision 2) addressed one at a time with implementation narrative, evidence pointers, and any gaps. This section typically runs forty to one hundred plus pages depending on the environment.
Section 8: Plan Of Action And Milestones (POA&M) Reference. POA&M lives as its own companion document but is referenced and summarized here. Every gap identified in Section 7 should have a POA&M entry with target remediation date, responsible person, and status.
Section 9: Roles And Responsibilities. Named individuals with specific security roles, including System Owner, Authorizing Official, Information System Security Officer, and operational roles. CMMC assessors specifically look for named accountability.
Section 10: Appendices. Supporting diagrams, inventories, letter of approval, and any referenced artifact that the SSP cites. Well organized appendices can cut assessment time significantly.
How Do You Write Control Implementations So An Assessor Can Actually Verify Them?
Section 7 is where most SSPs fail. Most organizations either write too little (generic statements that do not address the requirement) or too much (marketing prose that does not map to assessment objectives).
Each control implementation in Section 7 should answer four questions: what the control is, how your organization implements it in this specific system, what evidence demonstrates implementation, and who is responsible. Avoid copy-paste language from the NIST 800-171 requirement itself. Assessors look for tenant-specific specificity, not restated requirement text.
Each NIST 800-171 Revision 3 security requirement should be addressed in a consistent, repeatable pattern:
1. State the requirement. Quote the requirement number and text. For example, 03.01.01 Account Management.
2. Describe the policy. What your written policy says about this requirement, with a pointer to the policy document and version.
3. Describe the implementation. The specific technology, configuration, and procedures that satisfy the requirement. Name the tools. Name the settings. Describe the process in enough detail that an assessor could verify it.
4. List evidence. The artifacts an assessor can examine to verify the implementation. Screenshots, configuration exports, reports, ticket samples, training records. Each evidence item should have a stable location and a responsible owner.
5. Identify responsibility. Who on your team is responsible for operating the implementation, and how often it is reviewed.
6. Note any limitations. If a requirement is only partially met, or met through a compensating control, or scheduled for improvement, say so clearly and reference the POA&M entry.
This pattern applied across all required security requirements produces an SSP an assessor can work through efficiently. Avoid passive voice. Avoid aspirational language. Describe what is actually happening today, with enough specificity that the description survives a challenge.
Common Mistakes We See In SSPs
Copy Paste Templates
An SSP built entirely from a generic template, with placeholder language that was never customized to the actual environment. Assessors spot these within a few pages. Invariably leads to significant findings.
Outdated Scope
An SSP that still references Revision 2's 110 requirements after Revision 3 went live. Systems, vendors, and users that have changed since the last revision. Update cadence is usually missing.
Ambiguous Boundary
CUI boundary is not clearly drawn, so the in scope system is unclear, and the SSP ends up trying to describe the entire enterprise. This pattern causes disproportionate assessment work and often fails.
Missing Named Owners
Roles written in organizational language ("IT team", "Security") rather than named individuals. Assessors want a specific accountable person per role.
No Evidence Links
Implementation narratives with no pointer to the evidence that proves them. Assessors have to hunt, which slows the assessment and raises the risk of findings.
Aspirational Language
"Will be" or "is planned" language for things that should be operating today. Anything that is not in place now goes in the POA&M, not the SSP narrative as if it were done.
How Do You Draw A Defensible CUI Boundary For A CMMC 2.0 Level 2 Assessment?
The single most impactful decision in a CMMC program. A well scoped CUI enclave dramatically reduces assessment cost and ongoing maintenance.
Start with the specific CUI data types your contract handles, then map every system, storage location, network segment, and user role that touches those data types. Everything in scope gets assessed; everything out of scope must be demonstrably isolated. A strong boundary is narrow enough to be assessable and wide enough to be truthful. A vague boundary causes assessment failure more often than any other single issue.
Controlled Unclassified Information has defined handling requirements. Any system that stores, processes, or transmits CUI is in scope for the SSP and for assessment. Any system that does not is out of scope. The practical question for every DIB contractor is how narrowly you can scope the CUI enclave while still supporting the contracts you hold.
Common scoping models include a dedicated CUI enclave in a GCC High tenant with tightly controlled membership, an on premises CUI enclave segregated from corporate IT by network boundary and identity separation, or a hybrid where specific cloud applications are the only CUI processing surface.
The trade off is always between operational convenience (having CUI accessible to more users makes work easier) and compliance burden (more in scope users and systems mean more controls to implement and evidence). Most organizations that have gone through a Level 2 assessment now work with a noticeably narrower enclave than they started with. Learning happens.
Our SSP engagements usually start with a scoping workshop that walks through the specific contracts handled, the information types flowing into and out of CUI enclaves, and the practical implications of alternative boundary decisions. The output is a scope diagram that becomes Section 2 and Section 3 of the SSP, along with the rationale for the chosen boundary documented so leadership and assessors both understand why the boundary is where it is.
Petronella's SSP Engagement Model
Most clients engage us for one of three patterns. Each is built around real delivery outcomes rather than billable hours.
New SSP development. For organizations that have no usable SSP or that have a template filled document that will not pass assessment. We interview your technical team, map your environment, scope the CUI enclave, and build the SSP section by section. Typical duration four to eight weeks. Includes supporting artifacts (data flow diagrams, network diagrams, CUI boundary map) and a POA&M aligned to gaps found during development.
SSP refresh and revision alignment. For organizations that have a working SSP but need to align with NIST 800-171 Revision 3 or update for significant environmental changes. We diff your current SSP against current requirements, rewrite affected sections, update the POA&M, and deliver a refreshed document. Typical duration two to four weeks.
Ongoing SSP maintenance. For organizations that want a named partner responsible for keeping the SSP current quarter over quarter. We review quarterly, update after significant environmental changes, attend your assessment prep meetings, and keep the POA&M current. Usually a fixed retainer, priced per user or per assessment complexity.
Every engagement includes direct interaction with named team members who hold CMMC Registered Practitioner credentials. Our team has Craig Petronella, Blake Rea, Justin Summers, and Jonathan Wood all CMMC-RP certified. The SSP is written in our voice but owned in your organization's name, and the relationship is designed to make your CMMC assessment experience smooth rather than adversarial.
Common Questions
Can we use a free SSP template?
Free templates are a fine starting structure. They are not a finished SSP. The value of a real SSP is in the organization specific implementation narrative, the boundary scoping, and the evidence mapping. Those cannot be copied from a template.
How long should an SSP be?
A typical Level 2 SSP for a mid market defense contractor runs between one hundred and two hundred fifty pages. Very small enclaves with narrow scope can be shorter. Complex multi tenant environments can be longer. Length is not the goal. Complete, specific coverage is.
Who owns the SSP inside our organization?
Usually the Information System Security Officer, with the System Owner as the executive accountable party. We support both roles but the ownership is internal to your organization.
How often should it be updated?
Quarterly review minimum. Immediate updates after significant environmental changes (new system, new contract, new subcontractor, new regulatory guidance). Annual thorough refresh regardless of other triggers.
Is the SSP the same for all CMMC levels?
Level 1 has lighter documentation requirements focused on the seventeen requirements for FCI. Level 2 requires a full NIST 800-171 aligned SSP. Level 3 adds additional requirements from NIST 800-172 on top of the Level 2 baseline.
Does the SSP count for DFARS compliance too?
A Level 2 SSP aligned with NIST 800-171 Revision 3 supports DFARS 252.204-7012 compliance. CMMC 2.0 Level 2 certification is becoming the expected evidence method as the CMMC rollout completes through 2025 and 2026.
What does it cost?
Scoped per environment complexity. A straightforward small DIB contractor engagement is a fixed fee in the mid four to low five figures. Large complex environments are scoped after initial review. We quote before work begins.
The Fourteen NIST 800-171 Control Families
A brief orientation to what Section 7 of the SSP has to cover. NIST SP 800-171 Revision 3 organizes security requirements across fourteen families. Each must be addressed in the SSP.
Access Control (03.01). Account management, access enforcement, information flow enforcement, separation of duties, least privilege, unsuccessful logon attempts, session management, wireless access, mobile devices, and external systems. Usually the longest family in the SSP.
Awareness and Training (03.02). Literacy training, role based training, and insider threat awareness. Evidence typically includes training platform reports and signed acknowledgment logs.
Audit and Accountability (03.03). Event logging, audit record content, audit record storage, audit review and analysis, audit record protection, and audit generation. Maps directly to your SIEM and log retention posture.
Configuration Management (03.04). Baseline configuration, configuration settings, least functionality, system component inventory, and change control. Evidence often includes Intune or SCCM configuration profiles and change management ticketing records.
Identification and Authentication (03.05). User identification, device identification, authentication, password management, and authenticator management. Covers MFA posture, password policy, and service account management.
Incident Response (03.06). Incident handling, incident monitoring, incident reporting, and incident response testing. Evidence includes your IR plan, tabletop records, and actual incident documentation where applicable.
Maintenance (03.07). System maintenance, non local maintenance, and maintenance tools. Often overlooked. Remote support tools need specific handling here.
Media Protection (03.08). Media access, media marking, media storage, media transport, and media sanitization. Covers both physical and digital media, including removable drives and printed material.
Personnel Security (03.09). Personnel screening and personnel termination. Links to HR workflows for onboarding and offboarding.
Physical Protection (03.10). Physical access authorizations, monitoring, visitor control, and environmental controls. Building access systems, camera coverage, visitor logs, and environmental monitoring.
Risk Assessment (03.11). Risk assessment, vulnerability scanning, and risk response. Evidence includes your annual risk assessment, quarterly vulnerability scan reports, and documented remediation.
Security Assessment (03.12). Security assessment, plan of action and milestones, system interconnections, and continuous monitoring. The place where the POA&M is formally documented as a process.
System and Communications Protection (03.13). Boundary protection, cryptographic protection, collaborative computing devices, and mobile code. Covers firewalls, encryption in transit and at rest, and related controls.
System and Information Integrity (03.14). Flaw remediation, malicious code protection, system monitoring, and security alerts. EDR posture, patching cadence, and alerting.
NIST 800-171 Revision 3 organizes these under ninety seven security requirements total. Each requirement should have its own implementation narrative in Section 7 of the SSP.
Documents That Sit Alongside The SSP
The SSP does not live alone. A complete compliance program includes a set of related documents that the SSP references.
Policies and procedures. Acceptable use policy, access control policy, incident response plan, configuration management procedure, and similar. The SSP's Section 7 should reference these documents, not recreate them. Your policy library needs to exist, be versioned, and be accessible for review.
Plan of Action and Milestones (POA&M). The companion to the SSP that tracks every identified gap with a target remediation date, responsible person, and status. Assessors review the POA&M in parallel with the SSP. Open POA&M items are acceptable if managed well. Unmanaged POA&M items signal a broken compliance program.
Asset inventory. Hardware, software, cloud services, and data assets. The SSP references the inventory rather than embedding it. Many clients maintain the inventory in a tool like ServiceNow, Jira, or even a shared spreadsheet. The specific tool matters less than the completeness and currency.
Network and data flow diagrams. Architecture diagrams that show the CUI enclave, user populations, data flows, and security boundary. These typically live as SSP appendices or as separately maintained documents referenced from the SSP.
Risk assessment. Annual documented risk assessment that drives control selection and POA&M priorities. NIST SP 800-30 provides guidance. The risk assessment is usually a separate document referenced from the SSP.
Training records. Annual security awareness training, role based training for privileged users, and insider threat awareness training. Evidence usually comes from your LMS and signed acknowledgments.
Incident response plan and tabletop records. A written incident response plan, exercised at least annually via tabletop, with written records of the exercise. The SSP references both the plan and the exercise cadence.
Vendor and subcontractor management records. Business associate agreements, CUI flowdown clauses in subcontracts, and vendor risk assessment records. CMMC Level 2 explicitly looks at how CUI flowdown is managed.
Organizations that have all of these documents current, referenced from the SSP, and accessible to assessors typically have smoother assessments. Organizations that do not usually spend assessment week scrambling to produce evidence that should have existed all along.
What Happens In The Weeks Before A CMMC Assessment
Even with a well maintained SSP, an assessment is a production. Organizations that prepare well pass. Organizations that do not prepare struggle even with good underlying posture.
Four to eight weeks before a scheduled CMMC Level 2 assessment, most engagements include a full document readiness review. The SSP is walked through with the named owner, the POA&M is reviewed for currency, every referenced policy is pulled and verified, every evidence artifact is located and tested. Any gaps become the final sprint items before assessment.
Two to four weeks before, a mock assessment is often scheduled. The assessor experience is simulated with someone familiar with the CMMC process asking the same questions a C3PAO would. Surprises are better caught in the mock than in the real assessment. We frequently catch SSP language that was clear to the author but ambiguous to a third party, or evidence pointers that have drifted since they were last verified.
One to two weeks before, the team practices the interview format. CMMC Level 2 assessments include interviews with named control owners. These should not be their first experience talking about their controls. Even brief preparation on how to answer questions without over explaining, how to refer to the SSP when asked, and how to honestly state limitations makes a measurable difference in assessment outcome.
On assessment week, the SSP becomes the reference document the assessor reads from. If the SSP is clear, specific, and supported by evidence, the assessment moves efficiently. If the SSP is ambiguous or unsupported, the assessor digs, and the assessment takes longer and produces more findings.
Post assessment, the SSP needs maintenance. Findings become POA&M entries. Any gaps closed during the assessment window get documented. The SSP becomes the basis for the continuous monitoring evidence that supports the certification through its three year period.
Related Services
Build An SSP That Actually Passes Assessment
Petronella Technology Group has delivered SSPs for defense contractors across the Southeast. CMMC-AB RPO #1449. Call (919) 348-4912 to scope your engagement.