If your company is established in the EU and starts marketing to people in Saudi Arabia, the PDPL vs GDPR question has a short answer: both laws apply. The GDPR applies to processing carried out in the context of an EU establishment, regardless of where the data is processed. Saudi Arabia's Personal Data Protection Law (PDPL) applies to processing in the Kingdom and, under its Article 2, to processing by entities outside the Kingdom of personal data relating to individuals who live there. A lead form on your Arabic landing page brings you under both.

The two laws share a lot of structure. This article covers the points where the PDPL and its Implementing Regulations, published by the Saudi Data and AI Authority (SDAIA), ask for something different or more specific. Where a point depends on your facts, we say so.

Legal bases: consent is the default under the PDPL

The GDPR gives six equal legal grounds for processing: consent, contract, legal obligation, vital interests, public task and legitimate interests.

The PDPL is built the other way round. Article 5 makes consent the rule, and Article 6 lists the cases where consent is not needed: a real benefit to the person when contacting them is impossible or difficult, a legal requirement or an existing agreement with the person, certain public-sector security and judicial needs, and the controller's legitimate interests. Legitimate interests cannot be used for sensitive data, and Article 16 of the Implementing Regulations adds conditions: a lawful purpose, a balance against the person's rights, processing within their reasonable expectations, and a documented assessment before processing starts.

In practice, a European company that relied on legitimate interests for its EU funnel should plan on consent for most Saudi marketing processing, unless a legal review supports another basis for a specific use.

What valid consent looks like

Both laws want consent that is freely given, specific and easy to withdraw. Article 11 of the PDPL Implementing Regulations spells out a few details that affect how you build forms and store records:

  • Consent can be written, oral or electronic, but it must be documented with the time and the method used to obtain it.
  • Consent must be obtained separately for each purpose. One checkbox covering newsletters, profiling and partner sharing does not meet this.
  • Explicit consent is required for sensitive data, credit data and decisions made entirely by automated processing.
  • Under Article 12, withdrawing consent must be as easy as giving it, and processing must stop without undue delay.

If your CRM stores a single opt-in flag, add fields for purpose, timestamp, source form and wording version. That record is what you will need to show SDAIA or an EU authority if a complaint arrives.

Marketing emails and messages

In the EU, rules on marketing emails come from the ePrivacy Directive as well as the GDPR. Article 13 of that directive requires prior consent for email marketing, with an exception for existing customers receiving offers for similar products, provided they can object easily and free of charge.

The PDPL Implementing Regulations take a comparable line in two articles. Article 28 covers promotional and awareness material: you need the recipient's consent before sending unless there has been a prior dealing between you, and the recipient must be able to choose what they receive. Article 29 covers direct marketing and requires consent under Article 11. Both articles require that each message names the sender clearly, that an opt-out mechanism exists which is at least as easy as giving consent, that opt-out is free, and that sending stops promptly once someone opts out. Article 28 also requires records that prove consent.

Cookies and website analytics

EU cookie rules come from Article 5(3) of the ePrivacy Directive: storing or reading information on a user's device needs consent, except where it is strictly needed for a service the user asked for.

The PDPL Implementing Regulations we reviewed do not contain a cookie-specific article. Where analytics or advertising tags collect personal data from visitors in the Kingdom, the general PDPL consent rules apply. The simplest defensible setup is to run the same consent banner on your Arabic pages as on your European ones, written properly in Arabic, with analytics and advertising tags firing only after acceptance. Ask your legal adviser to confirm this for your tag set.

Cross-border transfers: both directions

From the EU to Saudi Arabia

Saudi Arabia does not have an EU adequacy decision. Sending personal data from your EU systems to a Saudi distributor, partner or subsidiary therefore needs an appropriate safeguard under the GDPR, usually the European Commission's standard contractual clauses with a transfer impact assessment. The derogations in Article 49 GDPR are meant for occasional cases, not routine business flows.

From Saudi Arabia to the EU

If leads collected from Saudi residents land in a CRM hosted in Frankfurt or Dublin, that is a transfer outside the Kingdom under Article 29 of the PDPL. SDAIA's Regulation on Personal Data Transfer outside the Kingdom sets out how it can happen:

  • Transfer to a country or organisation on the competent authority's list of destinations with adequate protection.
  • Where no adequacy finding covers the destination, appropriate safeguards: standard contractual clauses based on the authority's model, binding common rules within a multinational group, or a certification issued to the recipient by a body the authority has licensed.
  • Limited exemptions for specific purposes, each still tied to safeguards and most excluding sensitive data.

Article 7 of the transfer regulation requires a risk assessment before transfers that rely on safeguards, before any transfer of sensitive data, and before continuous or large-scale transfers. A CRM that receives every Saudi lead is likely to be continuous. Map where your website forms, CRM, email platform and analytics actually store data before you launch, because changing hosting after launch is harder.

Breach notification timelines

  • GDPR: notify the supervisory authority without undue delay and at the latest within 72 hours of becoming aware, where the breach is likely to pose a risk to people's rights and freedoms. Tell affected individuals when the risk is high.
  • PDPL: Article 24 of the Implementing Regulations requires notice to the competent authority within 72 hours of becoming aware of an incident that could harm personal data, data subjects or their rights and interests. Affected individuals must be told without undue delay where harm is likely.

One incident affecting both EU and Saudi contacts can therefore mean two notifications to two authorities on the same clock. Your incident plan should name who files each one and in which language.

Data subject rights and response times

Both laws give people rights of access, correction and deletion, and the right to withdraw consent. The European Commission's guidance asks for a response without undue delay and in principle within one month. Article 3 of the PDPL Implementing Regulations sets a maximum of thirty days, extendable by up to thirty more where a request needs unexpected effort or several requests arrive, provided the person is told in advance with reasons. A shared thirty-day internal deadline works for both.

DPO, records and registration

The DPO tests are close. The GDPR requires a data protection officer for public authorities, and where core activities involve large-scale regular and systematic monitoring or large-scale processing of sensitive data. Article 32 of the PDPL Implementing Regulations uses similar triggers and allows the DPO to be an employee or an external contractor.

Records go further under the PDPL. Article 33 of the Implementing Regulations requires written records of processing activities kept for the duration of the processing plus five years after it ends. Article 34 refers to a National Register of Controllers, with SDAIA setting the rules on which controllers must register, and SDAIA's platform includes a registration path for entities outside the Kingdom. Whether your company has to register depends on your facts; check it with legal counsel early in the project rather than after launch.

Penalties

GDPR fines reach up to 20 million euros or 4% of worldwide annual turnover. Under the PDPL, Article 36 allows a warning or a fine of up to 5 million riyals for violations, which can be doubled for repeat offences. Article 35 provides criminal penalties, including imprisonment, for disclosing or publishing sensitive data with intent to harm or for personal gain.

A practical checklist before your Saudi launch

  1. List every system that will touch Saudi personal data: website forms, CRM, email and WhatsApp tools, analytics, ad platforms, partner portals.
  2. Record where each stores data and which transfer route covers each direction.
  3. Rework forms so consent is separate per purpose and stored with timestamp, source and wording.
  4. Publish an Arabic privacy notice that reflects the PDPL as well as the GDPR. SDAIA publishes a guideline on preparing privacy policies.
  5. Add opt-out and sender identification to every marketing channel.
  6. Extend the incident plan to cover SDAIA notification within 72 hours.
  7. Set one internal response deadline for rights requests that meets both laws.
  8. Get a legal review of the whole setup before the first campaign goes live.

Our IT solutions team maps data flows, configures consent and CRM fields and works alongside your legal advisers on the compliance side. For companies at an earlier stage, data protection is one workstream inside a Saudi market entry plan.

This article is a general comparison for planning purposes and is not legal advice. Both laws, their regulations and SDAIA guidance are updated from time to time, and how they apply depends on your activities. Have a qualified lawyer review your setup in both jurisdictions.