The Conditional Path: Restricted Transactions and Required Controls

The DOJ Data Security Program gives some covered data-access arrangements a conditional path instead of an absolute prohibition. This chapter explains what makes a vendor, employment, or investment arrangement restricted, and what a U.S. person must build before relying on that path. The practical judgment is deliberately narrow: security controls and a Data Compliance Program can support authorization of a qualifying restricted transaction, but they do not change the underlying access facts or rescue a transaction that belongs in a prohibited category.

Restricted does not mean lightly regulated

A restricted transaction is generally a covered data transaction involving a vendor agreement, employment agreement, or investment agreement with a country of concern or covered person, where the arrangement gives the relevant party access to government-related data or bulk U.S. sensitive personal data. Unless an exemption or other authorization applies, the U.S. person may engage in the transaction only if it complies with the applicable security requirements and the other requirements of the Data Security Program.

This is the key difference from the prohibited path. The regulation does not say that the access is harmless. It says that a qualifying arrangement may proceed under specified conditions designed to reduce and manage the risk. The transaction remains covered. Its parties, data, access capability, and commercial form still have to be identified, and the controls must be applied in the way the rule requires.

The distinction also has a data-specific boundary. A vendor, employment, or investment transaction that gives a covered person or country of concern access to bulk human ‘omic data or related human biospecimens is subject to the separate prohibition for that data. It is not converted into a restricted transaction merely because the company promises to apply security controls. Classification must come before control selection.

The security requirements for restricted transactions are incorporated into the DSP by reference from the Cybersecurity and Infrastructure Security Agency, or CISA. That incorporation matters because a company cannot simply select a different set of controls and assume that its own risk judgment creates equivalent authorization. The Compliance Guide describes an example in which a U.S. company uses a vendor agreement to store bulk personal health data for a covered person. If the company implements the specified security requirements, the arrangement can be authorized as a restricted transaction. If it substitutes controls that it believes mitigate the risk but does not comply with the required security requirements, the agreement is not authorized and is treated as a prohibited transaction.

The principle is easy to state but important in practice: a control can reduce exposure without changing the legal existence of access. The rule’s coverage analysis asks whether the counterparty has the ability to obtain or view the data. The restricted-transaction analysis then asks whether the required security requirements and other obligations are satisfied. These questions are related, but they are not interchangeable.

For example, an employment agreement may give a covered person information-technology support responsibilities and access to personal financial data. Applying the mandated security requirements can place that employment arrangement on the restricted path. A company cannot instead argue that the employee is technically unable to download a complete database and therefore no access exists. Nor can it decide that an informal internal standard is “good enough” without meeting the incorporated requirements. The legal status follows the defined access and the specified conditions together.

The same logic applies to investment arrangements. An investor or investment vehicle may receive rights that affect company decisions, systems, or operations.