JordanPersonal Data Protection Law, cross-border transfer
In force since .
A cross border transfer rule binding public and private bodies.
- Audit expectation
- none
What it requires
- An app transferring or exchanging the personal data of an individual in Jordan with another recipient must obtain the Data Subject's consent, confirm a legitimate interest on both sides, ensure the Data Subject has sufficient knowledge of the purpose, and must not use the data for marketing without a separate consent; Jordan's base Law does not impose an adequacy or localization gate on the transfer.
These lines are LexLint's reading of the law's text.
In the frameworks
- NIST Privacy Framework
- CT.PO-P1Policies, processes, and procedures for authorizing data processing (e.g., organizational decisions, individual consent), revoking authorizations, and maintaining authorizations are established and in place.
Our reading of where this law's duties sit in each framework. It never says that running a control meets the law. How we read a framework against the law
Who enforces it
Settledness
- As of
- Open questions
- Does the Consent that Article 14(A) of the Personal Data Protection Law requires for the "transfer and exchange of Data" to a Recipient apply when the Recipient is the Controller's own Processor?
What it makes you log
What the log must hold
Data lineage, Consent or opt-out state
Logging duty
Article 14(B) requires the controller to keep records documenting the Data transferred or exchanged with a Recipient, the purpose of the transfer, and the Data Subjects' consent to the transfer. The record is of what went to which recipient and under what consent, so the contents listed are data lineage and the consent state; the Article gives no further field. It states no period for keeping the record, no audit and no person entitled to examine it (Article 18(C) of the Law gives the Unit the task of monitoring compliance but this row does not cite it). Article 14(E) requires the Controller, Processor and Recipient to provide measures to detect and track any breach of security and safety, which is a security measure and names no record. The Article names no territorial test; Recipient is defined in Article 2 as a person inside or outside the Kingdom. The adequacy rule for transfers outside the Kingdom is in Article 15, which this row does not cite.
- Kind
- Explicit
- As of
- Provision
- Article 14(B) (the Controller keeps records of the Data transferred or exchanged with a Recipient, the purpose of the transfer, and the Data Subjects' consent)
- Trigger
- personal_data_processing
What this law does
No adequacy test, whitelist, or data-localization requirement was found anywhere in the untruncated text, searched directly for "adequate," "localiz," and "stored within the Kingdom" with zero hits.
Article 14 sets a general transfer or exchange-to-a-recipient rule, not framed specifically as cross-border, requiring the Data Subject's consent plus three conditions: legitimate interest of both parties, the Data Subject having sufficient knowledge of the purpose, and no use for marketing without separate consent, with a record-keeping duty on the Controller and a carve-out for public-entity-to-public-entity transfers.
This reads as a consent-based transfer regime rather than an adequacy-gated one on the primary text alone, more permissive in structure than the carried strict seed; it remains possible that unread implementing regulations supply a stricter, cross-border-specific rule the base Law defers to, a deferral pattern also seen in Oman.
When LexLint raises it
When your app profile says your app sends automated outreach or processes personal data.
Back to the example · Lint your app
Page updated .