Saudi PDPL vs. GDPR: Registration, Transfers, and Penalties Compared

Saudi Arabia's data protection law and the GDPR both build on a similar backbone of consent, data-subject rights, and regulator oversight, but the details diverge in ways that matter for anyone processing data of people in the Kingdom. Saudi Arabia runs a controller registration system the GDPR abandoned in 2018, has no published list of adequate countries for outbound transfers, and carries a criminal penalty for sensitive-data misuse that has no GDPR-level equivalent.

This page compares the Personal Data Protection Law (PDPL), its Implementing Regulation, and the Data Transfer Regulation against the GDPR article by article, using the official English texts published by the Saudi Data and Artificial Intelligence Authority (SDAIA).

At a Glance: PDPL vs. GDPR

Background and Enforcement Timeline

The GDPR took effect across the EU/EEA on 25 May 2018 and remains the most litigated and most extensively guided data protection framework in the world. For background on how it works, see our explainer on what GDPR requires.

Saudi Arabia's Personal Data Protection Law was issued by Royal Decree No. M/19 and later amended by Royal Decree No. M/148. It is supplemented by an Implementing Regulation, which itself contains a distinct chapter known as the Data Transfer Regulation governing cross-border transfers. All three instruments are administered by SDAIA, which acts as the PDPL's Competent Authority.

The law carried a three-year grace period before full enforceability, which ended on 14 September 2024. Since that date, the PDPL's substantive obligations, including registration, breach notification, and the administrative and criminal penalty tracks, are all live. For a fuller country-level walkthrough, see our Saudi Arabia data privacy laws page.

A note on article numbering: the amended PDPL numbers its consent and legal-basis provisions as Article 5 (consent) and Article 6 (processing without consent), and its rights provisions as Article 4. The Implementing Regulation separately cross-references the Law's own Article 10, which governs collecting data from a source other than the data subject, a different provision from Article 6. This page cites each article precisely rather than treating "Article 6" and "Article 10" as interchangeable.

Scope

GDPR applies to controllers and processors established in the EU/EEA, and extraterritorially to non-EU entities that offer goods or services to, or monitor the behavior of, people in the EU/EEA.

The PDPL applies to processing of personal data of individuals residing in Saudi Arabia, and it reaches extraterritorially as well: PDPL Article 2(1) applies the Law to processing carried out "by any means from any party outside the Kingdom" where it concerns a Saudi resident's data. That extraterritorial reach is a jurisdictional hook, similar in function to GDPR Article 3, and should not be confused with a data-localization mandate (see the dedicated section below).

Definitions: Sensitive Data and Credit Data Are Separate Categories

PDPL Article 1(11) defines Sensitive Data as personal data revealing racial or ethnic origin, or religious, intellectual, or political belief; data relating to security, criminal convictions, and offenses; biometric or genetic data used to identify a person; health data; and data indicating that one or both of an individual's parents are unknown. That list tracks GDPR Article 9's special categories closely, with one category GDPR does not treat as sensitive at all: parentage status, an illegitimacy-adjacent category with no GDPR analogue. Criminal-conviction data, which GDPR handles under a related but separate regime in Article 10, is folded directly into the PDPL's Sensitive Data definition.

Credit Data is a separate, independently defined category. PDPL Article 1(15) defines it as personal data related to an individual's request for, or obtaining of, financing, including their ability to obtain and repay debts and their credit history. It is not part of the Article 1(11) Sensitive Data definition. Instead, it is regulated under its own provision, PDPL Article 24, which cross-references the Kingdom's Credit Information Law and requires explicit consent verification plus subject notice when credit data is disclosed. GDPR has no equivalent special category for financial or credit data at all, so Saudi Arabia's treatment of credit information as a separately regulated category, distinct from its general sensitive-data rules, is a genuine point of divergence worth stating precisely rather than folding the two together.

Legal Bases for Processing and the Constrained Legitimate-Interest Ground

GDPR Article 6 gives controllers six possible legal bases: consent, contractual necessity, legal obligation, vital interests, public task, and legitimate interests, with a stricter regime for special-category data under Article 9.

The PDPL structures this differently and more narrowly.

Consent is the default rule. PDPL Article 5(1) requires the data subject's consent to process their data, or to change the purpose of processing, "except for the cases stated in this Law." Article 5(2) makes consent withdrawable at any time.

Article 6 sets out four grounds for processing without consent, each narrower and more specific than GDPR's six:

1. Processing serves the data subject's actual interests, but contacting them is impossible or difficult.
2. Processing is required by another law, or under a prior agreement to which the data subject is a party. This single ground covers ground that GDPR splits across separate contract and legal-obligation bases.
3. The controller is a Public Entity and the processing is for security purposes or judicial requirements.
4. Legitimate interest of the controller, "without prejudice to the rights and interests of the Data Subject," and provided no Sensitive Data is processed.

Ground four is where the two laws diverge most sharply. Implementing Regulation Article 16 makes clear that legitimate interest is available to private controllers only, not Public Entities. It requires a lawful purpose, a documented balancing test, a guarantee that no sensitive data is involved, and processing that stays within the data subject's reasonable expectations. Article 16(3) goes further and requires a mandatory documented impact assessment, covering purpose, necessity, potential harm, and mitigation, before a controller can rely on the ground at all. GDPR's Article 6(1)(f) balancing test has no equivalent blanket requirement to complete a formal assessment before relying on legitimate interest.

There is no separate public-task or vital-interests ground under PDPL Article 6 the way GDPR enumerates them individually. Saudi Arabia instead folds vital-interests and public-health/public-safety language into a different provision, Article 10, which governs collecting data from a source other than the data subject.

The net effect: Saudi legitimate interest is real, but it is consent's understudy for private controllers only, categorically off the table for any sensitive data, and gated behind a documented pre-assessment GDPR does not require as a universal rule.

Data Subject Rights and the Gaps

PDPL Article 4 enumerates data-subject rights exhaustively:

1. The right to be informed of the legal basis and purpose of collection.
2. The right to access personal data held by the controller, subject to the timeframes and limits in Article 9.
3. The right to request obtaining personal data "in a readable and clear format."
4. The right to request correction, completion, or updating.
5. The right to request destruction, subject to the retention exceptions in Article 18.

Compared against GDPR's Articles 15 through 22, several rights that GDPR grants have no PDPL counterpart, and the gaps are specific enough to state plainly:

• No right to object. There is no PDPL provision equivalent to GDPR Article 21 letting a data subject object to legitimate-interest processing, or to direct marketing, on grounds relating to their particular situation. Saudi Arabia instead makes marketing consent opt-in under Articles 25 and 26, which covers overlapping ground but is not framed as an objection right.
• No automated-decision-making or profiling right. No provision equivalent to GDPR Article 22 appears anywhere in the PDPL or its Implementing Regulation. A direct search of both texts turns up no substantive treatment of automated decision-making beyond listing it as a processing method in the Article 1 definition of "Processing," and no treatment of profiling at all. This is a genuine, notable gap.
• No true data portability right. Article 4(3)'s right to obtain personal data "in a readable and clear format" is a copy-in-usable-format right, closer to GDPR's access right (Article 15) than to GDPR Article 20's portability right, which includes the right to have data transmitted directly to a different controller. The PDPL does not grant that transmission right.
• No explicit restriction-of-processing right distinct from correction or destruction, unlike GDPR Article 18.
• The destruction right that does exist is qualified: Article 18 lets a controller retain data past purpose-completion where a legal basis supports a specific retention period, or where the data relates to a pending judicial matter.

The National Register of Controllers

This is one of the clearest structural forks between the two laws. GDPR abolished general prior notification and registration requirements in 2018, moving to an accountability-based model where controllers document their own compliance rather than registering with a regulator up front.

Saudi Arabia went the other way. 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 registration rules to SDAIA, stating that the Competent Authority "shall issue the rules for registration," provided those rules identify which controllers are required to register. The Implementing Regulation itself does not spell out the specific registration criteria; SDAIA determines and publishes them separately as regulator guidance rather than statutory text.

The practical takeaway for a controller assessing whether it needs to register is to check SDAIA's current published registration rules directly, since the underlying law text delegates that determination rather than fixing it in the statute.

Breach Notification

The PDPL and its Implementing Regulation split the breach-notification clock across two instruments, and it is easy to cite the wrong one.

PDPL Article 20 itself sets no numeric deadline. It requires the controller to notify SDAIA "upon knowing of any breach, damage, or illegal access to personal data, in accordance with the Regulations," and to notify the data subject of a breach that would cause damage or prejudice their rights, again "in accordance with the Regulations." The Law explicitly defers the actual clock to the Implementing Regulation rather than fixing it itself.

Implementing Regulation Article 24 sets the clock. Article 24(1) requires notice to SDAIA "within a delay not exceeding (72) hours" of becoming aware of an incident that potentially causes harm to the personal data, or to the data subject, or conflicts with their rights or interests, a risk-based trigger rather than a fixed headcount threshold. Article 24(2) allows a controller unable to provide full information within 72 hours to supply it as soon as possible afterward, along with justification for the delay. Article 24(5) requires notice to the data subject "without undue delay" where the breach may cause damage or conflict with their rights or interests, with no fixed hour count for that leg.

So the regulator-facing deadline (72 hours) mirrors GDPR Article 33's own 72-hour standard closely. The individual-facing deadline diverges in form only: GDPR Article 34 also uses "without undue delay" language for high-risk breaches, so the two laws land in a similar place on individual notice, even though the PDPL reaches that standard through its Implementing Regulation rather than the Law itself. For how this compares across other jurisdictions, see our survey of data breach notification deadlines by country.

Cross-Border Transfers, SCCs, and the Missing Adequacy List

This is where the PDPL's compliance burden diverges most sharply from GDPR's in practice, and it deserves the depth secondary summaries usually skip.

Adequacy exists as a mechanism, but no country has been found adequate yet. Data Transfer Regulation Article 3 has SDAIA, working with coordinating authorities, evaluate a destination country, sector, or organization against seven criteria: protective laws at least equivalent to the PDPL; rule of law; effective enforcement; data subjects' practical ability to exercise rights and complain; the existence of a supervisory authority; that authority's willingness to cooperate with SDAIA; and clarity of the destination's government-access rules. Article 4 has SDAIA recommend a decision to the Prime Minister, who issues or declines an adequacy decision, reviewed at least every four years. As of the most recent primary-source check, no adequacy decisions have been published. GDPR, by contrast, already has a populated adequacy list covering countries such as the UK, Japan, and South Korea, where transfers need no additional mechanism at all.

Because no adequacy list exists, most real-world transfers run on Article 5 appropriate safeguards. The options are Binding Common Rules (intra-group arrangements SDAIA approves case by case), Standard Contractual Clauses following SDAIA's own standard model issued in September 2024, compliance certifications from an SDAIA-accredited certifier, or binding codes of conduct. Binding Common Rules carry a substantial documentation burden: Article 5(2) lists at least fourteen required elements, including commercial registration information, the categories, purposes, and destinations of the transfer, data-subject rights and complaint mechanisms, a designated compliance-monitoring role, audit obligations, and a conflict-of-law escalation mechanism. Our page on Standard Contractual Clauses covers how SCCs function as a transfer mechanism more broadly.

Narrow exceptions exist without a safeguard, but only where a safeguard genuinely cannot be used. Data Transfer Regulation Article 6 permits transfer without an Article 5 safeguard for performance of an agreement the data subject is party to, Public Entity transfers for international cooperation or judicial purposes, protecting a data subject's vital interests, or scientific research.

A kill-switch obligation sits on top of all of this. Article 7 requires the controller to immediately stop an Article 5 or Article 6 transfer if it affects the Kingdom's national security or vital interests, or if a risk assessment finds high privacy risk, and to reassess before resuming.

A documented risk assessment is separately mandatory under Data Transfer Regulation Article 8 whenever a transfer relies on the Article 5 safeguards route, relies on an Article 6 exception, or involves continuous or large-scale transfer of Sensitive Data outside the Kingdom. That third trigger matters on its own: volume and sensitivity alone can force a fresh risk assessment even where a valid transfer mechanism is already in place. Article 8(2) requires the assessment to cover the purpose and legal basis for the transfer, its nature and scope, the adequacy of the chosen safeguard, data-minimization measures taken, and the potential material or moral impact on data subjects. SDAIA's Risk Assessment Guideline for Transferring Personal Data Outside the Kingdom, issued in February 2025, provides SDAIA's implementing guidance on how to conduct that assessment; the Article 8 obligation is the underlying legal requirement, and the Guideline is how SDAIA expects it to be carried out.

The practical upshot: because no adequacy list exists, essentially every routine cross-border transfer, including something as ordinary as using a US-based cloud vendor, runs on Article 5 safeguards, overwhelmingly SCCs in practice, plus a documented Article 8 risk assessment wherever the sensitive, continuous, or large-scale trigger is met. That is a materially heavier compliance lift than a GDPR transfer to a country already on the European Commission's adequacy list, where no transfer mechanism is required at all.

Data Localization: Correcting a Common Misreading

Data localization, meaning a legal requirement that personal data physically remain stored within a country's borders, is one of the most frequently and incorrectly attributed features of Gulf-region privacy laws in secondary commentary. The PDPL does not impose a general data-localization requirement. A direct search of the official PDPL and Implementing Regulation texts for localization-related language, including "local," "within the Kingdom," and "stored," turns up no provision requiring personal data to be processed or stored inside Saudi Arabia as a default rule.

What the PDPL and its Data Transfer Regulation actually do is regulate the conditions under which data may leave the Kingdom, through the adequacy, safeguards, and exception framework described above. They govern outbound transfer; they do not prohibit it or default to in-country storage. This distinction is frequently conflated with sector-specific localization rules in other GCC states, for example certain banking or healthcare data rules in the UAE, which are separate regimes entirely unconnected to the PDPL.

The one PDPL provision that comes closest to a residency-related hook is the extraterritorial-reach clause discussed above, Article 2(1), which applies the Law to processing of Saudi residents' data carried out from outside the Kingdom. That is a jurisdictional-reach provision, functioning like GDPR Article 3, not a localization mandate; it extends where the Law applies, it does not restrict where data may be stored. For how localization rules vary elsewhere, see our survey of data localization laws by country.

Penalties: Administrative and Criminal

GDPR Article 83 caps fines at the higher of a flat sum, up to EUR 20 million for the most serious tier, or a percentage of global annual turnover, up to 4%. The percentage mechanism scales exposure to a company's size and is effectively uncapped in absolute terms for a large multinational.

Saudi Arabia has no revenue-percentage mechanism at all. Instead, the PDPL runs two entirely separate tracks:

Administrative track (Article 36): a warning or fine of up to SAR 5,000,000 for any violation not covered by Article 35, doubled to SAR 10,000,000 on a repeat violation. The decision is made by an SDAIA-appointed committee of at least three members, including a technical specialist and a legal advisor, and approved by SDAIA's president.

Criminal track (Article 35): 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 applies specifically to a person who discloses or publishes Sensitive Data in violation of the Law, with the intention of harming the data subject or achieving a personal benefit. It is categorically separate from, and additional to, the Article 36 administrative track, and it is prosecuted as a criminal matter rather than decided by SDAIA's committee.

Other consequences beyond the fine schedule: 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 the administrative or criminal track.

The structural contrast: for a large multinational, GDPR's realistic financial exposure is typically far higher than Saudi Arabia's fixed administrative ceiling, because the 4%-of-turnover mechanism scales with company size while the PDPL's SAR 5,000,000 cap (SAR 10,000,000 doubled) does not. Saudi Arabia's comparatively unique exposure runs the other direction: a criminal offense that GDPR itself does not create, since criminal liability for EU data-protection violations is left to individual member states' own laws rather than the Regulation.

Data Protection Officer Requirement

Implementing Regulation Article 32(1) makes DPO appointment mandatory, using an individual who may be an employee or an external contractor, in three scenarios: a Public Entity providing services that involve large-scale processing; primary activities requiring regular and continuous large-scale monitoring of individuals; and core activities that consist of processing Sensitive Data. These three triggers closely mirror GDPR Article 37(1)'s own three triggers, public authority status, core activities requiring regular and systematic large-scale monitoring, and core activities involving large-scale special-category or criminal-conviction data, making this one of the few areas where the two laws structurally converge rather than diverge. Article 32(3) gives the DPO responsibilities that mirror GDPR's DPO role: acting as the regulator's point of contact, overseeing impact assessments, enabling data-subject rights, handling breach notification, and managing complaints. For jurisdiction-by-jurisdiction depth on when a DPO is required, see our data protection officer requirements page.

Recent Developments

Dual-Compliance Guidance

A controller operating under both laws should treat them as related but non-substitutable programs, not assume GDPR compliance covers Saudi obligations by default.

• Confirm registration status directly with SDAIA. GDPR abolished general registration; the PDPL did not. Do not assume a GDPR-style accountability model applies.
• Never rely on legitimate interest for sensitive data, and complete the documented pre-assessment before relying on it for anything else. A GDPR-style Article 6(1)(f) balancing analysis is not sufficient on its own under Implementing Regulation Article 16, which requires that pre-assessment as a separate, mandatory step.
• Build separate rights-fulfillment workflows. A process built only to the PDPL's four rights will fall short of GDPR obligations for EU data subjects, and vice versa; map which individuals each request actually covers before applying one global process.
• Treat outbound transfers as needing their own mechanism. GDPR SCCs are not the same instrument as SDAIA's September 2024 SCC model, and an adequacy finding under one regime does not carry over to the other. Budget for a documented Article 8 risk assessment as a real compliance step wherever its triggers apply.
• Name the criminal-liability risk in training specifically. GDPR programs are not built around personal criminal exposure for staff; PDPL Article 35 introduces one for intentional, harmful, or self-benefiting sensitive-data disclosure.
• Do not describe the PDPL as requiring data to stay in Saudi Arabia. It does not; build the program around the actual requirement, a documented and safeguarded transfer process.