Saudi PDPL: What Your Technology Architecture Must Now Demonstrate

Saudi Arabia’s Personal Data Protection Law has been fully enforceable since September 2024, and SDAIA has moved from a grace-period posture to active enforcement. What the underlying technology architecture actually needs to demonstrate, beyond the policy documents.

The PDPL, issued under Royal Decree No. M/19 and amended by Royal Decree No. M/148, entered into force on 14 September 2023 with a one-year grace period. That grace period ended on 14 September 2024, and the Saudi Data and Artificial Intelligence Authority — SDAIA — has been in full enforcement mode since. As of early 2026, SDAIA has issued dozens of cumulative enforcement decisions. This is a reading of what the law requires from a technology function’s perspective, not a legal summary.

The extraterritorial reach that catches technology teams off guard

The PDPL applies to any entity — inside or outside the Kingdom — that processes the personal data of individuals located in Saudi Arabia, without the “targeting or monitoring” threshold that limits GDPR’s extraterritorial scope. A company with no Saudi office, no Saudi entity, and no deliberate Saudi market strategy can still be in scope simply because it processes data belonging to someone physically present in the Kingdom — a tourist, a temporary resident, an employee on secondment. Technology functions that have mapped their GDPR extraterritorial exposure often haven’t separately mapped this broader PDPL trigger.

Who this is for

• The CTO or data protection lead at a firm with any Saudi-resident customers, employees, or users, regardless of whether the firm has a Saudi legal entity.
• The compliance officer extending an existing GDPR programme to cover PDPL and needing to know exactly where the two diverge.
• The board member who assumed “we did our GDPR work” closed the Saudi question too.

Where PDPL diverges from GDPR — and why that matters architecturally

The PDPL borrows heavily from GDPR’s concepts and structure, which tempts technology teams into assuming an existing GDPR-compliant architecture is largely sufficient with a policy update layered on top. It isn’t, in at least three respects that touch architecture directly rather than just documentation.

No joint controller concept. Where GDPR allows two organisations to share controller responsibilities under a joint arrangement, PDPL doesn’t recognise that structure. Each party must independently fulfil the full set of compliance requirements. An architecture built around a GDPR joint-controller data-sharing model needs to be re-examined for how it allocates responsibility under PDPL — the technical access and audit trails need to support two independently defensible compliance positions, not one shared one.

A lower breach-notification threshold. PDPL’s threshold for notifying SDAIA is “potentially causes harm” — broader than GDPR’s “likely to result in a risk to individuals’ rights and freedoms.” A breach detection and classification workflow tuned to GDPR’s threshold may under-report under PDPL’s lower bar. This is a configuration decision inside the incident response tooling, not just a policy update.

Cross-border transfer mechanics run through SDAIA specifically. The Data Transfer Regulation permits transfers to jurisdictions SDAIA has recognised as providing adequate protection, or under SDAIA-approved standard contractual clauses or binding common rules — codes of conduct, notably, were removed from the list of acceptable safeguards. A data flow architecture relying on GDPR-style SCCs for a Saudi data transfer needs the SDAIA-specific version, not the EU one, and needs a Transfer Risk Assessment for transfers where the risk profile warrants it. For BFSI-sector data specifically, a no-objection letter from the Saudi Central Bank is also required.

The DPIA trigger is broader than most teams assume

PDPL requires a Data Protection Impact Assessment for all processing of sensitive personal data — a lower and more mechanical trigger than GDPR’s risk-based DPIA threshold, which requires judgement about whether processing is “likely to result in high risk.” Any system processing sensitive categories — health data, biometric data, financial account details, among others defined in the Implementing Regulations — needs a DPIA on file, and DPIAs must also be made available to data processors where relevant. Architecturally, this means the data classification layer needs to reliably flag sensitive-category processing so the DPIA requirement is triggered automatically, not caught later in a manual review.

The AI layer SDAIA is now building on top

In November 2025, SDAIA published its AI Adoption Framework, establishing governance obligations covering data governance, model accountability, transparency, human oversight, and risk management — layered on top of, not replacing, PDPL obligations. Any AI system processing the personal data of Saudi residents now has to satisfy both frameworks simultaneously. For firms that have already built an EU AI Act risk management process, the practical move is extending it to explicitly cover the Saudi AI Adoption Framework’s five pillars rather than building a second, parallel process.

What the technology function needs to demonstrate

1. A data inventory that specifically identifies Saudi-resident data subjects, independent of any existing GDPR data mapping.
2. Controller registration on SDAIA’s National Data Governance Platform, where the entity’s activity profile requires it.
3. A breach classification workflow calibrated to PDPL’s “potentially causes harm” threshold, distinct from the GDPR workflow if the two thresholds would produce different outcomes.
4. SDAIA-specific cross-border transfer mechanisms — approved SCCs or BCRs, plus Transfer Risk Assessments where required — rather than reliance on GDPR transfer tools.
5. DPIAs on file for every sensitive-data-processing system, generated by a data classification layer that reliably catches sensitive categories.

Registration isn’t universal, but the trigger is easy to miss

Not every controller needs to register on SDAIA’s National Data Governance Platform — the requirement applies to public entities, organisations whose primary activity involves personal data processing, and any organisation processing sensitive data. That third trigger is the one technology teams most often overlook: a company whose core business isn’t data processing in any obvious sense can still cross the registration threshold purely because one system somewhere in the estate handles sensitive-category data — health information gathered through an employee wellness benefit, for instance, or biometric data used for office access control. The data inventory work described above needs to answer the registration question specifically, not just the general compliance question.

Worth building into the same architecture review: SDAIA’s guidance suite — covering privacy policies, data disclosure, destruction and anonymisation, records of processing, and data minimisation — sets out practical expectations for exactly how these obligations should be operationalised. A programme built purely from the PDPL text, without checking it against SDAIA’s published guidelines, risks technically compliant documentation that doesn’t match what SDAIA has said it actually expects to see in practice.

How we engage with this

We read data architectures against what PDPL specifically requires — not against an assumption that GDPR compliance transfers across — as a Data Governance Review. The output is a written gap analysis identifying where an existing GDPR programme needs Saudi-specific extension, not a generic privacy audit.

We don’t draft privacy policies. We don’t run DPIAs on a client’s behalf. We don’t represent firms to SDAIA. We read what’s there, identify what’s missing, and write it down for the people who have to decide what to do about it.

Pricing is published at /pricing/. If your GDPR programme hasn’t been specifically extended to PDPL’s divergences, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.