Learn About Saudi Arabia's Personal Data Protection Law (PDPL)

Discover Saudi Arabia's 2023 PDPL, its guidelines for data handling, individual rights, and penalties, ensuring privacy and security

By

Jatin Solanki

Updated on

October 2, 2024

Overview

Saudi Arabia has enacted its first comprehensive data protection law. The Personal Data Protection Law (PDPL) seeks to secure the privacy of individuals' personal data and to regulate the acquisition, processing, disclosure, and retention of such data by organisations.

The PDPL lays out extensive requirements pertaining to processing principles, data subjects' rights, organisations' obligations when processing personal data of individuals, cross-border data transfer mechanisms, and penalties for non-compliance.

One of the most notable characteristics of the PDPL is that it does not interfere with any provision that grants a data subject a right or specifies a higher level of protection in any other law or international convention to which Saudi Arabia is a party.

In addition, the SDAIA, in collaboration with the National Data Management Office (NDMO), issued a draft version of the Executive Regulations on 10 March 2022.

The PDPL was initially scheduled to go into effect on March 23, 2022. However, the SDAIA has submitted proposed amendments to the PDPL for public comment between November 20 and December 20, 2022. The Saudi Council of Ministers approved amendments to the PDPL on March 21, 2023. According to the revised version's timeline, PDPL will go into effect on 14 September 2023, and organisations will have until 13 September 2024 to conform.

Therefore, who must comply with this law? What rights do subjects of data have? Who administers this new law? To learn more about these queries and many others to enhance your compliance efforts, continue reading:

1. Who is Required to Comply with the Law?

The following describes how the new law applies to organisations based on their jurisdiction and the type of data involved:

a. Material Scope

The PDPL applies to the processing of personal and sensitive personal data pertaining to Saudi Arabian residents. The PDPL also applies to the deceased's personal information if it could be used to identify the deceased or a family member. The PDPL does not apply to the processing of personal information for domestic purposes.

b. Territorial Scope

The PDPL applies to any organisation, public or private, that processes personal data pertaining to individuals in Saudi Arabia. If a foreign organisation processes the personal information of Saudi Arabian citizens, the PDPL will also apply.

2. Responsibilities of Organisations In accordance with that Specific Statute

The PDPL imposes a number of responsibilities on controlling authorities (data administrators). Before processing personal data, data administrators (organisations) must ensure the data's accuracy, completeness, and relevance. The controlling authorities must also adhere to the data protection principles (limited collection, limited use, data security, accountability, limited retention, etc.).

The following are the essential PDPL obligations that organisations must fulfil to remain compliant:

a. Consent Requirements

The PDPL stipulates that organisations may not process personal data without the consent of the data's proprietor, with the exception of the circumstances outlined in the Draft Regulation.

Data subjects may revoke their consent to the processing of personal data at any time, and consent should not be required for the data controller to provide a service or benefit (unless the service or benefit is directly related to the processing activity for which consent is obtained).

The PDPL exempts the following scenarios from requiring consent:

  • If the processing would accomplish a clear benefit and contacting the data subject is impossible or impracticable; 
  • If it is mandated by law or a prior agreement to which the data subject is a party;
  • If the controller is a public entity and the processing is necessary for security or judicial purposes; 
  • If the controller is collecting data for scientific, research, or statistical purposes and has taken the required legal measures;
  • The processing is necessary to protect the legitimate interests of the controller or a third party, as long as the rights of the data subjects are not compromised. This, however, does not apply to sensitive personal data.

b. Requirements for Privacy Notification and Privacy Policy

Before collecting personal data, the PDPL mandates that organisations adopt a personal data privacy policy and make it accessible to data subjects. This policy shall include the purpose of its collection, the content of the personal data to be collected, the method of its collection, the means of its storage, the manner in which it will be processed, the manner in which it will be destroyed, the rights of its owner in relation to it, and the manner in which these rights will be exercised.

Before initiating the collection of a data subject's personal information, organisations that collect the data directly from the data subject are required to inform the data subject of the following:

  • The legitimate legal or practical basis for collecting their personal information;
  • The purpose of collecting their personal data and whether collecting all or a portion of it is mandatory or voluntary, as well as informing them that their data will not be processed in a manner inconsistent with the purpose of its collection or in circumstances not specified in the PDPL;
  • The identity of the person collecting the personal information and, when necessary, the address of their reference, unless the collection is for security purposes;
    The organisation(s), its/their capacity, and whether the personal data will be transferred, disclosed, or processed outside the United Kingdom;
  • Effects and risks of failing to complete the personal data collection procedure;
    Subject data privileges; and
  • Other elements are determined by the character of the organization's activity, as specified by the regulations.

c. Security Prerequisites

The PDPL requires organisations to adopt the organisational, administrative, and technical measures and means necessary to ensure the protection of personal data, including when it is transferred, in accordance with the provisions and controls outlined in the Draft Regulations.

d. Data Breach Requirements

The PDPL stipulates that organisations must notify the regulatory authority within 72 hours of discovering a data breach. In addition, the data controller must provide the regulatory authority with a comprehensive analysis of the violation and the measures being taken to prevent a recurrence.

In addition, if the data intrusion poses a substantial danger to the personal information of the data subjects, the data controller must promptly notify them. The controller must also provide the contact information of the DPO the data subjects can contact to learn more about the compromised data.

e. Data Protection Officer Requirement

The PDPL stipulates that organisations must appoint an individual (or multiple people) to be responsible for implementing its provisions.

f. Data Protection Impact Evaluation

According to the nature of their processing activities, the PDPL requires organisations to conduct an assessment of the consequences of processing personal data for any product or service offered to the public.

g. Processing Activity Record

Under the PDPL, organisations are required to maintain records of their processing activities for the duration specified in the Draft Regulation. The records should contain at least the following information:

  • Contact information for the company;
  • The reason for processing personal information;
  • A description of the data subject categories;
  • Any recipient to whom personal information has been (or will be) disclosed;
  • Whether personal information has been (or will be) transferred or disclosed outside Saudi Arabia; and
  • The anticipated length of time that the personal data will be stored.

h. Vendor Evaluation/Third Party Processing Demands

The PDPL stipulates that, when selecting the processing party, organisations must choose an entity that provides the necessary guarantees for enforcing the provisions of the PDPL and must continuously verify such entity's compliance with their instructions in all matters pertaining to the protection of personal data.

i. Cross border data transmission Requirements

The PDPL permits transfers outside of Saudi Arabia, but stipulates that the recipient country must have regulations that guarantee the appropriate protection of personal data and a supervisory entity that requires controllers to implement appropriate procedures and mechanisms to protect personal data. To this end, SDAIA will establish evaluation criteria. In addition, Article 28 of the PDPL specifies that any of the following may serve as a transfer basis:

Preservation of the public interest, public health, public safety, or protection of the life or health of a specific individual or individuals; Performance of an obligation under an international agreement to which the Kingdom of Saudi Arabia is a party; or Performance of an obligation of the data subject under the Draft Regulations.
Previously, cross-border transmission was only permitted in exceptional circumstances and under certain conditions, such as in cases of extreme necessity to protect the life or vital interests of the data subject outside of Saudi Arabia, or to prevent, investigate, or treat an infection. In addition, SDAIA was compelled to approve each transfer individually.

3. Rights of Data Subjects

As with the majority of other global data protection regulations, the PDPL ensures that all data subjects have certain rights. These rights, also known as data subject rights, guarantee that all users retain control over their collected data. Different data protection regulations provide a variety of rights for data subjects. Among those protected by the PDPL are the following:

Right to Know/Information - Data subjects have the right to know the contact information of the data controller, the precise reason the data is being collected, the methods being used to collect the data, and whether or not the collected data will be shared or sold.

Right to Request Correction - Data subjects have the right to request correction of any incomplete, inaccurate, or outdated data collected on them.

Data subjects have the right to request the eradication of data collected on them. The reasons can range from the user revoking their consent for data acquisition to the data no longer fulfilling its intended purpose.

Right to Limit/Restrict Processing - Data subjects have the right to limit or refuse the processing of their personal data by the organisation in limited circumstances and for a limited duration. This privilege is not expressly granted by the PDPL; however, the regulatory authority has published a set of Frequently Asked Questions (FAQs) that describe it.

Right to Data Portability: Data subjects have the right to obtain their personal data in a comprehensible and machine-readable format and to request the transmission of their personal data to another controller.

The data controller must ensure that all data subjects are adequately informed of these rights and establish channels for data subjects to exercise them. The data controller must respond to these requests within 30 days and document all requests received from data subjects.

4. Regulatory Agency

Within Saudi Arabia, the Saudi Data & Artificial Intelligence Authority (SDAIA) will be primarily responsible for enforcing the PDPL. In addition to penalising organisations found to have violated the PDPL, the SDAIA is also tasked with advising organisations on internal data transfers and keeping track of data subject rights petitions received by organisations.

Nevertheless, the Saudi Data & Artificial Intelligence Authority (SDAIA) will only oversee the implementation of the new law for the first two years. Consideration will be given to transferring supervision to the National Data Management Office (NDMO) in 2024.

5. Consequences for Non-Compliance:

The PDPL stipulates that the penalty for disclosing or publishing sensitive personal data may be up to two years in prison and/or a fine of up to SAR 3 million ($800,000); therefore, both organisations and individuals can be punished.

For violations of other PDPL provisions, the maximum penalty is a warning letter or a fine of up to SAR 5 million ($1.3 million). In cases of repeated offences, the court may decide to double the sanction.

How an Organisation Can Implement the Regulation

Organisations will be compelled to modify their status in accordance with the PDPL provisions within one year of the law's effective date.

  • Catalog their data inventories and classify sensitive personal data and personal data;
  • Determine if it is necessary to appoint a representative in Saudi Arabia;
  • Registering in Saudi Arabia;
  • Disclosing how personal data is processed through formal policies and privacy notices that are transparent.
  • Create formal policies and procedures for data acquisition (consent framework, etc.) and processing, and revise privacy policies as necessary;
  • Have comprehensive notification mechanisms in place for data breaches;
  • Map their processes, identify cross-border data flows from Saudi Arabia to other countries, and comply with the PDPL's stringent cross-border requirements;
  • Have a comprehensive framework for data subject requests in place;
  • Develop the capability to scan and trace data processing activity and generate ROPA compliance reports;
  • Have in place technical and organisational safeguards to secure their processing activities; and
  • Conduct impact assessments on personal information protection, vendor assessments, and other risk assessments.

How can Decube help?

Decube is one of the unified platform which is designed to efficiently manage Governance, PrivacyOps, Catalog and Observability. Not only you will be able to classify the data assets but also monitor for any incidents around that. We can help you stay compliant, schedule a demo here.

What is a Data Trust Platform in financial services?
A Data Trust Platform is a unified framework that combines data observability, governance, lineage, and cataloging to ensure financial institutions have accurate, secure, and compliant data. In banking, it enables faster regulatory reporting, safer AI adoption, and new revenue opportunities from data products and APIs.
Why do AI initiatives fail in Latin American banks and fintechs?
Most AI initiatives in LATAM fail due to poor data quality, fragmented architectures, and lack of governance. When AI models are fed stale or incomplete data, predictions become inaccurate and untrustworthy. Establishing a Data Trust Strategy ensures models receive fresh, auditable, and high-quality data, significantly reducing failure rates.
What are the biggest data challenges for financial institutions in LATAM?
Key challenges include: Data silos and fragmentation across legacy and cloud systems. Stale and inconsistent data, leading to poor decision-making. Complex compliance requirements from regulators like CNBV, BCB, and SFC. Security and privacy risks in rapidly digitizing markets. AI adoption bottlenecks due to ungoverned data pipelines.
How can banks and fintechs monetize trusted data?
Once data is governed and AI-ready, institutions can: Reduce OPEX with predictive intelligence. Offer hyper-personalized products like ESG loans or SME financing. Launch data-as-a-product (DaaP) initiatives with anonymized, compliant data. Build API-driven ecosystems with partners and B2B customers.
What is data dictionary example?
A data dictionary is a centralized repository that provides detailed information about the data within an organization. It defines each data element—such as tables, columns, fields, metrics, and relationships—along with its meaning, format, source, and usage rules. Think of it as the “glossary” of your data landscape. By documenting metadata in a structured way, a data dictionary helps ensure consistency, reduces misinterpretation, and improves collaboration between business and technical teams. For example, when multiple teams use the term “customer ID”, the dictionary clarifies exactly how it is defined, where it is stored, and how it should be used. Modern platforms like Decube extend the concept of a data dictionary by connecting it directly with lineage, quality checks, and governance—so it’s not just documentation, but an active part of ensuring data trust across the enterprise.
What is an MCP Server?
An MCP Server stands for Model Context Protocol Server—a lightweight service that securely exposes tools, data, or functionality to AI systems (MCP clients) via a standardized protocol. It enables LLMs and agents to access external resources (like files, tools, or APIs) without custom integration for each one. Think of it as the “USB-C port for AI integrations.”
How does MCP architecture work?
The MCP architecture operates under a client-server model: MCP Host: The AI application (e.g., Claude Desktop or VS Code). MCP Client: Connects the host to the MCP Server. MCP Server: Exposes context or tools (e.g., file browsing, database access). These components communicate over JSON‑RPC (via stdio or HTTP), facilitating discovery, execution, and contextual handoffs.
Why does the MCP Server matter in AI workflows?
MCP simplifies access to data and tools, enabling modular, interoperable, and scalable AI systems. It eliminates repetitive, brittle integrations and accelerates tool interoperability.
How is MCP different from Retrieval-Augmented Generation (RAG)?
Unlike RAG—which retrieves documents for LLM consumption—MCP enables live, interactive tool execution and context exchange between agents and external systems. It’s more dynamic, bidirectional, and context-aware.
What is a data dictionary?
A data dictionary is a centralized repository that provides detailed information about the data within an organization. It defines each data element—such as tables, columns, fields, metrics, and relationships—along with its meaning, format, source, and usage rules. Think of it as the “glossary” of your data landscape. By documenting metadata in a structured way, a data dictionary helps ensure consistency, reduces misinterpretation, and improves collaboration between business and technical teams. For example, when multiple teams use the term “customer ID”, the dictionary clarifies exactly how it is defined, where it is stored, and how it should be used. Modern platforms like Decube extend the concept of a data dictionary by connecting it directly with lineage, quality checks, and governance—so it’s not just documentation, but an active part of ensuring data trust across the enterprise.
What is the purpose of a data dictionary?
The primary purpose of a data dictionary is to help data teams understand and use data assets effectively. It provides a centralized repository of information about the data, including its meaning, origins, usage, and format, which helps in planning, controlling, and evaluating the collection, storage, and use of data.
What are some best practices for data dictionary management?
Best practices for data dictionary management include assigning ownership of the document, involving key stakeholders in defining and documenting terms and definitions, encouraging collaboration and communication among team members, and regularly reviewing and updating the data dictionary to reflect any changes in data elements or relationships.
How does a business glossary differ from a data dictionary?
A business glossary covers business terminology and concepts for an entire organization, ensuring consistency in business terms and definitions. It is a prerequisite for data governance and should be established before building a data dictionary. While a data dictionary focuses on technical metadata and data objects, a business glossary provides a common vocabulary for discussing data.
What is the difference between a data catalog and a data dictionary?
While a data catalog focuses on indexing, inventorying, and classifying data assets across multiple sources, a data dictionary provides specific details about data elements within those assets. Data catalogs often integrate data dictionaries to provide rich context and offer features like data lineage, data observability, and collaboration.
What challenges do organizations face in implementing data governance?
Common challenges include resistance from business teams, lack of clear ownership, siloed systems, and tool fragmentation. Many organizations also struggle to balance strict governance with data democratization. The right approach involves embedding governance into workflows and using platforms that unify governance, observability, and catalog capabilities.
How does data governance impact AI and machine learning projects?
AI and ML rely on high-quality, unbiased, and compliant data. Poorly governed data leads to unreliable predictions and regulatory risks. A governance framework ensures that data feeding AI models is trustworthy, well-documented, and traceable. This increases confidence in AI outputs and makes enterprises audit-ready when regulations apply.
What is data governance and why is it important?
Data governance is the framework of policies, ownership, and controls that ensure data is accurate, secure, and compliant. It assigns accountability to data owners, enforces standards, and ensures consistency across the organization. Strong governance not only reduces compliance risks but also builds trust in data for AI and analytics initiatives.
What is the difference between a data catalog and metadata management?
A data catalog is a user-facing tool that provides a searchable inventory of data assets, enriched with business context such as ownership, lineage, and quality. It’s designed to help users easily discover, understand, and trust data across the organization. Metadata management, on the other hand, is the broader discipline of collecting, storing, and maintaining metadata (technical, business, and operational). It involves defining standards, policies, and processes for metadata to ensure consistency and governance. In short, metadata management is the foundation—it structures and governs metadata—while a data catalog is the application layer that makes this metadata accessible and actionable for business and technical users.
What features should you look for in a modern data catalog?
A strong catalog includes metadata harvesting, search and discovery, lineage visualization, business glossary integration, access controls, and collaboration features like data ratings or comments. More advanced catalogs integrate with observability platforms, enabling teams to not only find data but also understand its quality and reliability.
Why do businesses need a data catalog?
Without a catalog, employees often struggle to find the right datasets or waste time duplicating efforts. A data catalog solves this by centralizing metadata, providing business context, and improving collaboration. It enhances productivity, accelerates analytics projects, reduces compliance risks, and enables data democratization across teams.
What is a data catalog and how does it work?
A data catalog is a centralized inventory that organizes metadata about data assets, making them searchable and easy to understand. It typically extracts metadata automatically from various sources like databases, warehouses, and BI tools. Users can then discover datasets, understand their lineage, and see how they’re used across the organization.
What are the key features of a data observability platform?
Modern platforms include anomaly detection, schema and freshness monitoring, end-to-end lineage visualization, and alerting systems. Some also integrate with business glossaries, support SLA monitoring, and automate root cause analysis. Together, these features provide a holistic view of both technical data pipelines and business data quality.
How is data observability different from data monitoring?
Monitoring typically tracks system metrics (like CPU usage or uptime), whereas observability provides deep visibility into how data behaves across systems. Observability answers not only “is something wrong?” but also “why did it go wrong?” and “how does it impact downstream consumers?” This makes it a foundational practice for building AI-ready, trustworthy data systems.
What are the key pillars of Data Observability?
The five common pillars include: Freshness, Volume, Schema, Lineage, and Quality. Together, they provide a 360° view of how data flows and where issues might occur.
What is Data Observability and why is it important?
Data observability is the practice of continuously monitoring, tracking, and understanding the health of your data systems. It goes beyond simple monitoring by giving visibility into data freshness, schema changes, anomalies, and lineage. This helps organizations quickly detect and resolve issues before they impact analytics or AI models. For enterprises, data observability builds trust in data pipelines, ensuring decisions are made with reliable and accurate information.

Table of Contents

Read other blog articles

Grow with our latest insights

Sneak peek from the data world.

Thank you! Your submission has been received!
Talk to a designer

All in one place

Comprehensive and centralized solution for data governance, and observability.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
decube all in one image