Data Protection · SDAIA · Regulatory Compliance
Quick Answer
The Personal Data Protection Law (PDPL) is Saudi Arabia's national data protection law, enacted by Royal Decree No. M/19 in September 2021, amended in March 2023, and in full force since 14 September 2023. Its compliance grace period expired on 14 September 2024 — enforcement is now an operational reality, not a future date.
PDPL is enforced by the Saudi Data & Artificial Intelligence Authority (SDAIA), alongside the National Data Management Office (NDMO). It applies to any entity processing personal data of individuals in the Kingdom — including foreign organizations processing Saudi residents' data from abroad — and requires a valid legal basis, honored data subject rights, proportionate safeguards, and approved cross-border transfer mechanisms.
Saudi Arabia's Personal Data Protection Law is no longer a law organizations are "preparing for." Enforcement has been live since September 2024, and by 2026 SDAIA's enforcement committees have issued a steady stream of decisions confirming violations across sectors. For any organization that collects, stores, or processes personal data of individuals in the Kingdom, PDPL compliance is now operational reality — the question is no longer whether it applies, but whether your program can demonstrate it.
This guide covers what PDPL is and its legal timeline, who it applies to, the core obligations organizations must meet, data subject rights, cross-border transfer mechanics, the regulators behind it, and a practical roadmap to close gaps — including where PDPL work overlaps with security frameworks you may already have in place.
The Personal Data Protection Law was enacted by Royal Decree No. M/19 in September 2021, with amendments issued in March 2023. It came into full force on 14 September 2023, giving organizations a grace period to reach compliance. That grace period expired on 14 September 2024. Since that date, PDPL obligations are enforced in practice, not just on paper — organizations should treat every requirement below as a current operational obligation.
PDPL applies broadly and extraterritorially:
This extraterritorial reach means the scope question is about whose data you process, not where your company is incorporated.
The Saudi Data & Artificial Intelligence Authority (SDAIA) is the competent regulatory authority responsible for supervising and enforcing PDPL. SDAIA works alongside the National Data Management Office (NDMO), which handles broader national data governance policy. As of 2026, SDAIA's enforcement committees have issued a meaningful volume of enforcement decisions, with recurring root causes including processing personal data without a valid legal basis, unauthorized disclosure of personal data, failure to implement adequate technical and organizational safeguards, and sending marketing communications without consent. These are the exact failure patterns a compliance program should be built to prevent.
| Obligation | What It Requires |
|---|---|
| Legal basis | A valid legal basis established before any collection or processing of personal data |
| Data subject rights | Access, correction, deletion, objection to processing, and data portability, honored on request |
| Responsible person | A designated data protection function for qualifying processing activities |
| Records of processing | Documented, maintained inventory of processing activities |
| Technical & organizational safeguards | Controls proportionate to the risk of the processing activity |
| Privacy notices | Clear, accessible disclosure of what data is collected and why |
| Purpose limitation & minimization | Data collected and used only for stated, necessary purposes |
| Cross-border transfer controls | Specific requirements and approval mechanisms before data leaves the Kingdom |
| Breach notification | Notifying the competent authority of qualifying personal data breaches |
Individuals whose personal data you process have enforceable rights under PDPL, and your organization needs an operational process — not just a policy statement — to honor each one:
Honoring these rights requires an intake channel individuals can actually use, a defined internal workflow to route the request to whoever holds the relevant data, a way to verify the requester's identity before acting on the request, and a response timeline your organization tracks and meets consistently. A privacy notice that lists these rights without an operating process behind it does not satisfy the obligation — regulators and audits alike look for evidence that requests are logged, actioned, and closed out, not just described in policy.
Moving personal data outside Saudi Arabia is not automatically permitted — PDPL requires specific mechanisms and approval before a cross-border transfer can proceed. In practice, this means organizations need to map exactly where Saudi personal data flows — which cloud regions, which third-party processors, which group-company transfers — and confirm each flow has an appropriate transfer mechanism in place before assuming it's compliant by default. This is one of the most commonly overlooked obligations, particularly for organizations using global SaaS platforms or cloud infrastructure hosted outside the Kingdom.
A practical starting point is treating your data flow map as a living inventory rather than a one-time exercise: every new vendor, SaaS tool, backup location, or support-desk integration is a potential new cross-border flow, and each one needs to be checked against your transfer mechanism before it goes live — not discovered during an audit months later.
Most organizations don't process personal data in isolation — payroll providers, cloud hosts, marketing platforms, and outsourced support desks all touch personal data on your behalf. PDPL treats this relationship seriously: sharing personal data with a third-party processor doesn't transfer away your accountability for how that data is protected. Before onboarding any vendor that will touch personal data, confirm the vendor's own safeguards are adequate, put a data processing agreement in place that sets out permitted uses, retention, and breach-notification obligations, and if the vendor operates or stores data outside the Kingdom, treat that as a cross-border transfer requiring its own mechanism. Vendor risk is data protection risk under PDPL, not a separate category.
Yes — and this is the point most organizations underestimate. By 2026, SDAIA's enforcement committees have issued numerous decisions confirming PDPL violations, with recurring causes centered on missing legal basis, unauthorized disclosure, inadequate safeguards, and unconsented marketing. This confirms PDPL is being actively applied, not sitting dormant as a theoretical requirement. Organizations should treat compliance as a current operational priority rather than something to revisit "eventually." The organizations best positioned heading into any future enforcement activity are the ones that can already produce a current ROPA, documented legal basis for each processing activity, and evidence that data subject rights requests are actually being handled — not the ones still treating these as documentation to write "when there's time."
GHS Perspective
The organizations we see struggle with PDPL aren't lacking security controls — they're lacking the legal-basis documentation, data subject rights process, and cross-border transfer mapping that PDPL specifically requires on top of good security hygiene. PDPL compliance is as much a governance and process exercise as a technical one. ComplyOS helps teams maintain a live records-of-processing inventory and track evidence across PDPL alongside NCA ECC and SAMA CSF, so nothing falls through the cracks between frameworks.
Build and maintain a Record of Processing Activities — what personal data you hold, where it lives, who touches it, and why.
Confirm each processing activity in your ROPA has a documented, valid legal basis — not an assumed one.
Publish clear, accessible privacy notices that match what your ROPA says you actually do with personal data.
Designate a responsible person or data protection function accountable for qualifying processing activities.
Build and rehearse a process for detecting, assessing, and notifying the competent authority of qualifying breaches within required timeframes.
Put data processing agreements in place with vendors and processors handling personal data on your behalf, including cross-border transfer terms.
PDPL's technical and organizational safeguard requirements are not written in a vacuum — they overlap substantially with controls Saudi organizations may already have in place under NCA ECC, SAMA CSF, or ISO 27001. Access management, encryption, logging, incident response, and asset management controls that satisfy those frameworks generally satisfy PDPL's safeguard expectations too. What PDPL adds on top is the legal and governance layer: documented legal basis, data subject rights processes, records of processing, and cross-border transfer approval — none of which a pure security framework addresses on its own.
Mapping PDPL requirements against your existing NCA ECC or ISO 27001 control set — rather than building a separate program from scratch — avoids duplicate evidence collection and audit fatigue. GHS's compliance advisory services help organizations build that unified control map across PDPL, NCA ECC, SAMA CSF, and ISO 27001 in one exercise rather than four.
GHS maps your data processing activities against PDPL obligations, identifies gaps against your existing NCA ECC or ISO 27001 controls, and builds a prioritized remediation roadmap.
