PDPL Cross-Border Transfers: Rules for Saudi Data

Every Saudi organisation that uses a cloud service hosted outside the Kingdom, sends employee data to an international payroll provider, or shares customer records with a foreign parent company is making a cross-border data transfer under PDPL. The Personal Data Protection Law restricts these transfers by default, and the Implementing Regulations set out the narrow conditions under which they are permitted. For compliance teams, the challenge is not understanding the rule — it is mapping it against the reality of how data actually flows through modern enterprise technology.

This post explains the transfer framework, walks through the permitted mechanisms, and offers a practical approach for Saudi controllers who need to bring their data flows into compliance.

The default position

PDPL starts from a restrictive baseline: personal data must not be transferred outside Saudi Arabia unless specific conditions are met. This is a meaningful departure from the approach taken by some other data protection regimes, which permit transfers more freely. The intent is to protect the personal data of individuals in the Kingdom from being processed in jurisdictions where they may have weaker protections or limited recourse.

Controllers must stop a transfer immediately if the safeguards that justified it no longer apply, or if the transfer threatens national security or vital interests.

Permitted transfer mechanisms

The law and Implementing Regulations recognise several bases for lawful cross-border transfer:

1. Adequacy decisions

SDAIA may determine that a receiving country or international organisation provides an adequate level of protection for personal data. Where an adequacy decision exists, transfers to that jurisdiction can proceed without additional safeguards. As of early 2026, SDAIA has not yet published a formal adequacy list. This means most organisations cannot rely on this mechanism today and should plan on the basis that additional safeguards will be required.

2. Appropriate safeguards

In the absence of an adequacy decision, controllers can transfer data by putting appropriate safeguards in place. The Implementing Regulations accept:

• Binding corporate rules — Internal policies adopted by a group of companies that are legally binding on all members and enforceable by data subjects.
• Standard contractual clauses — Pre-approved contractual terms between the controller and the receiving party.
• Compliance certifications — Recognised data protection certifications held by the receiving entity.
• Codes of conduct — Adherence to approved industry codes with binding and enforceable commitments.

Each of these must include effective mechanisms for enforcement and for data subjects to exercise their rights.

3. Specific derogations

Where neither adequacy nor safeguards are available, PDPL permits transfers in limited circumstances:

• Explicit consent — The data subject has been informed of the risks and has given explicit consent.
• Contractual necessity — The transfer is necessary to perform a contract with the data subject or to take pre-contractual steps at their request.
• Vital interests — The transfer is necessary to protect the vital interests of the data subject or another person, and the data subject is unable to provide consent.
• Public interest — Government entities may transfer data for reasons of public security, crime detection, or judicial proceedings.

These derogations are not intended to be the primary transfer mechanism for routine business operations. Relying on consent for every API call to a foreign SaaS provider is not a scalable or defensible strategy.

The SaaS problem

The most common cross-border transfer scenario for Saudi organisations is not a deliberate decision to send data abroad — it is the default architecture of a SaaS product. A Saudi company using an HR platform hosted in Europe, a CRM hosted in the United States, or an analytics tool that processes data through servers in multiple jurisdictions is making continuous cross-border transfers, often without the compliance team's knowledge.

Mapping these flows requires a systematic inventory:

• Identify every SaaS product that touches personal data (HR, CRM, finance, marketing, IT service management, collaboration tools).
• Determine where data is stored and processed — not just the vendor's headquarters, but the actual data centre locations and any sub-processors.
• Classify the data flowing to each service — employee data, customer data, sensitive data, identification documents.
• Assess the legal basis for each transfer — is there an adequacy decision, a contractual safeguard, or a derogation that applies?
• Document the risk — what happens to the data if the vendor is acquired, if the data centre moves, or if the underlying jurisdiction changes its data protection posture?

Many organisations discover during this exercise that they have dozens of undocumented cross-border flows that were never assessed against PDPL.

Data residency as a strategy

For Saudi organisations in heavily regulated sectors — banking (SAMA-regulated), government (NCA-regulated), healthcare, energy — the simplest way to avoid the cross-border transfer problem is to keep personal data inside Saudi Arabia in the first place.

Data residency means:

• Choosing SaaS vendors that offer a Saudi-hosted deployment or a data residency option within the Kingdom.
• Configuring cloud infrastructure to ensure that storage and processing remain in Saudi data centres.
• Contractually binding processors to keep data within Saudi Arabia unless explicitly authorised otherwise.
• Verifying residency claims — a vendor saying they offer KSA hosting is not the same as data actually staying in KSA. Audit it.

Data residency does not eliminate all PDPL obligations — you still need lawful basis, RoPA, data subject rights, breach notification and everything else in the PDPL checklist. But it removes the single most operationally complex obligation and the one most likely to generate enforcement attention.

Building a transfer impact assessment

For transfers that cannot be avoided through residency, PDPL expects controllers to conduct a documented assessment before the transfer takes place. A transfer impact assessment should cover:

1. Nature of the data — What categories of personal data are being transferred? Is any of it sensitive?
2. Purpose of the transfer — Why is the data leaving Saudi Arabia? Is the transfer necessary for the stated purpose, or could the purpose be achieved without it?
3. Receiving jurisdiction — What data protection laws apply in the receiving country? Is there an independent supervisory authority? Are data subject rights enforceable?
4. Recipient safeguards — What technical and organisational measures does the recipient have in place? Are they certified under a recognised framework (ISO 27001, SOC 2)?
5. Legal basis — Which PDPL transfer mechanism applies — adequacy, safeguards, or derogation?
6. Supplementary measures — If the receiving jurisdiction's protections are weaker than PDPL, what additional measures (encryption, pseudonymisation, contractual restrictions) are in place to bridge the gap?
7. Risk to data subjects — What is the residual risk to individuals in Saudi Arabia after all measures are applied?

Document the assessment, have the DPO review it, and keep it in your compliance evidence library. SDAIA may request it at any time.

Penalties for non-compliant transfers

PDPL violations can attract fines of up to SAR 5 million per violation, with increased penalties for repeat offences. Intentional disclosure of sensitive personal data carries criminal penalties — up to two years' imprisonment and fines of up to SAR 3 million. Cross-border transfers that violate PDPL are not a grey area; they are a defined obligation with defined consequences.

SDAIA's early enforcement activity shows a willingness to act. The 48 enforcement decisions issued in the first year of full enforcement signal that this is not a law that will gather dust.

Practical steps for compliance teams

1. Run a data flow inventory. Map every cross-border transfer — SaaS, cloud, intercompany, outsourced processing. You cannot assess what you have not found.
2. Classify each flow by transfer mechanism. Adequacy (unlikely today), safeguards (most common path), or derogation (last resort).
3. Negotiate contractual safeguards. Update processor agreements to include PDPL-compliant standard clauses, data residency commitments where available, and audit rights.
4. Conduct transfer impact assessments. For each flow that cannot be brought in-Kingdom, document the risk and the mitigations.
5. Monitor for changes. Vendor acquisitions, data centre relocations and sub-processor changes can turn a compliant transfer into a non-compliant one overnight. Build a monitoring cadence.
6. Evaluate data residency. For high-risk data categories and regulated sectors, moving to Saudi-hosted infrastructure is often cheaper and simpler than maintaining a cross-border transfer compliance programme in perpetuity.

How GRC Vantage helps

GRC Vantage's compliance module includes a cross-border transfer register that maps every data flow to its legal basis, safeguards and receiving jurisdiction. Transfer impact assessments are built into the workflow, with automatic linkage to your PDPL control library, processor agreements and risk register. The platform itself runs inside Saudi Arabia — hosted from our Riyadh and Dammam offices — so your GRC data stays in the Kingdom by default.

For the full PDPL implementation roadmap, see our PDPL Saudi Arabia checklist. To see how the cross-border transfer register works, book a demo.