The Complete Guide to PDPL Compliance in Saudi Arabia

Section 1

What is the PDPL?

Saudi Arabia's Personal Data Protection Law (PDPL) is the Kingdom's first comprehensive data protection legislation. It was issued under Royal Decree No. M/19 on 16 September 2021 and amended by Royal Decree No. M/148 on 27 March 2023. The law formally came into force on 14 September 2023, and after a one-year transitional grace period, became fully enforceable on 14 September 2024.

The PDPL is part of Saudi Arabia's broader Vision 2030 digital transformation agenda. It establishes a unified legal framework governing how personal data must be collected, processed, stored, transferred, and disclosed — creating clear obligations for organisations and enshrining specific rights for individuals whose data is being handled.

The primary enforcement authority is the Saudi Data and Artificial Intelligence Authority (SDAIA), which issued the Implementing Regulations and the Regulation on Personal Data Transfers Outside the Kingdom. SDAIA oversees compliance, receives breach notifications, handles data subject complaints, and has the power to investigate, fine, and sanction violators.

The broader regulatory ecosystem

The PDPL sits alongside other laws that touch data and privacy in the Kingdom. Organisations — especially those in regulated industries — must comply with all applicable frameworks simultaneously:

• Anti-Cyber Crime Law (No. M/17) — governs cybercrime, illegal access, and online privacy violations
• Electronic Transactions Law (No. M/18) — covers digital signatures and electronic records
• Telecommunications and Information Technology Law (No. M/160) — sector rules from the Communications, Space and Technology Commission
• SAMA Cybersecurity Framework — mandatory for banks and financial institutions
• NCA Essential Cybersecurity Controls — cybersecurity standards that intersect with PDPL data security obligations

Section 2

Who Must Comply?

One of the defining characteristics of the PDPL is its broad extraterritorial reach — arguably broader than the EU's GDPR. The law applies to:

• Any entity or individual located inside Saudi Arabia that processes personal data of any kind
• Any entity or individual located outside Saudi Arabia that processes the personal data of individuals residing in the Kingdom — regardless of whether they are actively targeting Saudi residents or merely happen to process their data
• Both public and private sector entities
• Data relating to deceased individuals, if it could lead to the identification of that person or a specific family member

Who is covered by the data subject protections?

The PDPL protects the personal data of all individuals residing in Saudi Arabia, which includes:

• Saudi nationals
• Permanent and temporary residents (including Iqama holders)
• Visitors, tourists, and any person physically present in the Kingdom

Does the PDPL apply to B2B businesses?

Yes. Even if your business operates purely in a B2B context with no direct consumer relationships, you almost certainly process personal data — employee records, payroll data, HR files, business contact information for clients and vendors. All of this falls within the scope of the PDPL, and the obligations apply in full.

Foreign companies: do you need a local representative?

Entities outside Saudi Arabia that regularly process personal data of Saudi residents should assess whether they need to appoint a local representative. While the PDPL and Implementing Regulations are not yet fully explicit on this point (SDAIA is expected to issue further guidance), it is prudent best practice for foreign entities with significant Saudi data processing activities to appoint an in-Kingdom contact who can liaise with SDAIA and respond to data subject requests.

Section 3

Key Definitions

Understanding the PDPL starts with understanding its terminology. The law uses specific defined terms that determine how obligations apply to your organisation.

• Personal Data Any data — regardless of source or form — that leads to the identification of an individual directly or indirectly. This includes names, national ID numbers, email addresses, phone numbers, location data, IP addresses, and any other identifier that singles out a specific person.
• Sensitive Personal Data A special sub-category of personal data that receives heightened protection. See Section 5 for the full list of categories and applicable obligations.
• Processing Any operation performed on personal data — whether automated or manual — including collection, recording, storage, organisation, transmission, modification, retrieval, use, disclosure, erasure, or destruction.
• Data Controller The natural or legal person (or public entity) that determines the purposes and means of processing personal data. Most businesses operating in Saudi Arabia will be data controllers with respect to their customer and employee data.
• Data Processor A third party that processes personal data on behalf of a data controller. Payroll providers, cloud hosting companies, and HR software vendors are typical examples. Controllers remain accountable for their processors' compliance.
• Data Subject The individual whose personal data is being processed — the customer, employee, user, or other person whose information your organisation handles.
• Consent A freely given, specific, informed, and unambiguous indication by the data subject that they agree to the processing of their personal data. Consent is the default legal basis under the PDPL, but not the only one available.
• Data Protection Officer (DPO) A designated individual (or team) responsible for monitoring PDPL compliance, conducting impact assessments, handling data subject requests, and acting as the point of contact with SDAIA. Mandatory for certain types of organisations.

Section 4

Legal Bases for Processing

Every act of processing personal data under the PDPL must be justified by a recognised legal basis. Processing personal data without a valid legal basis is unlawful and exposes your organisation to regulatory action. The PDPL recognises the following legal bases:

1. Consent

Consent is the default legal basis under the PDPL, and unlike under the GDPR, it is the starting point from which organisations must work. Consent must be:

• Freely given — not coerced or conditional on another service (in most circumstances)
• Specific — covering the particular purpose of processing
• Informed — the data subject must understand what they are consenting to
• Unambiguous — a clear affirmative action, not pre-ticked boxes or silence

Consent can be withdrawn at any time. The withdrawal must be as easy as the giving of consent. When consent is withdrawn, processing based solely on consent must cease, though data may be retained if there is another valid basis for retention.

2. Legal Obligation

Processing is permitted when it is necessary to comply with a legal obligation applicable to the controller. For example, processing employee tax and payroll data under Saudi labour law, or retaining transaction records under commercial regulations.

3. Contractual Necessity

Processing is permitted where it is necessary to perform a contract to which the data subject is a party, or to take pre-contractual steps at the data subject's request. For example, processing a customer's name and address to fulfil an order. Crucially, the PDPL specifies this must be based on a prior agreement, meaning the contract relationship must already exist or be in the process of being formed.

4. Vital Interests

Processing is permitted where it is necessary to protect the vital interests of the data subject or of another person — for example, emergency medical treatment where the individual cannot give consent.

5. Public Interest

Processing is permitted in the public interest where authorised by applicable law. Public entities regularly rely on this basis.

6. Legitimate Interests

Processing is permitted where necessary for the legitimate interests of the controller or a third party, provided this does not override the interests or fundamental rights of the data subject. Importantly, the PDPL does not permit reliance on legitimate interests for processing sensitive personal data. This restriction is a key divergence from the GDPR.

Section 5

Sensitive Personal Data

The PDPL establishes a distinct sub-category of personal data — sensitive personal data — that is subject to stricter processing requirements and higher penalties for unlawful disclosure. Unlike the GDPR, the PDPL does not require a separate legal basis for processing sensitive data, but additional safeguards must be applied.

What qualifies as sensitive personal data?

• Racial or ethnic origin
• Religious, intellectual, or political beliefs
• Criminal records and security-related data
• Biometric data used for the purpose of identifying a person
• Genetic data
• Health data
• Data indicating that one or both parents of the individual are unknown

Additional obligations when processing sensitive data

• Heightened security measures must be implemented — including alignment with National Cybersecurity Authority (NCA) standards
• Controllers must register on the National Data Governance Platform if processing sensitive data is a core activity
• Data Protection Impact Assessments (DPIAs) are mandatory for processing activities involving sensitive data
• Legitimate interests cannot be used as a legal basis for processing sensitive data
• Cross-border transfers of sensitive data are subject to additional restrictions — a full Transfer Risk Assessment is required
• Stricter data minimisation applies — only the minimum necessary sensitive data may be collected

Health and credit data: additional rules

The Implementing Regulations contain specific additional provisions for health data and credit data. For health data, processing is generally restricted to healthcare providers, public health authorities, and research institutions subject to strict conditions. For credit data, lenders and financial service providers must comply with SAMA's framework alongside the PDPL's requirements.

Section 6

Data Subject Rights

The PDPL grants individuals a comprehensive set of rights over their personal data. Organisations must establish clear, documented procedures for handling data subject requests within the prescribed timeframes. Failure to respond appropriately is a violation that can trigger enforcement action.

Handling data subject requests in practice

Organisations must establish a documented workflow for receiving, verifying, and responding to data subject requests (DSRs). Key operational requirements include:

• Authentication: Requests can be submitted verbally or in writing. Controllers must authenticate the identity of requestors — including verbal requests — which the Implementing Regulation acknowledges creates an operational burden. Identity verification should be proportionate to the sensitivity of the data concerned.
• 30-day response window: Controllers must respond within 30 days of receiving a request. Where a request is refused, the controller must provide written reasons and inform the individual of their right to complain to SDAIA.
• No charges for DSRs: Unlike the GDPR (which allows fees for manifestly unfounded or excessive requests), the PDPL does not permit controllers to charge data subjects for requests. Controllers can reject requests they consider unfounded, but must do so with written justification.
• Retention of records: All DSR correspondence and outcomes must be documented and retained as part of your compliance records.

Section 7

Controller Obligations

Data controllers bear the heaviest set of obligations under the PDPL. The following are the core duties every controller must fulfil to achieve compliance.

1. Controller Registration

Controllers must register on SDAIA's National Data Governance Platform in the following circumstances:

• The entity is a public authority
• The primary business activity involves personal data processing
• The controller processes sensitive personal data
• The controller transfers personal data outside the Kingdom
• The controller processes personal data of vulnerable individuals (including minors)

2. Records of Processing Activities (RoPA)

Controllers must maintain a comprehensive, documented Record of Processing Activities covering all data processing operations. RoPA records must include:

• The purposes of processing and the legal basis for each activity
• Categories of personal data processed
• Categories of data subjects
• Retention timelines for each data category
• Details of any processors engaged and safeguards in place
• Cross-border transfer destinations and the safeguard mechanisms used
• Technical and organisational security measures applied

Records must be retained for five years after the relevant processing activity ceases, and must be made available to SDAIA upon request.

3. Privacy Notices

Controllers must provide data subjects with clear, accessible privacy notices at or before the point of data collection. These notices must disclose:

• The identity and contact details of the controller (and DPO, where applicable)
• The purposes of processing and the legal basis relied upon
• Whether processing is for direct marketing and how to opt out
• Details of any cross-border transfers
• Retention periods
• The data subject's rights and how to exercise them
• The right to lodge a complaint with SDAIA

4. Data Minimisation and Purpose Limitation

Controllers may only collect and process personal data that is adequate, relevant, and limited to what is necessary for the stated purpose. Collecting data on a "just in case" basis is not permitted. Data must not be used for purposes materially different from those disclosed at the time of collection without a separate legal basis and fresh notice to the data subject.

5. Retention Limits

Personal data must not be retained for longer than is necessary for the purpose for which it was collected. Once the purpose has been fulfilled and there is no other legal basis for retention (such as a legal obligation to retain records), the data must be deleted or anonymised. Controllers must establish and document retention schedules for each category of personal data they hold.

6. Processor Agreements

When engaging a third-party processor to process personal data on the controller's behalf, a written Data Processing Agreement (DPA) is mandatory. This agreement must include, as a minimum:

• The scope, nature, purpose, and duration of the processing
• The type of personal data and categories of data subjects involved
• The processor's obligations and rights
• A requirement that the processor notify the controller without delay of any data breach
• Restrictions on sub-processing (engaging further processors)
• Security requirements aligned with PDPL and NCA standards
• Deletion or return of data at the end of the processing relationship

Critically, the controller remains fully accountable to SDAIA and to data subjects for everything the processor does with the data. Engaging a non-compliant processor does not reduce the controller's exposure — it simply creates an additional contractual claim against the processor.

7. Data Protection Impact Assessments (DPIAs)

The Implementing Regulations mandate DPIAs in at least nine documented scenarios, including:

• Processing involving anonymisation of personal data
• Processing sensitive personal data
• Processing involving new or emerging technologies
• Processing likely to involve high risk to data subjects
• Large-scale or systematic monitoring of individuals
• Processing involving children's data or other vulnerable groups

DPIAs must be documented and retained. Where a DPIA identifies a high residual risk that cannot be mitigated, the controller must consult SDAIA before commencing the processing activity.

8. Technical and Organisational Security Measures

Controllers must implement necessary (the Implementing Regulations emphasise this word) technical and organisational measures to protect personal data against accidental loss, destruction, alteration, or unauthorised access. The benchmark for these measures is alignment with the National Cybersecurity Authority (NCA) Essential Cybersecurity Controls, or internationally recognised security standards for entities that fall outside NCA's direct regulatory scope.

• Encryption of personal data in transit and at rest
• Access controls and role-based permissions
• Logging and audit trails for data access
• Regular vulnerability assessments and penetration testing
• Staff training and awareness programmes
• Incident response and breach containment procedures

9. Staff Training

Organisations must provide regular privacy training to employees — particularly those in data-heavy functions such as HR, marketing, IT, and customer service. Training must cover PDPL obligations, internal data policies, and practical handling procedures. Training logs must be maintained as part of compliance documentation.

Section 8

Data Protection Officer (DPO)

The PDPL requires certain categories of controller to appoint one or more Data Protection Officers. Even where appointment is not strictly mandatory, designating a DPO or an equivalent compliance lead is strongly recommended as a demonstration of accountability.

When must you appoint a DPO?

A DPO must be appointed where any of the following applies to your organisation:

• You are a public entity providing large-scale personal data processing services
• Your core business activities inherently involve regular and systematic monitoring of data subjects at scale
• Your core business activities involve processing sensitive personal data

Who can serve as DPO?

The DPO may be:

• An employee of the controller (a dedicated DPO or existing staff member with appropriate capacity)
• An external service provider or consultant engaged under a service contract
• In some circumstances, the controller's own representative

A single DPO may potentially cover multiple group entities, though the PDPL is silent on this point pending further SDAIA guidance.

DPO registration requirements

When a DPO is appointed, the controller must register the DPO's details on SDAIA's platform. The following information is required:

• National ID or residency number (for Saudi-based DPOs)
• Date of birth (for verification purposes)
• Official contact information — phone number and email address
• For DPOs located outside the Kingdom: full name and contact details

DPO responsibilities

The DPO's role under the PDPL is multi-faceted and carries significant accountability. Key responsibilities include:

• Overseeing and monitoring the controller's ongoing compliance with the PDPL and Implementing Regulations
• Supervising all data processing methods and practices adopted by the organisation
• Managing and tracking data subject requests, ensuring timely responses
• Overseeing and conducting Data Protection Impact Assessments
• Acting as the primary point of contact between the organisation and SDAIA
• Receiving and acting on SDAIA's decisions, instructions, and guidance
• Identifying and escalating PDPL violations within the organisation and taking corrective action
• Reporting directly to senior leadership on data protection matters

Section 9

Breach Notification

The PDPL imposes a strict and time-sensitive breach notification obligation — one of the most operationally demanding requirements in the entire law. Organisations that suffer a data breach must act quickly and in a structured way.

The 72-hour rule

Controllers must notify SDAIA within 72 hours of first becoming aware of a personal data breach that may cause harm to the personal data or data subject, or that conflicts with their rights and interests. This mirrors the GDPR's 72-hour notification window and requires organisations to have pre-built breach response procedures — there is not enough time to improvise.

What constitutes a reportable breach?

A personal data breach is any security incident that leads to — or is likely to lead to — the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. A breach is reportable to SDAIA if it potentially causes harm to data subjects. The threshold is deliberately low — if there is any reasonable risk of harm, the default should be to notify. This is notably broader than the GDPR's "risk to rights and freedoms" standard.

Notification to SDAIA: what to include

The initial notification to SDAIA within 72 hours should include, to the extent known:

• The nature of the breach — what happened, when, and how
• Categories and approximate number of data subjects affected
• Categories and approximate volume of personal data records involved
• Likely consequences of the breach
• Measures taken or proposed to address the breach
• Contact details of the DPO or designated point of contact

The controller must subsequently provide SDAIA with a detailed analysis of the breach and the measures implemented to prevent recurrence. Where all information is not available within 72 hours, organisations may phase their notification — but the initial report must be submitted on time.

Notifying data subjects

Where a breach creates a significant risk to data subjects' personal data, the controller must also notify affected individuals without undue delay. The notification must:

• Describe in clear, plain language the nature of the breach
• Explain the likely consequences
• Describe the measures the controller has taken or plans to take
• Provide the DPO's contact details so data subjects can obtain further information

Processor obligations on breach

If a data processor discovers or suffers a breach affecting data it processes on behalf of a controller, it must notify the controller without delay. The contract between controller and processor must specify this obligation. The processor's notification triggers the controller's 72-hour clock for notifying SDAIA.

Section 10

Cross-Border Data Transfers

For many international businesses operating in Saudi Arabia, cross-border data transfers are one of the most operationally complex aspects of PDPL compliance. The law permits transfers outside the Kingdom, but only when specific conditions and safeguards are satisfied.

In August 2024, SDAIA issued the Regulation on Personal Data Transfer Outside the Kingdom (the Transfer Regulations), which operationalised the transfer framework.

Permitted transfer grounds

A transfer of personal data outside Saudi Arabia is permitted in the following circumstances:

1. Adequacy

Transfers to jurisdictions that SDAIA has deemed to provide an adequate level of data protection. As of early 2025, SDAIA has not yet published an official adequacy list. The regulatory approach is expected to broadly mirror the EU's adequacy framework, and organisations should monitor SDAIA for list publication.

2. Appropriate Safeguards

Where no adequacy decision exists, transfers are permitted if appropriate safeguards are in place. Available safeguards under the Transfer Regulations include:

• Saudi Standard Contractual Clauses (Saudi SCCs) — SDAIA has published templates and these are expected to be the most widely used mechanism for international businesses
• Binding Corporate Rules (BCRs) — suitable for multinational groups transferring data between group entities
• Accreditation Certificate — a certificate issued by SDAIA-approved agencies confirming a non-Saudi entity's compliance level. Guidance on obtaining certificates is still pending.

Note: Codes of conduct have been removed from the list of available safeguards under the updated Transfer Regulations.

3. Exempt Cases

Transfers may also proceed without a safeguard where they fall into specific exempt categories:

• Transfers necessary to protect the life or health of the data subject
• Transfers to fulfil obligations under an international agreement to which Saudi Arabia is a party
• Transfers for scientific research purposes (with Saudi SCC usage or an approval certificate)
• Transfers to provide a direct benefit or service to the data subject (subject to the data importer holding an accreditation certificate and no sensitive data being transferred)

Transfer Risk Assessment (TRA)

The Transfer Regulations require a Transfer Risk Assessment before any transfer where safeguards (such as Saudi SCCs) are used, or where the transfer involves sensitive data on a continuous or large-scale basis. The TRA must consider:

• The purpose of the transfer and the nature of processing activities involved
• The appropriateness of safeguards and measures in place for the transfer
• The adequacy of protection provided by the recipient jurisdiction
• Whether data minimisation principles are satisfied
• Whether the transfer could conflict with Saudi Arabia's national security or vital interests

Sensitive data: additional restrictions

Cross-border transfers of sensitive personal data are subject to stricter requirements. In addition to the standard transfer conditions, a Transfer Risk Assessment is always required regardless of volume. SDAIA must not have prohibited the specific transfer. Controllers in regulated sectors (such as banking) must also ensure compliance with sector-specific data localisation requirements — SAMA requires that certain financial data remain in the Kingdom.

Practical steps for international businesses

• Data flow mappingIdentify all personal data that flows out of Saudi Arabia — including cloud services hosted abroad, payroll processing by offshore HR platforms, and customer data sent to international headquarters.
• Legal basis assessmentFor each transfer, determine which permitted ground or safeguard applies. In most cases, Saudi SCCs will be the primary mechanism.
• Execute Saudi SCCsPut in place SDAIA-template SCCs with each non-Saudi recipient of personal data. Ensure these are signed and stored as part of compliance documentation.
• Conduct Transfer Risk AssessmentsComplete and document TRAs for all applicable transfers. Review these every two years or when the nature of the transfer changes materially.
• Update RoPA and privacy noticesEnsure your records of processing activities and privacy notices accurately reflect all cross-border transfers, the recipients, and the safeguards in place.

Section 11

PDPL vs GDPR: Key Differences

Many international organisations approaching PDPL compliance will have an existing GDPR programme. The good news is that the PDPL draws heavily on GDPR principles and concepts. However, there are meaningful divergences that require specific attention and cannot simply be copy-pasted from a GDPR programme.

Section 12

Penalties and Enforcement

The PDPL and its Implementing Regulations establish a tiered penalty regime. Enforcement authority rests with SDAIA, which has powers comparable to those of supervisory authorities under the GDPR — including the right to investigate, audit, impose fines, and order the suspension of processing activities.

Additional enforcement powers

Beyond financial penalties, SDAIA may exercise the following enforcement measures:

• Corrective orders — directing the controller to take specific remediation steps within a defined timeframe
• Suspension of processing — ordering a halt to specific data processing activities until compliance is achieved
• Confiscation of financial proceeds obtained as a result of a PDPL violation
• Audits and inspections — SDAIA may conduct compliance audits and inspect data processing activities
• Publication of violations — naming non-compliant organisations publicly, with significant reputational consequences

Enforcement approach in practice

SDAIA has adopted a progressive enforcement approach, particularly given that the PDPL only became fully enforceable in September 2024. Early enforcement actions have been initiated but have not yet resulted in public financial penalties — the authority has signalled that it will escalate from warnings and corrective orders to fines as the market matures. Organisations should not interpret the current relatively cautious enforcement environment as permission to delay compliance — SDAIA is actively building its enforcement infrastructure, and the window for voluntary compliance before significant penalties become routine is narrowing.

Section 13

PDPL Compliance Roadmap

Building a PDPL compliance programme can feel overwhelming, particularly for organisations starting from scratch or those adapting an existing GDPR framework. The roadmap below provides a structured, phased approach.

Section 14

Sector-Specific Considerations

While the PDPL applies universally, certain sectors in Saudi Arabia face additional data protection obligations layered on top of the PDPL framework. Organisations in these sectors must comply with both regimes simultaneously.

Financial services and banking (SAMA)

The Saudi Central Bank (SAMA) has its own cybersecurity framework and data governance requirements that apply to banks, insurance companies, and other regulated financial entities. SAMA requires that certain categories of financial and customer data be held within the Kingdom — organisations subject to SAMA must map their PDPL obligations against these localisation requirements carefully. Where SAMA's rules are stricter, they prevail.

Healthcare

Health data is sensitive personal data under the PDPL and is subject to the strictest protections. The Ministry of Health and the Saudi Food and Drug Authority regulate healthcare data separately. Processing health data requires heightened security measures, strict access controls, and additional DPIA requirements. Cross-border transfers of health data are heavily restricted and require Transfer Risk Assessment regardless of volume.

Telecommunications

The Communications, Space and Technology Commission (CST) regulates data privacy and security for telecom operators, internet service providers, and related technology businesses. CST's sector-specific requirements operate alongside the PDPL and in some respects impose stricter standards — including data localisation requirements for certain categories of communications data.

E-commerce and digital platforms

The Electronic Commerce Law and Implementing Regulations impose specific disclosure and consent requirements for online retailers and digital service providers. These overlay with the PDPL's requirements for privacy notices and consent management on websites and apps. Cookie consent, tracking technologies, and digital marketing practices must comply with both frameworks.

HR, payroll, and employment data

Processing employee data is one of the most common PDPL compliance challenges for businesses entering Saudi Arabia. Employee personal data — including national ID numbers, salary information, residence permit (Iqama) data, bank account details, and performance records — is comprehensively covered by the PDPL. The legal basis for most routine HR processing will be contractual necessity or legal obligation. Employers should review their employment contracts, HR policies, and payroll processing arrangements for PDPL alignment.

Section 15

Frequently Asked Questions

Is PDPL compliance mandatory for small businesses?

Yes. The PDPL does not include an SME exemption. Any entity — regardless of size — that processes personal data of individuals residing in Saudi Arabia must comply. The obligations are proportionate in practice (a small business processing minimal data will have a lighter RoPA and fewer DPIAs than a large enterprise), but the legal requirements apply to all.

Our business is outside Saudi Arabia. Do we need to comply?

If you process personal data of individuals residing in Saudi Arabia — regardless of where your business is incorporated or operated — you are in scope of the PDPL. This includes foreign companies with Saudi customers or employees, international platforms accessible to Saudi users, and overseas headquarters processing data sent from a Saudi subsidiary.

Can we rely on our GDPR programme for PDPL compliance?

Partially. A GDPR programme provides an excellent foundation — the principles, concepts, and many procedural requirements are similar. However, a gap analysis is essential because there are meaningful divergences: the PDPL's default reliance on consent, the prohibition on legitimate interests for sensitive data, the broader extraterritorial scope, and the Saudi SCC requirement for cross-border transfers, among others. A gap analysis followed by targeted remediation is more efficient than building from scratch.

Does all personal data need to be stored in Saudi Arabia?

No — there is no blanket data localisation requirement under the PDPL. Cross-border transfers are permitted when the appropriate conditions and safeguards are met. However, certain sector-specific regulators (SAMA for financial data, CST for telecommunications data) impose localisation requirements that override the PDPL's permissive transfer framework for data in their respective sectors.

How quickly must we respond to a data subject access request?

Within 30 days of receiving the request. Unlike the GDPR, there is no formal mechanism to extend this period for complex requests, and you cannot charge a fee for any data subject request — even one you consider excessive. You may reject unfounded requests but must provide written justification and inform the individual of their right to complain to SDAIA.

What is the difference between a data controller and a data processor under the PDPL?

A controller determines the purposes and means of processing — they are the decision-maker. A processor handles data solely on the controller's instructions. Most businesses operating in Saudi Arabia will be controllers with respect to their customer and employee data. If you use a payroll platform, cloud storage provider, or CRM vendor, those vendors are typically processors on your behalf — and you must have written DPAs with each of them.

When will SDAIA publish an adequacy list for cross-border transfers?

As of early 2025, SDAIA has not published an official adequacy list. The expectation is that SDAIA will adopt an approach broadly similar to the EU's adequacy framework. In the meantime, organisations must rely on Saudi SCCs, BCRs, or other permitted safeguards for transfers to non-adequate countries. This situation may evolve during 2025 — organisations should monitor SDAIA's National Data Governance Platform for announcements.

Is the PDPL the only law we need to consider for data privacy in Saudi Arabia?

No. The PDPL is the primary framework but it operates alongside the Anti-Cyber Crime Law, Electronic Commerce Law, Electronic Transactions Law, and sector-specific frameworks from SAMA, CST, and the NCA. For most businesses the PDPL will be the dominant compliance obligation, but organisations in regulated sectors — banking, healthcare, telecom — must ensure alignment with all applicable frameworks simultaneously.