Saudi PDPL AI Compliance Checklist: 12 Items With an Objective Completion Test
SDAIA has issued 48 enforcement decisions since the PDPL transition period closed on 14 September 2024, concentrated on legal basis, unauthorised disclosure, absent safeguards and marketing consent. This is a twelve-item checklist for an organisation running AI on personal data in the Kingdom, ordered by dependency rather than by statutory sequence, each item carrying a test somebody outside the privacy team could run, and honest about the five items no architecture closes.
SDAIA's specialised committees have issued 48 decisions confirming Personal Data Protection Law violations since the transition period closed on 14 September 2024. The recurring findings were processing without a valid legal basis, unauthorised disclosure, missing technical and organisational safeguards, and marketing without consent.
Three of those four are things that happen when an employee routes customer data through a hosted model. These twelve items run in dependency order rather than statutory order, because item 7 cannot be tested until item 4 exists. Each states a test somebody outside your privacy team could run.
1. Establish which AI tools process personal data of individuals in the Kingdom
Scope attaches to the data subject's location rather than to where your servers sit, and it reaches foreign entities processing that data.
Done when: a written scope determination exists per tool, and the tool list reconciles against observed egress to model endpoints over the last 30 days. The reconciliation method is the same one in shadow AI discovery.
2. Record the legal basis for each AI processing activity
Consent, contractual necessity, legal obligation, and legitimate interest for non-sensitive data are the available routes. A basis registered for holding customer records does not extend to transferring them to a third-party model.
Done when: each tool in item 1 has a named basis, and where legitimate interest is relied on, a dated balancing assessment covering the transfer to that specific provider. This item is owned by the privacy function.
3. Complete the impact assessment before deployment
The Implementing Regulations require assessing the impact of processing for products and services offered to the public, and for processing that carries heightened risk.
Done when: each customer-facing AI tool has an assessment dated before its go-live, naming data categories, provider, transfer route, safeguards, and residual risk. This item is owned by the privacy function.
4. Record every outbound AI request off the application path
This is the item items 5 through 10 depend on. A record written by the application that made the call is a statement by the party under examination, which is the self-attestation problem in a data protection setting.
Done when: for a sampled hour, a record exists per outbound request naming the destination endpoint and its region, the initiating identity, the data classes present, the policy evaluated, and the outcome.
5. Populate the RoPA recipient and transfer fields from observed traffic
Controllers must maintain records of processing activities and produce them on request, covering purposes, data subject and data categories, recipients, cross-border transfers, and retention.
Done when: the recipients and cross-border sections of the RoPA reconcile against the destination list from item 4, with every discrepancy either explained or closed.
6. Enforce region on the transfer, not only in the contract
The transfer regime issued alongside the Implementing Regulations, amended in 2024, permits transfer for specified purposes subject to conditions including a risk assessment where adequate protection has not been established. A hosted model endpoint sits in a foreign region by default, and the transfer happens per request.
Done when: a request routed to an endpoint outside the permitted region set is refused at the request layer, with the refusal recorded, and a config change that repoints a base URL cannot bypass it.
7. Classify on the request rather than on documents at rest
Network data-loss prevention runs underneath TLS to a provider API. Document classification reads a file, while a prompt assembles fragments from several systems into one payload.
Done when: a test prompt carrying a known sensitive pattern is classified and handled by policy at the request layer, and the decision appears in the record from item 4.
8. Treat sensitive personal data as a separate policy class
The criminal limb of the PDPL attaches to disclosure of sensitive personal data, carrying up to two years imprisonment and a fine of up to SAR 3 million where done with intent to harm or for personal benefit.
Done when: sensitive categories are enumerated in policy with their own destination rules, and a test prompt carrying a sensitive category to a general-purpose endpoint is refused rather than logged.
9. Set the default to deny
A control that falls open on evaluator error, timeout, or an unrecognised destination is a control during normal operation only.
Done when: an induced policy-service failure in a test environment produces refused requests, recorded and alerted.
10. Make the 72-hour breach assessment produceable from records
Controllers must notify SDAIA within 72 hours of becoming aware of a breach that may cause harm to the personal data or the data subject, and inform affected individuals without delay, on a clock that runs continuously through weekends.
Done when: a tabletop covering an agent that sent prompts to an unapproved endpoint for six weeks produces a harm assessment naming the data classes, the volume, the destination region, and the individuals implicated, drawn from records rather than estimates, inside one working day.
11. Appoint the data protection officer and complete registration
Certain controllers must appoint a data protection officer, and controller registration on SDAIA's national platform is part of the regime.
Done when: the appointment is documented with contact details published, and the registration record exists. This item is owned by the privacy function.
12. Set retention and disposal on both sides
Retention periods appear in the RoPA, and two stores matter: your own, and the provider's.
Done when: a written schedule covers AI request records and outputs held internally, and each provider agreement states whether prompts are retained and for how long. This item is owned by data governance and procurement.
What this checklist does not cover
Items 2, 3, 11 and 12 are governance, legal and procurement work that no component on the HTTP path closes. Marketing consent, which drove a share of the 48 decisions, belongs to campaign systems and sits outside this list.
Data subject rights workflows, covering access, correction, destruction and the right to obtain a copy, are process obligations the privacy function runs. What architecture contributes there is the disclosure history underneath the answer. The obligation-by-obligation version with owners is in the Saudi PDPL controls mapping, and the artifacts an inspector examines are in the PDPL audit evidence walkthrough.
My candid view: item 8 is the one I would do first in this jurisdiction, ahead of items with earlier numbers, because the PDPL is one of the few data protection regimes where a wrong disclosure carries a prison term rather than a fine. Nobody expects an analyst summarising a medical record at the end of a long day to be forming criminal intent. The exposure is that the highest-consequence provision in the law reaches an action that takes four seconds and leaves no trace anyone can find afterwards, and the only place to catch it is on the request.
DeepInspect
This is the control point items 4 through 10 describe. DeepInspect sits inline between your users or agents and the LLM APIs they call, as a stateless proxy the calling application has no custody over. It evaluates identity, request classification, and destination on every call, enforces per-role and per-route policy with a fail-closed default, and writes a signed, tamper-evident per-decision record.
That component supplies the reconciliation in item 1, the record in item 4, the RoPA recipient and transfer fields in item 5, region enforcement per call in item 6, classification in items 7 and 8, the fail-closed posture in item 9, and the data-class, volume and destination figures item 10 needs inside the 72-hour window. The legal basis register, the impact assessment, the DPO appointment and the retention schedule stay with your privacy, legal and procurement functions. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Does the Saudi PDPL apply to a company based outside the Kingdom?
It applies to any entity processing the personal data of individuals residing in Saudi Arabia, including entities located abroad. That extraterritorial reach has been live since the transition period closed on 14 September 2024, and SDAIA has issued 48 decisions confirming violations since.
- What are the penalties for non-compliance?
Administrative fines reach SAR 5 million for general violations and double for repeat offences. Disclosure of sensitive personal data with intent to harm or for personal benefit carries criminal penalties of up to two years imprisonment and a fine of up to SAR 3 million, also doubling on repeat.
- Is a prompt sent to a foreign model a cross-border transfer?
Where the request carries personal data to an endpoint outside the Kingdom, the transfer rules apply to that request. The regime permits transfer for specified purposes subject to conditions, including a risk assessment where an adequate level of protection has not been established for the destination, which makes the endpoint's region a compliance-relevant property of every call.
- Do we need a data protection officer?
Certain controllers are required to appoint one under the Implementing Regulations, including where the core activities involve regular monitoring or processing of sensitive data on a large scale. The appointment has to be documented with published contact details, and controller registration on SDAIA's national platform forms part of the same obligation set.
- How quickly must we notify SDAIA of a breach?
Within 72 hours of becoming aware of a personal data breach that may cause harm to the personal data or the data subject, with affected individuals informed without delay. The clock runs continuously, which is the reason item 10 asks for a one-working-day tabletop rather than a three-day one.
- Which items can architecture close?
Items 1 and 4 through 10, in the sense that a policy enforcement point on the request path supplies the artifact each test asks for. Items 2, 3, 11 and 12 are governance, legal and procurement work, and no honest checklist assigns them to a platform team.