Most defense contractors know they need an SSP before their CMMC Level 2 assessment. Fewer understand what an assessor actually does with it, or why the encryption section is where most SSPs quietly fail.
Your SSP is not a policy document; it’s an evidence package. A C3PAO assessor reviews it practice by practice, looking for a documented description of how each control is implemented, where that implementation applies, and what proof exists that the implementation is real. A statement that says "we encrypt CUI at rest" is not implementation evidence. It is an intention statement, and it will generate a finding.
The encryption controls under CMMC Level 2 — particularly SC.L2-3.13.10 and SC.L2-3.13.16 — are among the most frequently misrepresented in SSP submissions. This post explains what those controls require, what a complete SSP encryption section looks like, and where most contractors leave gaps that become assessment failures.
What Is a System Security Plan, and Why Does It Determine Your CMMC Outcome?
The SSP is the central document in a CMMC Level 2 assessment. It maps each of the 110 NIST 800-171 practices to your organization's specific implementation — describing what you have in place, where it operates, and how you know it's working.
When a C3PAO assessor arrives, the SSP is their primary reference. What assessors actually check during a CMMC evaluation is not a review of your stated policies — it is a walk-through of your documented implementation, followed by technical verification. Every practice that lacks a specific, accurate implementation description becomes a candidate for a finding.
The stakes remain immediate. Approximately 80,000 defense contractors handle CUI and fall under Level 2 scope. While the Department of War paused the mandatory C3PAO third-party assessment mandate (Phase II) in July 2026 to review small-business burdens, Phase I self-assessment requirements under DFARS 252.204-7012 and NIST SP 800-171 remain fully active.
When submitting annual SPRS scores or responding to prime contractor flowdown audits, your SSP is the primary evidence package. An inaccurate self-affirmation or missing SSP documentation does not produce a simple remediation request; it creates contract ineligibility and potential liability under the Department of Justice’s Civil Cyber-Fraud Initiative.
What Do C3PAO Assessors Look for in a CMMC SSP?
An assessor reviewing your SSP applies three questions to each practice:
Is the implementation described specifically? "We use encryption" is not a description. "We apply AES-256 encryption using the AWS CMVP-validated cryptographic module (Certificate #XXXX) to all CUI at rest in our SharePoint tenant and on-premises file servers" is a description. The difference between those two statements is the difference between a satisfactory finding and a not-yet finding.
Does the scope match the system boundary? Your SSP must define the assessment scope — the systems, environments, and locations where CUI exists. Any encryption control must demonstrably cover that scope. If CUI can travel to a contractor's laptop, to a cloud storage service, or to a subcontractor's environment, and your encryption description only covers your on-premises server, the scope coverage is incomplete.
Is there evidence that can be independently verified? SSP descriptions are cross-checked against system configurations, technical documentation, and in some cases live technical testing. Implementation claims that cannot be verified through artifacts or system inspection will be downgraded.
📝 Eliminate Generic Language from Your Encryption SSP
Don't let vague "AES-256" claims trigger an audit finding. See how per-file zero-knowledge encryption gives you verified CMVP certificate references and instant audit logs.
Which CMMC Practices Govern Encryption, and What Do They Actually Require?
Two practices sit at the center of the encryption section:
SC.L2-3.13.10 — Employ FIPS-Validated Cryptography: This practice requires organizations to use FIPS 140-3 validated cryptographic modules when protecting the confidentiality of CUI. The requirement is not met by using AES-256 in general — it is met by using a module that appears on NIST's Cryptographic Module Validation Program (CMVP) list. Your SSP must name the specific validated module and its certificate number.
SC.L2-3.13.16 — Protect CUI at Rest: This practice requires that CUI stored in your environment — on servers, endpoints, cloud storage, or removable media — is protected against unauthorized access. Encryption is the typical control, but the SSP must describe which systems hold CUI at rest and how encryption is applied to each.
Two additional practices intersect with encryption implementation:
SC.L2-3.13.8 requires encryption for CUI in transit. Your SSP must describe the cryptographic protocols applied to CUI as it moves between systems, to external parties, and to cloud environments.
AU.L2-3.3.1 and related audit practices require that access to CUI is logged. If your encryption architecture does not generate access telemetry — which key was used, by which user, at which time — you cannot satisfy the audit control requirements with the same implementation.
What Should the Encryption Section of Your SSP Actually Say?
A complete encryption section for SC.L2-3.13.10 and SC.L2-3.13.16 includes the following:
The cryptographic module reference: Name the specific module. Name the CMVP certificate number. Describe where the module is deployed. This is the single most common gap in SSP encryption sections — contractors name an encryption standard (AES-256) without naming the validated module that implements it.
The scope of CUI at rest: List every location where CUI resides. SharePoint. File servers. Endpoint storage. Cloud backup. External sharing environments. For each location, describe how encryption is applied and which module applies it.
The scope of CUI in transit: List every path over which CUI travels. Internal system-to-system. External to partners. External to cloud services. Describe the cryptographic protocol for each path — TLS version, key length, certificate management.
The key management architecture: Describe how encryption keys are generated, stored, rotated, and revoked. If your encryption architecture is zero-knowledge — meaning the vendor cannot access your keys — document that explicitly. Zero-knowledge key architecture removes the vendor from the decryption chain and changes the legal and compliance risk profile in ways that assessors recognize.
The access control integration: Describe how encryption and access policy work together. Who can decrypt which files, under what conditions, and how is that access logged?
The boundary coverage: Explicitly address what happens to CUI when it leaves your primary environment. If CUI is shared with subcontractors, downloaded to endpoints, or accessed through mobile devices, the SSP must describe the encryption controls that apply in those scenarios. The gap between transfer encryption and persistent file-level encryption is exactly where SSP descriptions tend to break down — the practice requires FIPS-validated cryptography, not just a secure channel.
What Is the Difference Between a Policy Statement and Implementation Evidence?
This distinction is the most consequential one in SSP drafting, and it is where most contractors lose findings they didn't expect to lose.
A policy statement describes what you intend to do. An implementation description describes what you have done, where, and how it can be verified. Assessors are trained to distinguish between them, and they will generate a finding for any practice where the SSP offers a policy statement in place of an implementation description.
Policy statement (will generate a finding): "CUI is encrypted at rest using AES-256 encryption across all systems."
Implementation description (satisfies the assessor): "CUI at rest in the Microsoft 365 tenant (SharePoint Online and Exchange Online) is encrypted using the AWS CMVP-validated cryptographic module (Certificate #4316), deployed through Theodosian's per-file AES-256 encryption layer. Each file receives a unique encryption key. Key custody is zero-knowledge — neither Microsoft nor Theodosian holds or can reconstruct decryption keys. CUI stored on endpoint devices is encrypted at rest via BitLocker (FIPS 140-3 mode, CMVP Certificate #XXXX). Access events are logged at the file level and are available for audit review."
The second version answers the assessor's three questions: what is implemented, where does it apply, and how can it be verified.
What Are the Most Common Encryption-Related SSP Failures?
Scope gaps: The SSP describes encryption on the primary server but not on contractor endpoints, cloud backup systems, or external sharing environments where CUI actually travels.
Module vagueness: The SSP names AES-256 without naming the validated module. FIPS 140-3 validation is a property of a specific cryptographic module, not of an algorithm. An algorithm can be implemented in a non-validated way.
No key management description: The SSP describes what encrypts the data but not how keys are managed, who controls them, how they are rotated, and what happens to keys when an employee leaves or a device is compromised.
Missing boundary coverage: The SSP describes encryption within the assessment boundary but goes silent when CUI crosses to subcontractors, partners, or cloud services. CMMC Level 2 POA&M guidance is explicit: encryption boundary gaps are not deferrable. They are day-one assessment failures.
No audit trail linkage: The encryption section is written without reference to how access to encrypted files is logged. Encryption and audit logging must be described as a coordinated architecture, not as separate controls.
Relying on the Phase II pause for delay: Assuming the suspension of C3PAO third-party certifications gives contractors a pass on SSP documentation. DFARS 252.204-7012, mandatory SPRS self-attestations, and DoD DIBCAC direct audits are actively enforced today regardless of the C3PAO review outcome.
How Does a Two-Week Proof of Concept Produce SSP-Ready Documentation?
This is the practical value of deploying before your assessment rather than after.
A Theodosian proof of concept running on your actual file environment produces the following artifacts as byproducts of the deployment itself:
CMVP module documentation: Theodosian's FIPS 140-3 AES-256 per-file encryption runs on FedRAMP Moderate infrastructure using AWS's CMVP-validated cryptographic module. The module reference and certificate number are available for direct inclusion in your SSP's SC.L2-3.13.10 section — no module identification research required.
Access telemetry: Every file access event during the POC generates a log entry: which user, which file, which key, at which time, from which device. This telemetry feeds directly into your audit evidence package and satisfies the AU.L2-3.3.1 implementation requirements.
Boundary coverage evidence: The patent-pending zero-knowledge architecture means encryption persists when files leave your primary environment — when shared with a subcontractor, downloaded to a contractor's laptop, or accessed from a personal device. The SSP description for boundary coverage becomes technically accurate rather than aspirational.
Blast radius documentation: Per-file encryption with a unique key per document means that a credential compromise exposes a bounded set of files rather than an entire repository. The POC produces documentation of this architecture that speaks directly to the assessor's scope-limitation analysis.
An SSP section that would otherwise require 60 to 120 hours of consultant time to produce accurately is generated as a byproduct of a two-week technical evaluation. Building the CMMC audit trail starts at deployment, not at assessment preparation — and the POC is when deployment happens.
📋 Generate CMMC-Ready SSP Encryption Evidence in 14 Days
Validate persistent FIPS 140-3 file encryption across your actual environment.
FAQs: CMMC SSP Encryption Compliance
Can I use a template SSP and fill in my organization's details?
Template SSPs are a legitimate starting point, but they create a systematic failure mode: contractors fill in their organizational name and leave the implementation descriptions generic. An assessor who has reviewed dozens of SSPs recognizes template language immediately, and generic implementation descriptions generate findings regardless of how accurate the underlying security posture is. Your SSP must describe your specific systems, your specific cryptographic modules, and your specific scope.
How specific does the CMVP module citation need to be?
It needs to be specific enough that an assessor can independently verify the module on the NIST CMVP validated modules list. That means the module name, the certificate number, and the version of the module in use. If you are using a cloud provider's infrastructure, the validated module is typically the provider's — AWS, Azure, and Google Cloud all have CMVP-validated modules — and the certificate number is publicly available on NIST's website.
What happens if CUI is shared with subcontractors who don't have CMMC Level 2 certification yet?
Your SSP must address this. The encryption control requirement applies to CUI you share, not just to CUI you store. If you share CUI with an uncertified subcontractor using transfer encryption only — a secure portal, SFTP, or a TLS-protected email attachment — the file is unprotected once it lands on their system. What CMMC requires for sub-tier supply chain CUI is that the protection follows the data, which means your SSP needs to describe how encryption persists after the file leaves your environment.
Is the SSP a one-time document or does it need to be maintained?
The SSP must reflect your current implementation at the time of assessment. It also needs to be updated when your environment changes — new systems, new cloud services, new subcontractors, or changes to how CUI flows through your organization. Many contractors draft an SSP for assessment and treat it as done. C3PAOs increasingly ask about the SSP update process as part of the assessment, because an SSP that doesn't evolve with the environment is an SSP that will diverge from reality and generate findings at the next assessment cycle.