Lesson 14: Saudi Personal Data Protection Law (PDPL) — A Practical Guide

What You Will Learn in This Lesson

• The scope, definitions, and core principles of Saudi Arabia's Personal Data Protection Law (PDPL)
• Data subject rights and how financial institutions must honor them operationally
• Practical steps to build a PDPL compliance program from scratch
• How PDPL intersects with SAMA CSCC, NCA ECC, and PCI-DSS requirements you may already meet

Why PDPL Changes Everything for Saudi Financial Institutions

Before September 2023, Saudi Arabia had no comprehensive personal data protection statute. Organizations processed customer data under a patchwork of sector-specific rules — SAMA's instructions on confidentiality, NCA's data-related controls, and internal policies that varied wildly between institutions. The Personal Data Protection Law (PDPL), enacted by Royal Decree M/19 and enforced by the Saudi Data and Artificial Intelligence Authority (SDAIA), replaced that patchwork with a single, enforceable framework that applies to every entity processing personal data inside the Kingdom — or processing the data of Saudi residents from abroad.

If your institution handles customer names, national IDs (Absher data), financial transactions, credit scores, biometric data for branch access, or even IP addresses from your mobile banking app, PDPL applies to you. The compliance grace period has ended, and SDAIA has begun conducting audits. Penalties reach up to SAR 5 million per violation, with the possibility of doubling for repeat offenses — and that is before considering reputational damage in a market where trust is currency.

Core Definitions You Must Know

PDPL introduces terminology that your legal, IT, and business teams all need to speak fluently. Personal Data means any data that identifies a natural person or makes them identifiable — directly (name, ID number) or indirectly (location data, device fingerprint). Sensitive Personal Data gets elevated protection: this covers health records, genetic and biometric data, ethnic origin, political or religious beliefs, criminal records, and credit information. For a bank, credit data alone puts a massive portion of your databases into the "sensitive" category.

The Data Controller is the entity that determines why and how personal data is processed — typically your institution. The Data Processor is any third party processing data on your behalf: your cloud provider, your outsourced call center, your fraud analytics vendor. PDPL holds the controller ultimately accountable, even when the processor causes the breach. This is why your vendor contracts need revisiting.

The Six Lawful Bases for Processing

PDPL requires that every processing activity rests on at least one lawful basis. The six bases are: (1) Consent of the data subject — which must be explicit, informed, and freely given; (2) Contract performance — processing necessary to fulfill a contract with the data subject, such as opening a bank account; (3) Legal obligation — processing required by Saudi law, like anti-money laundering reporting to SAMA; (4) Vital interests — protecting someone's life, which is rare in financial services; (5) Public interest — processing for a task carried out in the public interest; and (6) Legitimate interest — processing necessary for a legitimate interest of the controller, provided it does not override the rights of the data subject.

Practical Example: A Saudi bank collects a customer's national ID, income details, and employment history to process a personal loan application. The lawful basis here is contract performance — the bank cannot evaluate or issue the loan without this data. However, if the same bank wants to share that customer's spending patterns with a marketing partner for targeted advertising, the basis shifts to consent — and the customer must opt in explicitly, not through a pre-ticked checkbox buried in 40 pages of terms and conditions.

Data Subject Rights — What Your Systems Must Support

PDPL grants individuals a set of enforceable rights that your institution must be able to honor within defined timeframes. These are not aspirational — they are operational requirements that demand technical capabilities.

Right to Access: Customers can request a copy of all personal data you hold about them. Your systems must be able to locate, extract, and compile data from every database, data warehouse, CRM, and backup where that customer's data resides. For a typical bank, this means querying core banking, card management, mobile app logs, call center recordings, and possibly archived tapes.

Right to Correction: If a customer identifies inaccurate data, you must correct it — and propagate that correction across all systems and any third parties you shared the data with.

Right to Deletion: Customers can request deletion of their data when it is no longer necessary for the original purpose. However, this right is not absolute — regulatory retention requirements under SAMA and the Anti-Money Laundering Law override it. You need a clear retention schedule that maps each data category to its legal hold period.

Right to Data Portability: Upon request, you must provide personal data in a structured, machine-readable format. This means CSV or JSON exports, not scanned PDFs of printed reports.

Right to Object: Data subjects can object to processing based on legitimate interest or direct marketing. Your marketing systems need a robust opt-out mechanism that takes effect immediately.

Building Your PDPL Compliance Program — A 7-Step Roadmap

Compliance is not a one-time project — it is a capability you build and maintain. Here is a practical roadmap tailored for financial institutions:

Step 1: Data Discovery and Mapping. You cannot protect what you do not know exists. Conduct a comprehensive data inventory across all business units. For each data element, document: what it is, where it is stored, why it is collected, who accesses it, who it is shared with, and how long it is retained. Tools like OneTrust, BigID, or even a well-structured spreadsheet can serve this purpose.

Step 2: Legal Basis Assessment. For every processing activity identified in Step 1, assign a lawful basis. Where consent is required, audit your current consent mechanisms — are they explicit, granular, and documented? Replace blanket consent forms with purpose-specific ones.

Step 3: Privacy Impact Assessments (PIAs). PDPL requires PIAs for high-risk processing activities — which includes most things banks do with sensitive data. Build a PIA template and integrate it into your project management process so that every new system, product, or vendor engagement triggers an assessment before launch.

Step 4: Update Vendor Contracts. Review every contract with a data processor. Insert PDPL-compliant data processing agreements (DPAs) that specify: scope of processing, security obligations, sub-processor approval rights, breach notification timelines, audit rights, and data return/deletion upon contract termination.

Step 5: Implement Data Subject Request (DSR) Workflows. Build or configure a system to receive, verify, track, and fulfill data subject requests within the legally mandated response window. Assign clear ownership — typically your Data Protection Officer (DPO) or compliance team — and establish escalation paths for complex requests.

Step 6: Breach Notification Procedures. PDPL requires notification to SDAIA and affected data subjects when a breach is likely to cause harm. Define what constitutes a reportable breach, set up internal escalation within 24 hours of detection, and prepare template notifications in both Arabic and English. Align this with your existing SAMA incident reporting obligations to avoid duplicating effort.

Step 7: Training and Awareness. Every employee who touches personal data — from tellers to developers to executives — needs role-appropriate PDPL training. Conduct it annually, track completion, and test retention. Your front-line staff are both your greatest risk and your first line of defense.

How PDPL Intersects With Your Existing Compliance Obligations

If you have already been working on SAMA CSCC and NCA ECC compliance, you are not starting from zero. SAMA CSCC Domain 3 (Information Asset Management) requires data classification and handling procedures — this directly supports your PDPL data mapping. NCA ECC controls around data protection (specifically the Data Governance and Privacy subcategory) overlap significantly with PDPL's security requirements. PCI-DSS, which you already comply with for card data, enforces many of the same technical controls — encryption, access restrictions, logging — that PDPL demands for all personal data, not just cardholder data.

The key difference is scope: SAMA and PCI focus on financial and card data respectively, while PDPL covers all personal data. Your employee HR records, CCTV footage of branch visitors, and vendor contact databases all fall under PDPL even if they never touched a SAMA audit. The smart approach is to extend the controls and governance structures you already have rather than building a parallel compliance silo.

Common Mistakes to Avoid

• Treating PDPL as a legal-only project: Compliance requires changes to IT systems, business processes, vendor contracts, and employee behavior. If your legal team writes a privacy policy but nobody modifies the CRM to handle deletion requests, you are exposed. Build a cross-functional team from day one.
• Relying on blanket consent: A single "I agree to everything" checkbox at account opening does not meet PDPL's requirement for specific, informed consent. Each processing purpose needs its own consent mechanism, and customers must be able to withdraw consent as easily as they gave it.
• Ignoring cross-border data transfers: If your data flows to cloud servers outside Saudi Arabia, to a regional headquarters in the UAE, or to a vendor in India, PDPL's cross-border transfer rules apply. You need either an adequacy determination from SDAIA, appropriate safeguards (binding corporate rules, standard contractual clauses), or explicit consent from the data subject. Many institutions discover these flows only during an audit — by then it is too late.

Lesson Summary

• PDPL applies to every entity processing personal data in Saudi Arabia, with penalties up to SAR 5 million per violation — financial institutions handle massive volumes of sensitive personal data and face outsized exposure.
• Compliance requires a structured program: data mapping, legal basis assessment, PIAs, vendor contract updates, DSR workflows, breach notification procedures, and ongoing training.
• Leverage your existing SAMA CSCC, NCA ECC, and PCI-DSS controls as a foundation — extend them to cover all personal data, not just financial or card data, and close the gaps in areas like consent management and data subject rights.

Next Lesson

In the next lesson we will cover: PCI-DSS v4.0 — New Requirements for the Payments Sector — a deep dive into the latest PCI standard, what changed from v3.2.1, the new requirements for customized approaches, and a practical transition timeline for Saudi payment processors and banks.

Ready to apply these concepts in your organization? Contact Fyntralink for a complimentary SAMA Cyber Maturity Assessment and a PDPL gap analysis tailored to your institution.