As of October 2026, Saudi Arabia's Personal Data Protection Law (PDPL) and its Implementing Regulation are in force, supervised by SDAIA, the Saudi Data & AI Authority. The privacy policy is the easy part; the work is the plumbing behind it. This is the checklist I would work through with a founder before launch. It is engineering guidance, not legal advice: have a lawyer licensed in the Kingdom confirm your legal bases and contracts.
Does the Saudi PDPL apply to my app if my company is outside Saudi Arabia?
Yes, for the personal data of people residing in the Kingdom. Article 2 of the law covers processing in Saudi Arabia, "including the Processing of Personal Data related to individuals residing in the Kingdom by any means from any party outside the Kingdom".
The trigger is the person, not where you are registered or host: a UAE-registered SaaS with Saudi users is in scope for that data. Duties sit mainly with the controller, which decides why and how data is processed; a processor that departs from the controller's instructions is treated as a controller and held directly accountable (Implementing Regulation, Article 17).
The stakes: a warning or a fine of up to SAR 5 million, which can be doubled for a repeat violation (PDPL Article 36). Intentionally disclosing or publishing sensitive data to cause harm or for personal benefit carries up to two years in prison, a fine of up to SAR 3 million, or both (PDPL Article 35). A summary of the decision can be published at the violator's expense, which worries me more than the fine.
What does PDPL compliance require us to build?
Eleven controls: the obligation, the control that satisfies it, and one accountable owner. Numbers are articles of the PDPL and the Implementing Regulation (IR).
| Obligation (source) | Engineering control | Owner |
|---|---|---|
| Consent and lawful basis (PDPL 5–7; IR 11–12) | Per-purpose consent log with time and channel; withdrawal as easy as consent | Product lead |
| Notice at collection (PDPL 12–13; IR 4) | Privacy policy before collection; notices on purpose, retention and transfers abroad | Product lead |
| Minimisation (PDPL 11; IR 19) | Field-level data map tying each field to a purpose | Data owner |
| Retention and destruction (PDPL 18; IR 8) | Retention per data category; scheduled deletion or anonymisation, backups included | Backend lead |
| Data-subject rights (PDPL 4; IR 3, 6, 10) | Request queue, identity checks, 30-day clock, export in a common format | Support lead |
| Security (PDPL 19; IR 23) | NCA controls if they bind you; otherwise a recognised standard | Security lead |
| Breach notification (PDPL 20; IR 24) | Detection, awareness timestamp, 72-hour SDAIA notice, user notices | Security lead |
| Impact assessment (PDPL 22; IR 25) | Written assessment before launching processing that triggers one | DPO |
| Records of processing (PDPL 31; IR 33) | Living register of processing activities, kept five years after each ends | DPO |
| Processors (PDPL 8; IR 17) | Required contract terms, sub-processor approval, periodic review | Founder |
| Transfers abroad (PDPL 29; Transfer Regulation) | Data-flow map, safeguards, transfer risk assessment, a switch-off per flow | Architect |
Put each row in your SRS with acceptance criteria; designing controls in costs far less than retrofitting them. My SRS guide shows how.
How should consent, minimisation and deletion work inside the product?
Consent is a record, not a checkbox: prove who agreed to which purpose, when and how, and make withdrawal at least as easy as agreeing.
Article 11 of the Implementing Regulation requires consent that can be verified later, recorded with its time and means, separately for each purpose, and explicit consent for sensitive data, credit data and solely automated decisions. Article 7 of the law bars making consent a condition of service unless the service is directly related to that processing.
What I look for in the codebase:
- A purposes registry and a consent table keyed by user, purpose and policy version, with timestamps and channel.
- A field-level data map: Implementing Regulation Article 19 limits collection to what each purpose needs and names data maps as evidence. Fields without a purpose leave the schema.
- Retention per data category, enforced by scheduled jobs. Implementing Regulation Article 8 requires destruction, backups included and in line with relevant regulatory requirements, when the person asks, the purpose ends, consent was the only basis and is withdrawn, or you learn the processing is unlawful. Destroyable per-user encryption keys make backups manageable.
- Anonymised or synthetic data outside production. Anonymised data stops being personal data only if re-identification is impossible (Implementing Regulation, Article 9); pseudonymised data, which a separately held key can link back, does not.
How do we answer data-subject requests within 30 days?
Treat each request as a ticket with a 30-day deadline. Article 3 of the Implementing Regulation allows one extension of up to 30 more days, for unusual effort or several requests from the same person, and only if you tell them in advance with reasons.
Article 4 of the law grants rights to information, access, a readable copy, correction and destruction. Verify the requester's identity, log every request, oral ones included, and offer the channels listed in Implementing Regulation Article 10, such as email, text message and in-app. You may decline unjustifiably repetitive requests or those needing unusual effort, telling the person why.
The engineering trap is fan-out: user data sits in the main database, analytics, the CRM, the help desk, logs and SaaS tools. Build one internal subject lookup that knows every store, plus export and deletion jobs that reach each, vendors included. A vendor on SDAIA's controller-to-processor clauses must pass you any request it receives within 48 hours. Corrections fan out too: Implementing Regulation Article 7 requires notifying, without delay, the parties you disclosed the data to. Test the whole flow before launch.
What has to happen in the first 72 hours after a breach?
If a breach may harm the data or the people it concerns, notify SDAIA within 72 hours of becoming aware and tell affected users without undue delay (Implementing Regulation, Article 24). The clock starts at awareness, so detection decides whether you make it.
A breach is any incident leading to disclosure, destruction or unauthorised access, intentional or accidental (Implementing Regulation, Article 1); a storage bucket left public can count. SDAIA's National Data Governance Platform has a breach notification service. My runbook:
- Hour 0: open an incident, record the time of awareness, name one lead.
- Contain: revoke keys, close the exposure, preserve logs.
- Scope: data categories, approximate number of people, affected systems.
- Assess harm: decide whether it may cause harm and record why.
- Notify SDAIA by hour 72: what happened and when, when you learned, data categories and numbers, risks, measures taken and planned, whether users were told, a contact. Late details follow as soon as possible, with reasons.
- Tell users in simple, clear language what happened, the risks, what you did and what they should do; in Arabic first for Saudi users.
- Close out: keep copies of what you filed and evidence of corrective measures.
Implementing Regulation Article 17 requires processor contracts to include breach notice without undue delay, and SDAIA's controller-to-processor clauses are stricter: 24 hours for the vendor to tell you, then 48 hours, not 72, for you to notify SDAIA. Design for the tighter number; NCA reporting duties are separate.
When do we need an impact assessment, a DPO or SDAIA registration?
Each has its own triggers; check all three before launch.
Data protection impact assessment
Article 25 of the Implementing Regulation requires a written assessment if you process sensitive data; collect, compare or link two or more datasets from different sources; offer a product likely to seriously harm privacy; or, at large scale or recurrently, process data of people lacking full legal capacity, monitor people continuously, use emerging technologies or make automated decisions. SDAIA's platform offers a Privacy Impact Assessment service.
Data protection officer
Implementing Regulation Article 32 requires one or more DPOs for a public entity processing at large scale, or when your primary activities need regular and systematic monitoring of people or your core activities rest on sensitive data. The DPO can be an executive, an employee or an external contractor. Products built on continuous location tracking or behavioural profiling should assume the monitoring trigger applies.
Registration
SDAIA's register rules require controllers in the Kingdom to register on the National Data Governance Platform if they are a public entity, their main activity is based on processing personal data, or they process sensitive data. The rules say separate rules for controllers outside the Kingdom will follow.
Can we use vendors, cloud regions or engineers outside the Kingdom?
Yes, but every flow needs a legal route under Article 29 of the law and SDAIA's Regulation on Personal Data Transfer Outside the Kingdom (version 2.0, August 2024).
A hypothetical: a Saudi delivery app whose support agents abroad can open customer profiles. No data is copied out, yet SDAIA's Risk Assessment Guideline (February 2025, not legally binding) counts remote access as part of a transfer and asks for the exact country where data, backups included, is stored. The route, simplified:
- Purpose and conditions: a purpose in Article 29 or added by the Transfer Regulation, such as central processing or a service to the data subject; no prejudice to national security or vital interests; adequate protection at the destination; minimum data only. SDAIA is to publish an adequacy list.
- Exemptions: otherwise, one of five exemption cases, each tied to safeguards such as standard contractual clauses, binding common rules or a certificate of accreditation.
- Risk assessment: before transfers under those exemptions, and before continuous or large-scale transfers of sensitive data (Transfer Regulation, Article 7).
- Stop on failure: if safeguards are not applied or SDAIA finds them inadequate, halt the transfer and notify the recipients (Transfer Regulation, Article 6).
SDAIA's standard contractual clauses (version 1.0, September 2024) offer four templates: controller to controller, controller to processor, processor to processor and processor to controller. They define transfer to include granting access.
Processor selection sits on top: Article 8 of the law allows only processors with sufficient guarantees, and Article 17 of the Implementing Regulation lists the contract terms, from breach notice and exposure to foreign laws to subcontractors you approve in advance. My pre-signing checklist covers the rest.
Behind it, I want a data-flow map covering logs, error tracking, analytics SDKs and AI APIs; synthetic or pseudonymised data outside production; brokered, time-limited, logged access for engineers abroad; sensitive data pinned to one region; and a switch that cuts any cross-border flow without downing the product.
Do we have to host inside Saudi Arabia?
As of October 2026, I know of no single published rule requiring every private startup to host in the Kingdom. Your customers, data and sector decide, and the strictest requirement often arrives in a customer's contract.
The belief that NCA mandates in-Kingdom hosting is outdated. NCA's Essential Cybersecurity Controls (ECC-2:2024) apply to government agencies, their affiliated companies and private entities that own, operate or host critical national infrastructure. Their update table deletes the control "Entity's information hosting and storage must be inside the Kingdom of Saudi Arabia", because localisation moved to the National Data Management Office (NDMO) at SDAIA, which entities must consult before acting. The Cloud Cybersecurity Controls (CCC-2:2024) deleted the matching in-Kingdom subcontrols; CCC binds providers serving government or critical-infrastructure tenants, not those serving only individuals and private firms outside critical infrastructure.
My decision factors:
- Who buys from you? Ministries and critical-infrastructure operators bring NCA's controls, and usually hosting terms, into the contract.
- What data do you hold? For health and credit data, the Implementing Regulation points to sector regulators such as the Ministry of Health and the Saudi Central Bank.
- Can you meet the transfer rules? If every offshore flow needs safeguards and a risk assessment, an in-Kingdom region may be simpler.
- Has NDMO addressed your case? NCA sends localisation questions there; check before committing.
These rules changed in 2024 and 2025, so record your hosting decision with its date and reasoning.