Checklist · Compliance

PDPL & data residency: a checklist for MENA AI teams

Training data is personal data more often than teams assume. Here is what Saudi Arabia's PDPL actually requires, how the regional landscape fits together, and the questions to put to any data partner before a single record leaves your systems.

Bayanat Labs Research· · 11 min read· Updated · اقرأ بالعربية

This brief is general information, not legal advice. Regulations and implementing rules evolve; confirm current requirements with counsel and with the regulator's published guidance before making compliance decisions. Legal references were checked against SDAIA's published texts in September 2026.

PDPL data residency, in short: Saudi Arabia's Personal Data Protection Law does not force every record to stay in the Kingdom, but it follows the personal data of people in Saudi Arabia wherever that data is processed, and it regulates every transfer abroad. Keeping raw data, and the people who handle it, in-region is the simplest way to stay on the right side of it.

AI teams in the region tend to treat data protection as a deployment problem, something to solve when the model ships. In practice, the highest-risk step often happens much earlier: the moment call recordings, chat logs, documents or medical notes are handed to an annotation workforce. That handoff is a disclosure, frequently a cross-border transfer, and always something a regulator can ask you to account for.

The PDPL, briefly

Saudi Arabia's Personal Data Protection Law (PDPL) was issued by Royal Decree M/19 in September 2021 and amended by Royal Decree M/148 in March 2023, as the Implementing Regulation records. According to SDAIA's guide for controllers and processors, it came into force on 14 September 2023, with a one-year grace period for compliance that ended on 14 September 2024. The Saudi Data & AI Authority (SDAIA) supervises it. Two instruments sit underneath it: the Implementing Regulation and the Regulation on Personal Data Transfer outside the Kingdom (version 2.0, August 2024).

PDPL: from decree to enforcement Sep 2021 PDPL issued (Royal Decree M/19) Mar 2023 Law amended (Royal Decree M/148) 14 Sep 2023 In force; grace period begins 14 Sep 2024 Grace ends: full enforcement
Figure 1. The PDPL is no longer a future obligation. Since 14 September 2024, controllers processing the personal data of people in the Kingdom are expected to be fully compliant, with SDAIA as the supervisory authority.

Three features matter most for AI data work:

  • Broad scope. Under Article 2, the law applies to processing that takes place in the Kingdom and to the processing of personal data of people residing in the Kingdom by any party outside it. Article 1 defines personal data as any data, whatever its source or form, that can identify a person directly or indirectly. In practice that covers voice recordings, names, phone and account numbers inside chat logs and documents, and anything that makes a person identifiable in combination.
  • Sensitive data is a separate tier. Article 1 lists racial or ethnic origin; religious, intellectual or political belief; security and criminal convictions; biometric or genetic data used to identify a person; health data; and data indicating that one or both of a person's parents are unknown. Health and credit data also get their own extra controls (Articles 23 and 24). Disclosing or publishing sensitive data unlawfully, with intent to harm the data subject or for personal benefit, is the law's one criminal offense: up to two years' imprisonment and/or a fine of up to SAR 3 million (Article 35). Other violations carry a warning or a fine of up to SAR 5 million (Article 36). In both cases the fine can be doubled for repeat offenses.
  • Cross-border transfers are regulated, not banned. Article 29 allows transfers for defined purposes, provided they do not prejudice national security or the Kingdom's vital interests, the destination offers protection at least equivalent to the PDPL's, and only the minimum data needed leaves. Where those conditions are exempted, the Transfer Regulation requires appropriate safeguards (standard contractual clauses, binding common rules or a certificate of accreditation). It also requires a documented risk assessment before such transfers, and before continuous or widespread transfers of sensitive data. Every mechanism adds paperwork and ongoing accountability. Keeping the data in-Kingdom is not the only lawful path; it is simply the path with the fewest moving parts.

Why annotation is the exposed step

A typical Arabic data labeling engagement copies raw production data, the most identifying form of it, to a vendor whose annotators view every record in full. If that vendor routes tasks through a global crowd, your call recordings may be listened to on personal laptops in several other jurisdictions, outside any transfer mechanism you have assessed. Under the PDPL you remain the controller throughout. Article 8 requires you to choose processors that give the necessary guarantees and to monitor their compliance, and it leaves your own responsibilities intact. The vendor's shortcuts are your liability.

This is why "where is the data processed?" is the most useful question to ask a data partner. Not where the company is headquartered, and not where the servers are: where the humans who open each record sit, and under what contractual and technical controls.

Speech is the sharpest case. A voice can identify a speaker on its own, and biometric data used for identification sits in the sensitive tier. Consent wording, speaker metadata and residency belong in the scope of any Arabic speech data collection and transcription project from day one, not in a clause added after the recordings exist.

The regional picture

Saudi Arabia is not an outlier. As of September 2026, most major MENA markets have comprehensive data protection statutes, each with its own transfer rules and regulator:

JurisdictionLawNotes for AI data work
Saudi ArabiaPDPL (Royal Decree M/19 of 2021, amended 2023)Fully enforced since 14 Sep 2024; SDAIA supervises; transfers under Article 29 plus a dedicated Transfer Regulation.
UAEFederal Decree-Law No. 45 of 2021Applies to processing inside or outside the country and sets cross-border transfer requirements; the UAE Data Office oversees it. The DIFC (Law No. 5 of 2020) and ADGM financial free zones run their own regimes.
QatarLaw No. 13 of 2016Oldest law in this table. Article 15 bars controllers from restricting cross-border flows unless the processing breaches the law or risks serious harm, but data of a "special nature" (health, children, religious beliefs, among others) needs prior permission (Article 16).
EgyptLaw No. 151 of 2020Article 14 generally requires equivalent protection at the destination plus a license or permit from the Personal Data Protection Center; Executive Regulations were issued in November 2025.
JordanLaw No. 24 of 2023In force since March 2024; transfers only to recipients offering protection at least equal to Jordan's, with limited exceptions.

The regimes point in different directions: Qatar's statute leans toward free flow, Egypt gates transfers behind a license, and Saudi Arabia and Jordan test the destination's level of protection. For a regional team the practical answer is still simple: architect for the strictest regime in scope (in-region processing, documented lawful basis, minimal disclosure) and the rest usually follows.

The PDPL data residency checklist

Before any dataset leaves your environment for annotation, alignment or evaluation, you should be able to answer yes to each of these:

  1. Data mapping. Do we know exactly which fields in this dataset are personal data, and which are sensitive under the PDPL's definitions (health, biometric or genetic, ethnic origin, beliefs, criminal records)?
  2. Minimization. Have we removed or masked every field the labeling task does not require? Annotators rarely need names, phone numbers or account IDs to label intent. Arabic makes masking harder than it looks: many given names are also common words, such as أمل (Amal, "hope") and نور (Nour, "light"), and phone numbers typed in Eastern Arabic digits (٠٥٥…) slip past patterns written for Western ones. Build these cases into your guidelines; our playbook on how to annotate Arabic text covers the normalization steps.
  3. Lawful basis and purpose. Is the processing covered by consent or another recognized basis, and does model training fall within the purpose the data was originally collected for?
  4. Impact assessment. If the dataset contains sensitive data, links datasets from different sources, or feeds a newly adopted technology, have we written the impact assessment that Article 25 of the Implementing Regulation calls for, and given the processor a copy as it requires?
  5. Residency. Do we know the physical location of storage, of processing, and of the annotators themselves? Is each location consistent with our transfer obligations?
  6. Contracts. Does the processing agreement include what Article 17 of the Implementing Regulation lists: purpose, data categories, duration, breach notification, whether the vendor is subject to other countries' laws, and every subcontractor? Add confidentiality and deletion on completion.
  7. Workforce controls. Are annotators under individual NDAs, working in access-controlled environments, with no local downloads and full audit logs per record?
  8. Retention. Is there a dated, verifiable deletion plan for raw data and intermediate artifacts once deliverables are accepted? Article 18 of the Law expects personal data to be destroyed once it is no longer needed for its purpose.
  9. Incident path. If a record is exposed, does the vendor's notification commitment leave us enough time to meet our own regulatory deadline?

Questions to ask a data partner

The checklist covers your side of the table. These questions show how a vendor actually handles your data; vague answers are an answer.

  • Where do the people who open each record sit? Ask for the country of every annotator, reviewer and QA lead, and how that is enforced and logged per task.
  • Who else touches the data, and under which laws? Labeling tools, cloud hosts, crowd platforms and QA subcontractors should all be named, along with any foreign law that could compel disclosure.
  • Can the work run in our environment? For the most sensitive sets, on-prem or private-cloud delivery keeps the data inside your perimeter.
  • What stops an annotator copying a record? Ask what is technically blocked (downloads, screenshots, clipboard, personal devices), not what is contractually forbidden.
  • How many hours until you tell us about a breach? "Without undue delay" is the regulatory floor for processors; a number of hours is what your own clock needs.
  • What is left when the project ends? Raw files, exports, caches and backups, and written proof that each was deleted.

Residency is one part of a vendor decision; quality, dialect coverage and pricing model are the others. Our RFP checklist and scorecard for choosing an Arabic annotation vendor covers the rest. Bayanat Labs is set up around the questions above: Riyadh-based, in-region hosting by default with on-prem and private-cloud options, least-privilege access, audit logs, and contributors under NDA who pass dialect and domain screening before they touch client data. If you need in-Kingdom data annotation, a fixed-scope pilot is the place to test those answers against your own data.

Not every training set has to start from your own customers' records. The Bayanat product catalog lists ready-to-license Arabic speech and text datasets, with permitted uses set in each agreement. Put licensed data through the same checklist: ask for each dataset's source details before it enters your data map.

Key takeaways
  • The PDPL is enforced now. The grace period ended on 14 September 2024; unlawful disclosure of sensitive data can be a criminal offense.
  • Annotation is a disclosure event. Your compliance posture is only as strong as the humans who open each record. Ask where they sit, not where the servers are.
  • In-region is the simplest lawful path. Transfers are possible with conditions and safeguards, but keeping data in-Kingdom removes most of the transfer paperwork.
  • Training is a purpose. Reusing customer data to train models needs a lawful basis for that use, not just for the original collection.
  • Minimize before you share. Most labeling tasks need far less identifying data than teams send by default, and Arabic PII needs Arabic-aware masking.

Frequently asked questions

Does the Saudi PDPL require data to be stored in Saudi Arabia?

Not as a blanket rule. The PDPL lets a controller transfer personal data abroad when the conditions of Article 29 are met or one of the safeguarded exemptions in the Transfer Regulation applies. What it does require is accountability for every transfer. Rules for government, sector-regulated or classified data can be stricter, so check with your sector regulator. Many teams keep processing in the Kingdom because it removes most of that work, not because the PDPL alone mandates it.

Can customer data be used as AI training data under the PDPL?

Only with a lawful basis for that use. Article 10 limits processing to the purposes the data was collected for, apart from listed exceptions such as consent. Article 6 allows legitimate interest in some cases, but never for sensitive data, and Article 27 permits research use without consent when the data does not identify anyone. In practice, check your privacy notice, strip identifiers before annotation, and take advice before turning support calls or medical notes into a training set.

Is anonymized or masked data still covered by the PDPL?

Data that cannot identify a person, directly or indirectly, falls outside the Law's definition of personal data. Masked or pseudonymized data often does not clear that bar: a stable customer ID, a rare surname plus a neighborhood, or the voice itself can still point to one individual. Treat masked datasets as personal data until you have tested re-identification risk. Article 18 also expects data kept after its purpose ends to contain nothing that identifies the data subject.

How quickly must a personal data breach be reported under the PDPL?

The Implementing Regulation (Article 24) gives the controller 72 hours from becoming aware of a breach that could harm the data or the data subject to notify SDAIA. Affected individuals must be told without undue delay where the breach may harm them. Processors owe the controller notice without undue delay, so write a specific number of hours into your annotation contract. Otherwise the vendor's delay eats into your 72 hours.

Who enforces the PDPL, and how is compliance checked?

SDAIA is the competent authority. Committees formed by its president examine violations and issue warnings or fines, with a right of appeal to the courts (Article 36). The Public Prosecution handles the criminal offense of unlawfully disclosing sensitive data (Article 35). Since the grace period ended, SDAIA says it evaluates compliance periodically through the National Data Governance Platform, against published standards.

Need the data work done in-region?

Bayanat Labs runs annotation, alignment and evaluation with in-region hosting by default: vetted contributors under NDA, least-privilege access, an audit trail on every task, and on-prem or private-cloud options for the work that demands them.

Talk to us about residency