There's a meaningful difference between being compliant and being able to prove it.
Many defense contractors have invested in the right controls. They have encryption in place. They have access policies configured. They have an SSP that documents the controls they've implemented. What they don't have — and what surfaces during an audit — is a coherent, auditor-ready evidence package that connects each claimed control to the technical and administrative reality of how it's deployed.
This distinction matters across three audit scenarios that defense contractors face: a C3PAO assessment for CMMC Level 2, a DDTC or DoS review for ITAR compliance, and a DOJ False Claims Act investigation triggered by an inaccurate SPRS score or SSP misrepresentation. Each scenario involves a different auditor asking different questions, but all three converge on the same file security domain.
Here's what each scenario requires, and what a complete evidence package looks like.
The Documentation Gap That Keeps Appearing
The cause of many audit failures in the file security domain is that the documentation trail connecting controls to deployed reality has gaps.
A C3PAO assessor, an ITAR reviewer, and a DOJ investigator are all asking a version of the same question: "You say your sensitive data is protected. Show me the trail — from policy to procedure to technical configuration to evidence of active operation."
Organizations that fail that question typically fail it at one of three points: the SSP describes controls that aren't fully deployed, the deployed controls generate logs that no one is reviewing, or the evidence is scattered across tools and people without a coherent package that can be produced on request.
Scenario 1: C3PAO Assessment — CMMC Level 2
What the Assessor Is Looking for
A Certified Third-Party Assessment Organization evaluates CMMC Level 2 using three methods: examination (reviewing documentation and configurations), interviews (talking to people who manage the controls), and testing (technical verification of claimed capabilities).
For file security controls, the specific practices being scored are:
- SC.3.177 — FIPS-validated cryptographic protection of CUI in transit and at rest
- SC.3.187 — Key management for cryptographic systems used to protect CUI
- MP.2.121 — Media protection for contractor-controlled devices handling CUI
- AC.2.007 — Least privilege access controls for CUI
- AU.2.041 — Audit logging of access to CUI
Each practice is scored as MET or NOT MET. There is no partial credit.
The Evidence Package for C3PAO
| Practice | Documentation Required | Technical Evidence Required | Interview Readiness |
|---|---|---|---|
| SC.3.177 | Encryption policy, CMVP validation certificate for encryption module. | Configuration screenshots showing FIPS-validated encryption active on CUI repositories and endpoints. Theodosian automated FIPS 140-3 validation logs for every file at rest and in transit. | Team members can explain which module is in use and reference its validation certificate number. |
| SC.3.187 | Key management policy, key lifecycle procedures (generation, rotation, destruction), key custodian designations. | Evidence of active key management practices (rotation logs, custodian access records). Theodosian tamper-proof key lifecycle audit trails (generation, rotation, and access) are generated per-file. | Team members can walk through the key management process end-to-end. |
| MP.2.121 | Media protection policy, device inventory, coverage documentation for contractor-controlled devices. | Encryption status evidence for each device category, including documentation for devices outside managed MDM enrollment. Theodosian 'File-Level' telemetry proving CUI remains encrypted even when moved to unmanaged contractor devices. | Team members can explain how CUI is protected on devices not enrolled in your MDM. |
| AC.2.007 | Access control policy, least privilege justification for each role with CUI access. | Current access control configurations, recent access review evidence. | Team members can explain the access decision logic and where context-aware controls are applied. |
| AU.2.041 | Audit logging policy, log retention policy. | Sample audit logs showing CUI access events, evidence of log review. | Team members can demonstrate where logs are stored and how they're reviewed. |
The single most common documentation failure in C3PAO assessments: An SSP that describes controls in aspirational or generic terms, rather than specific deployed reality. If your SSP says "CUI is encrypted using AES-256" but doesn't name the tool, cite the CMVP certificate, and describe the key management architecture, the assessor's follow-up questions will surface those gaps immediately.
📋 CMMC Assessment Readiness Checklist
Get the complete evidence checklist for SC.3.177, SC.3.187, and MP.2.121 — formatted as an assessor-ready documentation guide.
Scenario 2: ITAR/DDTC Review
What the Reviewer Is Looking for
An ITAR audit by the Directorate of Defense Trade Controls (DDTC) focuses on whether your technical safeguards are sufficient to ensure that defense articles and technical data are accessible only to U.S. persons or to foreign nationals with the appropriate license and authorization.
For file security, the key ITAR requirements are:
- Technology controls for technical data (ITAR § 120.31): Access to controlled technical data must be restricted to authorized persons. This means your access controls must be tied to identity and citizenship verification, not just network location.
- Encryption as a safe harbor (EAR § 734.18(a)(5)): Properly encrypted data can qualify for the encryption safe harbor, meaning a transfer of encrypted data is not considered an "export" under EAR if the encryption is FIPS-validated and the key is not provided to the recipient. This is a significant compliance benefit — but it requires documented proof that the encryption in place actually qualifies.
The Evidence Package for ITAR/DDTC
| Requirement | Documentation Required | Technical Evidence Required |
|---|---|---|
| Access control for technical data | Technology Control Plan (TCP), role-based access authorization, and citizenship verification in the access workflow | Access control configuration showing identity-bound restrictions on controlled technical data files |
| Encryption safe harbor eligibility | Encryption policy, CMVP certificate, documentation that keys are not provided with encrypted files | Evidence of encrypted file transfers with no corresponding key transfer to unauthorized recipients |
| Audit trail for technical data access | Audit logging policy, retention schedule | File-level access logs showing who accessed which controlled technical data documents, and when |
| Incident response for unauthorized access | Incident response plan for potential ITAR violations | Record of any access anomalies and the response taken |
The ITAR-specific evidence requirement that catches organizations unprepared: The TCP (Technology Control Plan) must describe not just your organizational policy but your specific technical controls. "We use encryption" is not sufficient. The TCP must name the encryption tool, cite the FIPS validation, describe the key management architecture, and demonstrate that the encryption safe harbor analysis has been performed.
Scenario 3: DOJ / False Claims Act Investigation
What the Investigator Is Looking for
A DOJ False Claims Act investigation in the defense contractor context typically originates from one of two triggers: a qui tam action by a whistleblower who alleges that a contractor submitted inaccurate SPRS (Supplier Performance Risk System) scores, or a breach event that surfaces SSP misrepresentations.
The DOJ's interest is straightforward: did the contractor certify compliance with cybersecurity requirements it knew — or should have known — it wasn't meeting? File security controls are a specific focus because they're among the most commonly inflated in self-assessment.
In December 2025, a defense subcontractor settled a DOJ FCA action for $4.6 million specifically related to inaccurate cybersecurity certifications. The controls cited included encryption and access management — the exact domain this post covers.
The Evidence Package for FCA Defense
| Risk Area | Documentation That Protects You | What to Avoid |
|---|---|---|
| SPRS score accuracy | Documented gap assessment history, POAM (Plan of Action and Milestones) for any controls not fully met, and score calculation methodology. | Inflated SPRS scores that don't reflect the actual control status. |
| SSP accuracy | SSP version history showing controls were claimed only after deployment, evidence of active control operation. | SSP is claiming controls as implemented before the technical deployment was complete. |
| Encryption control status | CMVP certificate, deployment evidence, and key management documentation. | Claiming FIPS-validated encryption when the module hasn't been CMVP-validated, or the validation certificate has lapsed. |
| Evidence of active management | Audit log review records, key rotation records, and access review records. | Static documentation with no evidence of ongoing operation. |
The FCA-specific risk that most contractors underestimate: The Act's liability doesn't require intent to defraud. "Reckless disregard" for the accuracy of a compliance certification is sufficient for liability. If your SSP described encryption controls that an internal reviewer could have identified as inaccurate, the FCA exposure exists regardless of whether the misrepresentation was intentional.
The Common Thread Across All Three Scenarios
Across C3PAO, ITAR, and FCA scenarios, the evidence that passes is structurally the same:
1. Policy and procedure documentation that describes what you do, specifically — not generically.
2. Technical configuration evidence that proves the described controls are deployed and active.
3. Operational evidence — logs, review records, key rotation records — that show the controls are being actively managed, not just installed and forgotten.
4. Gap documentation (for controls not fully implemented) that shows you know what's incomplete, have a remediation plan, and are managing the risk — rather than pretending the gap doesn't exist.
The organizations that pass these reviews aren't the ones with the most sophisticated encryption architecture. They're the ones whose documentation trail is clean, current, and matches their deployed reality.
Building the Package Now
The worst time to build an evidence package is during an audit. The evidence that holds up under scrutiny is the evidence that was generated in the course of normal operations — access logs that accumulated over months, key rotation records that show consistent process adherence, SSP versions that document the progression of implementation.
Start the package now. Assign ownership for each control's evidence to a specific person. Schedule a quarterly review to verify that operational evidence is being generated and retained. And when the assessment, review, or investigation arrives, the package exists.
🔒 Generate Audit Evidence Automatically
Theodosian's per-file encryption generates assessor-ready access logs, encryption status evidence, and key management documentation as part of normal operation, not as a separate audit prep exercise.
FAQs: Surviving a File Security Audit Review
What specific documents does a C3PAO assessor require to score SC.3.177 as MET?
Three categories of evidence are required. First, the CMVP validation certificate for the specific cryptographic module in use — not just the algorithm name, but the module certificate number from the NIST CMVP database. Second, technical configuration evidence showing that the FIPS-validated module is active on CUI repositories and endpoints — configuration screenshots, system settings exports, or technical documentation. Third, your encryption policy document describes the requirement. The interview component requires a team member who can name the module, reference its certificate number, and explain where it's deployed. "We use AES-256" without the certificate fails the control.
What is the difference between an SSP and a POAM, and do I need both?
Yes, both are required. The System Security Plan (SSP) documents your security controls as implemented — it describes your current environment, the controls in place, and how each requirement is met. The Plan of Action and Milestones (POAM) documents controls that are not yet fully implemented — it records the gap, the planned remediation, the timeline, and the responsible party. An SSP without a POAM for any open gaps creates FCA exposure: if your SSP claims all controls are implemented when some are still in progress, that's a misrepresentation. A POAM that accurately reflects open items actually reduces your risk by demonstrating you're managing gaps rather than hiding them.
What is a Technology Control Plan (TCP), and when is it required for ITAR compliance?
A TCP is required for any organization that handles defense articles or controlled technical data and employs — or grants access to — foreign nationals. It documents how the organization prevents unauthorized access by foreign persons to ITAR-controlled technical data. For file security, the TCP must describe your technical controls in specific terms: which encryption tool, the FIPS validation, the key management architecture, and the identity-based access controls that restrict access to authorized U.S. persons. A generic statement that "data is encrypted" is not sufficient for DDTC. The TCP must also address physical access, IT system access, and the procedures followed when a foreign national is present in the environment.
How long do I need to retain audit logs to satisfy CMMC Level 2 and ITAR requirements?
NIST 800-171 (which underpins CMMC Level 2) requires that audit records be retained for a period sufficient to support after-the-fact investigations — the DoD typically expects at least 90 days of active log availability, with longer-term retention (one to three years) for archived records, per your organization's audit policy. For ITAR, the DDTC requires records related to controlled technical data handling to be retained for five years. In practice, the safest approach for a contractor subject to both is to retain file-level access logs for a minimum of three years with active access to at least 12 months. Your SSP and audit logging policy must specify your retention periods explicitly — an assessor or reviewer will ask.
The Theodosian Advantage for Audit Compliance: While standard systems often "roll" or delete logs to save space, Theodosian is built for long-term regulatory durability:
- Immutable, Perpetual Retention: Audit logs in the Theodosian platform are kept for the entire duration of your time as a customer. We do not delete your access logs after a set period, ensuring you always have the evidence needed for a multi-year ITAR lookback or a CMMC assessment.
- On-Demand Portability: You can download your full audit logs at any time. This allows you to integrate file-access data into your SIEM or provide raw evidence to a C3PAO assessor during an audit.
- Zero-Knowledge Continuity: Because our architecture is zero-knowledge and decentralized, your audit history is tied to your active organization. Please note that audit logs are non-transferable; if you cease being a customer and return later, you cannot "pick up where you left off" with old logs. Compliance requires an unbroken chain of custody, and we enforce that mathematically.
Assessor Tip: Don't just rely on a vendor's "retention" claim. Your System Security Plan (SSP) must explicitly state your retention periods. Using Theodosian allows you to simply state: "File-level audit logs are retained for the duration of the system's lifecycle," which is a much stronger position than the minimum 90-day requirement.
What actually triggers a False Claims Act investigation against a defense contractor, and how common is it?
FCA investigations in the defense contractor cybersecurity context are triggered by two primary events. First, qui tam actions: whistleblowers (often current or former employees) who allege that a contractor submitted inaccurate SPRS scores or certified compliance it didn't have. Second, breach events that cause the DoD or an Inspector General to examine the contractor's pre-breach security posture and certifications. The DOJ Civil Cyber-Fraud Initiative — launched in 2021 — specifically targets government contractors who misrepresent their cybersecurity compliance. Actions have accelerated since 2023. Settlements have ranged from hundreds of thousands to tens of millions of dollars. The consistent thread is contractors who certified DFARS 252.204-7012 compliance without actually meeting NIST 800-171 requirements. The FCA's "reckless disregard" standard means intent is not required — if the gap was discoverable, liability can follow.