Saudi Arabia's Personal Data Protection Law (PDPL) is in force, with a detailed executive regulation and a regulator. The UAE has its federal equivalent. For a team building a product that collects customer data in the Gulf, this is not a privacy-policy document for the site footer - it is a set of design decisions that need to be in the product from the start.

The data map

The first question any audit asks: where does personal data live, why was it collected, who can reach it, and how long is it kept? Most systems cannot answer without a search. We start with an inventory: every field holding personal data, its lawful basis (consent, contract, legal obligation), where it is stored, and which external systems it is sent to. That map is the foundation for everything else.

Data-subject rights as features, not promises

The law gives an individual the right to access their data, correct it, request its destruction, and receive it in a portable form. Each of those needs a real code path:

  • Access: export everything you hold about a person, in a readable form, from every table - not one.
  • Correction and destruction: a delete that reaches backups, system logs and the analytics platform - not a single row deleted while its trace stays in ten other places.
  • Portability: data in a structured, machine-readable form.

Building these as features early is far cheaper than adding them under the pressure of a formal request with a fixed deadline.

Retention and deletion

"We keep everything forever" is no longer an acceptable position. The product needs a retention schedule: how long each category of data stays, and what happens when the period ends - destruction or anonymisation. Real deletion has to include backups and logs, and that is an architectural decision made early because it is hard to add later.

Cross-border transfer

This is the question a remote provider has to answer honestly. The law restricts transferring personal data outside the Kingdom and requires that an adequate level of protection is ensured. In practice that means: documenting where data is processed and stored, clear data-processing agreements, and contractual transfer safeguards where needed. Where a project requires data to stay inside Saudi Arabia or the UAE, in-country hosting can be arranged - and that decision is built into the architecture, not retrofitted.

Breach notification

The law requires reporting data-breach incidents within a short window. That requires the system to be able to detect an incident at all: access logging, monitoring, alerting, and a tested runbook - not learning about a breach from a third party weeks later.

Privacy by design

The rest of it comes down to one principle: collect the minimum needed, for a specific and stated purpose, keep it for the shortest time possible, and record consent where consent is the basis. Appointing a data protection officer is required in certain cases.

How we approach it

We design for these requirements from the first commit: the data map is part of discovery, data-subject rights and the retention policy are in the written scope, and the hosting question is settled before code is written. We are not legal compliance advisers, but the engineering side of regulatory readiness is our day-to-day work for teams across the Gulf.