Saudi PDPL Compliance: A Working Guide for Businesses

The Kingdom's Personal Data Protection Law changed the default assumption for every organisation holding customer data. Before it, data handling was governed largely by sector rules and contract. Now there is a horizontal law, a named regulator, and enforceable rights that any individual can assert against you.

Most compliance content on this subject is written by lawyers for lawyers. This one is written for the person who has to translate the law into a system change, a retention policy, and a conversation with a vendor. It is not legal advice — for that, you need counsel who can look at your specific processing. But it should tell you what questions to bring them.

Who it applies to

The law reaches further than many organisations assume. It applies to the processing of personal data of individuals in the Kingdom — including processing carried out by entities outside Saudi Arabia. A company headquartered elsewhere that serves Saudi customers is within scope. So is a Saudi entity processing data about people abroad, under the law's treatment of processing that takes place in the Kingdom.

The practical consequence: "our servers are in Europe" is not an answer to the question of whether the PDPL applies to you.

Controller or processor?

This distinction determines most of your obligations. A controller decides why and how personal data is processed. A processor processes it on the controller's behalf and on the controller's instructions. Your CRM vendor is a processor. You are the controller. If you run a platform where merchants hold their own customer relationships, you may be both, in different respects — and mapping that honestly is a prerequisite for everything else.

You need a lawful basis for every processing activity

This is the concept most organisations get wrong, because it requires you to stop thinking about data as a bucket and start thinking in terms of specific activities. "We hold customer data" is not a processing activity. "We use customer purchase history to send marketing messages" is.

For each such activity you must identify a lawful basis. The law recognises several, including consent, performance of a contract with the data subject, compliance with a legal obligation, and — introduced in the 2023 amendments — legitimate interest, subject to conditions and not available for sensitive data.

Two things follow that people find uncomfortable:

• Consent is not a universal solvent. Where consent is your basis, it must be freely given and specific, and the individual can withdraw it. If withdrawing consent would break something you consider essential, consent was probably the wrong basis and you needed contractual necessity or legitimate interest instead.
• You cannot repurpose data silently. Data collected to fulfil an order is not automatically available for a marketing model. A new purpose needs its own basis and, usually, its own notice.

Sensitive personal data

The law defines a category of sensitive data that attracts stricter treatment — including data revealing ethnic or tribal origin, religious or intellectual belief, criminal convictions, biometric and genetic data, health data, and data indicating that an individual's parents, or one of them, are unknown. If you process any of these, your controls need to be materially stronger, and several of the ordinary flexibilities do not apply.

The rights individuals can assert

These are the ones that generate work, because each implies an operational process, not just a policy paragraph:

• The right to be informed — a clear privacy notice explaining what you collect, why, on what basis, who receives it, and how long you keep it.
• The right of access — to know what you hold about them.
• The right to obtain a copy — in a readable, transferable form.
• The right to correction — of inaccurate or incomplete data.
• The right to destruction — where the data is no longer needed for the purpose it was collected for, subject to your other legal retention duties.

Ask yourself a concrete question: if a customer emailed today asking for a copy of everything you hold about them, how many systems would someone have to search by hand, and how long would it take? For most organisations the honest answer is "we do not know," and that answer is itself the finding. You cannot serve rights you cannot execute.

Breach notification

The law requires notification to the competent authority upon becoming aware of a personal data breach, within the timeframe set by the regulations, and notification to affected individuals where the breach could cause them harm.

A short notification window is not really a legal requirement — it is an operational one. It means you need, in advance:

• Monitoring that would actually detect a breach rather than waiting for a customer to report it.
• A named person with authority to make the notification decision, and a deputy, because breaches do not respect the calendar.
• A drafted notification template, so you are not writing from scratch under pressure.
• Processor contracts that oblige your vendors to tell you fast enough that you can still meet your own deadline. A vendor SLA that allows them five days to inform you has made your compliance impossible.

Transferring data outside the Kingdom

This is where most cloud-dependent businesses have real exposure. Transfers outside Saudi Arabia are permitted only under conditions set out in the law and the dedicated transfer regulations, which contemplate mechanisms such as an adequate level of protection in the destination, or appropriate safeguards where that is absent, together with an assessment of the risk to the data subjects.

The practical work is unglamorous: build an inventory of every place your data physically goes. Not the vendors you have contracts with — the actual destinations, including your vendors' sub-processors. An analytics tool, a support desk platform, an email provider, a model API, a backup service, and a monitoring agent each represent a transfer. Most organisations discover they have between three and five times as many as they expected.

Governance you actually need

A record of processing activities. A living inventory of what you process, why, on what basis, where it sits, who it goes to, and how long you keep it. Every other obligation depends on this document existing and being accurate. If you build one thing first, build this.

A data protection officer, where required. The regulations specify circumstances in which appointing one is mandatory — including certain public entities and organisations whose core activities involve regular large-scale monitoring or processing of sensitive data. Even where not mandatory, someone needs to own this or it will belong to nobody.

Impact assessments. For processing likely to result in high risk — new AI systems making decisions about people, large-scale profiling, novel uses of sensitive data — assess before you build, not after you launch.

Processor agreements. Every vendor touching personal data needs contract terms covering purpose limitation, security, sub-processing, breach notification timing, and deletion or return at the end of the relationship.

Retention schedules that are actually enforced. A policy saying you delete after five years, running against a database where nothing has ever been deleted, is worse than no policy — it documents your own non-compliance.

What non-compliance costs

The law sets out administrative penalties for violations, with substantially higher exposure for the unlawful disclosure or publication of sensitive data, where criminal liability including imprisonment is contemplated. Penalties can be increased for repeat violations, and the regulator can require corrective action.

In practice, though, the enforcement fine is rarely the largest cost. Contract loss is. Enterprise and government procurement in the Kingdom increasingly requires evidence of data protection compliance as a precondition of bidding. Organisations that cannot produce a record of processing activities and a set of processor agreements are being screened out before price is discussed.

A sensible order of operations

You cannot do all of this at once, and trying to will stall everything. This sequence gets you materially safer fastest:

1. Map. Build the record of processing activities. Interview each function about what data they hold and which tools they use — you will find systems the technology team does not know about, and that is the point.
2. Triage. Rank processing activities by volume, sensitivity and whether data leaves the Kingdom. Fix the top of that list first.
3. Notice and basis. Rewrite your privacy notice against what you actually do, not what you intended to do. Assign a lawful basis to each activity and write down the reasoning.
4. Contracts. Paper your processors. Start with the ones holding the most data.
5. Rights and breach. Build the two processes you will be judged on when something goes wrong: responding to a data subject request, and notifying a breach.
6. Retention and minimisation. Delete what you should not still have. This is the step everyone defers, and it is the one that most reduces your exposure, because data you do not hold cannot be breached.

The underlying point

The PDPL is not asking you to stop using data. It is asking you to be able to explain, at any moment, what you hold, why you are entitled to hold it, and what you would do if it leaked. Organisations that treat that as a documentation exercise stay permanently behind. The ones that treat it as an architecture question — minimise what you collect, know where it lives, be able to find and delete it — end up compliant almost as a side effect, and with cleaner systems for it.