When Data Access Becomes Export Control
The subject of this series is the Department of Justice’s Data Security Program, or DSP. This opening focuses on the program’s central shift: certain commercial access to sensitive data is treated as a national-security transaction, not only as a privacy or cybersecurity matter. That distinction supports a practical judgment. Before a company shares, licenses, stores, processes, or otherwise exposes data through an ordinary business relationship, it must ask not only whether the data is protected, but also who can access it, through what arrangement, and under which legal boundary.
The shift matters because the relevant access paths are often ordinary. A dataset may sit behind a cloud service, feed an advertising exchange, support an application, be available to an employee, or move as part of an investment or vendor relationship. The business may not think of itself as exporting anything. Yet the DSP is concerned with the capability created by the transaction: whether a country of concern or a covered person can obtain or exploit U.S. Government-related data or Americans’ bulk sensitive personal data.
The result is neither “all foreign access is forbidden” nor “good cybersecurity makes all access acceptable.” The program creates a structured analysis. Some transactions are prohibited. Some are restricted and can proceed only when specified security and compliance conditions are met. Some are exempt because of their purpose and circumstances. Others may require a license or an advisory opinion. The rest of this series develops the facts that distinguish those paths.
Why the DOJ treats data access as national-security conduct
The DSP was issued by the National Security Division under Executive Order 14117 and the International Emergency Economic Powers Act. The executive order responded to the risk that foreign adversaries could obtain Americans’ sensitive information and use it for espionage, surveillance, coercion, blackmail, influence, or the development of artificial-intelligence and military capabilities. The DOJ’s overview describes the program as addressing commercial activities that can give foreign adversaries access to data and says that it establishes what are effectively export controls.
That description is important because it changes the object of concern. In a familiar privacy analysis, the first questions might be whether a person consented, whether a company secured a database, or whether a processor followed a contract. Those questions can remain relevant, but the DSP adds a national-security question: does a commercial transaction create access for a party whose jurisdiction, ownership, residence, employment, or conduct places it within the rule’s concern?
“Access” is consequently broader than a completed download. The regulation describes logical or physical ability to obtain, read, copy, decrypt, edit, divert, release, affect, alter, view, or receive information through systems, cloud platforms, networks, security systems, equipment, or software. A party can create the relevant capability through a product interface or a service relationship even when no employee manually hands over a file.
This is why the legal analysis follows the path of access rather than the vocabulary used by the business. A company that sells advertising space may also provide identifiers to an exchange. A software product may expose information from its training data. A vendor may store a database or give personnel administrative rights. An investment or employment agreement may give someone authority to reach information. Whether any particular arrangement is covered still depends on the rule’s factual elements, but the commercial label is not decisive.
The program’s general effective date is 12:01 a.m. Eastern Time on April 8, 2025. Current eCFR text sets October 6, 2025 as the date by which the affirmative data-compliance program and audit requirements apply to restricted transactions, and uses that date for specified annual and rejected-transaction reports. The DOJ’s public overview contains a conflicting October 5 wording for some later obligations, while the April Compliance Guide uses October 6. For an operative conclusion, the current regulation controls. The larger point is that compliance has a legal start date and an implementation lifecycle; it is not merely a voluntary security aspiration.
The rule matters more than the guide that explains it
The DOJ’s Compliance Guide is valuable because it translates the program into business questions. It tells U.S. persons to “know their data”: what kinds and volumes they hold, how the company uses the data, whether a covered transaction exists, and how the data is marketed. It also describes practical work such as mapping data flows, revising contracts, changing suppliers, adjusting employee responsibilities, deploying security requirements, and auditing systems.
But the guide is not the law itself. It expressly says that it is general information, does not create enforceable rights or privileges, and does not change the legally binding provisions of the DSP. If its wording appears inconsistent with the International Emergency Economic Powers Act, Executive Order 14117, or 28 CFR Part 202, those authorities control. That hierarchy is more than a legal footnote. It tells a company how to use the material responsibly: use the guide to understand the problem and design questions, then use the regulation and any applicable license, exemption, or current agency instruction to decide.
The distinction also prevents two opposite mistakes. One is under-compliance: treating the guide as optional commentary and missing a binding requirement. The other is over-compliance: treating every recommendation in the guide as a universal rule, regardless of the facts. For example, risk assessments, periodic training, and robust escalation practices may be sensible ways to build a stronger program, but the regulation’s minimum requirements and the guide’s best-practice suggestions should not be presented as identical.
The same caution applies to the program’s scope. Part 202 does not replace other federal authority, and compliance with the DSP does not establish compliance with other sanctions, export-control, privacy, procurement, sectoral, or security regimes. A company may need to run more than one legal analysis on the same data flow. The DSP supplies one national-security boundary; it does not make every other boundary disappear.
A five-part way to see the problem
A useful first model has five connected questions.
First: what data is involved? The program names categories such as covered personal identifiers, precise geolocation, biometric identifiers, human ‘omic data, personal health data, and personal financial data. Some government-related data is covered regardless of volume, including precise geolocation for listed government-related locations and sensitive personal data marketed as linked or linkable to current or recent former U.S. Government employees, contractors, or senior officials. Other categories become relevant when they meet a defined bulk threshold. The ordinary description “customer data” is therefore too vague to decide anything.
Second: what does access mean here? The question is not limited to whether a recipient has already copied raw records. It includes the technical ability to view, receive, decrypt, alter, or otherwise obtain information. A control may reduce the risk of access, but the regulation says access is determined without regard to the application or effect of security requirements when deciding whether a transaction is covered. Controls can be decisive later for an authorized restricted transaction; they do not erase the underlying access fact.
Third: who can access the data? The program names six countries of concern—China, including Hong Kong and Macau, Cuba, Iran, North Korea, Russia, and Venezuela—but it also defines covered persons more broadly. Covered status can arise from an entity’s organization or principal place of business, direct or indirect ownership, an individual’s residence or employment, or a specific designation. A public list may help, but it cannot substitute for checking the relevant ownership, location, and role facts.
Fourth: what kind of transaction creates the access? The rule identifies data brokerage, vendor agreements, employment agreements, and investment agreements. A sale or license is the clearest example, but access can also be embedded in cloud services, advertising technology, software, corporate structures, or a job with administrator privileges. Conversely, a foreign relationship that does not give the relevant party access, or that lacks one of the listed transaction forms, may not be a covered data transaction. The analysis must follow the actual arrangement rather than assume that every foreign commercial activity has the same status.
Fifth: what boundary changes the result? Once the data, access, counterparty, and transaction are understood, the company must ask whether the arrangement is prohibited, restricted, exempt, or authorized under a license or other mechanism. This is the point at which legal categories matter. A prohibited data-brokerage transaction cannot be made permissible merely by adding a security policy. A restricted vendor transaction may be possible, but only with the required security and other compliance measures. An exemption may apply to a financial, governmental, corporate, research, or other activity, but only within its stated purpose and conditions.
The model can be pictured as a chain rather than as a single “sensitive data” switch:
The chain is deliberately more demanding than a checklist that asks only whether data is “sensitive.” A company can misclassify the data, overlook an indirect ownership relationship, fail to notice that a software feature creates access, or mistake a contract for permission. It can also apply the opposite error and treat a fact-specific exemption as a blanket waiver. The useful decision record must connect the data description, access path, counterparty facts, transaction form, and legal basis in one place.
That is the practical reason this series begins with foundations rather than with a list of controls. The controls are meaningful only after the subject has been identified. The next question is therefore precise: what does the DSP mean by sensitive personal data, bulk data, government-related data, and access—and how can aggregation or linkage change the answer?