Saudi compliance work changed character in September 2024: the question stopped being “when do we need to be ready” and became “what does SDAIA see if it looks today.” What it sees first is the externally visible layer, platform registration, the Arabic privacy notice, consent behavior on your Saudi-facing properties, and what it asks for in an inquiry is the producible layer: RoPA, consent records, DPIAs, breach log, transfer instruments. The checklist below builds both layers in the order enforcement actually tests them.
| Step | Deliverable |
|---|---|
| 1. Scope | Applicability memo (residents’ data, extraterritorial reach) |
| 2. Inventory | RoPA with basis per purpose |
| 3. Register | National Data Governance Platform filing |
| 4. Notices | Arabic-first notice to the regulations’ content list |
| 5. Consent | Provable consent + withdrawal mechanics |
| 6. Rights | 30-day DSR pipeline |
| 7. Governance | DPO trigger analysis; DPIA templates |
| 8. Incidents | 72-hour SDAIA breach runbook |
| 9. Transfers | SDAIA SCCs, risk assessments, localization check |
Running the checklist
Steps 3, 4, and 8 are the urgency tier. Registration gaps and non-compliant notices are visible without an investigation, and the 72-hour breach duty fails catastrophically if built mid-incident.
Consent is an engineering problem. Provable, specific, withdrawable consent means consent-management tooling wired to your Saudi-facing web properties, the same machinery GDPR programs use, tuned to PDPL’s stricter marketing stance; the PDPL vs GDPR guide lists the deltas.
Close transfers last but audit them first. Most Saudi programs discover unlawful transfers already running; inventory them in step 2, then paper them with SDAIA instruments and localization checks in step 9.
Gulf-wide reuse. The RoPA, DSR pipeline, and breach runbook extend to the UAE and Bahrain with jurisdiction switches rather than rebuilds.
Steps 4 and 5 are testable from outside right now: check your Saudi-facing pages with a free scan.