DEV Community

Cover image for Saudi PDPL Compliance in 2026: A Product Checklist, the Draft Localisation and Breach Rules (Comments Close 5 November), and SDAIA's Sandbox
iFynx Studio
iFynx Studio

Posted on Originally published at ifynx.com

Saudi PDPL Compliance in 2026: A Product Checklist, the Draft Localisation and Breach Rules (Comments Close 5 November), and SDAIA's Sandbox

#privacy #security #compliance #webdev

The short answer

Saudi PDPL compliance is a product job before it is a legal one. The Personal Data Protection Law (Royal Decree M/19 of 9/2/1443 AH, amended by Royal Decree M/148 of 5/9/1444 AH) and its Implementing Regulations already require things your app has to show and do: a privacy policy before collection, a notice at the point of collection that says which fields are mandatory and whether data leaves the Kingdom, a separate and documented consent for each purpose, a withdrawal path that is as easy as the opt-in, answers to access, copy, correction and destruction requests within 30 days, and a notification to SDAIA within 72 hours of becoming aware of a breach that may cause harm. Two new hooks make this the right month to fix it. SDAIA has a draft of amendments to the Implementing Regulations out for public comment on Istitlaa until 5 November 2026; law-firm summaries say it would add a duty to store personal data inside the Kingdom and a breach-reporting trigger without the harm test. And on 6 October 2026 SDAIA opened registration for the Personal Data Protection track of its Data Regulatory Sandbox, open for two months. The draft is not law. The current rules are, and they are what this checklist is built on.

Key facts, with dates and primary sources

  • The law and who it covers: the PDPL applies to any processing of personal data in the Kingdom, including processing of data about individuals residing in the Kingdom by any party outside the Kingdom (Article 2). (SDAIA, PDPL text)
  • Data subject rights: to be informed, to access, to obtain a copy in a readable and clear format, to correct, complete or update, and to request destruction (PDPL Article 4). Controllers must act within 30 days, extendable once by up to 30 more days with advance notice and reasons, verify the requester's identity, and keep a record of every request, including oral ones (Implementing Regulations Article 3). (SDAIA, Implementing Regulations)
  • Consent: freely given, purpose explained before or at the time of asking, documented so it can be verified later, and a separate consent for each processing purpose; explicit consent for sensitive data, credit data, and decisions made solely by automated processing (Regulations Article 11). Withdrawal must be as easy as giving consent or easier (Article 12). Consent cannot be a condition of a service unless the service is directly related to the processing (PDPL Article 7).
  • Breach notification: notify SDAIA within 72 hours of becoming aware of an incident that potentially causes harm, and notify affected people without undue delay in simple, clear language where the breach may damage their data or rights (Regulations Article 24). SDAIA's procedural guide routes the notice through the breach notification service of the National Data Governance Platform, which requires registration. (SDAIA breach guide, October 2024)
  • Cross-border transfers: allowed for the purposes in PDPL Article 29 and the Transfer Regulation (version 2.0, August 2024), subject to an adequate level of protection or, in the exemption cases, appropriate safeguards (standard contractual clauses, binding common rules or an accreditation certificate), plus a written risk assessment in defined cases (Transfer Regulation Articles 4 and 7). (SDAIA, Regulation on Personal Data Transfer Outside the Kingdom)
  • National Register of Controllers: registration on the National Data Governance Platform is mandatory if you are a public entity, if your main activity is based on processing personal data, or if you process sensitive data; separate rules for controllers outside the Kingdom are to be issued, and the Platform already offers a registration service for entities outside the Kingdom. (SDAIA, Rules Governing the National Register of Controllers; DGP, entities outside the Kingdom)
  • Penalties: a warning or a fine of up to SAR 5 million for violations of the Law or Regulations, which may be doubled for repeat violations (PDPL Article 36); up to two years in prison or a fine of up to SAR 3 million, or both, for disclosing or publishing sensitive data with intent to harm or for personal benefit (Article 35).
  • DRAFT amendments (not law): consultation on Istitlaa from 6 October to 5 November 2026, according to Clyde & Co and Bird & Bird (both 8 October 2026) and the Bawadir mirror of the Istitlaa listing. We could not load the Istitlaa project page from our network on 13 October 2026; the draft's contents below are attributed to those summaries.
  • Sandbox: SDAIA opened registration for the Personal Data Protection track on the National Data Governance Platform; registration stays open for two months; applicants must be licensed private entities operating in the Kingdom, processing personal data, and registered in the National Register (SPA, 6 October 2026). The Platform page lists the service as free, the Data Monetisation track as opening in January 2027, and six graduates from the 2025 cohort. (SPA; DGP, Data Regulatory Sandbox)

Why Saudi PDPL compliance is a product problem, not a policy PDF

Most pages that rank for this topic are law-firm summaries. They are useful, and they stop where product work starts. The PDPL does not ask you to publish a policy and move on. It asks you to prove, per user and per purpose, what you told them, what they agreed to, when, and how they can undo it. That proof lives in your database schema, your onboarding screens, your support tooling and your incident pager, not in a legal folder.

Three features of the Saudi text make this sharper than many teams expect. Consent is per purpose and must be documented "through means allowing future verification", so a single "I agree" checkbox is not a consent model. The notice at collection must say which fields are mandatory and which are optional and whether data will be processed outside the Kingdom, so the form itself carries legal content. And rights requests run on a 30-day clock that starts when the request arrives through any channel, including a call centre, so your support team is part of the compliance surface.

What does the Saudi PDPL require from an app or SaaS product?

Read the Law and Regulations as a backlog, and the requirements group into seven product capabilities:

  1. Privacy policy before collection (PDPL Article 12): purpose, data collected, means of collection, processing, storage and destruction, rights and how to exercise them. SDAIA also publishes a privacy-policy guideline. Ship it in Arabic and English with the same version number and date.
  2. A notice at the point of collection (Article 13): legal basis, purpose, mandatory versus optional fields, the consequence of not providing data, who receives it, and whether it is transferred, disclosed or processed outside the Kingdom.
  3. A consent ledger: one record per user, per purpose, per version of the notice, with timestamp and channel (Regulations Article 11).
  4. A withdrawal path that is at least as easy as the opt-in, and that triggers downstream notifications to parties you disclosed data to, asking them to destroy it (Article 12).
  5. A rights centre for access, copy, correction and destruction, with identity verification, a 30-day SLA and a logged extension path (Article 3).
  6. A breach runbook that can produce the Article 24 fields within 72 hours.
  7. Records of processing kept for the life of each processing activity and five years after it ends (Article 33), including transfers outside the Kingdom and their legal basis.

None of these is exotic. What is unusual is that the Saudi rules make them testable: an SDAIA request, a complaint or a sandbox test plan can ask you to show each one working.

Consent and purpose notices in Arabic and English

Design the notice as structured data, not as a paragraph. Each purpose needs an identifier, a plain-language label in both languages, a legal basis, a list of fields, a retention rule and a flag for whether it involves a transfer outside the Kingdom. Render the notice from that object so the Arabic and English screens can never drift apart.

Practical rules we use on bilingual products:

  • Write the Arabic first and in Modern Standard Arabic that a customer would actually read, then produce the English. A literal translation of an English legal sentence usually fails the Implementing Regulations' test of clear, specific purposes.
  • Split purposes visibly. "Account and service delivery", "fraud prevention", "product analytics", "marketing", "sharing with partners" and "AI-assisted features" should be separate toggles where consent is the basis, not one bundle.
  • Mark mandatory fields at the field, not in the footer. Article 13 asks you to say which data is mandatory and which is optional; a small "required" or "optional" label next to the input does that honestly.
  • Say where the data goes. If any purpose uses a processor outside the Kingdom, say so in the notice in one line, for example: "Your support chats are processed by our customer-service provider outside Saudi Arabia under contract safeguards."
  • Explicit means explicit. For sensitive data (health, biometrics for identification, religious belief and others listed in PDPL Article 1), credit data and solely automated decisions, use an unticked control the user actively selects, with the purpose shown right next to it.
  • Version everything. When the notice text changes, the consent ledger should know which version each user saw.

Example English microcopy for a marketing toggle: "Send me offers by SMS and email. You can switch this off any time in Settings, Privacy." The Arabic version should be equally short, carry the same purpose identifier, and live in the same component.

Data-subject-rights flows that meet the 30-day clock

The rights in PDPL Article 4 map to four in-app actions: see my data, download my data, fix my data, delete my data. Build them as one "Privacy centre" entry in Settings, reachable in two taps, with the same structure in Arabic and English.

  • Identity first. Article 3 requires you to verify the requester's identity. Reuse the strongest factor you already have (an authenticated session plus one-time code, or a national digital ID flow where you already use one), and never ask for more data than you hold just to verify.
  • One ticket for every channel. Requests made by phone, email, in a branch or in chat must land in the same queue with the same 30-day timer. The Regulations require you to document oral requests too.
  • Show the clock to the user. "We received your request on 13 October. We will answer by 12 November." If you need the extension, tell them before day 30 with the reason, as Article 3 requires.
  • Copies in a readable format. A machine-readable export (JSON or CSV) plus a human-readable summary in the user's language is a sensible default for "obtain a copy in a readable and clear format".
  • Destruction with exceptions explained. When you must keep some records under another law (tax, AML or sector rules), say which and for how long, instead of silently refusing.
  • Watch the draft. Clyde & Co and Bird & Bird report that the draft would treat a request not answered within the period as deemed rejected and let the person complain to SDAIA. If adopted, a missed SLA becomes a complaint trigger, not just a backlog item.

The 72-hour breach runbook

The current Article 24 already gives you 72 hours from awareness to notify SDAIA when an incident potentially causes harm, and it lists exactly what the notice must contain. That list is your runbook template:

  1. Hour 0, awareness logged. Record the time the company became aware; the clock runs from here, not from when the incident started.
  2. Hours 0 to 12, scope. Data categories, actual or approximate number of people affected, types of personal data, and whether processors or sub-processors are involved (SDAIA's guide says processors follow the notice requirements in coordination with the controller).
  3. Hours 12 to 48, risk and containment. What could happen to people (fraud, identity theft, physical harm or rights damage, the examples SDAIA's guide gives), what you did, and what you will do to prevent a repeat. Rotate anything changeable, such as passwords or tokens.
  4. Before hour 72, notify SDAIA through the Platform's breach notification service. If some fields are missing, the Regulations let you send the rest as soon as possible with reasons for the delay.
  5. Notify people without undue delay where the breach may damage their data or rights: simple language, risks, what you did, contact details for your DPO or privacy contact, and concrete advice. Pre-write these messages in Arabic and English now.
  6. Keep the evidence. Copies of reports, corrective actions and supporting documents (Article 24(3)).

Remember the parallel track: Article 24(4) preserves separate reporting duties under National Cybersecurity Authority rules and other laws. If you are a SAMA-regulated firm, your sector incident process still applies. The DRAFT amendments, as reported by both law firms, would remove the harm threshold for notifying SDAIA, so any breach, damage or unauthorised access would be reportable within 72 hours, while the harm test for notifying individuals stays. If that passes, expect more notifications and design the runbook so that a low-impact report is cheap to file.

Cross-border transfers and the draft data-localisation rule

Today the PDPL does not impose a general rule that personal data must be stored in Saudi Arabia, as both law firms note. Transfers outside the Kingdom are allowed for the Article 29 purposes and the Transfer Regulation's "other purposes" (central processing for the controller's activities, providing a service or benefit to the data subject, scientific research), with the adequacy, minimisation and safeguard conditions above.

The DRAFT changes the default. Bird & Bird quotes a new Article 23(2) under which the Controller "shall store Personal Data within the Kingdom", while still permitting transfers and disclosures under the PDPL. Neither summary says how storage and transfer will interact in practice, and Bird & Bird lists the scope of Article 23(2) as a point needing clarification. So treat this as a planning scenario, not a requirement, and make decisions that are cheap now and valuable in both outcomes:

  • Data map by region. For every store, list the cloud region, the backup region, and the disaster-recovery region. Backups and log archives are where offshore copies hide.
  • Primary storage inside the Kingdom where it is easy. If your provider offers an in-Kingdom region for the services you use, new Saudi tenants can start there without waiting for the final text.
  • Separate the "where it lives" question from the "who touches it" question. Offshore support teams, AI model APIs, analytics SDKs, crash reporters and email delivery all access or receive data even when the database is local. Each is a transfer or disclosure to assess.
  • Minimise what leaves. Send pseudonymised identifiers to analytics, strip free text before it reaches an offshore model, and keep raw identifiers in-region.
  • Paperwork that survives either outcome. Standard contractual clauses or binding common rules for group transfers, and a written transfer risk assessment where the Transfer Regulation requires one (Article 7).

Offshore AI, analytics vendors and backups

AI features are where Saudi product teams create new transfers without noticing. A support chatbot that sends a customer's message to a model hosted abroad is a transfer of whatever personal data the message contains. Under the current rules you need a purpose that fits Article 29 or the Transfer Regulation, the minimisation condition, safeguards where you rely on an exemption, and an entry in your records of processing. Under the draft, as summarised, any transfer outside the Kingdom would also trigger registration in the National Register of Controllers.

A workable pattern:

  • Classify prompts before they leave. Redact national ID numbers, IBANs, phone numbers and health terms in-region; send the rest.
  • Prefer in-Kingdom or on-device inference for sensitive or credit-related features, where explicit consent and automated-decision rules already bite.
  • Contract for no training on your data, and record the processor's sub-processors, as Article 8 of the Law and Article 17 of the Regulations expect controllers to monitor processors.
  • Treat backups as processing. Encrypted cross-border backups are still copies; list them in the records of processing with retention and region.
  • Watch "emerging technologies". Both summaries say the draft's revised impact-assessment triggers include processing with emerging technologies, undefined in the draft, which Bird & Bird notes could capture a wide range of AI processing. If you ship AI features to Saudi users, plan a privacy impact assessment now; the Platform already offers one as a service.

Who must register in the National Personal Data Protection Register?

Under the rules SDAIA published for controllers within the Kingdom, you must register on the National Data Governance Platform if you are a public entity, if your main activity is based on processing personal data, if you process sensitive data, or if you are an individual processing personal data beyond personal or family use. Registration produces a certificate with a QR code that the public can verify, valid for up to five years, and it unlocks the Platform's breach notification, privacy impact assessment and compliance self-assessment services.

For a SaaS company, "main activity based on personal data processing" covers more products than founders assume: HR platforms, marketing automation, health apps, ed-tech with student records, consumer fintech. For entities outside the Kingdom, the Platform's registration page requires an active commercial registration and a representative authorised through the Ministry of Foreign Affairs' service for authenticating non-Saudi company data. Under the DRAFT, as both law firms report, any transfer or disclosure outside the Kingdom would itself trigger registration, which would pull in most companies using offshore cloud or support.

How is the Saudi PDPL different from GDPR?

Teams that already run a GDPR programme have a head start, but several Saudi rules do not port cleanly:

  • Consent sits closer to the centre. PDPL Article 5 makes consent the default basis "except for the cases stated in this Law", and the legitimate-interest exception in Articles 6 and 10 excludes sensitive data. Reusing a GDPR legitimate-interest assessment for sensitive processing will not carry over.
  • Credit data is its own explicit-consent category (Regulations Article 11), which matters for BNPL, lending and open-banking products.
  • Records of processing must be kept for five years after an activity ends (Article 33).
  • Registration with the regulator is mandatory for many controllers through the National Register, with a public certificate.
  • Criminal exposure exists for disclosing or publishing sensitive data with intent to harm or for personal benefit (Article 35).
  • Timelines look similar but differ. Saudi rights requests run on 30 days plus up to 30 more with notice; the 72-hour SDAIA notice currently applies to incidents that potentially cause harm, and the DRAFT would drop that test.

The SDAIA Data Regulatory Sandbox: who can apply and how

The sandbox lets participants test a data-based product or service under supervision, with a defined scope, duration and requirements, before scaling it. SDAIA's Platform page describes two main tracks: Personal Data Protection (applications opened October 2026) and Data Monetisation (applications from January 2027), each with a biometric-data sub-track. Participation is free, and benefits listed include expert guidance, workshops, a digital badge for passing the track, publication in the graduates list and invitations to speak at SDAIA events.

Who can apply? The SPA release says applicants must be licensed private entities operating in the Kingdom, with products or services that process personal data, and registered in the National Personal Data Protection Register. The Platform's FAQ is broader for the Personal Data Protection track: private entities in the Kingdom and entities outside the Kingdom that process personal data of individuals residing in the Kingdom. The two texts do not match, so a company outside Saudi Arabia should confirm eligibility with SDAIA (the sandbox page lists a support email) before investing in an application.

How to apply: authorise your representative through the Saudi Business Center's delegation service, create a new authorisation and choose your commercial registration, select SDAIA and the service for representation and registration on the National Data Governance Platform, then sign in to the Platform, choose the Data Regulatory Sandbox service, complete the application with attachments and submit it for evaluation. The participant journey then runs through evaluation and acceptance, a test plan, supervised testing, evaluation, graduation and post-exit follow-up.

Who has done it? The Platform lists six 2025-cohort graduates: Codata (privacy-enhancing analytics), Hojjah (AI legal research), Medical Circles (secure clinical messaging), Sahl AI (Arabic medical transcription and de-identification), Smart Reach (AI marketing orchestration) and Waki (cashless school and family payments using children's facial biometrics). All joined in Rabi' al-Awwal 1447 and graduated in Shawwal 1447 (roughly August–September 2025 to March–April 2026).

Sandbox go/no-go checklist

Apply if most of these are true:

  • You are, or can quickly become, registered in the National Register, with a named representative and a DPO decision made under Regulations Article 32.
  • Your product has a genuinely hard PDPL question: biometrics, children's data, credit data, solely automated decisions, AI on personal data, or a cross-border architecture you want reviewed before the localisation rule is settled.
  • You can write a test plan with measurable outcomes (for example, consent withdrawal completed in under 24 hours end to end, rights requests closed within 30 days, re-identification risk below a threshold).
  • You can staff the supervised testing period with an engineer and a product owner, not just counsel.
  • A public graduate listing and badge would help sales to Saudi enterprises or government.

Skip, or wait for the next window, if your PDPL gaps are basic (no notice, no consent ledger, no rights flow). Fix those first; the sandbox is for testing a product against requirements, not for writing your first privacy policy.

A six-week plan from 13 October 2026

  1. Week 1: data map with regions, processors and AI vendors; decide whether you must register in the National Register; read the draft on Istitlaa if you can reach it.
  2. Week 2: purpose catalogue and bilingual notice components; consent ledger schema with versioning.
  3. Week 3: Privacy centre in Settings (see, download, fix, delete) on one ticket queue with a 30-day timer.
  4. Week 4 (by 5 November): breach runbook drill to the Article 24 fields; submit comments on the draft through Istitlaa if localisation or the registration trigger affects you.
  5. Week 5: transfer risk assessments and safeguards for offshore processors; redact-before-send for AI features.
  6. Week 6: sandbox go/no-go decision and, if yes, application before registration closes (two months from 6 October per SPA; SDAIA did not publish an exact date in that release).

Metrics that tell you it is working

  • Share of active users with a current, versioned consent record per purpose.
  • Median and 95th-percentile time to close rights requests, by channel.
  • Time from consent withdrawal to processing stop, including downstream processors.
  • Breach drill: time to a complete Article 24 notice draft.
  • Number of offshore data flows without a documented basis or safeguard (target zero).

Risks, trade-offs and honest limits

  • The amendments are a draft. Everything we attribute to the draft comes from Clyde & Co and Bird & Bird summaries dated 8 October 2026. SDAIA may change or drop any of it. Clyde & Co says that, if approved, the amended regulations enter into force 60 days after publication in the Official Gazette.
  • We could not open Istitlaa. The consultation page timed out from our network and from our fetch service on 13 October 2026. We link to it; please read the draft there before you submit comments or change architecture.
  • Eligibility mismatch. SPA and the Platform FAQ describe sandbox eligibility differently; confirm with SDAIA.
  • Sector rules stack. SAMA, NCA and sector-specific rules may impose stricter localisation or incident duties than the PDPL. This article covers the PDPL layer only.
  • Not legal advice. We read SDAIA's English texts of the Law, Regulations, Transfer Regulation, Register rules and breach guide on 13 October 2026. The Arabic texts are authoritative.

iFynx designs and builds bilingual Arabic-English products for regulated MENA markets, including consent, onboarding and privacy flows. Browse the iFynx articles hub for more regional product and engineering analysis.

Related reading on iFynx

Frequently asked questions

What does Saudi PDPL compliance require from an app or SaaS product?

A privacy policy available before collection, a notice at collection that states the legal basis, purpose, mandatory and optional fields, recipients and any processing outside the Kingdom, a separate documented consent for each purpose where consent is the basis, a withdrawal path at least as easy as the opt-in, responses to access, copy, correction and destruction requests within 30 days, notification to SDAIA within 72 hours of becoming aware of a breach that may cause harm, and written records of processing kept until five years after each activity ends.

What do the draft amendments to the PDPL Implementing Regulations change?

They are a draft on Istitlaa, with comments open from 6 October to 5 November 2026, and are not law. According to Clyde & Co and Bird & Bird, the draft would require controllers to store personal data inside the Kingdom while still permitting lawful transfers, remove the harm threshold for notifying SDAIA of breaches within 72 hours, widen impact-assessment triggers, require registration in the National Register for any transfer outside the Kingdom, set a 20-business-day deadline to answer SDAIA requests, and tighten marketing consent rules.

Who must register in the National Register of Controllers?

Under SDAIA's current rules for controllers within the Kingdom: public entities, controllers whose main activity is based on processing personal data, controllers that process sensitive data, and individuals processing personal data beyond personal or family use. Registration is done on the National Data Governance Platform, which also has a separate registration path for entities outside the Kingdom.

Who can join the SDAIA Data Regulatory Sandbox Personal Data Protection track?

SPA's 6 October 2026 release says licensed private entities operating in the Kingdom, whose products or services process personal data and who are registered in the National Personal Data Protection Register. The National Data Governance Platform FAQ also lists entities outside the Kingdom that process personal data of residents. Registration is open for two months from the announcement, participation is free, and applications are made through the Platform after authorising a representative through the Saudi Business Center.

Does the Saudi PDPL apply to companies outside Saudi Arabia?

Yes. Article 2 of the PDPL applies the Law to processing of personal data of individuals residing in the Kingdom by any party outside the Kingdom. Article 33 asks SDAIA to define tools to monitor controllers and processors outside the Kingdom, and the National Data Governance Platform already offers a registration service for entities outside the Kingdom.

Sources

Closing craft note

The easy way to read this month is as two deadlines: comments by 5 November and a sandbox window that closes around early December. The better way is to notice that every rule in the Saudi text, current or draft, asks the same question: can you show it working? A consent ledger, a privacy centre with a visible clock, a breach drill that ends in a filed notice, and a data map that knows where every backup lives answer that question whatever the final text says.

Originally published on iFynx.

Top comments (0)