Proof of Compliance: Audits, Records, and Reporting

The DOJ Data Security Program treats compliance as something a U.S. person must be able to demonstrate after a transaction, not merely promise before it. This chapter follows the evidence lifecycle for restricted transactions: what an independent audit examines, what records persist for years, and which events trigger targeted reports. The practical judgment is that an approval, a rejection, or an automated block must leave enough traceable evidence to explain what happened and why.

An audit tests reality, not intention

For each calendar year in which a U.S. person engages in a restricted transaction, the DSP requires an audit that covers the preceding twelve months. The audit is not limited to reviewing the contract that created the relationship. It must examine the U.S. person’s restricted transactions, the Data Compliance Program and its implementation, relevant records, and the applicable security requirements. It must use a reliable methodology suited to a comprehensive assessment.

The required auditor is part of the control. The auditor must be qualified and competent to examine, verify, and attest to compliance and the effectiveness of the applicable security requirements. The auditor must also be independent and cannot be a covered person or a country of concern. Independence matters because the audit is supposed to test the organization’s own claims, not merely repeat the judgment of the team that designed or operated the transaction.

The distinction between policy and operation is the reason for the audit’s breadth. A written policy can say that access is verified, vendors are screened, and security requirements are implemented. The audit asks whether those steps were actually applied to the restricted transactions conducted during the period. It can compare the data-flow record with system behavior, examine the records supporting counterparty diligence, and test whether the written program describes day-to-day practice. A mismatch may reveal a weakness even when no known transfer has produced harm.

The auditor must prepare and submit a written report to the U.S. person within 60 days after the audit is completed. The report must describe the restricted transactions, the methodology used, the policies and documents reviewed, the relevant personnel interviewed, and the facilities, equipment, networks, or systems examined. It must also describe the effectiveness of the Data Compliance Program and its implementation, identify vulnerabilities or deficiencies in the security requirements that affected or could affect access, note instances where those requirements failed or were ineffective, and recommend improvements or changes.

This scope makes the audit a feedback mechanism. If a control failed, the useful response is not to hide the finding inside a general statement that the company has a security program. The organization should identify the root cause, apply compensating controls where appropriate, document the remediation, and determine whether the weakness affected other transactions. The guide presents audit findings as a reason to enhance the program and security practices. A favorable audit is evidence about the period and scope examined; it is not a guarantee that a later transaction is permitted or that a past violation disappears.

The report itself must be retained for at least ten years. So must the underlying recordkeeping that allows the audit to be meaningful.