The Bureau of Industry and Security (BIS) does not announce enforcement reviews months in advance. They issue an administrative subpoena, open an end-use check, or refer a case to the DOJ. When that happens, a compliance officer has days, sometimes hours, to produce documentation proving that EAR controls were real, operational, and applied consistently.
Most teams pass the policy test. They have an export compliance program, a technology classification list, and records of annual training. What they cannot produce on short notice is the operational evidence: access logs with timestamp integrity, documented denials of unauthorized access attempts, and a chain-of-custody record for EAR-controlled files that left the primary network.
Understanding what EAR compliance requires of your organization is the starting point. But a BIS audit is not a policy review. It is an evidence review, and the two demand entirely different preparation.
🛡️ Audit-Proof Your EAR Data
Stop manually building logs. Automate your evidence package today.
The 5 Critical Evidence Categories for a BIS Enforcement Review
A BIS enforcement review is a records request. Enforcement staff look for five specific categories of documentation:
- Transaction Records — documentation of every export, reexport, or deemed export involving EAR-controlled items. This includes the Export Control Classification Number (ECCN), the applicable license or license exception, and the verified identity of each recipient.
- Access Logs — records showing who accessed EAR-controlled technical data, when, from which device and location, and under what authorization. This is the category where most companies have a gap.
- Technology Classification Documentation — written records showing that each controlled item was correctly classified, by whom, and when. Reclassification events must be documented with a rationale.
- End-User Verification — evidence that denied-party screening against the Entity List, Denied Persons List, and Unverified List was performed before each transaction. A screenshot of a check run six months ago does not satisfy this requirement.
- Remediation Records — if any violation or near-miss occurred, BIS expects documentation of the corrective action taken, including technical controls applied and the timeline of implementation.
Why Manual Tracking Fails the Evidence Test
Most export compliance operations run on spreadsheets, email threads, and periodic manual audits. The problem is not that this approach is insincere. The problem is that it produces records that BIS cannot independently verify.
A spreadsheet access log has no cryptographic timestamp and can be edited. It contains no chain-of-custody record demonstrating that the data it describes was actually protected at the time of access. An email thread documenting a file transfer does not prove the file was encrypted during transit or that the recipient's authorization was checked at the moment they opened it.
This problem compounds for companies managing EAR-controlled data across cloud environments and remote teams. When files travel through OneDrive, SharePoint, Slack, and a subcontractor's local drive, a manual log cannot follow them. The access record breaks at every handoff point, which is precisely where BIS looks.
The Technical Standard that Satisfies the Obligation
For EAR-controlled technical data, the appropriate encryption baseline is FIPS 140-3 validated cryptographic modules — the current federal standard, which superseded FIPS 140-2 in March 2022. NIST SP 800-171 control 3.13.10 explicitly requires FIPS-validated cryptography for protecting Controlled Unclassified Information (CUI), which frequently overlaps with EAR-controlled technical data in defense contractor environments.
FIPS 140-3 validation matters to a BIS audit for a specific reason: it is an independently certified, federally recognized cryptographic implementation. When you produce evidence of FIPS 140-3 validated encryption applied to a controlled file, you are citing an objective technical standard rather than a vendor claim or internal assertion.
There is a meaningful distinction here from what most cloud providers offer. A cloud storage bucket encrypted with AES-256 is not automatically FIPS 140-3 validated. The validation covers the cryptographic module, its design, implementation, and key management, not just the algorithm. This matters when a BIS reviewer asks how you can confirm the encryption was implemented correctly, not just that it was switched on.
This distinction is also directly relevant when determining whether EAR or ITAR governs your specific export obligations, since the two regimes impose different technical control requirements and different evidentiary standards during enforcement.
What an Automated Evidence Package Looks Like
File-level encryption with persistent access controls generates the evidence package BIS requests; automatically, on every file, without a compliance officer assembling it before a review.
Specifically, Theodosian's per-file controls generate a tamper-evident audit trail that records: the identity of every user who opened a controlled file; the device, location, and credentials presented at the time of access; each policy condition checked and any that failed; and every access denial event, including the reason the system refused.
That record is not a log you produce; it is created at the moment of each access event and stored independently of the file. A BIS reviewer requesting access records on a specific controlled document receives a complete, timestamped chain of custody, not a spreadsheet someone compiled the week before the audit.
30-Day EAR Audit Readiness Checklist
| Status | Action Item |
|---|---|
| Confirm every EAR-controlled file in your environment has an assigned Export Control Classification Number (ECCN). | |
| Verify that FIPS 140-3 validated encryption is applied at the file level, not just at the storage or transit layer. | |
| Confirm automated access logs are generating per-file records with cryptographic timestamps for all controlled data. | |
| Run a current denied-parties screen (Entity List, Denied Persons List, Unverified List) against all active recipients of EAR-controlled technical data. | |
| Test access denial by attempting to open a controlled file from an unauthorized device or location, and confirm the denial event is logged with the reason recorded. | |
| Review cloud storage configurations to confirm EAR-controlled files are not accessible to foreign nationals without documented authorization. | |
| Verify technology classification records exist for each controlled item and include the classifying party, date, and ECCN assigned. | |
| Produce a sample evidence package for one controlled file, transaction record, access log, classification documentation, end-user verification, and confirm it tells a coherent story without manual assembly. |
🛡️ Standard DLP Isn't Enough for EAR
See why defense contractors are moving to data-centric evidence for BIS readiness.
FAQs: EAR Enforcement & BIS Audit Readiness
What typically triggers a BIS audit or enforcement review?
BIS enforcement actions are typically triggered by one of three events: a voluntary self-disclosure by the company, a tip or referral from another agency (often DDTC or DOJ), or a routine end-use check that surfaces anomalies. Companies in the defense industrial base or those handling dual-use technology are at a higher baseline risk of a check than most commercial entities.
How long does BIS require EAR compliance records to be retained?
BIS requires retention of records related to exports for five years from the date of export or from the date of any applicable license. For access logs and technology classification records, maintaining them for the full five-year period is the minimum standard. Automated, timestamped records are significantly easier to retain in audit-ready format than manual logs.
Is AES-256 encryption sufficient to satisfy EAR technical control requirements?
The algorithm alone is not sufficient. NIST SP 800-171 requires FIPS-validated cryptographic modules — meaning the implementation, not just the algorithm, has been independently verified to federal standards. A cloud provider using AES-256 without a current FIPS 140-3 module validation does not automatically satisfy the technical control standard required for CUI and EAR-controlled technical data.
Can file-level encryption replace an export compliance program?
No. Technical controls address the data protection and audit trail obligations, not the transaction reporting, classification, and recipient verification obligations. A complete EAR compliance posture requires both an operational compliance program and technical controls that generate auditable evidence of that program running consistently on every controlled file.
What is the practical difference between an EAR compliance policy and EAR compliance evidence?
A policy documents your intent. Evidence proves what you actually did. BIS enforcement is interested in the latter. If your policy states that all EAR-controlled files are encrypted and access-logged, your evidence should be a complete record of those controls operating on every file, automatically, without exception, not a policy document signed by the compliance officer.