PDPL Saudi Arabia: An Implementation Checklist for 2026

The Personal Data Protection Law of Saudi Arabia — PDPL — is now fully in force, and the grace period that many organisations used as an excuse to delay implementation is behind us. The Saudi Data and AI Authority (SDAIA) is actively engaging with controllers and processors, the Implementing Regulations have been published and updated, and PDPL enforcement is no longer a distant possibility. If your organisation processes personal data of individuals in Saudi Arabia — and almost every organisation operating in the Kingdom does — the work is practical and it is work you should already be doing.

This post is a step-by-step implementation checklist, organised in the order a compliance team should actually tackle it. It is not a legal interpretation of the statute; it is a practitioner guide to getting the programme into a defensible state.

Step 1 — Confirm scope

Start with the honest answer to a simple question: who has your organisation got personal data about? PDPL applies to any organisation, located inside or outside Saudi Arabia, that processes personal data relating to individuals in the Kingdom. There is no employee-count or revenue threshold. A fintech in London with one Saudi customer is in scope for that customer's data; a Saudi hospital is in scope for every patient, employee and visitor.

Document the scope:

• Personal data categories you hold (employee, customer, vendor, patient, citizen, prospect, website visitor).
• Data subject populations (Saudi residents, Saudi nationals abroad, non-Saudi residents in KSA).
• Whether you are acting as a controller (determining the purposes and means) or a processor (acting on a controller's instructions), or both.
• Whether you hold sensitive personal data — health, genetic, biometric, credit data, data concerning criminal record, data concerning ethnic origin, religious belief or ideological opinion — which carries heightened obligations.

Get the scope wrong at the start and every downstream step has to be redone.

Step 2 — Appoint a Data Protection Officer

PDPL requires the appointment of a DPO in defined circumstances — public entities, organisations whose core activity is large-scale processing of sensitive data, and organisations whose core activity involves regular and systematic monitoring of data subjects. In practice, many in-scope Saudi organisations appoint a DPO regardless because it is the simplest way to evidence accountability to SDAIA.

The DPO should be independent, should report to the highest administrative level of the organisation, should not be subject to instructions on the performance of their duties, and must have a direct line to the governing body. The DPO's contact details must be published and notified to SDAIA.

Step 3 — Identify lawful basis

Every processing activity must have a lawful basis. PDPL accepts processing on the basis of:

• Consent of the data subject (with strict conditions on what valid consent looks like).
• Performance of a contract with the data subject.
• Compliance with a legal obligation to which the controller is subject.
• Protection of vital interests of the data subject.
• Public interest or exercise of official authority.
• Legitimate interests of the controller, weighed against the rights of the data subject.

Walk through every processing activity in your inventory and record the lawful basis against it. Where you rely on consent, make sure the mechanism captures genuine, informed, specific, revocable consent — not a pre-ticked box buried in a 20-page terms document. Consent relied on today should still be defensible in an audit tomorrow.

Step 4 — Build the Records of Processing

The Records of Processing Activities (RoPA) is the beating heart of a PDPL programme. It is the single document SDAIA will ask to see first. The RoPA should list, for each processing activity:

• Name of the controller (or joint controllers) and their contact details.
• Name and contact of the DPO.
• Purposes of the processing.
• Categories of data subjects and categories of personal data.
• Recipients (including processors and any third-country recipients).
• Retention period.
• Lawful basis.
• A general description of the technical and organisational security measures.

Organisations that try to build the RoPA by circulating a spreadsheet get an inconsistent and incomplete document. Organisations that build it inside a GRC platform, with each record tagged to the controls that protect it, build something that stays current and can be produced on demand.

Step 5 — Implement data subject rights

PDPL grants data subjects a set of rights: the right to be informed about processing, the right of access, the right to request correction or completion, the right to request destruction, and the right to object to certain processing. Your organisation must be able to:

• Receive a data subject request through a published channel.
• Verify the identity of the requester.
• Respond within the statutory timeframe (generally 30 days).
• Maintain a log of requests and responses as evidence of compliance.

Running this as an email inbox is a common anti-pattern. The right model is a structured request intake that routes each request to the right owner, tracks the response clock, collects the evidence, and produces the audit log automatically.

Step 6 — Breach notification readiness

PDPL requires notification of personal data breaches to SDAIA and, in certain circumstances, to affected data subjects. The timing and threshold are set out in the Implementing Regulations. In practice this means:

• A documented incident response runbook that contains an explicit decision point for PDPL breach notification.
• Defined criteria for what constitutes a notifiable breach.
• A pre-drafted notification template so that the clock is not spent wordsmithing.
• A rehearsed handoff between the security team, the DPO and the legal/regulatory team.
• A post-incident log that includes the PDPL-relevant facts — what data, how many subjects, what mitigations.

Breach notification is the single PDPL obligation most often discovered mid-incident by teams that have not rehearsed it. Fix that before you need it.

Step 7 — Cross-border transfers

PDPL restricts the transfer of personal data outside Saudi Arabia. Transfers are permitted in defined circumstances, including explicit consent of the data subject, performance of an international obligation, and transfers where SDAIA has determined the receiving jurisdiction provides an adequate level of protection. Many organisations using international SaaS products have legacy data flows that will need to be reassessed against PDPL's transfer rules.

Inventory every cross-border flow. For each one, record the receiving jurisdiction, the lawful basis for the transfer, the safeguards in place (contractual clauses, technical measures), and the mitigations you have considered if the transfer ever has to stop. For Saudi organisations in regulated sectors — banking, government, healthcare — data residency is often the cleanest answer: keep the data in the Kingdom in the first place.

Step 8 — Third-party and processor agreements

Where you rely on processors, PDPL requires a written agreement that binds the processor to process personal data only on the controller's documented instructions, to implement appropriate security measures, to assist with data subject requests, to notify the controller of breaches, and to return or destroy the data at the end of the contract. Review every material processor contract and close the gap between what the contract currently says and what PDPL requires.

Step 9 — Privacy by design and impact assessments

PDPL expects personal data protection to be embedded into new systems, products and processes from the start, not bolted on afterwards. Build a Data Protection Impact Assessment (DPIA) gate into your change management process: any new processing activity involving sensitive data, large-scale monitoring, or new technologies should trigger a DPIA before go-live.

Step 10 — Ongoing audit and management review

The final step is the one most organisations neglect — the improvement loop. PDPL is not a project with a closing date. It is a programme that needs a regular audit cadence, a management review that looks at metrics and open actions, and a visible owner. SDAIA's mature expectation is that in-scope organisations can demonstrate not just compliance at a point in time, but an operating management system for personal data.

How GRC Vantage helps with PDPL

GRC Vantage's compliance module includes a pre-built PDPL control library, a RoPA template, a data subject rights workflow, a breach notification runbook and a cross-border transfer register. The platform runs inside Saudi Arabia to satisfy data residency expectations, is supported from our Riyadh and Dammam offices, and can connect PDPL evidence to the ISO 27001 and NCA ECC controls that protect the underlying data, so you are not collecting the same evidence three times for three different audiences.

For the full picture of the Saudi Personal Data Protection Law — including scope, lawful basis, rights, penalties and the SDAIA enforcement posture — read our PDPL Saudi Arabia guide. If you are building a PDPL programme, book a demo and we will walk through how Saudi controllers and processors use GRC Vantage to run PDPL as a managed programme rather than a one-off project.