What is the difference between prohibited transactions and restricted transactions under EO 14117?

Prohibited transactions are sales, licensing, or brokerage of bulk sensitive data to entities linked to countries of concern, and they are generally not allowed. Restricted transactions are data transfers inside vendor, employment, or investment relationships that may proceed only with added due diligence, technical safeguards, monitoring, and recordkeeping to reduce national security risk.

How EO 14117 Separates a Flat Ban from a Conditional Transfer Control

Prohibited transactions are the line the rule draws around direct sale, licensing, or brokerage of bulk sensitive data to covered foreign-linked entities. Restricted transactions are different because they are not an automatic ban, they are permitted only when the relationship and transfer conditions are managed tightly enough to reduce national security exposure. The practical difference is not just legal wording, it is the level of allowable risk.

A useful way to think about the split is that prohibited transactions are designed to stop certain data flows altogether, while restricted transactions are designed to allow only narrower, controlled flows where the surrounding safeguards matter. That means organisations need to classify the relationship first, then decide whether the activity is off-limits or conditionally allowed.

For practitioners, that distinction changes the control posture. A prohibited transaction should trigger refusal or redesign of the arrangement. A restricted transaction should trigger due diligence, technical safeguards, monitoring, and recordkeeping before any transfer proceeds. The control burden is therefore materially higher for restricted transactions than for ordinary commercial data sharing.

One useful reference point for the data-control side of the problem is Ultimate Guide to NHIs, What are Non-Human Identities, which is helpful when transfers depend on service accounts, API keys, or other machine-facing access paths that must be governed carefully.

Why the Difference Matters in Practice

EO 14117 is not just about whether data moves. It is about which kinds of data relationships create unacceptable exposure and which ones can be tolerated only with compensating controls. That makes the distinction important for vendor due diligence, employment-related data flows, and investment-related sharing, because the same dataset may be treated very differently depending on who receives it and why.

Restricted transactions are especially sensitive because the risk is not eliminated, only reduced. The organisation still has to show it understood the destination, the transfer purpose, the access path, and the audit trail. In practice, that means legal review, security review, and operational ownership all need to line up before the transfer is approved.

This is also where data governance and access governance intersect. The more a transfer depends on tightly scoped credentials, controlled interfaces, and traceable handling, the easier it is to demonstrate that the organisation is treating the transaction as restricted rather than casually permitted.

For broader security context on how data handling and privacy risk are managed, the NIST Privacy Framework is a useful authority for aligning data governance with risk treatment.

Risk and Threat Considerations

The main risk is treating a restricted transaction as if it were merely a contractual formality. If the added safeguards are weak, the transfer can become a bypass for sensitive bulk data exposure, especially where third parties, cross-border services, or complex vendor chains are involved. Prohibited transactions reduce that exposure by drawing a hard line, while restricted transactions rely on the organisation to keep the risk bounded.

Failure mechanism: the control fails when a transfer is misclassified, when due diligence is shallow, or when technical and recordkeeping safeguards do not actually constrain who can receive, retain, or re-use the data.

Impact: sensitive bulk data can move into a relationship or jurisdiction that increases national security risk, and the organisation may lose the ability to prove that the transfer was properly controlled.

For threat modelling and control design around access paths, identity governance, and data exposure, the OWASP Non-Human Identity Top 10 is relevant when restricted transactions depend on machine credentials, automation, or service-to-service access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST IR 8596 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.OV-01 — Oversight and Risk Management	EO 14117 requires governance over data-transfer risk decisions.
Recommendation — Establish governance review for prohibited versus restricted transfer decisions.
CIS Controls v8	6 — Access Control Management	Restricted transactions depend on controlling who can access and move sensitive data.
Recommendation — Limit data access paths and enforce least privilege for transferred datasets.
NIST SP 800-63	2 — Authentication and Lifecycle	Restricted transfers often rely on stronger identity assurance and accountable access.
Recommendation — Use strong authentication and lifecycle controls for transfer operators and approvers.
NIST IR 8596	AI RMF Govern — Govern	Use governance discipline when automated systems handle sensitive transfer decisions.
Recommendation — Apply governance controls to automated data-transfer workflows and approvals.

Practitioner Guidance

What to verify: verify whether the transaction is actually a prohibited sale, licensing, or brokerage arrangement, or whether it is a restricted transfer that can be justified only with documented safeguards. Do not rely on business owner labels, because the legal category should drive the control path.

Decision rule: if the relationship creates covered exposure to bulk sensitive data and the counterparty falls within the prohibited set, stop and redesign the arrangement; if the transfer is potentially restricted, require a documented control package before approval, not after the fact.

What good looks like: the organisation can show a clean classification decision, a pre-approval review, traceable transfer records, and controls that meaningfully reduce access, reuse, and retention risk rather than merely acknowledging it.

Practitioner takeaway: the key difference is not permissibility alone, it is whether the activity is barred outright or only allowed when the organisation can prove it has reduced the national security risk to an acceptable level.