PDPL Compliance: What Saudi Arabia's Data Protection Law Means for Your Website

Consent under Saudi Arabia's Personal Data Protection Law (PDPL) is not a checkbox. It is a timestamped record of who agreed, to what, and when. That technical distinction changes how you build your forms, and it is where violations most often occur.

Most writing about PDPL compliance is aimed at lawyers and explains articles and definitions. Most site owners read it and come away thinking the whole thing is "legal" and unrelated to code.

That is wrong. The larger part of compliance is implemented in the website itself: in the contact forms, in the cookie banner, and in the database storing what visitors submit.

This guide covers that technical part specifically.

An important note: this is not legal advice, and I am not a legal authority. The only authoritative references are the Saudi Data and Artificial Intelligence Authority (SDAIA) and the text of the law itself, and any decision affecting you should go through qualified counsel. The information below is assembled from published legal commentary rather than read from the statute directly, verify it before building on it.

Where things stand

The Personal Data Protection Law (PDPL) is Saudi Arabia's national law governing the collection and processing of individuals' personal data, with the Saudi Data and Artificial Intelligence Authority (SDAIA) as its supervisory authority. According to published legal sources: the law came into force on 14 September 2023, with a one-year compliance grace period that ended on 14 September 2024. We are no longer in an awareness phase; enforcement is active.

The authority announced in early 2026 that it had issued dozens of decisions against organisations in violation. The recurring pattern in those cases, per published analyses, is processing without a lawful basis, missing security controls, undocumented practices, and marketing messages sent without consent.

Pay particular attention to that last one, because it is closest to what websites do every day.

The core distinction: consent is a record, not a checkbox

This is the idea that changes how you build.

Many sites, from a startup store in Riyadh to a services firm in Jeddah, add an "I agree to the privacy policy" checkbox and consider the matter closed. The problem is that the checkbox proves one thing at the moment of submission, and proves nothing six months later when you are asked to demonstrate that this person consented.

What is actually needed is a record: who consented, to what exactly, when, and from which form. That is database work, not interface work.

In practice, with every form submission, store:

• The consent text exactly as it was displayed at the time: not a link to a page that may later change. • A precise timestamp. • The purpose they agreed to: contact about an enquiry, or marketing messages? Those are two separate purposes. • The form's source and version.

Which is why copying an "I agree" line from another site solves nothing. What is required is a storage design, not a wording.

The three most common mistakes on Saudi websites

One: assumed consent instead of explicit consent. A pre-ticked box, or a line saying "by using this site you agree", or a cookie banner whose only button is "Accept" with no way to decline. The common thread is that the user never took a clear affirmative action.

Two: a copy-pasted privacy policy. Saudi sites routinely carry policies describing rights lifted from European regulations and naming non-Saudi supervisory authorities. A policy that does not describe what your site actually does is decoration rather than compliance. and worse, it commits you to obligations you do not perform.

Three: no way to withdraw or delete. The site collects data easily and offers no clear route for a user to request their copy or its deletion. And even where an email address would suffice as the channel, usually nobody internally knows how to action the request when it arrives.

A practical list: what gets implemented in the site

These are technical items you could do this week:

1. Audit every form on the site. For each: what does it collect, why, where is it stored, and for how long? Most sites have no written answer to those four questions. 2. Separate the purposes. Consent to "contact me about my enquiry" is not consent to "send me offers". Make them two separate, unticked choices. 3. Store the consent record as described above, text, timestamp, purpose. 4. Write a privacy policy that describes your site. What you actually collect, where it is actually stored, which analytics tools actually run.

The first four are build tasks. The last three are about what happens after launch, and they are the ones teams forget:

5. Provide a route for requests. A published address or a dedicated form for access, correction and deletion. and an internal owner who knows how to action them. 6. Review third-party tools. Analytics, heatmaps and ad pixels all transmit data to other parties. If they are not named in your policy, they are undisclosed. 7. Collect less. The simplest way to reduce risk: do not ask for a field you do not use. Every extra field is extra obligation for nothing.

The item that surprises everyone: retention

Forms collect, data accumulates, and nobody deletes anything. An inbox holding three years of contact-form messages is a personal data store in every meaningful sense, even if you have never thought of it that way.

Ask yourself: what purpose still exists for holding the details of someone who wrote to you two years ago and whose matter closed? If no live purpose exists, the holding itself is the risk.

Set a written retention period for each data type, and actually apply it, rather than writing it into the policy and leaving it there.

Does any of this affect your search rankings?

Not directly, and I will say so plainly rather than claim a connection that does not exist: data protection compliance is not a ranking factor.

But the indirect effects are real:

• A genuine privacy policy is a trust signal a buyer reads before leaving their details; its absence or its obvious sloppiness is friction in the conversion path. • A heavy or badly implemented cookie banner affects page speed and visual stability. and both of those are measured. • Collecting less means shorter forms, and shorter forms get completed more often.

So the real benefit is operational and conversion-related, not positional.

Sensitive data: the category collected by accident

Some data attracts stricter treatment, and websites sometimes collect it without meaning to.

Examples that recur on Saudi sites:

• A careers form asking for an ID copy, date of birth, or marital status. • A health-products store with a "describe your condition" field: that is health data. • A booking form asking for a national ID number "for confirmation" when a name and mobile would do. • An open text field with no guidance, where a customer volunteers details you never asked for and do not want to be responsible for.

The preventive rule is simple: do not ask for what you do not need. Every sensitive field you collect raises your obligations and your risk while usually adding nothing. And if you genuinely need it for an operational reason, that is a question for your counsel rather than your own judgement.

Watch the open text field in particular. You do not control what a user types into it, but you do control what you do with what arrives. Add a short note above it: "please do not enter sensitive information here".

PDPL compliance across borders: where is your site hosted?

A question that gets skipped entirely, despite applying to most modern Saudi websites.

Your site is probably hosted on global infrastructure, your files sit in cloud storage, your forms pass through an email service, and your analytics live with a foreign provider. Which means your visitors' data leaves the Kingdom in its ordinary path, even if you have never once thought about it.

That is not necessarily prohibited, but it is something you must know and disclose: published legal sources indicate there are controls on transfers outside the Kingdom, and the detail is a question for your counsel.

One more note if you serve customers beyond the Kingdom: each Gulf state has its own data-protection regime, the UAE and Qatar have their own laws, and this guide covers the Saudi PDPL specifically.

The practical minimum:

• Know where your data actually lives. Hosting, database, file storage, email provider, analytics tools. Write the list. • Say so in your policy, plainly: "your data may be transferred and processed outside your country of residence". • Ask before adding any new tool: where does this send data? One question before installing costs less than an audit a year later.

The idea running through all of this: you cannot protect what you do not know exists. The inventory is always the first step, and most sites have never done one.

Who does what?

Confusion over responsibility is a leading reason this stays unresolved:

• The developer implements: purpose separation, consent-record storage, the deletion mechanism, and the third-party tool review. • Legal counsel decides: the lawful basis, the policy wording, any registration obligations that apply, and retention periods. • You settle: what data your business genuinely needs, and who handles incoming requests.

Do not let the developer decide what is lawful, and do not expect counsel to write you code.

Where to start if your site already exists

Do not start with the policy. Start with the inventory, because the policy describes what you do, and you cannot describe what you do not know.

Week one: inventory. Open every page carrying a form and record, in a table: the form's name, the fields it collects, where the data goes, and who can reach it. Then open the site's code and list every third-party script running on it. Most people doing this step discover two or three tools they no longer remember installing.

Week two: reduce. Delete every field you do not actually use, and switch off every tool whose data nobody looks at. This single step cuts your obligations more than anything else on the list, and it costs nothing.

Week three: implement. Purpose separation, consent-record storage, and a route for incoming requests.

Only then: write the policy: from the table in front of you, not from a template online.

The order matters: anyone starting with the policy ends up with a handsome document describing a website that does not exist.

Related reading: zatca e-invoicing, platforms code, ui/ux design.

Market data: Statista — Saudi Arabia Digital Economy.