Saudi Arabia’s Personal Data Protection Law (PDPL) reached full enforcement on 14 September 2024. The year that followed was the first real test of what the law means in practice — not in the statute book, but in the decision files of the Saudi Data & Artificial Intelligence Authority (SDAIA).
In 2025, SDAIA’s enforcement committees issued 48 confirmed breach decisions. No SaaS vendor has summarised the shape of those decisions publicly. This post is our attempt to do that — and to extract the five patterns a procurement team at a KSA buyer should now expect when they evaluate any SaaS contract.
What the PDPL actually requires
The PDPL mirrors most of GDPR’s spine — lawful basis for processing, data subject rights, breach notification, cross-border transfer controls — with three KSA-specific twists: registration with SDAIA for certain processors, explicit consent language that matches Arabic form conventions, and a data-residency posture that favours in-Kingdom storage for sensitive categories.
The five patterns SDAIA is clearly enforcing
- Consent language that doesn’t match the processing. If the form collects category X and the consent notice says Y, SDAIA treats it as no consent.
- Cross-border transfer without disclosure. Sub-processors in the US or Ireland are fine — undisclosed sub-processors are not.
- Slow breach notifications. The 72-hour window is being enforced tightly.
- Data subject rights endpoints that don’t work. Export / erasure promised in a privacy policy, missing in the product, is the single most common 2025 finding.
- Missing DPA on file. Vendor has one; the KSA buyer never received a signed copy. Both sides get cited.
Three patterns SDAIA is not enforcing yet
Worth being honest about. As of Q1 2026, SDAIA has not yet moved against pure Singapore-hosted SaaS serving KSA buyers, retention-period over-collection, or sub-processor changes notified by email rather than contract amendment. That may change — the law permits action on all three — but there is no published precedent yet.
What this means for a SaaS vendor’s DPA
Buyers are now reading DPAs the way they used to read indemnification clauses. If your DPA doesn’t (a) cite PDPL by article, (b) name every sub-processor, (c) commit to a 72-hour breach notification, and (d) spell out the data-subject-rights mechanism, it’s materially weaker than the ones procurement teams are now comparing it against.
Checklist — what to ask every vendor
- Does your DPA reference PDPL by article number?
- Where is production data stored today, and when does that change?
- Who are your sub-processors, and how are changes communicated?
- What is your breach notification window, and from which event does it start?
- How is data subject access / erasure exposed — API, dashboard, email-request?
The answers a PDPL-aware vendor gives to these five questions will look unremarkably similar. The answers a non-PDPL-aware vendor gives will include a lot of “we can get back to you.”