Saudi PDPL: The Practical Compliance Guide

Most PDPL guidance circulating in Saudi Arabia has a tell: it reads like GDPR with the place names swapped. It will confidently list a "right to object," a "right to restriction of processing," a duty to "acknowledge a data subject request within five working days," and a DPO who cannot be dismissed for doing the job. None of those exist in Saudi law. They were imported from Europe by writers who assumed the two regimes must be the same, and they are not.

That matters more than a pedant's footnote. If you build your compliance programme against the wrong statute, you will over-engineer the parts Saudi law does not require and under-build the parts it does — and the parts it does require are, in at least one important respect, stricter than GDPR.

Everything below is quoted from the two documents that actually govern this:

• The Personal Data Protection Law, issued by Royal Decree No. M/19 dated 9/2/1443H, as amended by Royal Decree No. M/148 dated 5/9/1444H. (Referred to below as "the Law".)
• The Implementing Regulation of the Personal Data Protection Law, issued by SDAIA. (Referred to below as "the Regulation".)

Both are issued and published by SDAIA — the Saudi Data and Artificial Intelligence Authority — on its website at sdaia.gov.sa. (SDAIA's site blocks automated fetching, so navigate to the personal-data-protection section from the homepage rather than trusting a deep link copied from a blog.) Where the Law or the Regulation is silent on something, this guide says so rather than borrowing an answer from elsewhere.

Who this binds, and where

The Law does not name its own regulator. Article 1(3) defines the "Competent Authority" as "the authority to be determined by a resolution of the Council of Ministers." In practice that authority is SDAIA — the Saudi Data and Artificial Intelligence Authority — which issues the Implementing Regulation, operates the national register, and receives breach notifications.

On timing: Article 43 states that "This Law shall come into force after (seven hundred and twenty) days commencing on the date of its publication in the Official Gazette." That clock produced an enforcement date of 14 September 2023, and the Regulation, per its own Article 38, "shall come into force from the date of the Law's enforcement." The transition period that followed has since closed. PDPL is live law, not a forthcoming obligation.

And it reaches beyond the Kingdom's borders. Article 33(4) of the Law requires the Competent Authority to "specify the appropriate tools and mechanisms to monitor compliance of Controllers and Processors outside the Kingdom in regard with their obligations as stated in the Law and the Regulations when Processing personal data related to individuals residing in the Kingdom by any means, and shall define procedures to enforce the provisions of the Law and the Regulations outside the Kingdom." If you process the data of people living in Saudi Arabia, you are in scope regardless of where your company or your servers sit.

The five rights — and there are exactly five

Article 4 of the Law is short, closed, and exhaustive. "Data Subject shall have the following rights pursuant to this Law and as set out in the Regulations":

1. The right to be informed about the legal basis and the purpose of the Collection of their Personal Data.
2. The right to access their Personal Data held by the Controller, in accordance with the rules and procedures set out in the Regulations, and without prejudice to Article (9) of the Law.
3. The right to request obtaining their Personal Data held by the Controller in a readable and clear format, in accordance with the controls and procedures specified by the Regulations.
4. The right to request correcting, completing, or updating their Personal Data held by the Controller.
5. The right to request Destruction of their Personal Data held by the Controller when it is no longer needed by the Data Subject, without prejudice to Article (18) of the Law.

That is the whole list. Now, the list that is not in Saudi law, and which you should stop putting in your privacy notice:

Publishing rights you do not actually grant is not a harmless generosity. It creates contractual expectations you will be held to, and it signals to a regulator that you copied someone else's homework.

The deadlines that do exist

The 30-day clock is real, and it lives in Regulation Article 3(1)(a) — not Article 5, which is the right of access. Article 3(1)(a) requires the Controller to:

"Act on the request of the Data Subject for exercising their rights under the Law within a period not exceeding (30) days and without delay. This period may be extended in case the implementation requires disproportionate effort, or if the Controller receives multiple requests from the data subject, provided that the extension period does not exceed an additional (30) days and the Data Subject is notified in advance of the extension with the reasons for the delay."

Note the discipline in that sentence: the extension is not automatic and it is not silent. You must tell the data subject in advance, with reasons.

There is no five-working-day acknowledgement requirement anywhere in the Law or the Regulation. If your policy contains one, someone invented it.

Three further obligations in the same article are routinely missed:

• Art. 3(1)(c): you must "take appropriate measures to verify the identity of the requester" before executing the request.
• Art. 3(1)(d): you must "document and keep record of all received requests including oral requests." A request made verbally to a branch employee is a request. If you only log the ones that arrive through the web form, you are not compliant.
• Art. 3(2): you may refuse a request that is "repetitive, manifestly unfounded, or requires disproportionate efforts" — but you must notify the data subject of the reason.

Separately, Regulation Article 4(3) gives you a 30-day clock for data you collected about someone from a third party rather than from them: you must, "without undue delay and within a period not exceeding (30) days," tell them what you hold, the categories of data, and the source you obtained it from. Data-broker lists and enrichment vendors trip over this constantly.

Lawful bases: consent first, then four exceptions

Article 5(1) sets the default: "neither Personal Data may be processed nor the purpose of Personal Data Processing may be changed without the consent of the Data Subject." Article 5(2) guarantees withdrawal "at any time." Article 7 prohibits making consent "a condition of providing a service or a benefit, unless such service or benefit is directly related to the Processing of Personal Data for which the consent is given" — no consent-walls for unrelated processing.

Article 6 then lists the four cases where consent is not required:

1. The Processing serves actual interests of the Data Subject, but communicating with them is impossible or difficult.
2. The Processing is pursuant to another law, or in implementation of a previous agreement to which the Data Subject is a party.
3. The Controller is a Public Entity and the Processing is required for security purposes or to satisfy judicial requirements.
4. The Processing is necessary for the legitimate interest of the Controller, without prejudice to the rights and interests of the Data Subject, "and provided that no Sensitive Data is to be processed."

That fourth basis is the workhorse for commercial businesses, and the Regulation puts real conditions on it. Regulation Article 16(1) allows legitimate-interest processing "Except Public Entities" — public bodies cannot use it at all — and only if: the purpose does not violate any law in the Kingdom; the controller's interest is balanced against the data subject's rights; no Sensitive Data is involved; and the processing is "within the reasonable expectations of the Data Subject."

Article 16(3) then requires something most companies have simply not done: before relying on legitimate interest, "the Controller shall conduct and document an assessment of the proposed Processing and its impact on the rights and interests of Data Subjects." A written, retained Legitimate Interest Assessment is not optional. Article 16(2) helpfully names two examples that qualify: "the Disclosure of fraud operations" and "the protection of network and information security."

Sensitive Data — the definition drives everything else

Article 1(11) defines Sensitive Data as personal data revealing:

• racial or ethnic origin
• religious, intellectual or political belief
• data relating to security criminal convictions and offenses
• biometric or Genetic Data for the purpose of identifying the person
• Health Data
• data indicating that one or both of the individual's parents are unknown

Two things Saudi practitioners should notice. First, the final category — parentage unknown — has no GDPR analogue and reflects a specific social-protection concern in the Kingdom. Second, Credit Data is defined separately at Article 1(15) and is not on the Sensitive Data list. It carries its own controls elsewhere, but it does not automatically drag you into the sensitive-data regime. Guides that lump them together are guessing.

Why the definition matters so much is the next section.

Impact assessments: PDPL's trigger is broader than you think

This is the provision most commonly under-scoped, and getting it wrong is how organisations end up non-compliant while believing they are fine.

Regulation Article 25(1) requires a written, documented impact assessment in four cases:

Read 25(1)(a) again. It says "Processing of Sensitive Data." Full stop. There is no "large-scale" qualifier, no volume threshold, no "systematic and extensive" hedge. GDPR Article 35(3)(b) requires a DPIA for processing "on a large scale" of special categories; PDPL does not. Under Saudi law, any processing of Sensitive Data requires a documented impact assessment.

The practical consequence is large. A clinic with forty patients processes Health Data — DPIA required. An HR system that stores a single medical certificate processes Health Data — DPIA required. A building that uses fingerprint entry processes biometric data for identification — DPIA required. Guides that tell you "you only need a DPIA for large-scale sensitive processing" are quoting the wrong law, and the mistake is not conservative; it leaves you exposed.

25(1)(b) is the other sleeper. "Collecting, comparing, or linking two or more datasets of Personal Data obtained from different sources" describes, precisely, what a customer-360 project does. What a data warehouse does. What an identity-resolution or lead-enrichment pipeline does. If you are joining CRM data to billing data to web analytics from different origins, that is 25(1)(b), and it requires an assessment before you build it — not after.

Article 25(2) sets out what the assessment must contain, at minimum: the purpose and legal basis; the nature of the processing, data types and sources, and any disclosure recipients; the scope, including the geographical scope of the processing; the processing context and the relationships between data subjects, controller and processors; and the necessity and proportionality of the measures taken to keep processing to the minimum needed.

That geographical-scope requirement is not decorative. Article 25(2)(c) makes where your data physically is an element of a document you may have to hand a regulator. Organisations that cannot answer "which country is this database in?" in one sentence tend to discover it at the worst possible moment. Skyline Cloud keeps it a one-sentence answer: Saudi infrastructure, SAR billing, Arabic interface and support. Start your free 14-day trial — no credit card required.

The Data Protection Officer: appointed, but not protected

Regulation Article 32(1) requires a Controller to "appoint one or more individuals to be responsible for the protection of Personal Data" in any of three cases:

• (a) The Controller is a Public Entity that provides services involving Processing of Personal Data on a large scale.
• (b) The Controller's primary activities are based on processing operations that, by their nature, require regular and systematic monitoring of Data Subjects.
• (c) The core activities of the Controller are based on processing sensitive Personal Data.

Now the provision that Europe-derived guides get badly wrong. Article 32(2):

"Subject to the requirements of paragraph (1) of this Article, the data protection officer may be an executive, an employee or an external contractor of the Controller."

That is the entire statement on the DPO's status. There is no independence guarantee, no prohibition on conflicts of interest, and — critically — no protection against dismissal or penalty for performing the role. GDPR Article 38(3) says a DPO "shall not be dismissed or penalised for performing his tasks"; PDPL says no such thing. The Saudi DPO may be a serving executive of the very business they oversee.

You may, of course, choose to give your DPO independence as a matter of good governance — and if your organisation is also subject to sectoral rules (SAMA, NCA, health-sector requirements), those may impose more. But do not tell your board that Saudi law protects the DPO's tenure. It does not.

Article 32(3) lists the DPO's responsibilities: acting as the direct point of contact with the Competent Authority; supervising impact assessments and audit reporting; enabling data subjects to exercise their rights; notifying the Competent Authority of breaches; responding to data subject requests and complaints; maintaining the records of processing activities; and handling violations and corrective actions. Article 32(4) notes that the Competent Authority "shall issue rules for the appointment of the data protection officer, which shall include the circumstances under which a data protection officer shall be appointed" — so check SDAIA for rules issued after the Regulation.

Records of processing: five years past the end

Regulation Article 33 is unglamorous and frequently ignored. The Controller "shall keep a record of Personal Data Processing activities during all the period Personal Data is being processed, and till to five years after the date of end of any Personal Data Processing activity." The records must be written, kept accurate and up to date, and produced to the Competent Authority on request.

The minimum contents (Art. 33(5)) include the controller's contact details; DPO information where required; purposes; categories of data and data subjects; retention periods per category where possible; categories of recipients; a description of transfers outside the Kingdom, including the legal basis and recipient parties; and a description of the security measures in place.

Note the asymmetry that catches people: your record of a processing activity outlives the activity itself by five years. Deleting the data does not let you delete the record.

Breach notification: 72 hours, and what the clock is actually on

Regulation Article 24(1): the Controller "shall notify the Competent Authority within a delay not exceeding (72) hours of becoming aware of the incident, if such incident potentially causes harm to the Personal Data, or to Data Subject or conflict with their rights or interests."

The clock starts at awareness, not at occurrence. The notification must include: a description of the incident with time, date, circumstances and when you became aware; the data categories and actual or approximate number of affected data subjects; a description of the risks and the actual or potential impact, the measures taken to limit them and future measures to prevent recurrence; whether the data subjects have been notified; and contact details for the Controller or its DPO.

Article 24(2) is the pressure valve people miss: if you cannot provide all of that within 72 hours, "it shall provide it as soon as possible, along with justifications for the delay." You still notify inside 72 hours — you simply complete the picture afterwards, with reasons.

Now the part that differs from the assumption: notifying data subjects has no fixed deadline. Article 24(5) requires the Controller to notify the data subject "without undue delay" where the breach "may cause damage to their data or conflict with their rights or interests," in simple and clear language, including a description of the breach, the risks, contact details, and "any recommendations or advice that may assist the Data Subject in taking appropriate measures." No 72 hours. No 30 days. "Without undue delay" — and you will be judged on it.

Finally, Article 24(4): none of this "prejudice[s] the obligations of the Controller or Processor to submit any report or notification about Personal Data Breaches according to what is issued by the National Cybersecurity Authority or any laws and Regulations applicable in the Kingdom." A breach in a regulated sector can trigger SDAIA and NCA and sectoral reporting. They are not alternatives.

Article 24(3) also requires you to keep a copy of the reports you filed and document the corrective measures taken, "as well as any relevant documents or supporting evidence."

Cross-border transfer

Article 29(1) of the Law permits a Controller to transfer Personal Data outside the Kingdom, or disclose it to a party outside the Kingdom, for these purposes:

• (a) performing an obligation under an agreement to which the Kingdom is a party;
• (b) serving the interests of the Kingdom;
• (c) performing an obligation to which the Data Subject is a party;
• (d) fulfilling other purposes as set out in the Regulations.

Article 29(2) then imposes three cumulative conditions on any such transfer:

• (a) it "shall not cause any prejudice to national security or the vital interests of the Kingdom";
• (b) there is "an adequate level of protection for Personal Data outside the Kingdom ... at least equivalent to the level of protection guaranteed by the Law and Regulations, according to the results of an assessment conducted by the Competent Authority";
• (c) the transfer "shall be limited to the minimum amount of Personal Data needed."

Article 29(3) disapplies those conditions in "cases of extreme necessity to preserve the life or vital interests of the Data Subject or to prevent, examine or treat disease."

Article 29(4) delegates the detail — "the provisions, criteria and procedures related to the implementing this Article, including applicable exceptions" — to the Regulations.

Here is what this guide will not do. SDAIA issued a separate regulation governing personal data transfer outside the Kingdom under the authority of Article 29(4), setting out the adequacy-decision mechanics, the risk-assessment requirements and the exception conditions. I was not able to obtain an authoritative copy of that instrument while writing this guide, and I am therefore not quoting article numbers, thresholds or timelines from it. If your programme depends on cross-border transfer, read that regulation directly from SDAIA rather than trusting any secondary summary — including this one. What you can rely on from the primary text above is the shape of the obligation: a permitted purpose under 29(1), plus all three conditions under 29(2), plus data minimisation, plus a record of the transfer and its legal basis in your Article 33 processing record.

The simplest way to make a cross-border transfer problem go away is not to have one.

Penalties

Two separate regimes, and they are frequently conflated.

Two further exposures sit outside that table. Article 40: any individual who suffers damage from a violation "may apply to a competent court for proportionate compensation for the material or moral damage" — civil liability on top of the regulatory fine. And Article 41: "Any person that engages in the Processing of Personal Data shall protect the confidentiality of the Personal Data even after the end of such person's occupational or contractual relationship." Your obligations follow your leavers out of the door.

A 10-step programme that maps to the actual text

1. Map your processing. You cannot do anything else until you know what you hold, why, on what basis, and where it physically sits (Regulation Art. 33; Art. 25(2)(c)).
2. Classify Sensitive Data properly against Article 1(11) — including the parentage category, and excluding Credit Data, which has its own definition at Art. 1(15).
3. Run the DPIA test honestly against all four limbs of Regulation Art. 25(1). If you touch any Sensitive Data at all, you need one. If you join datasets from different sources, you need one.
4. Pick and document a lawful basis per processing activity. If it is legitimate interest, write the Art. 16(3) assessment before you start, and confirm you are not a Public Entity and not touching Sensitive Data.
5. Rewrite your privacy notice to the five Article 4 rights. Remove any right you do not actually grant. Add the Art. 4(1) disclosures from the Regulation, including retention periods and how to withdraw consent.
6. Build a DSR process with a 30-day SLA, an identity-verification step, a documented extension path (up to a further 30 days, notified in advance with reasons), and a log that captures oral requests.
7. Decide whether Art. 32(1) obliges you to appoint a DPO. If it does, appoint one — and remember Art. 32(2) permits an executive, employee or external contractor, but check SDAIA's appointment rules under Art. 32(4).
8. Write the breach runbook to the 72-hour clock from awareness, with a partial-notification path under Art. 24(2), a "without undue delay" data-subject path under Art. 24(5), and a parallel NCA path under Art. 24(4).
9. Stand up the Article 33 processing record — written, current, produced on request, retained five years past the end of the activity, including a description of any transfers outside the Kingdom.
10. Interrogate every cross-border flow against Art. 29(1) and 29(2), and read SDAIA's transfer regulation directly. Retire the flows you cannot justify.

FAQ

How many rights does PDPL actually grant? Exactly five, in Article 4: to be informed; to access; to obtain a copy in a readable and clear format; to correct, complete or update; and to request destruction when the data is no longer needed.

Does PDPL have a right to object or a right to restrict processing? No. Neither appears in Article 4. Both are GDPR concepts.

How long do I have to respond to a data subject request? Thirty days, "and without delay," under Regulation Article 3(1)(a) — extendable by up to a further 30 days where implementation requires disproportionate effort or where the data subject has made multiple requests, provided you notify them in advance with reasons.

Is there a five-working-day deadline to acknowledge a request? No. There is no such requirement in the Law or the Regulation.

When do I need a data protection impact assessment? In any of the four cases in Regulation Article 25(1): any processing of Sensitive Data (there is no large-scale threshold); collecting, comparing or linking two or more datasets obtained from different sources; large-scale and repetitive processing involving those lacking legal capacity, constant monitoring, newly adopted technologies, or automated decision-making; or providing a product or service likely to cause serious harm to privacy.

Can my DPO be an employee or an executive? Yes. Regulation Article 32(2) expressly permits the DPO to be "an executive, an employee or an external contractor of the Controller." Saudi law does not give the DPO the dismissal protection that GDPR does.

How fast must I report a breach? Within 72 hours of becoming aware of the incident, to the Competent Authority (Regulation Art. 24(1)). If you cannot supply everything within 72 hours, notify anyway and supply the rest as soon as possible with justification (Art. 24(2)). Affected individuals are notified "without undue delay" (Art. 24(5)) — no fixed clock. NCA and sectoral reporting duties are separate and additive (Art. 24(4)).

What are the maximum penalties? Article 35: up to two years' imprisonment and/or a fine up to SAR 3 million for disclosing or publishing Sensitive Data with intent to harm or gain. Article 36: for all other violations, a warning or a fine up to SAR 5 million. Both may be doubled for repeat offences, capped at double the limit. Article 40 adds a civil right to compensation for material or moral damage.

Does PDPL apply to my company if we are not in Saudi Arabia? If you process personal data of individuals residing in the Kingdom, yes — Article 33(4) directs the Competent Authority to monitor and enforce against controllers and processors outside the Kingdom.

Does PDPL require me to host data in Saudi Arabia? The Law does not impose a blanket localisation mandate. It regulates transfer: Article 29 permits it only for a listed purpose, only where the destination offers an adequate level of protection as assessed by the Competent Authority, only without prejudice to national security or the Kingdom's vital interests, and only to the minimum extent needed. Sector rules (NCA, SAMA, health) and the separate VAT record-keeping requirement to keep records in the Kingdom may bind you harder. In practice, keeping the data in Saudi Arabia removes an entire class of problem rather than solving it repeatedly.

PDPL is not GDPR with a different flag on it. It is shorter, it is stricter in places people do not expect — the sensitive-data DPIA trigger above all — and it is looser in places people assume are locked down, like the DPO's independence. Reading the actual text takes an afternoon. Building a programme on someone's blog post about it takes a lot longer to unwind.

If part of your answer is simply keeping Saudi personal data in Saudi Arabia, that part is easy. Skyline Cloud is Saudi-hosted with SAR billing, an Arabic interface and Arabic support, daily backups, free auto-renewing SSL and a 99.9% uptime SLA. Start your free 14-day trial — no credit card required, and make the geographical-scope line in your Article 25(2)(c) assessment a very short sentence.

Related reading: ZATCA Phase 2 (Integration) — the definitive technical guide · Saudi Aramco SACS-002: what Aramco actually asks contractors for · PDPL, NCA and Saudi data residency for hosting · Skyline Cloud hosting plans · Skyline Cloud in Saudi Arabia