Saudi PDPL compliance needs an operating model, not a document library

A privacy policy, a processing agreement and a spreadsheet of systems may each be useful. Together, they still do not establish that an organisation can explain how a personal-data decision is made, implemented and reviewed.

The Saudi Personal Data Protection Law and its regulations allocate obligations to identified actors and processing activities. An effective compliance model therefore has to connect the legal analysis to the organisation’s live systems, people, suppliers and records.

This analysis reflects official SDAIA materials checked on 23 August 2026. It is general information, not a conclusion about a particular organisation or processing activity.

Start with the processing, not the policy

The first record should describe how the processing activity works in practice. It should identify:

• which Saudi or overseas entity decides the purpose and manner of processing;
• which individuals and categories of personal data are involved;
• how the data is collected, used, disclosed, stored and destroyed;
• the specific purpose and proposed legal basis;
• the systems, recipients, processors and countries involved; and
• the person responsible for approving the activity and those authorised to restrict or stop it.

The PDPL applies according to its statutory scope, including relevant processing concerning individuals residing in the Kingdom by entities outside it. The scope review should be conducted entity by entity and activity by activity; a group-wide label is not enough.

Seven tasks for implementing compliance

The following tasks connect legal requirements with day-to-day operations.

1. Accountability and roles

Determine the controller and any processor for each material activity. The classification follows who determines the purpose and manner of processing, not what the contract calls the party. Record who is responsible for the decision, the privacy team’s duties and any circumstances requiring a data protection officer under the Implementing Regulation.

2. Processing inventory

Maintain an accurate, current written record of processing activities. Article 31 of the Law and Article 33 of the Implementing Regulation make this a controlled record, not a one-time survey. It needs to remain available to the competent authority on request and to be retained for the regulatory period.

3. Purpose and legal basis

Define each purpose precisely enough to control data collection and use. Then identify the applicable basis under the Law and Regulations. Consent is one possible basis, with its own conditions; it should not be inserted automatically where the activity is said to be “privacy related”.

4. Transparency and rights

The information given to data subjects should match the actual processing. Rights requests need a channel for receiving them, identity checks where appropriate, a reasoned decision, implementation in the systems and a record of the response. Publishing a notice without creating this response process leaves the operating model incomplete.

5. Suppliers and transfers

Map processors, subprocessors, disclosures and overseas access. A processing agreement allocates obligations but does not decide the Saudi transfer route or prove that system permissions match the approved design. Procurement, privacy, security and technology teams should work from the same data map.

6. Security, impact and incidents

Identify the security measures and evidence appropriate to the activity. Conduct the impact or risk assessment required by the applicable provisions and facts. For an incident, preserve one chronology connecting technical facts, affected data and people, containment, regulatory analysis, communications and the notification decision.

7. Review and change control

Specify which changes reopen the decision: a new purpose, data category, supplier, model, support country, integration, recipient, retention period or affected group. Without change triggers, a record may be accurate on approval day and misleading soon afterwards.

Retain records showing the decision’s basis and implementation

The model should produce evidence that can be used by management and the competent authority. For each activity, bring together the applicable records:

1. the processing record;
2. the purpose and legal-basis analysis;
3. the notice or other transparency material;
4. the supplier and transfer record;
5. the security and impact evidence;
6. the rights and incident procedures; and
7. the approval, person responsible for implementation, review date and changes that require reassessment.

These records do not all have to be long. They do have to agree. A privacy notice should not describe one purpose while the system collects data for another. A contract should not restrict overseas access that remains enabled in practice. A retention schedule should not conflict with deletion settings or a lawful preservation requirement.

The management question

The useful conclusion is not that the organisation “has PDPL documents”. It is whether the person responsible for an active processing activity can show what is being done, why it is permitted, what was communicated, who receives the data, how the activity is controlled and what evidence will be retained.

Temairik Law’s data protection practice advises on Saudi PDPL operating models, processing relationships, transfers, rights and incident decisions. This article is general information and does not constitute legal advice.