There are vendors selling CMMC compliance software that will tell you their platform covers 90 of the 110 NIST SP 800-171 practices. The number they're counting is documentation practices. The three they don't cover are the ones a C3PAO checks first and the ones that cannot be deferred to a POA&M.
SC.3.177 requires a CMVP validation certificate number — not AES-256 as an algorithm, but a specific module validation record. SC.3.187 requires that your organization controls the decryption keys, not your cloud provider. MP.2.121 requires that CUI protection extends to contractor-controlled devices, including devices that aren't on your network.
Most CMMC compliance software produces documentation that you have a plan for those controls. A C3PAO assessor doesn't ask for your compliance dashboard. They ask for the certificate number, the key architecture evidence, and the per-file access log.
Understanding which software category produces which artifact is the difference between walking into an assessment prepared and walking out without a certificate.
What Does a C3PAO Actually Check on Assessment Day?
C3PAO assessors follow the CMMC Assessment Process (CAP) guide. For the controls that cannot be deferred, the assessment is evidence-based: the assessor asks to see the artifact that proves the control exists, not the policy that says it should.
SC.3.177 (FIPS-validated encryption): The assessor asks for the CMVP validation certificate number of the cryptographic module in use. Many organizations have deployed AES-256 and assumed that satisfies the requirement. It does not. FIPS 140-2/3 validation is a module-level certification. The specific module must appear in the NIST CMVP database with a current certificate. That certificate number goes in your SSP. Without it, the control isn't met.
SC.3.187 (cryptographic key management): The assessor evaluates your key management architecture: who generates the keys, where they're stored, who can access them, and whether a third party could produce your decryption keys in response to a legal order. Cloud provider key management — even BYOK arrangements — frequently fails this evaluation when the provider's systems process the key material.
MP.2.121 (media protection on contractor devices): The assessor evaluates whether CUI on a contractor's laptop, portable drive, or device not enrolled in your MDM is protected. "We only share CUI through a governed platform" is not a complete answer. The assessor wants to know what happens to CUI after the download event.
AU.2.041 (per-access audit logging): The assessor asks for logs showing who accessed which files, when, from which device, with what outcome. Platform-level event logs record when someone accesses a folder or application. Per-file access logs record when someone opens a specific document. That's the level of specificity that C3PAOs request.
🛡️ Are Your Non-Deferrable CMMC Controls Assessment-Ready?
A single missing CMVP certificate or cloud key management gap will trigger an immediate C3PAO failure. Audit your technical evidence artifacts before your assessor arrives.
What Are the Four Categories of CMMC Compliance Software?
"CMMC compliance software" covers four distinct categories with different scopes, different control coverage, and different evidence artifacts. Conflating them is one of the most common reasons organizations walk into an assessment with excellent documentation and incomplete technical evidence.
| Category | Example Platforms | Primary Control Families | Evidence Produced | Non-Deferrable Gap |
|---|---|---|---|---|
| GRC / Documentation | CyberSheath, Drata, Vanta | CA, RA (documentation layer) | SSP, POA&M, policy docs | No technical evidence for SC / MP / AU |
| Cloud Infrastructure | Microsoft GCC High, Azure Gov | AC, IA, SI (platform level) | FedRAMP boundary docs, ATO | SC.L2-3.13.11: CMVP module required; SC.L2-3.13.10: vendor manages keys |
| Endpoint / Security | CrowdStrike, SentinelOne | SI, IR, RA | Endpoint logs, threat alerts | Does not address SC.L2-3.13.11, SC.L2-3.13.10, or MP.L2-3.8.7 |
| File-Layer Encryption | Theodosian | SC.L2-3.13.11, SC.L2-3.13.10, MP.L2-3.8.7, AU.L2-3.3.1 | CMVP certificate, key architecture docs, per-file access logs | Directly closes the non-deferrable gaps |
GRC / Documentation Software
CyberSheath, Drata, Vanta, and similar platforms are compliance program management tools. They track your SSP, manage your POA&M, document your policies, and help you demonstrate which controls are implemented versus planned. They're the backbone of your documentation layer and essential for assessment preparation.
What they don't produce: the technical evidence artifacts that C3PAOs request for SC, MP, and AU controls. A well-maintained SSP says you have FIPS-validated encryption and organizational key control. The C3PAO asks to see the CMVP certificate number and the key management documentation. GRC platforms manage the tracking. Technical controls generate the evidence.
Cloud Infrastructure
Microsoft GCC High and equivalent government cloud environments address the data residency and platform-level access control requirements that underpin CMMC compliance. US-person-only access, domestic data residency, FedRAMP authorization, and integration with Microsoft's compliance tooling collectively cover a substantial portion of CMMC practices across AC, IA, and SI.
The specific gap that assessors probe: SC.3.177 requires a FIPS 140-3 validated cryptographic module certificate number. GCC High uses AES-256 encryption, which is FIPS-approved as an algorithm. The module-level CMVP certificate for the specific cryptographic implementation still needs to be documented in the SSP. For SC.3.187, Microsoft's key management services reduce but don't eliminate Microsoft's theoretical access to key material. Whether that satisfies "organizational control" is a question assessors evaluate case by case.
Endpoint / Security Software
CrowdStrike, SentinelOne, and similar endpoint detection platforms address CMMC's System and Information Integrity (SI), Incident Response (IR), and Risk Assessment (RA) control families. Endpoint protection, behavioral detection, vulnerability scanning, and managed detection and response capabilities collectively address a significant portion of the 110 practices.
The gap: endpoint security platforms don't provide FIPS-validated file-level encryption (SC.3.177), organizational key management (SC.3.187), or media protection that extends to downloaded CUI files (MP.2.121). They protect the device and detect threats. They don't encrypt the files on the device at the file layer.
File-Layer Encryption
File-layer encryption applies FIPS-validated encryption at the file level, with organization-controlled key management, persistent protection that follows files wherever they go, and per-file access logging at the document level. This is the category that generates the evidence artifacts for the three controls that cannot be deferred.
Which CMMC Controls Cannot Be Deferred, and What Software Closes Them?
Under the CMMC scoring model, high-weight controls typically cannot be deferred to a POA&M for conditional certification. SC.3.177 (FIPS encryption), SC.3.187 (key management), and MP.2.121 (media protection) fall in this category. An organization that enters assessment without these controls implemented doesn't receive conditional certification — and a POA&M path isn't available for these specific gaps.
Three questions determine whether your software stack addresses them:
Does the encryption use a FIPS 140-2/3 validated module? Not AES-256 as an algorithm. A CMVP-validated module with a certificate number. The software generating your encryption must have that certificate, and that certificate must appear in your SSP documentation.
Who controls the cryptographic keys? SC.3.187 requires organizational control. If your cloud provider's key management service processes your key material, control is shared. Zero-knowledge architecture, where the vendor's infrastructure never receives the key, satisfies "organizational control" by design.
Does protection extend to downloaded files on contractor devices? MP.2.121 requires media protection that follows CUI to contractor-controlled devices. Relying solely on a governed transfer channel doesn't satisfy the requirement if files can be downloaded onto devices outside your MDM enrollment.
What Evidence Does File-Layer Software Produce That GRC Platforms Can't?
The difference matters because GRC platforms and file-layer encryption produce different categories of evidence.
A GRC platform produces documentation evidence: your SSP states that SC.3.177 is satisfied by a FIPS 140-3 validated encryption module. Your POA&M shows the implementation date. Your policy documents describe the key management procedures. That documentation is necessary.
File-layer encryption produces technical evidence: a CMVP certificate number that appears in the NIST CMVP database, a key management architecture document showing where keys are generated and stored, and per-file access logs showing who opened which document, from which device, at which time, with which policy outcome.
A C3PAO assessor reads your SSP and then asks to validate the claims. "Show me the CMVP certificate number" requires technical evidence. "Show me the key management implementation, not the policy" requires technical evidence. "Show me a sample audit log for a CUI file access event" requires technical evidence.
The gap most assessment failures trace back to: organizations with excellent GRC documentation and incomplete technical evidence. The SSP says the control is implemented. The implementation doesn't produce the artifact the assessor needs to validate it.
How Does Theodosian Map to the Non-Deferrable CMMC Controls?
Theodosian's three-layer architecture directly addresses the controls that generate the most assessment failures.
SC.3.177 (FIPS-validated encryption): Per-file FIPS 140-3 validated AES-256 encryption, with a unique cryptographic key per file. The CMVP validation certificate is available for SSP documentation. The certificate number goes in your control evidence package. Protection follows the file into SharePoint, Google Drive, Dropbox, Box, Windows file servers, NAS shares, and local endpoints. Protect the content, not the container.
SC.3.187 (organization-controlled keys): Patent-pending zero-knowledge architecture. Theodosian's infrastructure never processes your decryption keys. Keys are generated and held within your organizational control. A government subpoena served to Theodosian produces nothing useful. An assessor evaluating whether a third party can access your keys gets a clear architectural answer.
MP.2.121 (media protection on contractor devices): Per-file encryption means the same FIPS 140-3 protection follows CUI to any device. A contractor who downloads a CUI file from your SharePoint environment onto an unmanaged laptop carries the file's encryption with them. Protection doesn't depend on the device being MDM-enrolled.
AU.2.041 (per-access audit logging): Every file open event generates a structured log: user identity, file, device, location, network context, timestamp, and policy outcome. That log exists for access events across all integrated platforms, not just within a single application. It's the audit trail at the level of specificity C3PAOs request.
Deploying Theodosian doesn't require migrating your data. Integration with existing cloud storage (SharePoint/OneDrive, Google Drive/Workspace, Dropbox, Box, Windows file servers) deploys in days. Two-week proof of concept. The file defends itself — on every platform, in every location, on every device.
🔒 Generate Real-Time C3PAO Evidence Across Your Entire Environment
Stop relying on platform-bound promises. Deploy per-file FIPS 140-3 encryption with customer-held keys across SharePoint, Drive, and unmanaged contractor endpoints in days.
Related Reading:
- Best CMMC Compliance Tools for Defense Contractors in 2026: An Honest Buyer's Guide
- Best File Encryption for CMMC and ITAR in 2026
- How to Build a CMMC Audit Trail: What Your Evidence Package Needs to Show a C3PAO
- CMMC Level 2 Encryption Requirements: A Plain-Language Guide
- What Is CUI Scoping, and How Can It Cut Your CMMC Compliance Costs in Half?
FAQs: CMMC Compliance Software & Assessment Readiness
What is the difference between CMMC compliance software and CMMC compliance tools?
The terms are used interchangeably in practice, but the category distinction matters. GRC platforms help organizations manage their CMMC compliance program: tracking control status, maintaining SSPs and POA&Ms, managing evidence collection workflows, and preparing for assessments. Security tools (endpoint protection, file encryption, IAM) implement the technical controls that the documentation describes. For the three non-deferrable CMMC controls — SC.3.177, SC.3.187, and MP.2.121 — the compliance software tracks the requirement while the security tool generates the evidence artifact that a C3PAO validates. Both categories are necessary. Neither substitutes for the other.
Can a single CMMC compliance software platform cover all 110 practices?
No. CMMC Level 2's 110 practices span 14 control families covering access control, encryption, incident response, physical protection, maintenance, personnel security, and more. No single platform addresses all of them because they span organizational process, infrastructure, endpoint, and data-layer requirements. The assessment-ready stack typically combines: cloud infrastructure (GCC High or equivalent), identity and access management (Entra ID, Okta), endpoint protection (CrowdStrike, SentinelOne), file-layer encryption (Theodosian), secure file exchange (Kiteworks), and GRC program management (CyberSheath or equivalent). The CMMC Compliance Checklist breaks this down by control family.
What happens if SC.3.177 or SC.3.187 aren't implemented before an assessment?
These are high-weight controls under the CMMC scoring model. If an organization achieves a raw score below the conditional certification threshold (88 out of 110 practices), they cannot receive even conditional certification. More specifically, if SC.3.177 is completely unimplemented — no encryption architecture at all — the assessment fails immediately rather than generating a POA&M. The distinction: if FIPS-approved encryption is deployed but lacks formal CMVP module validation, that may qualify for a limited POA&M as a 3-point deduction. If no encryption is in place, there's no path to conditional certification.
How does CMMC compliance software handle evidence collection for a C3PAO audit?
GRC platforms like CyberSheath provide structured workflows for evidence collection: mapping controls to artifacts, storing documentation, tracking implementation status, and generating assessment-ready packages. The evidence artifacts themselves come from the technical systems implementing the controls. For SC.3.177, the evidence is the CMVP certificate number from the cryptographic module. For SC.3.187, the evidence is the key management architecture documentation and any key custody agreements. For AU.2.041, the evidence is the per-file access log export, which demonstrates that logging is operating at the required level of specificity. The GRC platform organizes and packages this evidence. The technical controls generate it.