Saudi Arabia Data Transfers and Localization: The PDPL Transfer Process

Saudi Arabia's Personal Data Protection Law (PDPL) is frequently described, in secondary commentary on Gulf privacy laws, as requiring personal data to be stored inside the Kingdom. That description is wrong. What the PDPL and its Data Transfer Regulation actually regulate is the process a controller must follow before sending personal data out of Saudi Arabia, not whether it can leave at all. This page is a process guide to that mechanism: the transfer cascade, the mandatory risk assessment, and the penalties for getting it wrong. For the PDPL's broader framework, see Saudi Arabia data privacy laws, and for a side-by-side comparison against the GDPR, see Saudi PDPL vs. GDPR.

The Localization Question, Answered First

This is the most misreported fact about Saudi Arabia's privacy regime, so it belongs at the top rather than buried under the transfer mechanics. The PDPL does not require personal data to be stored or processed inside Saudi Arabia. A direct text search of both the PDPL and its Implementing Regulation for localization-related language, including "local," "within the Kingdom," and "stored," turns up no provision defaulting personal data to in-country storage. The Data Transfer Regulation, discussed in full below, governs the conditions under which data may leave the Kingdom. It does not prohibit outbound transfer or require a Saudi-based copy to remain behind.

This gets conflated for two reasons. First, some other Gulf jurisdictions do impose sector-specific residency rules, for example certain banking or healthcare data requirements elsewhere in the region, and those get generalized into "Gulf privacy law requires localization" claims that do not hold for the PDPL specifically. Second, the PDPL does reach outside the Kingdom in a different sense: Article 2(1) applies the Law extraterritorially to processing of Saudi residents' personal data "by any means from any party outside the Kingdom." That is a jurisdictional-reach provision, functionally similar to GDPR Article 3's extraterritorial scope, and it is easy to mistake for a residency requirement because both provisions use the word "Kingdom." They do opposite things: Article 2(1) extends where the law applies; it says nothing about where data must physically sit.

For localization rules that do vary meaningfully by country, see our survey of data localization laws by country. Saudi Arabia is correctly classified there as a jurisdiction with a conditions-based transfer regime, not a localization mandate.

The Transfer Cascade: Articles 3 Through 8 of the Data Transfer Regulation

Once localization is off the table, the actual compliance question becomes: which of the Data Transfer Regulation's three routes does a given transfer use? The Regulation, a distinct chapter bound into the same Implementing Regulation PDF, sets out a cascade rather than a menu. A controller is expected to work down it in order, using safeguards or an exception only because the step above is not available.

Route 1: Adequacy (Articles 3-4), Currently Theoretical

Article 3 has SDAIA, working with relevant coordinating authorities, evaluate a destination country, sector, or international organization against seven criteria:

1. Protective laws at least equivalent to the PDPL.
2. Rule of law in the destination.
3. Effective enforcement of those protective laws.
4. Data subjects' practical ability to exercise their rights and file complaints.
5. Existence of an independent supervisory authority in the destination.
6. That authority's willingness to cooperate with SDAIA.
7. Clarity of the destination's rules governing government access to personal data.

Article 4 has SDAIA recommend a decision to the Prime Minister, who issues, or declines to issue, the actual adequacy decision, reviewed at least every four years once granted. As of this research, no adequacy decision has been published for any country, sector, or organization. That makes the adequacy route real as a legal mechanism but currently unusable in practice. A controller cannot rely on adequacy today for a transfer to any destination, including major trading partners, because SDAIA has not exercised the power Articles 3 and 4 give it.

Route 2: Appropriate Safeguards (Article 5), Where Nearly Everything Happens

With no adequacy list, Article 5's appropriate-safeguards route is where the overwhelming majority of real transfers live. It offers four instruments:

• Standard Contractual Clauses, following the standard model SDAIA itself issued in September 2024. This is the default choice for most vendor and service-provider relationships, the SCC-to-a-processor pattern familiar from GDPR practice, but running on SDAIA's own template rather than the European Commission's.
• Binding Common Rules, an intra-group instrument SDAIA approves case by case, suited to multinational groups moving data between affiliates rather than to an external vendor.
• Compliance certifications issued by an SDAIA-accredited certifying body.
• Binding codes of conduct.

Binding Common Rules carry the heaviest documentation burden of the four. Article 5(2) requires at least fourteen specific elements before SDAIA will approve a set of BCRs, including the group's commercial registration information, the categories, purposes, and destinations of the data covered, the rights data subjects can exercise and how they can complain, a named role responsible for compliance monitoring (functionally a DPO-style contact for the transfer program specifically), audit obligations, and a mechanism for escalating conflicts of law between the Kingdom and the destination jurisdiction. In practice, this level of documentation only pays for itself for a group moving data repeatedly and at volume between affiliates; a one-off or low-volume transfer to a single vendor is a poor fit for BCRs and belongs on the SCC track instead.

Our page on Standard Contractual Clauses covers how SCCs function as a transfer mechanism more generally; the point specific to Saudi Arabia is that SDAIA's September 2024 model is its own instrument, not a rebadged version of the EU's SCCs, and a controller already running EU SCCs for the same vendor relationship still needs the SDAIA-model contract layered on for the Saudi leg of the data flow.

Route 3: Narrow Exceptions Without a Safeguard (Article 6)

Article 6 lets a controller transfer without any Article 5 safeguard, but only where a safeguard genuinely cannot be applied, not merely where it is inconvenient. The listed grounds are:

• Performance of an agreement to which the data subject is a party.
• A Public Entity's transfer for purposes of international cooperation or judicial requirements.
• Protecting a data subject's vital interests.
• Scientific research purposes.

Because this route requires that a safeguard is unavailable rather than simply skipped, it functions as a genuine exception, not a default fallback a controller can select for convenience. Relying on Article 6 without documenting why Article 5 could not be used is a common overreach; see the failure-points section below.

The Kill-Switch: Article 7

Sitting on top of whichever route applies, Article 7 requires a controller to immediately stop a transfer made under either Article 5 or Article 6 if the transfer affects Saudi Arabia's national security or vital interests, or if a risk assessment finds a high privacy risk. The controller must reassess before resuming. This is not a one-time gate at the start of a transfer program; it is a standing obligation that applies for as long as the transfer continues, which means a transfer that was compliant when it started can become non-compliant later if circumstances change, and the controller is the one responsible for noticing.

The Risk Assessment: The Practical Core of Transfer Compliance

For most controllers, the risk assessment required under Data Transfer Regulation Article 8 is where the real compliance work sits, more so than choosing which cascade route to use.

When it is mandatory

Article 8 requires a documented risk assessment in three situations, and they are not mutually exclusive:

1. The transfer relies on Article 5 appropriate safeguards. This alone captures most real-world transfers, since Article 5 is the route almost everyone uses in the absence of an adequacy list.
2. The transfer relies on an Article 6 exception.
3. The transfer is continuous or large-scale and involves Sensitive Data, regardless of which mechanism is used. This third trigger is the one worth flagging separately: it is not tied to a specific legal route at all. Volume and sensitivity alone force a fresh risk assessment even where a valid transfer mechanism, such as an already-executed SCC, is already in place.

Read together, these three triggers mean the risk assessment is close to universal in practice. A controller sending any meaningful volume of personal data outside the Kingdom should assume a documented risk assessment applies unless it can affirmatively show none of the three triggers is met.

What the assessment must cover

Article 8(2) specifies the required elements:

• The purpose and legal basis for the transfer.
• The nature and scope of the transfer.
• The adequacy of the safeguard mechanism chosen for that specific transfer.
• The data-minimization measures actually taken.
• The potential material or moral impact on the data subjects involved.

SDAIA's Risk Assessment Guideline for Transferring Personal Data Outside the Kingdom, issued in February 2025, provides the implementing detail for how to conduct this assessment. Keep the two documents straight: Article 8 is the underlying legal obligation and fixes what must be assessed; the February 2025 Guideline is SDAIA's guidance on the method for doing it. A controller citing "the risk assessment requirement" should point to Article 8 as the rule and the Guideline as the how-to.

When it must be refreshed

The Regulation does not treat a completed risk assessment as a one-time artifact filed away with the contract. Two triggers force a refresh:

• After a kill-switch event. Article 7 requires reassessment before a controller resumes a transfer that was stopped for a national-security or high-risk finding.
• When the transfer's own profile changes into the continuous/large-scale-sensitive-data trigger. A transfer that starts small and grows in volume, or that begins including sensitive data it did not originally carry, can cross into Article 8's third trigger even without any change to the underlying legal mechanism, meaning a risk assessment done at the outset can go stale purely because the transfer scaled up.

A practical consequence: a risk assessment tied only to a fixed point in time, done once at contract signature and never revisited, is not sufficient if the transfer's volume or data mix later changes. Building a periodic review into the transfer program, not just an initial one, is the safer reading of Article 8 together with Article 7.

Which Route Applies to You: A Decision Table

How This Interacts With the National Register of Controllers

The Data Transfer Regulation does not operate in isolation from SDAIA's broader compliance infrastructure, and the National Register of Controllers is the piece most likely to intersect with a transfer program.

PDPL Article 30(4)(C) empowers SDAIA, as the Competent Authority, to specify tools and mechanisms for monitoring controllers' compliance, including "maintaining a national register of Controllers." Implementing Regulation Article 34 delegates the actual mechanics: SDAIA "shall issue the rules for registration," and those rules must identify which categories of controllers are required to register. Neither the Law nor the Implementing Regulation spells out the specific registration criteria in its own text; that determination is made and published separately, as SDAIA rules rather than statutory language.

What that means practically for a controller running a cross-border transfer program: registration status is a separate compliance question from which transfer route applies, and it should not be assumed away. A transfer program can be fully compliant on the Data Transfer Regulation side, correct mechanism, documented risk assessment, kill-switch monitoring in place, while the underlying controller is separately required to be on SDAIA's register because of factors SDAIA's own rules define. Because those criteria are not fixed in the Implementing Regulation text and can be updated by SDAIA independently of the Law, a controller should check SDAIA's current, published registration rules directly rather than relying on any older secondary summary of who has to register, including this one.

Penalties for Getting Transfers Wrong

A transfer-specific violation of the PDPL runs through the same two-track penalty structure that applies to the Law generally, and it is worth restating in the transfer context because both tracks can be triggered by a mishandled cross-border move specifically.

Administrative track (Article 36): a warning or a fine of up to SAR 5,000,000 for a violation not covered by Article 35, for example transferring without an appropriate safeguard, skipping a required risk assessment, or ignoring the Article 7 kill-switch obligation. The fine doubles to SAR 10,000,000 on a repeat violation. An SDAIA-appointed committee of at least three members, including a technical specialist and a legal advisor, decides the case, and the decision is approved by SDAIA's president.

Criminal track (Article 35): applies specifically where Sensitive Data is disclosed or published in violation of the Law, with the intent to harm the data subject or to achieve a personal benefit. If a mishandled transfer of Sensitive Data meets that intent standard, for example, sending sensitive data offshore without a lawful basis specifically to exploit or expose it, the exposure is up to two years' imprisonment and/or a fine of up to SAR 3,000,000, doubled on recidivism, prosecuted by the Public Prosecution before a competent court. This track is categorically separate from, and can apply in addition to, the Article 36 administrative track.

No revenue-percentage mechanism. Unlike GDPR Article 83, which caps fines at the higher of a flat sum or a percentage of global annual turnover (up to 4%), the PDPL's administrative ceiling is fixed regardless of the controller's size or global revenue. For a small controller, SAR 5,000,000 (roughly USD 1.3 million) is a meaningful sum; for a large multinational, it is a fixed ceiling that does not scale the way GDPR's percentage mechanism does. Saudi Arabia's distinctive exposure runs the other direction: a criminal offense for sensitive-data misuse that GDPR itself does not create at the Regulation level.

Beyond fines, courts may order confiscation of funds obtained through a violation (Article 38(1)), courts or the committee may order publication of a violation summary in local newspapers at the violator's expense (Article 38(2)), and data subjects retain a separate civil right to sue for proportionate compensation for material or moral damage under Article 40, independent of either penalty track.

Sequencing: How a Multinational Should Actually Move Saudi Data Offshore

Put together, the cascade, the risk assessment, and the register interact in a specific order. A practical sequence for a multinational standing up a new Saudi-to-elsewhere data flow looks like this:

1. Classify the data first. Is it Sensitive Data under PDPL Article 1(11)? Is the flow continuous or large-scale? These two questions determine whether Article 8's third risk-assessment trigger applies regardless of which transfer mechanism is chosen later.
2. Check for an adequacy decision covering the destination. As of this research, this step will not produce a usable result for any destination, since none has been published, but it should still be checked rather than assumed, since SDAIA can issue one at any time.
3. Select the safeguard mechanism that matches the relationship, not the one that is easiest to document. A single vendor relationship calls for SDAIA's SCC model. Recurring intra-group flows across a multinational's own affiliates are a better fit for Binding Common Rules, despite the heavier fourteen-element documentation burden, because BCRs cover the whole group rather than requiring a fresh contract per affiliate pair.
4. Determine whether the risk assessment is triggered, using Article 8's three conditions. In practice, assume it is triggered and confirm otherwise, rather than assuming it is not required and being wrong.
5. Conduct and document the risk assessment against Article 8(2)'s five required elements, using SDAIA's February 2025 Guideline for method.
6. Confirm the controller's registration status against SDAIA's current registration rules, independently of the transfer mechanism chosen, since registration turns on categories SDAIA defines separately from the Data Transfer Regulation.
7. Build kill-switch monitoring into the ongoing program, not just the launch. Article 7's obligation to stop and reassess is a standing duty, and a transfer that was compliant at launch can require action later if the transfer's scale, sensitivity, or risk profile changes.

Common failure points

• Treating GDPR SCCs as sufficient. SDAIA's September 2024 SCC model is a distinct instrument from the European Commission's clauses. A vendor contract that already carries EU SCCs still needs the SDAIA-model contract for the Saudi leg of the same data flow.
• Assuming legitimate interest covers the transfer question. Legitimate interest is a domestic legal-basis ground under PDPL Article 6, unavailable for sensitive data and gated by a mandatory pre-assessment; it is not a cross-border transfer mechanism and does not substitute for an Article 5 safeguard or Article 6 transfer exception.
• Treating the risk assessment as a one-time artifact. A transfer that grows in volume or begins carrying sensitive data can cross into Article 8's mandatory-assessment trigger after the fact, even with no change to the legal mechanism used.
• Skipping registration because the transfer mechanism is otherwise compliant. Registration status under Articles 30(4)(C) and 34 turns on categories SDAIA defines separately; a compliant transfer program does not automatically mean the controller is exempt from registering.
• Assuming localization applies and over-engineering a Saudi-only storage solution. Because the localization myth is so widely repeated, some organizations spend engineering effort keeping a Saudi-only data copy that the PDPL does not require, instead of building the transfer-compliance process the law actually asks for.
• Not monitoring for a kill-switch trigger after launch. Article 7 is a standing obligation, not a one-time check performed only when the transfer program is first built.

Recent Developments