StealthTech
Every CMMC Level 2 assessment begins the same way. Before interviews are scheduled, before a single system gets examined, before any technical testing occurs, the assessor sits down with the System Security Plan. Everything that follows — the questions asked in interviews, the configurations examined during technical testing, the evidence requested to support control claims — flows from what that document says.
This dynamic makes the SSP the most consequential document in a CMMC compliance program, and consistently the most underdeveloped one. Defense contractors that invest heavily in implementing security controls but give the SSP only surface-level attention regularly encounter a specific assessment experience: controls that are genuinely implemented get scored as Not Met because the documentation supporting them doesn’t satisfy assessor standards. Work that should have earned a clean certification produces findings — not because the security wasn’t there, but because the documentation didn’t demonstrate that it was.
Building a well-constructed SSP is not a writing exercise. It requires accurate knowledge of the technical environment, specific understanding of how each control is implemented in that environment, and disciplined documentation that connects the two in language that assessors can verify. This guide covers what that actually looks like in practice.
What the System Security Plan Is — and What It Is Not
The SSP is a formal document that describes the information system, the security requirements applicable to it, and the controls in place to meet those requirements. For CMMC Level 2, it covers all 110 practices drawn from NIST SP 800-171, documenting for each one how the requirement is satisfied within the organization’s specific environment.
What the SSP is not is a security policy document. Policies describe what the organization requires of its personnel and systems — rules and standards. The SSP describes how those policies are implemented in the actual environment — the specific configurations, tools, processes, and controls that make the policies operational. A policy that says “all users must use multi-factor authentication” belongs in the access control policy. The SSP describes the specific MFA implementation: which identity provider enforces it, what authenticator types are authorized, how enforcement is verified, which accounts are covered, and what the exception process looks like.
The SSP is also not a one-time deliverable. It’s a living document that must reflect the current state of the environment at all times — not just at the time of initial creation or at the time of the last assessment. Every significant change to the CUI environment requires an SSP update: new systems added to scope, vendor relationships with access to CUI systems changed or terminated, security tools replaced, network architecture modified, personnel access responsibilities shifted. An SSP that accurately described the environment 18 months ago but hasn’t been updated since is a liability during a CMMC assessment, not an asset.
Understanding this — that the SSP is a technical implementation description that must be continuously maintained, not a policy declaration that gets written and filed — is the foundational mindset shift that separates organizations that build effective SSPs from those that don’t.
The Scope Definition: Where the SSP Begins
The SSP cannot be built until the assessment scope is defined, because the SSP describes the security environment within that scope. Every decision about what goes into the SSP flows from the scope determination — which systems are in scope, which network segments are included, which personnel are covered, which vendors operate within the compliance boundary.
The scope definition embedded in the SSP needs to be specific enough that an assessor can understand exactly what’s covered and what isn’t, and why. This means a written narrative describing the CUI environment, a network diagram showing where the assessment boundary lies relative to the rest of the organization’s infrastructure, an asset inventory listing all in-scope systems by type and function, and a description of how in-scope and out-of-scope environments are separated and what controls maintain that separation.
The scope narrative is where most SSPs first show their weaknesses. Vague scope descriptions — “all systems that handle CUI” without specifying which systems those are — leave assessors with questions that should have been answered in the document. Overly broad scope descriptions that include systems that don’t need to be in scope create unnecessary assessment surface area. Scope descriptions that don’t address how out-of-scope systems are isolated invite questions about whether the isolation is real or just asserted.
A well-defined scope narrative answers the questions an assessor would ask before asking them: What systems process, store, or transmit CUI? What systems provide security functions for those systems? How are those systems separated from the general corporate environment? What vendors have access to the CUI environment, and under what conditions? What happens when a user needs to move between the CUI environment and the general corporate environment?
The work required to answer these questions accurately is the data flow analysis and system inventory work that precedes SSP writing. If that foundational work hasn’t been done, the scope description in the SSP will be inaccurate — and inaccuracy in the scope description creates problems throughout the rest of the document, because everything else the SSP says is scoped to what the boundary description defines. Our guide on how to scope your CMMC environment correctly covers the scoping methodology that precedes and informs SSP development.
System Description: Building the Technical Foundation
After the scope definition, the SSP includes a system description — a narrative account of the CUI environment’s technical architecture, the types of information it processes, the users who access it, the systems and applications that comprise it, and the interconnections between those components and external systems.
The system description is where an assessor who has never seen your environment forms their initial mental model of what they’ll be evaluating. A system description that reads like a marketing summary — “our environment leverages modern cloud infrastructure to securely process sensitive defense information” — gives the assessor nothing to work with. A system description that identifies the specific cloud platform, describes which services are used and for what purposes, identifies the user population by role and access level, describes how CUI enters the environment and how it’s stored and transmitted, and identifies the external connections that exist tells the assessor what they actually need to know.
Specific elements that should appear in a well-constructed system description include the types of CUI the system processes and the contracts or programs that generate it, the information flow diagram or narrative describing how CUI moves through the environment, the user types and their access levels with approximate population counts, the hardware and software components that comprise the in-scope environment organized by function, the boundary protection mechanisms (firewalls, network segmentation, access control systems) that separate the CUI environment from external networks and from the general corporate environment, and the external connections including cloud services, vendor access paths, government system connections, and any other network paths that cross the assessment boundary.
For organizations using a co-managed IT model, the system description needs to clearly delineate the responsibilities between the organization and the managed services provider — which systems and configurations are managed by internal staff and which are managed by the provider — because this affects how control implementation is described throughout the rest of the SSP.
Control Implementation Descriptions: The Core of the SSP
The largest and most technically demanding portion of the SSP is the control implementation section — the description of how each of the 110 CMMC Level 2 practices is satisfied within the specific environment. This is where most SSPs fail to meet assessor standards, and where the investment of getting it right pays the largest dividends.
For each of the 110 practices, the implementation description needs to answer three questions: what is implemented, how it is implemented in this specific environment, and where the evidence of implementation exists. These three elements together are what allows an assessor to verify a control claim — to move from “the organization says this control is implemented” to “the organization has demonstrated this control is implemented with specific, verifiable evidence.”
The most common failure mode in control implementation descriptions is answering only the first question — describing what is implemented without describing how. “Multi-factor authentication is implemented for all users accessing CUI systems” describes the what. “Multi-factor authentication is enforced through Azure Active Directory Conditional Access policies that require Microsoft Authenticator or FIDO2 hardware tokens for all accounts with access to the CUI SharePoint environment, the Azure Virtual Desktop instances hosting CUI workloads, and the on-premises file servers in the 192.168.10.x subnet. Service accounts are subject to separate MFA controls through Privileged Identity Management. The policy is named [specific policy name] and enforcement is verified through monthly access reviews conducted by the IT administrator.” That describes the how — with enough specificity that an assessor can verify the claim by examining the Azure AD configuration, reviewing the Conditional Access policies, and confirming coverage through a directory query.
The specificity threshold that distinguishes a verifiable control description from a general one is roughly this: if someone who wasn’t in the building could use your description to locate the specific configuration or process you’re describing, the description is specific enough. If they’d need to ask follow-up questions to find what you’re describing, it isn’t.
Control descriptions also need to be consistent with each other across the SSP. The access control implementation descriptions need to reference the same systems and populations described in the system description. The incident response implementation description needs to reference the same security team and escalation paths described in the personnel security section. Inconsistencies within the SSP — places where different sections appear to describe different environments — generate assessor questions that an internally consistent SSP wouldn’t produce.
Documenting the 14 NIST SP 800-171 Control Families
The 110 CMMC Level 2 practices span 14 control families, and the SSP needs to address each family with appropriate depth. The families vary significantly in their complexity, the number of practices they contain, and the implementation specificity that assessors expect.
Access Control, with 22 practices, is the largest family and the one where SSP specificity has the greatest impact on assessment efficiency. The access control section needs to describe the authorization process for CUI system access, the mechanisms enforcing least privilege, the MFA implementation, the remote access controls, the management of privileged accounts, and the process for revoking access when users leave or change roles — each with specific implementation detail rather than policy-level generality. Given how frequently access control findings appear in CMMC assessments, as covered in our guide on CMMC and NIST 800-171 critical controls, the investment in specificity in this section directly reduces assessment risk.
Audit and Accountability covers nine practices related to generating, protecting, and reviewing audit logs. The SSP description needs to identify which systems generate audit logs, what events are captured, where logs are stored and how they’re protected against unauthorized modification, how long logs are retained, and what the log review process looks like including who reviews, how often, and what the escalation path is when a review surfaces something concerning. The review process description is particularly important — stating that logs are reviewed is insufficient. Describing who reviews them, on what schedule, using what tools, and with what documented output is what assessors look for.
Configuration Management addresses nine practices related to establishing and maintaining secure system configurations. The SSP description needs to reference the organization’s documented baselines by name, describe how they’re applied to in-scope systems, describe the change management process that governs modifications to in-scope systems, and describe how unauthorized changes are detected. For organizations using automated configuration management tools, identifying those tools and describing how they enforce baseline compliance adds specificity that strengthens the description considerably.
Incident Response covers only three practices but carries significant operational weight. The SSP description needs to go beyond “we have an incident response plan” to describe the functional elements of the incident response capability: how incidents are detected and reported internally, who the incident response team members are and what their responsibilities are, how the team is activated when an incident is identified, what the containment and recovery procedures involve, and how incidents are reported to external parties including the requirement under DFARS 252.204-7012 to report CUI-related cyber incidents to the DoD within 72 hours. The testing cadence for the incident response plan — when it was last exercised and what form that exercise took — should also appear in this section.
Risk Assessment covers three practices but connects to the logic of the entire compliance program. The SSP description needs to explain how the organization identifies and evaluates risk to CUI systems, how often formal risk assessments are conducted, who participates in those assessments, how findings from risk assessments are connected to the POA&M and to control decisions, and how vulnerability scanning is integrated into the ongoing risk assessment process.
The remaining control families — Physical Protection, Personnel Security, System and Communications Protection, System and Information Integrity, Identification and Authentication, Media Protection, Maintenance, Awareness and Training, and Security Assessment — each require comparable specificity, with the depth proportional to the operational complexity of the controls they govern in the specific environment being documented.
The POA&M: An Integrated Element of the SSP, Not a Separate Document
The Plan of Action and Milestones documents known gaps in control implementation — practices that are not yet fully met — along with the planned remediation approach, the personnel responsible for remediation, and the target dates for completion. While the POA&M is sometimes treated as a separate document from the SSP, the two are integrated in practice: the SSP describes what is implemented, and the POA&M documents what isn’t yet and when it will be.
The POA&M serves two functions in the CMMC context. Within the compliance program, it’s a management tool that keeps remediation on track by assigning ownership and timelines to known gaps. In the assessment context, it’s a transparency mechanism that signals to assessors that the organization monitors its own compliance posture honestly and manages gaps actively rather than hoping they won’t be noticed.
A POA&M that signals maturity has certain characteristics. Items have specific owners, not just “IT department” — a named individual who is responsible for remediation. Items have specific target dates based on a realistic assessment of remediation effort, not uniformly optimistic timelines that suggest the dates were chosen to look favorable rather than to reflect actual plans. Items include a description of the interim mitigation measures in place while remediation is pending — what the organization is doing to reduce risk while the gap exists. And items have a history: they were opened when the gap was discovered, updated as remediation progressed, and closed with evidence when remediation was completed.
A POA&M that was created immediately before the assessment, lists every item as “in progress,” and assigns uniform 90-day target dates to every finding tells a different story — one that experienced assessors recognize immediately. The document’s history, or lack of it, is as revealing as its contents. Building the POA&M as a living document from the beginning of the compliance program, updating it through the internal audit process, and closing items with evidence as remediation occurs creates a POA&M history that reflects a mature program rather than an assessment preparation exercise.
Network Diagrams and System Inventories: The Visual Foundation of the SSP
The written narrative of the SSP is supported by two essential visual and tabular elements: network diagrams and system inventories. Both need to be accurate, current, and detailed enough to support the assessor’s technical understanding of the environment.
Network diagrams for CMMC purposes need to show more than a general IT architecture overview. They need to show the assessment boundary explicitly — where the CUI environment begins and ends relative to the general corporate network, the internet, and vendor access paths. They need to show the boundary protection mechanisms at those perimeters — firewalls, network access control systems, proxies, and other controls that enforce the separation. They need to show the data flows that cross the boundary — how CUI enters the environment, how it moves within it, and how it exits through authorized channels.
The level of detail that distinguishes a useful network diagram from an inadequate one is roughly: can an assessor, looking at the diagram without asking follow-up questions, understand what’s in scope and what controls protect the boundary? If the diagram requires significant explanation to be interpretable, it needs more detail. If it shows only a high-level topology without boundary controls, vendor connections, or data flow paths, it’s missing the elements assessors need.
System inventories need to capture every in-scope asset — servers, workstations, network devices, cloud instances, mobile devices, and security tools — along with the information that allows assessors to understand each asset’s role in the environment. Asset type, function, operating system, owner or manager, location (physical or cloud), and the specific controls applied to each asset type are the categories that matter. The inventory doesn’t need to be exhaustive at a serial number level, but it needs to be comprehensive enough that assessors can account for all in-scope assets and understand how controls are applied across different asset types.
For organizations using cloud infrastructure, the system inventory needs to reflect cloud resources with the same specificity as on-premises assets — not “Azure cloud resources” as a single line item, but the specific services, subscriptions, and resource groups that are in scope, organized by function and annotated with the controls that apply to each.
Evidence Management: Supporting the SSP With Proof
The SSP describes what’s implemented. Evidence proves it. These are distinct but inseparable elements of a functional compliance documentation package — an SSP without evidence is an assertion, and assertions don’t pass CMMC assessments.
Evidence for each control claim in the SSP takes different forms depending on the nature of the control. Technical controls produce technical evidence — configuration exports, system-generated reports, tool outputs, screenshots of settings that reflect the documented implementation. Process controls produce procedural evidence — documented procedures, meeting minutes from review activities, training completion records, audit outputs showing the process was followed on a recurring schedule. Policy controls produce documentary evidence — the signed, dated policy document and attestation or training records showing personnel were made aware of it.
The evidence management approach that produces the most efficient assessment experience is an evidence library organized by control family — a structured repository where evidence for each of the 14 NIST SP 800-171 families is collected, current, and ready to be produced when assessors request it. Building this library as controls are implemented, rather than assembling it retrospectively when the assessment is approaching, ensures two things: the evidence reflects ongoing operation rather than a point-in-time snapshot, and the collection process reveals gaps in evidence while there’s still time to address them.
The temporal dimension of evidence matters significantly. Evidence that demonstrates a control was implemented once is weaker than evidence that demonstrates it operates continuously. An access review conducted in the month before the assessment is weaker than access reviews conducted quarterly for the past year. A vulnerability scan from last week is weaker than a series of scans over the past 12 months with remediation records showing findings were addressed. Building an evidence library that has history — that shows controls operating continuously rather than being activated for the assessment — is one of the clearest markers of program maturity that assessors look for.
For organizations using managed IT services providers who manage portions of the CUI environment, evidence management requires coordination with those providers to ensure that evidence of their activities within the scope — configuration management, patch deployment, access management, monitoring — is captured in the organization’s evidence library rather than remaining only in the provider’s internal systems. This coordination needs to be structured into the managed services relationship contractually and operationally, not improvised when assessment preparation begins.
Common SSP Failures That Generate Assessment Findings
Understanding where SSPs most commonly fail assessor scrutiny helps organizations focus their development effort on the areas that matter most.
The most pervasive SSP failure is generic control descriptions that describe requirements rather than implementations. An SSP that says “the organization implements least privilege in accordance with NIST SP 800-171 requirement 3.1.3” hasn’t described an implementation — it’s restated the requirement. Assessors encounter this pattern frequently and the corrective question is always the same: how, specifically, is least privilege implemented in this environment? The SSP should answer that question before it’s asked.
Scope inconsistency is the second common failure — places within the SSP where different sections appear to describe different environments. The system description mentions four servers in the CUI environment, but the audit logging section describes three servers generating logs. The access control section describes MFA enforcement for 45 users, but the personnel security section describes 52 personnel with CUI access. These inconsistencies signal that different sections were written at different times by different people without cross-referencing, and they generate assessor questions that a consistent SSP wouldn’t produce.
Currency failures are the third common pattern — SSP sections that were accurate when written but haven’t been updated to reflect subsequent environment changes. A vendor relationship that ended six months ago still appears in the external connections description. A software tool that was replaced appears in the system inventory while its replacement doesn’t. A personnel change that affected security roles isn’t reflected in the access control section. Assessors conducting technical testing compare what they find to what the SSP says, and discrepancies in either direction — things in the SSP that don’t exist in the environment, things in the environment that don’t appear in the SSP — generate findings.
Documentation of process controls without evidence of operation is the fourth common failure. Incident response procedures are described in detail, but no tabletop exercise records exist. Log review is described as a weekly activity, but no review logs exist. Configuration reviews are described as quarterly, but no review records have been produced. Controls described in the SSP need evidence of operation, not just description of intent.
SSP Maintenance: Keeping the Document Current Through the Three-Year Cycle
A CMMC Level 2 certification is valid for three years, and the SSP that supported initial certification needs to remain current throughout that period. The triennial reassessment will evaluate the SSP against the environment as it exists at that time — and an organization that certified on an accurate SSP three years ago but hasn’t maintained the document as the environment evolved will face a reassessment that looks more like a first assessment than a verification.
SSP maintenance requires integrating document updates into the operational processes that drive environment changes. The change management process needs to include a compliance review step that identifies whether a proposed change affects the SSP — whether it changes the scope, adds or removes in-scope systems, modifies how a control is implemented, or creates new external connections. When it does, the SSP update should happen as part of the change implementation, not weeks or months later.
An annual SSP review — a structured review of the entire document against the current state of the environment — is a complement to change-triggered updates, not a substitute for them. The annual review catches the accumulated small changes that individually didn’t seem significant enough to trigger an update but collectively have drifted the document from current reality. It also provides the opportunity to update evidence references, refresh the system inventory, and verify that all external connections and vendor relationships described in the SSP remain accurate.
Building this maintenance discipline into the compliance program from the beginning — treating the SSP as a living operational document rather than a project deliverable — is what produces an SSP at triennial reassessment that accurately reflects a mature, continuously operated compliance program. Our guide on building a continuous CMMC compliance program covers the operational framework that SSP maintenance fits within.
When to Engage Outside Help for SSP Development
SSP development is a demanding exercise that requires both technical knowledge of the environment being documented and specific knowledge of CMMC assessment standards — what level of implementation specificity assessors expect, what evidence references should appear for different control types, and how the document structure should be organized for efficient assessor review.
Organizations that attempt SSP development without one of these two capabilities consistently produce documents that either misrepresent the environment (because the writer didn’t have accurate technical knowledge) or that satisfy documentation requirements at a level of generality that doesn’t survive assessor scrutiny (because the writer wasn’t familiar with assessment standards).
Engaging a compliance advisor for SSP development is most valuable when the advisor has both capabilities — technical familiarity with the types of environments being documented and specific CMMC assessment experience that calibrates their documentation standards against what assessors actually expect. An advisor who has participated in or supported CMMC assessments writes SSP language differently than one who has only studied the framework, because they’ve seen where the language that looks complete to an untrained reader fails to satisfy assessor scrutiny.
A vCIO with defense sector compliance experience can provide strategic guidance on SSP architecture and scope definition — the higher-level decisions that shape how the document is structured before detailed control descriptions are written. That strategic input at the beginning of the SSP development process prevents structural problems that are expensive to correct after the document is substantially complete.
For organizations undergoing significant organizational change — acquisitions, expansions into new markets, major technology transitions — the SSP implications of those changes deserve specific attention. Our piece on how mergers, acquisitions, and business expansion affect CMMC compliance covers how organizational change intersects with compliance documentation requirements and what SSP revisions those changes typically require.
Conclusion: The SSP Is Your Compliance Program on Paper
The System Security Plan is where a CMMC compliance program either demonstrates its maturity or reveals its gaps. A well-constructed, accurately maintained SSP that describes a specifically implemented, continuously operated compliance program is one of the clearest signals an assessor can receive that the organization before them has done the work. A generic, inconsistent, or outdated SSP signals the opposite — regardless of what the underlying security posture actually looks like.
Building the SSP correctly means starting with accurate scope definition, constructing a system description with technical specificity, writing control implementation descriptions that answer how rather than just what, building and maintaining an evidence library that demonstrates continuous operation, and treating the document as a living operational record rather than a project deliverable. That investment pays back at every subsequent assessment and through every year of the three-year certification cycle.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
