Frequently Asked Questions
Find answers to your questions about cybersecurity and the CISO Consulting platform
PDPL & Privacy 65
The Saudi Personal Data Protection Law (PDPL) was enacted by Royal Decree in September 2021 and officially entered into enforcement in September 2023 after a two-year transition period. Amendments were introduced in 2023 to align with global data protection best practices.
Under PDPL, organizations must: (1) Obtain explicit consent before collecting personal data; (2) Specify and limit the purpose of collection; (3) Implement appropriate security controls; (4) Honor data subject rights (access, correction, deletion, objection); (5) Report breaches within 72 hours to SDAIA; (6) Appoint a Data Protection Officer if processing large volumes; (7) Restrict cross-border data transfers.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data and AI Authority (SDAIA), grants individuals a comprehensive set of rights over their personal data. For financial institutions—which process particularly sensitive categories such as financial records, national IDs, and biometric data—meeting these obligations requires both legal and technical readiness.
Key Data Subject Rights Under PDPL (Arts. 4–9):
- Right to Access: Individuals can request a copy of their personal data. Institutions must respond within a defined timeframe (typically 30 days).
- Right to Correction: Inaccurate or incomplete data must be corrected upon request.
- Right to Erasure: Data must be deleted when no longer necessary, subject to legal retention obligations (e.g., SAMA requires transaction records retained for 10 years).
- Right to Object: Individuals may object to processing for direct marketing or profiling purposes.
- Right to Data Portability: Emerging obligation requiring data to be provided in a structured, machine-readable format.
Technical Controls Required:
- Data Discovery & Mapping: Maintain an up-to-date Record of Processing Activities (RoPA) identifying where personal data resides across systems.
- Access Request Workflows: Implement automated Subject Access Request (SAR) handling within your GRC or DPM platform to track requests, deadlines, and responses.
- Consent Management: Deploy consent management platforms to record and honour withdrawal of consent in near real-time.
- Data Masking & Deletion Pipelines: Build automated pseudonymisation and secure deletion workflows, ensuring deletion is propagated across backup systems.
- Audit Trails: Maintain immutable logs of all data processing activities to demonstrate accountability to SDAIA during audits.
Note: Regulatory retention requirements under SAMA CSF and AML/CFT rules may create legitimate grounds to decline erasure requests—document these exceptions explicitly in your privacy notices and internal policies.
Under Saudi Arabia's Personal Data Protection Law (PDPL) and its Executive Regulations, data breaches triggering notification obligations are those that result in — or are likely to result in — harm to data subjects. Here is a structured response framework for fintechs:
Step 1 — Breach Detection and Internal Escalation (0–24 hours): Activate your Incident Response Plan (IRP). Assign a breach response lead (typically the DPO or CISO). Preserve evidence, isolate affected systems, and begin preliminary impact assessment: How many records affected? What categories of personal data? (financial details, national IDs, biometrics carry higher risk weighting.)
Step 2 — Regulatory Notification to SDAIA (Within 72 Hours): Per PDPL Article 24 and the Executive Regulations, you must notify the Saudi Data & AI Authority (SDAIA) within 72 hours of becoming aware of a breach that poses risk of harm. Your notification must include: nature of the breach, categories and approximate number of affected individuals, likely consequences, and measures taken or planned.
Step 3 — Data Subject Notification: If the breach is likely to cause direct harm to individuals (identity theft, financial fraud risk, reputational damage), you must notify affected data subjects without undue delay. The notification should explain what happened, what data was exposed, and what steps individuals can take to protect themselves.
Step 4 — Documentation and Post-Incident Review: PDPL requires maintaining a breach register documenting all incidents regardless of notification threshold. Conduct a post-incident review aligned with ISO 27001 Clause 10.1 and update your risk register and controls accordingly.
Key consideration for fintechs: If your platform processes payment data, you also have parallel notification obligations under SAMA CSF Incident Management controls and potentially PCI-DSS breach notification requirements. Coordinate these notifications carefully to avoid conflicting communications.
The Saudi Personal Data Protection Law (PDPL) grants individuals a set of enforceable rights over their personal data, and fintechs — given the volume of sensitive financial and identity data they process — must establish robust, documented processes to handle these requests effectively.
Key Data Subject Rights under PDPL:
- Right to Access: Individuals can request a copy of their personal data and information about how it is being processed.
- Right to Correction: Inaccurate or incomplete data must be corrected upon request.
- Right to Erasure: Data subjects can request deletion of their data when it is no longer needed or consent is withdrawn (subject to legal retention obligations).
- Right to Data Portability: Where applicable, data must be provided in a structured, machine-readable format.
- Right to Object: Individuals can object to certain types of processing, including direct marketing.
Operational Requirements:
- Establish a dedicated intake channel (e.g., a privacy portal or email) clearly communicated in your privacy notice.
- Define an internal SLA — PDPL requires responses within 30 days, with the possibility of a single extension.
- Implement an identity verification step before disclosing any personal data.
- Maintain a request log for audit purposes — ZATCA and the National Data Management Office (NDMO) may audit your compliance posture.
- Train customer service and security teams on how to recognize and escalate DSRs.
Intersection with Financial Regulations: Note that some erasure requests may conflict with SAMA's mandatory record retention requirements (typically 10 years). Fintechs must balance PDPL obligations with SAMA CSF and AML record-keeping rules, documenting the legal basis for retention overrides.
Saudi fintechs operating mobile applications that collect and process customer financial data face specific obligations under the Personal Data Protection Law (PDPL) and its Implementing Regulations. Here is a practical compliance breakdown:
1. Lawful Basis for Processing: Under PDPL Article 6, processing personal financial data requires a valid legal basis — typically explicit consent or contractual necessity. Consent must be granular, informed, and freely withdrawable. Pre-ticked boxes or bundled consent are non-compliant.
2. Privacy Notice Requirements: PDPL Article 11 mandates a clear, accessible privacy notice within the app, disclosed at the point of data collection. It must specify: categories of data collected, processing purposes, retention periods, and data subject rights.
3. Sensitive Financial Data Handling: Financial data — including transaction history, credit scores, and account details — may be classified as sensitive under PDPL. Apply enhanced controls including encryption at rest and in transit, strict access controls, and audit logging per ISO 27001 Annex A.8 controls.
4. Data Minimization: Collect only data strictly necessary for the stated service purpose. Avoid collecting excessive device permissions (e.g., contacts, location) without demonstrable necessity, as SAMA also scrutinizes this under its Open Banking Framework.
5. Data Subject Rights: PDPL grants customers rights to access, correct, and request deletion of their personal data. Fintechs must operationalize these rights within the app UI and back-end systems, with responses delivered within regulatory timeframes (30 days under PDPL Article 15).
6. Data Breach Notification: Per PDPL Article 27, notify the Saudi Data and Artificial Intelligence Authority (SDAIA) within 72 hours of discovering a breach affecting personal data, and notify affected individuals without undue delay.
7. DPO Appointment: Fintechs processing data at scale should appoint a Data Protection Officer (DPO) to oversee compliance, liaise with SDAIA, and maintain the Records of Processing Activities (RoPA).
The Saudi Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), grants individuals a defined set of rights over their personal data. For fintechs processing customer data—including KYC information, transaction histories, and behavioral analytics—building robust request-handling processes is both a legal necessity and a competitive trust signal.
Rights Granted Under PDPL:
- Right to Access (Article 4): Individuals may request confirmation of whether their data is being processed and obtain a copy. Fintechs must respond within a reasonable timeframe (SDAIA guidance suggests 30 days).
- Right to Correction (Article 14): Customers may request correction of inaccurate or incomplete personal data. This is particularly relevant for KYC records and credit-related information.
- Right to Erasure (Article 15): Data subjects may request deletion of their data when the processing purpose is fulfilled or consent is withdrawn—subject to regulatory retention obligations under SAMA and FATF anti-money laundering rules.
- Right to Data Portability: Individuals may request transfer of their data in a structured, readable format.
- Right to Object: Data subjects may object to processing for direct marketing or automated decision-making purposes.
Practical Implementation for Fintechs:
- Establish a dedicated Data Subject Request (DSR) intake channel (web form or in-app)
- Assign ownership to a Data Protection Officer (DPO) or privacy lead
- Build a response workflow with internal SLAs aligned to PDPL timelines
- Document all requests, decisions, and outcomes in a DSR log
- Map tension points where PDPL erasure rights conflict with SAMA/AML data retention mandates, and document your legal basis for retention
Failure to respond to DSRs may attract regulatory scrutiny from SDAIA, including potential fines.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), imposes clear obligations on fintech companies regarding data classification and protection. Under PDPL Articles 5 and 6, organizations must identify all personal data they process, establish a lawful basis for processing, and implement proportionate technical and organizational safeguards.
A practical PDPL-compliant data protection framework for fintechs should include:
1. Data Inventory & Classification: Map all personal data flows across your systems — KYC records, transaction data, biometric identifiers, and credit information fall under general personal data. Health or financial distress information may qualify as sensitive data requiring heightened protection under PDPL Article 23.
2. Technical Controls: Encrypt personal data at rest and in transit (AES-256 and TLS 1.2+ minimum). Implement role-based access controls (RBAC) and data masking for non-production environments. Per NCA ECC Control 2-4, data classification labels must be enforced across storage and transmission systems.
3. Retention & Deletion: PDPL Article 18 mandates that personal data not be retained beyond its stated purpose. Establish automated data lifecycle policies with documented retention schedules.
4. Data Subject Rights: Build workflows to handle access, correction, and deletion requests within the PDPL-mandated timeframes (15 business days for most requests).
Non-compliance can result in fines of up to SAR 5 million, reputational damage, and suspension of operations. Fintechs regulated by SAMA should also cross-reference SAMA's Customer Data Protection guidelines to ensure alignment across both regulatory regimes.
Under Saudi Arabia's Personal Data Protection Law (PDPL) and its Executive Regulations, every processing activity must rest on a clearly identified and documented lawful basis. For fintech companies, this is a foundational compliance obligation that directly affects product design, onboarding flows, and data governance frameworks.
The Six Lawful Bases Under PDPL:
- Consent – Freely given, specific, informed, and unambiguous. Consent must be withdrawable at any time without penalty, and pre-ticked boxes are not valid.
- Contractual Necessity – Processing required to execute or fulfill a contract with the data subject (e.g., processing payment data to complete a transfer).
- Legal Obligation – Processing mandated by Saudi law, such as AML/CFT reporting requirements under SAMA guidelines.
- Vital Interests – Protecting the life or safety of the data subject or others.
- Public Interest – Relevant to licensed fintech activities serving the public.
- Legitimate Interests – Permitted only where the controller's interests do not override the individual's rights; requires a documented balancing test.
Practical Steps for Fintechs:
- Conduct a data mapping exercise to catalog all processing activities, data categories, and purposes.
- Assign a lawful basis to each processing activity in your Records of Processing Activities (RoPA).
- Review customer consent forms and app onboarding flows to ensure consent language meets PDPL Article 5 requirements.
- For sensitive data (financial history, biometrics), explicit consent is required unless a specific legal exemption applies.
- Appoint a Data Protection Officer (DPO) if your processing is large-scale or involves sensitive categories.
Regular review of your lawful bases is essential, especially as product features evolve or new data uses are introduced.
The Saudi Personal Data Protection Law (PDPL) and its Executive Regulations grant individuals a suite of enforceable rights over their personal data, and fintech companies must establish formal processes to manage these requests. Here is a compliance-focused breakdown:
Core Data Subject Rights Under PDPL:
- Right to Access (Article 4): Individuals can request a copy of their personal data held by the organization
- Right to Correction: Request correction of inaccurate or incomplete data
- Right to Erasure: Request deletion of data when processing is no longer justified
- Right to Data Portability: Receive data in a structured, usable format
- Right to Withdraw Consent: Where consent is the legal basis for processing
- Right to Object: Object to processing in certain circumstances
Response Timelines: The PDPL Executive Regulations require organizations to respond to data subject requests within 30 days. Complex requests may be extended, but the individual must be notified of the delay and the reason.
Practical Implementation Steps:
- Create a dedicated, accessible channel for submitting rights requests (web form, email, in-app)
- Establish an internal intake and routing workflow with clear ownership
- Verify the identity of the requester before disclosure
- Maintain a request log for audit purposes — PDPL enforcement by SDAIA/NCA may include reviewing request handling records
- Train customer-facing and HR teams on identifying and escalating rights requests
Penalties for Non-Compliance: Failure to honor data subject rights can result in fines up to SAR 1 million under PDPL, with higher penalties for aggravated violations.
Fintechs handling large volumes of customer data should automate this process through their GRC or privacy management platform to ensure consistent, timely responses.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), imposes specific obligations on fintechs operating mobile banking or payment applications. Non-compliance can result in fines of up to SAR 5 million and reputational damage under regulatory scrutiny from both SDAIA and SAMA.
Core PDPL Obligations for Mobile App Data Collection:
- Lawful Basis (Article 7): Every data processing activity must have a valid legal basis — typically explicit consent, contractual necessity, or a legal obligation. For mobile apps, consent must be granular, meaning users must be able to consent separately to different processing purposes (e.g., analytics vs. service delivery).
- Privacy Notice (Article 11): A clear, accessible privacy notice must be presented before or at the point of data collection. This must state the types of data collected, purposes, retention periods, and data subject rights in plain Arabic.
- Data Minimization: Collect only what is strictly necessary for the stated purpose. Avoid requesting excessive device permissions (contacts, location, microphone) unless technically justified and disclosed.
- Data Subject Rights (Articles 14–18): Users must be able to access, correct, request deletion of, and withdraw consent from their data. Your app must have a functioning mechanism (in-app or portal) to handle these requests within the PDPL-mandated timeframes.
- Data Retention: Define and enforce retention schedules. Personal data must not be retained beyond its legitimate processing purpose.
- Cross-Border Transfers (Article 29): If the app uses overseas cloud infrastructure or analytics services, ensure an adequate protection level or a Data Transfer Agreement is in place per PDPL requirements.
SAMA Intersection: SAMA CSF Control 3.1.4 requires financial institutions to classify and protect customer personal data, directly reinforcing PDPL obligations. Fintechs should align their Privacy Impact Assessments (PIAs) with both frameworks simultaneously.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), provides a specific and elevated category of protection for 'sensitive personal data.' Understanding this classification is critical for financial institutions handling customer information.
PDPL Definition of Sensitive Data (Article 2 & 23): Sensitive personal data includes: ethnic or racial origin, religious or political beliefs, criminal records, health and medical data, biometric data, credit and financial data revealing personal financial situations, and location data that could harm the individual if disclosed.
For Saudi banks and fintechs, this means customer credit scores, account balances when linked to identifiable individuals, biometric authentication data (fingerprints, facial recognition), and health-related insurance data all qualify as sensitive.
Additional Safeguards Required:
- Explicit Consent: Unlike regular personal data, sensitive data requires explicit, informed consent per PDPL Article 23 — implied or bundled consent is insufficient.
- Data Minimization: Collect only what is strictly necessary for the defined purpose; avoid retaining sensitive data beyond operational need.
- Encryption at Rest and in Transit: Apply strong encryption (AES-256 minimum) for all sensitive data storage and transmission, aligned with NCA ECC-2-14 data protection controls.
- Access Restrictions: Limit access to sensitive data to authorized personnel only, with full audit trails maintained.
- Data Protection Impact Assessment (DPIA): Conduct a DPIA before processing sensitive data at scale, especially for AI-driven credit scoring or biometric onboarding systems.
- Cross-Border Transfer Controls: Sensitive data transfers outside the Kingdom require SDAIA approval or adequacy assessment under PDPL Article 29.
Practical Tip: Map all sensitive data flows in your institution's data inventory and tag them distinctly in your Data Classification Policy to trigger enhanced controls automatically.
Cross-border data transfers are one of the most operationally complex PDPL obligations for Saudi financial institutions, especially those with international correspondent banking relationships, global cloud providers, or offshore IT operations.
PDPL Baseline Requirements: Under PDPL Article 29, transferring personal data outside the Kingdom is only permitted if adequate protection is ensured in the destination country — equivalent to PDPL standards — and one of the following conditions is met:
- The transfer serves a public interest or fulfils a legal obligation.
- The transfer is necessary to protect the vital interests of the data subject.
- The data subject has given explicit, informed consent.
- A Data Transfer Agreement (DTA) is in place, approved by the competent authority (SDAIA).
For Financial Institutions Specifically: SAMA CSF Control 3.3.8 adds a further layer: customer financial data is considered critical and subject to data localization requirements. This means even if PDPL permits a transfer, SAMA may require the primary copy of financial data to remain within the Kingdom.
Practical Compliance Steps:
- Conduct a Data Transfer Impact Assessment (DTIA) for each cross-border data flow — map the data type, volume, destination country, legal basis, and protective measures.
- Establish SCCs (Standard Contractual Clauses) or equivalent DTAs with all international recipients.
- Implement technical safeguards: encryption in transit (TLS 1.2+), data minimization, and pseudonymization where feasible.
- Maintain a Register of International Transfers updated quarterly and available for SDAIA inspection.
- For cloud providers, explicitly verify data residency guarantees and include contractual audit rights.
Key Risk: SDAIA can impose fines up to SAR 5 million for unlawful data transfers. Financial institutions should treat this as a board-level compliance risk, not just an IT issue.
Data retention and secure disposal represent a critical compliance intersection for Saudi financial institutions, governed simultaneously by the Personal Data Protection Law (PDPL), SAMA CSF, and applicable SAMA circulars on records management.
PDPL Retention Obligations: Under PDPL Article 18, personal data must not be retained beyond the period necessary for the purpose for which it was collected, unless a legitimate legal basis exists for extended retention. Financial institutions typically rely on regulatory and legal obligations as their retention justification. Upon expiry of the retention period, data must be permanently deleted or anonymized in a manner that prevents re-identification.
SAMA CSF Requirements: SAMA CSF Control 3.3.6 (Data and Information Management) requires institutions to establish and enforce a formal Data Retention Policy that defines retention periods by data category, aligns with regulatory minimums, and mandates secure disposal procedures. SAMA circulars generally require financial records to be retained for a minimum of 10 years.
Secure Disposal Standards: For digital media, SAMA CSF requires data sanitization methods compliant with recognized standards such as NIST SP 800-88 (Clear, Purge, or Destroy methods depending on data sensitivity). Physical media destruction must be documented with chain-of-custody records.
Practical Implementation Steps:
- Develop a Data Retention Schedule mapping each data category to its retention period and legal basis
- Implement automated data lifecycle management tools to trigger deletion workflows
- Maintain a Disposal Certificate log for auditor evidence
- Conduct annual reviews of the retention schedule as regulations evolve
- Ensure third-party processors contractually commit to equivalent disposal standards per PDPL Article 15
Failure to comply with PDPL disposal requirements can result in fines of up to SAR 5 million, while SAMA supervisory findings may trigger remediation orders.
Using customer personal data for marketing and personalization is one of the highest-risk processing activities under Saudi Arabia's Personal Data Protection Law (PDPL) and its Executive Regulations. Financial institutions must navigate this carefully.
Legal Basis for Processing (PDPL Article 5) Marketing and personalization generally cannot rely on contractual necessity. Institutions must obtain free, informed, and specific consent from customers. Pre-ticked boxes or bundled consent within T&Cs are non-compliant. Consent must be documented and easily withdrawable.
Data Minimization & Purpose Limitation (PDPL Article 9) Only collect data strictly necessary for the declared marketing purpose. Using transaction data collected for fraud detection to build marketing profiles violates purpose limitation principles unless customers are explicitly informed and consent obtained separately.
Right to Opt-Out (PDPL Article 11) Customers have the right to withdraw consent and object to direct marketing at any time. Financial institutions must implement a functional opt-out mechanism within their apps, websites, and call centers, with processing stopped within a reasonable timeframe — best practice is 5 business days.
Cross-Border Data Transfers (PDPL Article 29) If personalization engines or marketing platforms are hosted outside Saudi Arabia, a Data Transfer Impact Assessment (DTIA) is required, and transfers must only proceed to jurisdictions with adequate protection levels as determined by SDAIA.
Practical Controls:
- Implement a Consent Management Platform (CMP) integrated with your CRM.
- Conduct a Data Processing Impact Assessment (DPIA) for high-risk profiling activities.
- Maintain a Record of Processing Activities (ROPA) documenting lawful basis per PDPL Article 14.
- Train marketing teams on PDPL obligations annually.
Non-compliance can result in fines up to SAR 5 million under PDPL enforcement provisions.
Under Saudi Arabia's Personal Data Protection Law (PDPL), financial institutions face strict obligations around data residency and cross-border transfers that intersect with SAMA CSF and NCA ECC requirements.
Data Residency: PDPL Article 29 mandates that personal data collected within the Kingdom must generally be stored and processed on Saudi soil. SAMA CSF Control 3.3.5 reinforces this by requiring that critical financial data remain within SAMA-supervised infrastructure unless an explicit exception is granted.
Cross-Border Transfers: Any transfer of personal data outside Saudi Arabia requires one of the following conditions to be met:
- The transfer serves a legitimate public interest or is necessary to fulfill a contractual obligation
- The receiving country provides an adequate level of data protection as assessed by the Saudi Data & AI Authority (SDAIA)
- Explicit, informed consent is obtained from the data subject
- Binding contractual clauses or standard data protection agreements are in place with the recipient entity
Practical Steps for Compliance:
- Conduct a data mapping exercise to identify all personal data flows, including those to cloud providers and third-party processors
- Review vendor contracts to ensure Data Processing Agreements (DPAs) are in place per PDPL Article 32
- Implement technical controls such as data encryption in transit and at rest, and tokenization for sensitive financial identifiers
- Register cross-border transfer activities with SDAIA where required
- Align your data governance policy with NCA ECC Art. 2-1 controls on asset classification
Non-compliance can result in fines up to SAR 5 million, reputational damage, and regulatory sanctions from both SDAIA and SAMA. Institutions should conduct an annual PDPL gap assessment as part of their GRC program.
Saudi financial institutions handling customer personal data must comply with the Personal Data Protection Law (PDPL) issued under Royal Decree M/19 and its implementing regulations. Key obligations include: (1) Lawful Basis for Processing — you must establish a legitimate purpose before collecting data, such as contractual necessity or explicit consent; (2) Data Minimization — collect only what is strictly necessary for the defined purpose, avoiding excessive data retention; (3) Transparency & Notice — inform customers clearly about what data is collected, how it is used, retention periods, and their rights before or at the point of collection; (4) Data Subject Rights — honor requests for access, correction, and deletion within regulatory timelines, typically 30 days; (5) Cross-Border Transfers — transfers outside Saudi Arabia require SDAIA approval or must meet adequacy conditions, a critical control for banks using global cloud or SaaS providers; (6) Data Breach Notification — notify SDAIA and affected individuals without undue delay upon discovering a personal data breach; and (7) Data Protection Impact Assessments (DPIAs) — mandatory for high-risk processing activities, including profiling, credit scoring, or large-scale sensitive data processing. Practically, CISOs should map all personal data flows, maintain a Records of Processing Activities (RoPA) register, and embed privacy-by-design principles into product development and IT projects. Fintechs operating under SAMA's regulatory sandbox must simultaneously satisfy PDPL requirements alongside SAMA CSF's data protection controls (Domain 3), making integrated compliance planning essential rather than treating PDPL and SAMA CSF as separate workstreams.
Using customer personal data in AI/ML models for credit scoring or fraud detection creates significant obligations under Saudi Arabia's Personal Data Protection Law (PDPL) and its Executive Regulations. Here is what fintech compliance officers must address: 1. Lawful Basis for Processing: Under PDPL Article 7, processing personal data for credit scoring requires either explicit consent or a legitimate interest justification. Automated decision-making that significantly affects individuals (e.g., loan rejection) typically requires explicit consent and must be disclosed in the privacy notice. 2. Data Minimization & Purpose Limitation: PDPL Article 9 requires that only data strictly necessary for the stated purpose is collected. Fintechs must document which data fields feed their AI models and justify each one — regulators may scrutinize over-collection. 3. Automated Decision-Making Transparency: Customers have the right to be informed when a decision is made solely by automated means and to request human review. Your privacy notice must explicitly disclose AI-based decisioning per PDPL Article 13. 4. Data Retention: Model training datasets must comply with PDPL retention limits. Personal data should be anonymized or pseudonymized once it is no longer needed for its original purpose — retaining raw PII indefinitely for model retraining is non-compliant. 5. SAMA Intersection: SAMA's Open Banking Framework and consumer protection guidelines add requirements around consent management and data sharing with third-party AI vendors. Conduct a Data Protection Impact Assessment (DPIA) before deploying any new AI model that processes personal data at scale. 6. SDAIA Oversight: The Saudi Data & AI Authority (SDAIA) oversees PDPL enforcement; fintechs should align their AI governance policies with SDAIA's published guidelines on responsible AI.
Saudi Arabia's Personal Data Protection Law (PDPL), issued by Royal Decree M/19, establishes a distinct category of 'sensitive personal data' that attracts heightened regulatory obligations. Under Article 2 of the PDPL and further elaborated in the Implementing Regulations, sensitive personal data includes: genetic and biometric data, health and medical information, financial data revealing credit status, criminal records, ethnic or racial origin, religious beliefs, and political opinions.
For Saudi banks and fintechs, financial data — including credit scores, account details, and transaction histories — is explicitly classified as sensitive. This triggers the following additional obligations:
1. Explicit Consent: Processing sensitive data requires clear, specific, and informed consent (Article 5), which cannot be bundled with general terms and conditions.
2. Purpose Limitation: Data may only be used for the purpose explicitly stated at collection. Secondary use without fresh consent is prohibited.
3. Data Protection Impact Assessments (DPIAs): High-risk processing activities involving sensitive data require a formal DPIA before processing begins.
4. Cross-Border Transfer Restrictions: Transferring sensitive data outside Saudi Arabia requires SDAIA approval or must meet adequacy conditions under Article 29 of the PDPL.
5. Breach Notification: Data breaches involving sensitive personal data must be reported to SDAIA within 72 hours of discovery.
6. Retention Limits: Sensitive data must not be retained beyond the period necessary for the stated purpose, with secure deletion protocols in place.
Our platform maps PDPL obligations directly to your data processing activities, automates DPIA workflows, and provides breach notification templates — ensuring your institution meets PDPL requirements alongside SAMA CSF data protection controls.
The Saudi Personal Data Protection Law (PDPL) and its implementing regulations impose clear obligations on financial institutions regarding how long personal data may be retained and the manner in which it must be securely deleted once retention purposes are fulfilled. This is particularly complex for banks and fintechs that must simultaneously satisfy PDPL requirements alongside data retention mandates from SAMA, SOCPA, and FATF anti-money laundering guidelines.
Core PDPL Obligations: Under PDPL Article 18, personal data must not be retained beyond the period necessary to achieve the original processing purpose. Once that purpose expires, data must be anonymized or securely destroyed. Data subjects also hold the right to request deletion under PDPL Article 12, subject to legitimate exceptions.
Balancing Conflicting Retention Requirements: SAMA regulations and AML/CFT obligations typically mandate retention of customer transaction records and KYC data for a minimum of 10 years. Institutions must document the legal basis for extended retention in their data inventory and Records of Processing Activities (RoPA), clearly identifying which data is retained under a legal obligation versus consent.
Practical Implementation Steps:
- Conduct a comprehensive data mapping exercise to identify all personal data categories, storage locations, and current retention periods.
- Establish a Data Retention Schedule that maps each data category to its legal basis and maximum retention period.
- Implement automated deletion or anonymization workflows within core banking systems, CRMs, and data warehouses.
- Ensure third-party processors (cloud providers, analytics vendors) are contractually bound to equivalent deletion obligations per PDPL Article 29.
- Log all deletion activities for audit trail purposes.
- Review and update the retention schedule annually or when regulatory requirements change.
Appointing a Data Protection Officer (DPO) — or engaging a vCISO with PDPL expertise — is strongly recommended to oversee policy compliance.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO), imposes significant obligations on fintech companies processing personal data of Saudi residents. Non-compliance can result in fines up to SAR 5 million and reputational damage.
Core PDPL Obligations for Fintechs:
- Lawful Basis for Processing: Under PDPL Article 5, you must establish a lawful basis before processing personal data. For fintechs, this is typically contractual necessity (onboarding, KYC) or explicit consent for marketing purposes.
- Privacy Notice: Article 11 requires a clear, plain-language privacy notice informing customers what data is collected, why, how long it's retained, and whether it's shared with third parties (e.g., credit bureaus, SAMA-regulated entities).
- Data Subject Rights: Articles 13–18 grant customers rights to access, correct, and request deletion of their data. Fintechs must establish workflows to respond within 30 days.
- Cross-Border Data Transfers: Article 29 restricts transferring personal data outside Saudi Arabia unless the destination country provides adequate protection or NDMO approval is obtained — critical for fintechs using global cloud providers.
- Data Breach Notification: Article 20 requires notifying NDMO of personal data breaches within 72 hours of discovery if the breach poses risk to data subjects.
Practical Compliance Steps:
- Appoint a Data Protection Officer (DPO) or assign DPO responsibilities to your compliance function.
- Conduct a Data Mapping exercise to inventory all personal data flows across your platform.
- Implement Privacy by Design principles in product development cycles.
- Review all third-party data processing agreements (DPAs) to ensure PDPL-compliant clauses.
- Align your PDPL program with ISO 27701 for a structured privacy management framework recognized by regulators.
Data classification is a foundational control required under both the Saudi Personal Data Protection Law (PDPL) and SAMA CSF, and getting it right is critical for Saudi banks and fintechs managing vast volumes of customer financial and personal data.
SAMA CSF Requirements (Control Domain 3.6 — Data and Information Asset Management):
- Establish a formal data classification policy with defined sensitivity tiers (e.g., Public, Internal, Confidential, Restricted).
- Assign data ownership accountability to specific business units.
- Implement controls proportional to classification level: encryption, access restrictions, masking, and data loss prevention (DLP) tools.
- Per SAMA CSF Control 3.6.3, financial institutions must maintain a data inventory mapping sensitive data to systems, storage locations, and processing flows.
PDPL Obligations (Articles 5, 9, and 21):
- Personal data must only be collected and processed for a declared, legitimate purpose.
- Sensitive personal data (health, financial, biometric) requires heightened protection and explicit consent or a lawful basis.
- Data must not be retained longer than necessary — institutions must define and enforce data retention schedules.
- Cross-border transfers of personal data require PDPL-compliant safeguards, especially relevant for cloud-hosted platforms.
Practical Implementation Steps:
- Conduct a data discovery and inventory exercise across all systems and cloud environments.
- Apply classification labels using automated tools where possible (e.g., Microsoft Purview).
- Enforce encryption at rest (AES-256) and in transit (TLS 1.2+) for Confidential and Restricted data.
- Implement role-based access control (RBAC) aligned to data classification tiers.
- Document your data processing activities register (DPAR) to satisfy both PDPL audit requirements and SAMA examiner expectations.
Integrating PDPL and SAMA CSF data governance into a unified framework reduces duplication and creates a stronger, audit-ready data protection posture.
Saudi financial institutions must navigate overlapping data governance obligations from both the Personal Data Protection Law (PDPL) and SAMA CSF, making a unified data classification framework essential.
Data Classification Framework:
SAMA CSF Control 3.1.4 requires member organizations to implement a formal data classification policy. Recommended tiers for financial institutions include:
- Confidential/Restricted: Customer PII, financial transaction records, credit data, authentication credentials.
- Internal: Internal policies, employee records, operational procedures.
- Public: Marketing materials, published annual reports.
PDPL Obligations (Articles 5–9): Personal data — defined as any information that directly or indirectly identifies a natural person — must be:
- Collected for a specific, declared purpose.
- Processed only to the extent necessary (data minimization).
- Retained no longer than required for the stated purpose, with documented retention schedules.
- Protected using technical and organizational measures proportionate to the risk.
Practical Implementation Steps:
- Conduct a Data Discovery and Mapping exercise to identify all personal and sensitive financial data across systems (core banking, CRM, data lakes).
- Implement data classification labels (manual or automated via Microsoft Purview or similar tools).
- Define Data Retention and Destruction Schedules aligned with SAMA CSF and PDPL requirements.
- Establish a Data Governance Committee with a designated Data Protection Officer (DPO) or equivalent role.
- Integrate classification outputs into your DLP (Data Loss Prevention) policies and SIEM alert rules.
Note that PDPL violations can attract fines up to SAR 5 million, with potential criminal liability for intentional breaches — making proactive data governance a business-critical priority.
Data classification is the foundational pillar that bridges your SAMA CSF compliance obligations and your PDPL data protection duties. SAMA CSF Domain 3.2 (Information Asset Management) requires all member organizations to establish a formal data classification policy with at least three tiers: Public, Confidential, and Restricted — though most banks adopt a four-tier model adding 'Internal Use' for greater granularity.
For PDPL alignment, your classification framework must specifically tag datasets containing personal data as defined under PDPL Article 2, and flag special-category data (health, financial, biometric) for enhanced controls.
Recommended Classification-to-Control Mapping:
- Restricted / Special-Category Personal Data: End-to-end encryption at rest (AES-256) and in transit (TLS 1.3+), strict need-to-know access, mandatory audit logging, Data Loss Prevention (DLP) rules, and explicit consent documentation per PDPL Article 5.
- Confidential / Personal Data: Role-based access controls, encryption, retention schedules aligned with PDPL Article 18 (data must not be kept beyond its purpose), and annual data inventory reviews.
- Internal / Non-Personal: Standard access controls and basic monitoring.
Practical Steps:
- Conduct a comprehensive data discovery and inventory exercise — automated tools like Varonis or Microsoft Purview can accelerate this.
- Embed classification labels into document management systems and email platforms.
- Map data flows across third parties per SAMA CSF Control 3.2.3 and PDPL's data processor obligations.
- Define retention and disposal schedules and enforce them technically, not just procedurally.
The Saudi Data & AI Authority (SDAIA) and SAMA both expect documented, enforced classification schemes — not just policy documents.
Data Loss Prevention (DLP) sits at the intersection of cybersecurity and privacy compliance, making it doubly important for Saudi financial institutions that must satisfy both SAMA CSF and the Personal Data Protection Law (PDPL). Here is how to approach DLP implementation practically:
Understanding Your Regulatory Obligations SAMA CSF Control 3.2 requires data classification and protection controls proportionate to data sensitivity. PDPL Articles 5, 9, and 14 mandate that personal data be processed lawfully, protected from unauthorized access, and not transferred outside Saudi Arabia without meeting the cross-border transfer conditions.
Step 1 – Data Discovery & Classification Begin with a comprehensive data inventory. Classify all data assets into tiers — public, internal, confidential, and restricted (e.g., customer PII, payment card data, credit records). This classification drives your DLP policy configuration.
Step 2 – DLP Policy Design Configure DLP rules across three key channels: endpoint (laptops, USB), network (email, web uploads), and cloud (SaaS applications like M365, Google Workspace). Policies must block or alert on unauthorized transmission of PII, financial records, or confidential business data.
Step 3 – Integration with IAM & SIEM DLP tools must be integrated with your Identity and Access Management system to apply context-aware policies (e.g., stricter rules for contractors vs. full-time employees) and with your SIEM for real-time incident correlation.
Step 4 – PDPL-Specific Considerations Under PDPL, any DLP alert involving personal data leakage must trigger your privacy incident workflow, with potential notification obligations to the Saudi Data and Artificial Intelligence Authority (SDAIA) and affected individuals.
Step 5 – Ongoing Tuning & Reporting DLP effectiveness must be measured and reported to the CISO quarterly. Tune policies regularly to reduce false positives while maintaining high detection accuracy. Annual DLP audits aligned with ISO 27001 Annex A.8 controls are strongly recommended.
PDPL penalties include: fines up to SAR 5 million for violations of data subject rights or inadequate security controls; fines up to SAR 10 million for unauthorized cross-border data transfer; fines up to SAR 3 million for failure to notify of breaches. Repeat violations can result in doubled fines. Criminal prosecution may apply in cases of deliberate misuse.
Yes. PDPL applies to any entity that processes personal data of individuals residing in Saudi Arabia, regardless of whether the entity is based inside or outside the Kingdom. Foreign companies targeting Saudi consumers or processing data of Saudi residents must comply with PDPL requirements.
Cross-border data transfers are one of the most operationally complex requirements under Saudi Arabia's Personal Data Protection Law (PDPL) and its Implementing Regulations, particularly for fintechs that rely on global cloud providers, payment processors, or overseas analytics platforms.
Legal Basis for Transfer (PDPL Article 29): Transferring personal data outside the Kingdom is prohibited unless one of the following conditions is satisfied:
- The transfer is necessary to fulfill a contractual obligation with the data subject
- The transfer serves a vital interest of the data subject
- The destination country provides an adequate level of data protection as determined by the Saudi Data & AI Authority (SDAIA)
- A binding agreement exists that ensures equivalent protection standards
- Explicit consent has been obtained from the data subject
Practical Controls for Fintechs:
- Data Mapping & Flow Inventory: Document all data flows that cross borders — including API calls to foreign services, backup replication to non-Saudi cloud regions, and third-party analytics tools.
- Transfer Impact Assessment (TIA): Before initiating any cross-border transfer, conduct a TIA to assess the legal framework and security posture of the destination jurisdiction.
- Contractual Safeguards: Implement Data Processing Agreements (DPAs) with international vendors containing clauses that mirror PDPL protections, including breach notification, sub-processor controls, and data deletion rights.
- Localization Strategy: For sensitive financial data categories, consider data residency in Saudi-based cloud regions (e.g., AWS, Azure, or Google Cloud regions in KSA) to minimize transfer exposure.
- Consent Management: Build granular consent mechanisms in your customer onboarding flows for any data that may be processed abroad.
SDIA continues to publish guidance on adequacy decisions, so fintechs should monitor regulatory updates closely and integrate PDPL transfer compliance into their broader ISO 27001 and SAMA CSF programs.
Saudi PDPL (Royal Decree M/19, enforced July 2023) creates important obligations specifically around employee data processing — an area where HR, Legal, and Cybersecurity teams must align closely. Legal bases for processing employee personal data under PDPL include: (1) Contractual necessity — processing required to fulfill the employment contract (payroll, benefits, legal compliance); (2) Legal obligation — processing required by Saudi labor law, GOSI, HRDF, or regulatory reporting mandates; (3) Legitimate interest — security monitoring, fraud prevention, and business continuity activities, provided they are proportionate and documented; (4) Explicit consent — required for any processing that goes beyond contractual or legal necessity, particularly for sensitive categories such as biometrics, health data, or financial details beyond compensation. Key practical implications for Security Teams: Employee monitoring programs (endpoint DLP, email monitoring, access logs, CCTV in workplaces) must be disclosed in a transparent privacy notice and must have a documented legal basis. Covert surveillance without a legal basis is a PDPL violation. All employee data transfers outside KSA — including to global HR platforms, cloud tools, or parent company systems — require either an adequacy decision or appropriate safeguards per PDPL transfer rules. For HR teams: Update employment contracts and onboarding documentation to include PDPL-compliant privacy notices. Define and document your data retention schedules for ex-employee records. Employees have the right to access and correct their personal data. Align your HR data governance with ISO 27001 Annex A.6 (Human Resource Security) for a unified compliance posture. PDPL enforcement is overseen by SDAIA — fines reach SAR 5 million for violations.
The Saudi Personal Data Protection Law (PDPL) and its implementing regulations introduce meaningful obligations for fintech companies that deploy AI-driven or automated decision-making systems — such as credit scoring engines, fraud detection models, customer onboarding bots, or behavioral analytics platforms.
Key PDPL Obligations for Automated Processing:
1. Lawful Basis for Processing: Per PDPL Article 8, processing personal data through automated systems requires a valid legal basis — typically contractual necessity, legitimate interest, or explicit consent. For sensitive financial data, consent must be explicit and documented.
2. Transparency & Disclosure: PDPL Article 11 mandates that individuals be informed about the existence of automated decision-making processes that significantly affect them, the logic involved, and the potential consequences. Your privacy notice must clearly describe AI-driven decision systems.
3. Right to Object & Human Review: Individuals have the right to request human review of decisions made solely by automated systems, particularly when such decisions produce legal or similarly significant effects (e.g., loan denial, account suspension). Fintechs must establish a process to handle such requests within the regulatory timeframe.
4. Data Minimization: Only the personal data strictly necessary for the AI model's purpose should be processed. Avoid feeding models with unnecessary sensitive attributes — a principle directly aligned with PDPL Article 14.
5. Data Retention & Deletion: Define and enforce clear retention periods for data used in AI training and inference. Data should not be retained beyond its stated purpose per PDPL Article 18.
6. DPIA Requirement: High-risk processing activities — including large-scale AI profiling of customers — require a Data Protection Impact Assessment (DPIA) before deployment. Document risks and mitigations thoroughly.
Intersection with SAMA CSF: SAMA's customer data protection controls (Domain 3.5) complement PDPL requirements and expect financial institutions to implement technical safeguards around automated processing systems including access controls, audit logs, and explainability mechanisms.
Fintechs should engage their Data Protection Officer (DPO) early in AI product design cycles to ensure privacy-by-design principles are embedded from the outset.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), places direct obligations on fintech companies to implement a structured data classification and protection framework. Non-compliance can result in fines of up to SAR 5 million for first offenses, with doubling for repeat violations.
Step 1 – Data Discovery and Classification: Conduct a thorough data inventory mapping all personal data your platform collects, processes, or stores. Under PDPL Article 6, data must be classified at minimum into: General Personal Data, Sensitive Personal Data (including financial data, health records, biometric data, and national ID numbers), and data of minors.
Step 2 – Lawful Basis Determination: For each data category, establish and document the lawful processing basis per PDPL Article 5 — consent, contractual necessity, legal obligation, or legitimate interest (the latter must be balanced against data subject rights).
Step 3 – Technical and Organizational Controls:
- Encrypt sensitive personal data at rest and in transit (AES-256 and TLS 1.2+ as baseline).
- Implement role-based access controls (RBAC) with least-privilege principles.
- Maintain detailed processing records (PDPL Article 12 requires Record of Processing Activities — ROPA).
- Establish data retention and deletion schedules aligned to PDPL Article 18.
Step 4 – Breach Notification: PDPL Article 19 requires notifying SDAIA within 72 hours of discovering a personal data breach that poses risk to data subjects.
Intersection with SAMA CSF: For licensed fintechs, SAMA CSF Control 3.3.9 (Data and Information Protection) aligns closely with PDPL — a unified data protection policy satisfies both regulators simultaneously.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO), establishes clear obligations around data minimization and retention — principles that fintech companies must embed into both their technical architecture and operational processes.
Under PDPL Article 8, personal data must be collected only to the extent necessary for the declared purpose. Fintechs must avoid over-collection and ensure that data fields captured during onboarding, transactions, or KYC processes are strictly justified by a legitimate business or regulatory need. This requires conducting a Data Protection Impact Assessment (DPIA) for high-risk processing activities before deployment.
For retention, PDPL Article 14 requires that personal data not be retained beyond the period necessary to fulfill the processing purpose. In the fintech context, this intersects with SAMA's AML/CFT retention requirements (typically 10 years for transaction records), creating a layered compliance obligation. CISOs and compliance officers must map retention schedules per data category and align them with both PDPL and applicable financial regulations.
Practical implementation steps include:
- Building a data inventory and classification framework identifying all personal data assets
- Configuring automated data lifecycle policies in storage systems to trigger deletion or anonymization upon retention expiry
- Reviewing API integrations and third-party data processors to ensure downstream data handling aligns with minimization principles
- Documenting lawful retention justifications for each data category in your Record of Processing Activities (RoPA)
- Establishing a periodic review cycle — at least annually — to reassess whether retained data remains necessary
Non-compliance can result in fines up to SAR 5 million under PDPL, making proactive governance essential for Saudi fintechs.
The Saudi Personal Data Protection Law (PDPL) and its implementing regulations impose specific obligations on fintechs deploying AI systems or automated decision-making (ADM) tools that process personal data — an area of rapidly growing regulatory scrutiny.
Lawful Basis for AI Processing: Under PDPL Article 7, any AI system processing personal data must have a clearly identified lawful basis — typically contractual necessity or explicit consent. For credit scoring, fraud detection, or behavioral profiling, consent must be granular, informed, and revocable.
Transparency Requirements: PDPL Article 11 requires that individuals be informed when automated decisions are being made about them, the logic involved, and the potential consequences. Fintechs must provide clear, plain-language disclosures in their privacy notices — not buried in terms and conditions.
Right to Contest Automated Decisions: While Saudi PDPL is still maturing in this area, SDAIA's implementing regulations signal alignment with international standards giving data subjects the right to request human review of decisions made solely by automated means — particularly for loan approvals, account restrictions, or KYC rejections.
Data Minimization & Purpose Limitation: PDPL Articles 9 and 14 prohibit processing more data than necessary or using it for purposes beyond what was disclosed. AI models trained on customer behavioral data must be scoped and governed to prevent purpose creep.
Data Protection Impact Assessment (DPIA): High-risk AI processing — such as biometric data, financial profiling, or large-scale behavioral analysis — requires a DPIA before deployment. This must include risk assessment, mitigation controls, and documentation retained for regulatory review.
SAMA Intersection: SAMA's Open Banking Framework and Consumer Protection Principles further require fintechs to ensure algorithmic fairness and non-discrimination in financial product recommendations.
Our platform provides PDPL-aligned DPIA templates and AI governance checklists tailored for Saudi fintech environments.
Saudi fintechs operating mobile applications that collect and process customer financial data carry significant obligations under the Personal Data Protection Law (PDPL) and its Executive Regulations, enforced by the Saudi Data & AI Authority (SDAIA).
Lawful Basis and Consent (PDPL Article 5–7): Processing personal financial data requires a clear lawful basis — typically explicit, informed consent or contractual necessity. Consent must be granular: users should separately consent to data collection, processing, profiling, and marketing. Pre-ticked boxes or bundled consent clauses are non-compliant.
Transparency and Privacy Notices (PDPL Article 11): Mobile apps must display a clear, accessible Arabic-language privacy notice disclosing: categories of data collected, processing purposes, retention periods, third-party sharing, and user rights. The notice must be presented before or at the point of data collection.
Data Subject Rights (PDPL Article 14–18): Fintechs must operationalize user rights within the app or via a designated channel: the right to access, correct, delete (right to erasure subject to regulatory retention requirements), and withdraw consent. Response timelines must not exceed 30 days per PDPL Executive Regulations.
Data Minimization and Retention: Only data strictly necessary for the stated purpose should be collected. Financial transaction data may have mandatory retention periods under SAMA regulations (typically 10 years), which can override the PDPL erasure right — fintechs must document this conflict resolution in their Records of Processing Activities (RoPA).
Security Controls: PDPL Article 19 requires appropriate technical and organizational safeguards. For financial apps, this includes end-to-end encryption, certificate pinning, secure API authentication (OAuth 2.0/FAPI), and regular DAST/SAST testing of the mobile codebase.
Fintechs should appoint a Data Protection Officer (DPO) if processing is large-scale or involves sensitive financial profiles, and register processing activities with SDAIA as required.
The Saudi Personal Data Protection Law (PDPL), enforced by the Saudi Data and Artificial Intelligence Authority (SDAIA), imposes clear obligations on organizations when a personal data breach occurs. This is especially critical for banks and fintechs that process large volumes of sensitive financial and personal data.
Notification Obligations Under PDPL: Article 23 of the PDPL requires that organizations notify SDAIA of any personal data breach that could result in harm to data subjects. The notification must be submitted without undue delay — in practice, regulators expect notification within 72 hours of becoming aware, aligning with international best practices.
If the breach poses a high risk to individuals (e.g., exposure of financial account numbers, national ID data, or biometrics), data subjects must also be individually notified with clear information about the nature of the breach and protective steps they can take.
DPO Responsibilities Upon Breach:
- Contain: Immediately isolate affected systems and revoke compromised credentials.
- Assess: Determine the scope — which data categories, how many individuals, and what risk level.
- Document: Record the breach in the internal data breach register with timeline, cause, and impact details.
- Notify SDAIA: Submit a formal breach notification via the SDAIA portal including: nature of breach, categories/volume of data, likely consequences, and remediation measures taken.
- Notify Subjects: Where required, issue clear communications — avoid vague language that may increase legal exposure.
- Coordinate with SAMA: For financial institutions, simultaneously notify SAMA per CSF Control 3.4.2 (Cybersecurity Incident Management), as dual regulatory reporting is mandatory.
- Post-Incident Review: Conduct a root cause analysis within 30 days and update DPIAs and security controls accordingly.
Failure to comply with PDPL breach notification obligations can result in fines up to SAR 5 million, with repeated violations attracting doubled penalties.
Using AI for credit scoring in Saudi Arabia creates a complex intersection of PDPL obligations, SAMA CSF data governance requirements, and emerging AI ethics considerations. Here is what fintech compliance teams must address: (1) Legal Basis for Processing — Under PDPL Article 5, processing personal financial data for credit scoring must rest on a valid legal basis, typically contractual necessity or legitimate interest. Where sensitive inferences are drawn (e.g., financial vulnerability), explicit consent may be required. (2) Transparency and Notification — PDPL Articles 11-12 require individuals to be informed about automated decision-making processes affecting them, including credit decisions. Privacy notices must explicitly disclose AI-based scoring and the data inputs used. (3) Data Minimization — Only data directly relevant to creditworthiness assessment should be collected and processed. Behavioral or social data inputs must be legally justified and proportionate per PDPL principles. (4) Right to Explanation — While PDPL does not yet mandate a full 'right to explanation' equivalent to GDPR Article 22, SAMA CSF Control 3.3.7 on data governance expects institutions to maintain explainability of automated decisions affecting customers. (5) Retention Limits — Financial data used in scoring models must be retained only for the period necessary, with documented retention schedules reviewed annually. (6) Cross-Border Transfers — If AI models are trained or hosted outside Saudi Arabia, PDPL Article 29 transfer controls apply. Ensure adequate protection measures are contractually enforced with overseas processors. Engage your Data Protection Officer early in AI model design to embed privacy-by-design principles from inception.
Saudi fintech companies operate at the intersection of two major regulatory regimes — the Personal Data Protection Law (PDPL) and SAMA CSF — each with distinct but complementary breach response obligations. Building a unified response plan is both a compliance necessity and an operational best practice.
PDPL Obligations (SDAIA Oversight): Under PDPL Article 24, data controllers must notify the Saudi Data and Artificial Intelligence Authority (SDAIA) of any personal data breach that harms or is likely to harm data subjects, within a timeframe specified by the Implementing Regulations (currently expected within 72 hours of discovery for high-risk breaches). Affected individuals must also be notified when there is a direct risk to their rights or interests.
SAMA CSF Obligations: SAMA CSF Control 3.5.4 requires documented incident response procedures, including breach detection, containment, eradication, recovery, and post-incident review. Incidents impacting customer data or system availability must be reported to SAMA within defined timeframes — critical incidents typically within 24 hours.
Building a Unified Response Plan:
- Classify breach severity upfront: Define thresholds for when PDPL notification, SAMA reporting, and customer communication are triggered.
- Establish a response team: Include Legal, DPO, CISO, Operations, and Communications roles with clear RACI assignments.
- Maintain evidence logs: Preserve forensic evidence, access logs, and communication records throughout the incident lifecycle.
- Test regularly: Conduct tabletop exercises at least twice yearly simulating data breach scenarios.
- Coordinate notifications: Use pre-approved notification templates for SDAIA, SAMA, and affected customers to avoid delays under pressure.
A synchronized response plan not only ensures regulatory compliance but significantly reduces financial and reputational exposure in the event of a breach.
Saudi fintech companies face a dual compliance obligation when a data breach occurs: satisfying the Personal Data Protection Law (PDPL) administered by the Saudi Data and AI Authority (SDAIA), and meeting SAMA CSF incident reporting requirements. Aligning both is critical to avoid regulatory penalties and reputational damage.
PDPL Obligations (Articles 25–27): Upon discovering a personal data breach, organizations must notify SDAIA without undue delay — interpretive guidance suggests within 72 hours of awareness — if the breach poses a risk to data subjects' rights. If high risk is confirmed, affected individuals must also be notified with clear, plain-language communication describing the nature of the breach, data categories impacted, and steps taken.
SAMA CSF Obligations (Control 3.6 — Cyber Security Incident Management): SAMA requires financial institutions to report cybersecurity incidents to SAMA within specific timeframes based on severity. Critical incidents must be reported immediately (within 2 hours of detection), with a full post-incident report due within 72 hours. Fintechs must maintain an incident log and evidence chain throughout.
Practical Alignment Steps:
- Build a unified Incident Response Plan (IRP) that maps PDPL and SAMA notification triggers to the same detection-to-report workflow.
- Establish a data breach triage process that simultaneously evaluates personal data exposure (PDPL) and operational/financial system impact (SAMA).
- Designate a Data Protection Officer (DPO) and CISO with clear ownership over regulatory notifications.
- Conduct tabletop exercises simulating breach scenarios covering both regulators.
- Maintain pre-approved notification templates for SDAIA, SAMA, and affected customers to accelerate response times.
Proactive alignment reduces the risk of conflicting timelines and ensures regulatory trust is maintained across both frameworks.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), grants data subjects a defined set of rights that financial institutions must operationalize — not just acknowledge. Failure to establish response mechanisms is a direct compliance gap.
Core Data Subject Rights under PDPL:
- Right to Access (Article 10): Individuals can request access to their personal data held by the institution, including the purposes of processing. Banks must respond within a reasonable timeframe (SDAIA guidelines suggest 30 days).
- Right to Correction (Article 11): Data subjects can request correction of inaccurate or incomplete data.
- Right to Erasure (Article 12): Individuals may request deletion of their data when it is no longer needed for its original purpose — subject to legal retention obligations under SAMA and AML regulations, which may override this right.
- Right to Withdraw Consent (Article 7): Where processing is consent-based, withdrawal must be as easy as granting consent.
- Right to Object to Automated Decisions: Data subjects can contest decisions made solely through automated processing that affect them significantly.
Operationalization for Banks:
- Establish a Data Subject Request (DSR) portal or formal intake process accessible to customers and employees.
- Define an internal SLA of 20 business days to allow buffer before regulatory deadlines.
- Map all personal data repositories so requests can be fulfilled accurately across core banking, CRM, and marketing systems.
- Document legal retention obligations (e.g., SAMA requires transaction records for minimum 10 years) that may lawfully restrict erasure requests.
- Train customer-facing staff and the DPO on response procedures.
- Log all DSR activities for audit purposes — SDAIA may request evidence of compliance during inspections.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Governance Authority (NDGA), establishes clear obligations for data breach notification. Under PDPL Article 24 and its Implementing Regulations, organizations — including fintechs — must notify the competent authority (NDGA) without undue delay upon discovering a breach that affects personal data confidentiality, integrity, or availability. The notification must include: the nature of the breach, categories and approximate number of data subjects affected, likely consequences, and measures taken or proposed. If the breach poses a high risk to data subjects, individuals must also be notified directly and promptly. Practical Steps for Fintechs: (1) Detect and Contain: Activate the incident response plan immediately. Isolate affected systems and preserve forensic evidence. (2) Internal Escalation: Notify the DPO and CISO within hours. Engage legal counsel to assess notification obligations under PDPL and, where applicable, SAMA CSF incident reporting timelines (SAMA requires notification within 72 hours for significant cyber incidents). (3) NDGA Notification: File a formal breach notification with NDGA, ensuring completeness and accuracy. Document the timeline of discovery, assessment, and notification. (4) Affected Individuals: Assess whether the breach creates high risk for data subjects (e.g., exposure of financial or identity data) and send clear, plain-language notifications if required. (5) Post-Breach Review: Conduct a root cause analysis, update controls, and document lessons learned. PDPL violations can result in fines of up to SAR 5 million, with aggravated penalties for repeated offences. Maintaining a breach response runbook aligned to both PDPL and SAMA requirements is strongly recommended.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO), has direct implications for how banks and fintechs deploy cookies and tracking technologies on their digital platforms. While the PDPL does not use the word 'cookies' explicitly, Articles 4, 5, and 6 govern the lawful collection of personal data, which cookies often constitute when they capture identifiers, behavioral data, or device fingerprints.
Consent Requirements: Under PDPL Article 5, consent must be explicit, informed, and freely given before deploying non-essential cookies (analytics, advertising, behavioral tracking). Consent banners must clearly distinguish between essential cookies (exempt) and non-essential categories. Pre-ticked boxes or implied consent do not satisfy PDPL requirements.
Purpose Limitation: Data collected via cookies may only be used for the specific purpose disclosed at collection time (PDPL Article 7). Using session data for unrelated profiling or selling behavioral data to third-party ad networks would constitute a violation.
Cross-Border Transfers: If your analytics tools (e.g., Google Analytics, Adobe Analytics) transmit cookie data to servers outside Saudi Arabia, this triggers PDPL Article 29 cross-border transfer restrictions. You must ensure adequate data protection safeguards or obtain NDMO approval.
Retention Policies: Cookie data must not be retained beyond its stated purpose. Implement automated purging schedules and document data retention periods in your Records of Processing Activities (RoPA).
Practical Steps: Conduct a cookie audit of all your web and mobile properties, categorize each cookie, update your privacy notice to reflect PDPL-compliant disclosures, and implement a Consent Management Platform (CMP) that logs consent with timestamps for audit evidence.
Cross-border personal data transfers are among the most legally sensitive compliance areas for Saudi financial institutions under the Personal Data Protection Law (PDPL). Articles 29–30 of the PDPL and the implementing regulations set strict conditions for transferring personal data outside the Kingdom. Legal Bases for Transfer: (1) Adequacy Determination — Transfers are permitted to countries deemed by the Saudi Data & AI Authority (SDAIA) to provide an adequate level of data protection, comparable to the PDPL's standards. (2) Contractual Safeguards — Where adequacy is not established, institutions must execute SDAIA-approved standard contractual clauses (SCCs) with the receiving entity, ensuring equivalent protections are maintained abroad. (3) Explicit Consent — In the absence of adequacy or SCCs, explicit, informed consent from the data subject must be obtained specifically for the international transfer, with clear disclosure of the destination country and risks involved. (4) Vital Interests or Legal Obligations — Transfers may occur without consent if necessary to protect the individual's vital interests or to fulfil a legal obligation. Financial Sector Specifics: Banks and fintechs using international cloud providers, payment processors, or correspondent banking partners must map all cross-border data flows, maintain a Transfer Impact Assessment (TIA), and ensure contractual provisions are audited annually. SAMA CSF Control 3.3.7 also requires that data classification drives decisions on permissible cross-border transfers. Penalties: Non-compliant transfers can attract fines up to SAR 5 million under PDPL. Institutions should establish a Data Transfer Governance Committee with legal, compliance, and IT security representation to review and approve all outbound data flows quarterly.
The Saudi Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO), applies to all personal data processing activities — including employee data — conducted by Saudi-based financial institutions. This is an often-overlooked compliance gap in HR departments.
Key PDPL Obligations for Employee Data:
- Lawful Processing Basis: Under PDPL Article 8, processing employee data is permissible when necessary to fulfill employment contract obligations or comply with legal requirements. Reliance on consent alone is problematic in employment contexts due to the inherent power imbalance.
- Data Minimization: Institutions must collect only the minimum employee data necessary for the employment relationship. Excessive collection of biometric, health, or financial data without a clear purpose violates PDPL Article 5.
- Employee Rights Notification: Per PDPL Articles 4 and 14, employees must be formally notified of what data is collected, how it is used, how long it is retained, and their rights to access or correct their data. This is typically delivered via an internal Employee Privacy Notice.
- Retention Schedules: HR departments must define documented data retention periods. Employee records may be retained for the duration of employment plus a legally defensible period (commonly 5–7 years) aligned to Saudi Labor Law requirements.
- Cross-Border Transfers: If employee data is processed by overseas HR systems or payroll providers, PDPL Article 29 requires that the recipient country provide an adequate level of data protection or that appropriate contractual safeguards are in place.
- Data Breach Obligations: Employee data breaches must be reported to NDMO within 72 hours if they pose a risk of harm.
Institutions should conduct an HR-specific Data Protection Impact Assessment (DPIA) and update their internal HR policies to reflect PDPL requirements as a priority compliance action.
Cross-border data transfer is one of the most operationally complex obligations under Saudi Arabia's Personal Data Protection Law (PDPL), particularly for financial institutions that rely on global cloud providers, correspondent banking relationships, or international outsourcing arrangements.
Legal Basis Under PDPL Article 29 of the PDPL governs international data transfers. A transfer is only permitted when one or more of the following conditions are met:
- The destination country provides an adequate level of protection comparable to Saudi Arabia's standards (assessed by SDAIA).
- A contractual agreement exists ensuring equivalent protections are enforced.
- The transfer is necessary to execute a contract with the data subject (e.g., international payment processing).
- Explicit consent has been obtained from the data subject — noting this is the weakest legal basis and should not be relied upon as a primary mechanism.
SAMA-Specific Considerations SAMA CSF Control 3.3.5 and its Cloud Computing Guidelines add a financial-sector overlay: customer financial data classified as sensitive must not leave Saudi jurisdiction without SAMA's prior approval, regardless of PDPL permissions. This effectively creates a stricter dual-compliance requirement.
Practical Compliance Steps
- Map all data flows that cross Saudi borders — including subprocessors and cloud infrastructure regions.
- Classify data by sensitivity (PDPL personal data vs. SAMA-regulated financial data).
- Execute Data Transfer Agreements (DTAs) with vendors handling personal data abroad.
- Obtain SAMA no-objection for financial data transfers.
- Document transfer impact assessments and retain records for SDAIA and SAMA audit readiness.
Failure to comply exposes institutions to PDPL penalties of up to SAR 5 million and potential SAMA supervisory action.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), grants data subjects a set of enforceable rights that fintechs must operationalize systematically. Under PDPL Articles 4–7, individuals have the right to access, correct, and request deletion of their personal data, and organizations must respond within defined timeframes.
Operationalizing DSAR Handling:
1. Establish a DSAR Intake Process: Create a dedicated, accessible channel (web form, email, in-app) for receiving requests. Clearly communicate this in your privacy notice as required by PDPL Article 11.
2. Verify Identity Before Disclosure: Before processing any DSAR, verify the requester's identity using at least two factors to prevent unauthorized data disclosure. This step is critical for financial data held by fintechs.
3. Response Timelines: PDPL regulations require responses within 30 days of receiving a valid request. If the request is complex or high-volume, a 30-day extension may apply, but the requester must be notified within the initial period.
4. Scope of Disclosure: Provide data in a structured, commonly used format. For fintechs, this includes transaction records, KYC data, and behavioral profiling data — but must exclude data that could compromise third-party rights or regulatory confidentiality obligations.
5. Deletion vs. Retention Obligations: PDPL allows data subjects to request deletion, but SAMA CSF and FATF AML obligations may require you to retain certain financial records for up to 10 years. Document these conflicts in your Records Retention Policy.
6. SDAIA Complaint Risk: Failure to respond appropriately can result in SDAIA complaints and administrative penalties. Maintain an audit log of all DSARs and their outcomes for regulatory review.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO) and the Saudi Data and AI Authority (SDAIA), grants data subjects several enforceable rights that financial institutions must operationalize through formal procedures.
Under PDPL Articles 4–8, individuals have the right to access, correct, and request deletion of their personal data. For banks and fintechs, this creates specific obligations:
Response Timelines:
- Access and correction requests must be fulfilled within 30 days of receipt.
- If complexity warrants an extension, the institution must notify the requester within the original 30-day window and may extend by a further 30 days, with written justification.
Practical Compliance Steps:
- Request Intake Process: Establish a dedicated, secure channel (portal or email) for receiving DSARs with identity verification mechanisms to prevent unauthorized disclosure.
- Data Mapping Prerequisite: Maintain an updated Record of Processing Activities (RoPA) — this is foundational, as you cannot fulfill access requests without knowing where personal data resides.
- Financial Sector Exceptions: PDPL allows withholding data where disclosure would conflict with AML/CFT obligations (per SAMA's AML rules), legal hold requirements, or national security interests.
- Audit Trail: Log all DSARs, responses, extensions, and any denied requests with documented justifications — SDAIA auditors may request these records.
- Integration with ISO 27001: Align DSAR procedures with your Information Security Management System's access control and asset management controls.
Failure to comply may result in fines of up to SAR 5 million under PDPL enforcement provisions. Our platform provides automated DSAR workflow management with deadline tracking and audit logging.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO), imposes significant obligations on fintechs processing personal financial data — which qualifies as sensitive personal data under PDPL Article 23 due to its financial nature.
Key PDPL Obligations for Fintechs:
- Lawful Basis for Processing (Article 8): Financial data processing must be based on explicit consent, contractual necessity, or a legitimate interest that does not override individual rights. Passive consent mechanisms are insufficient.
- Data Minimization & Purpose Limitation (Article 9): Collect only data strictly necessary for the declared service purpose. Repurposing transaction data for marketing analytics requires fresh, specific consent.
- Data Subject Rights (Articles 13–17): Customers have rights to access, correction, and erasure. Fintechs must respond within 30 days and maintain documented request-handling procedures.
- Cross-Border Data Transfers (Article 29): Transferring financial data outside Saudi Arabia requires NDMO approval or adequate protection guarantees — critical for fintechs using international cloud providers or payment processors.
- Data Breach Notification (Article 24): Notify NDMO within 72 hours of discovering a breach affecting personal data, and notify affected individuals if there is high risk of harm.
Penalties: Violations can attract fines up to SAR 5 million, with repeat violations doubling the penalty. Intentional breaches involving sensitive data may result in criminal referral.
Practical Steps:
- Conduct a PDPL gap assessment mapped to your data flows
- Appoint a Data Protection Officer (DPO) if processing at scale
- Align PDPL controls with SAMA CSF data protection requirements to avoid duplicate compliance efforts
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data and Artificial Intelligence Authority (SDAIA), imposes specific obligations on financial institutions collecting and processing customer personal data. Key requirements include:
Lawful Basis for Processing: Under PDPL Article 4, institutions must establish a clear legal basis before processing personal data — typically contractual necessity, legal obligation, or explicit consent. For sensitive financial data such as credit scores or biometric authentication, explicit consent is mandatory.
Privacy Notice Requirements: Article 11 requires transparent disclosure to data subjects about the purpose of collection, retention periods, data sharing practices, and their rights — including the right to access, correct, and request deletion of their data.
Data Minimization & Retention: Institutions must collect only data strictly necessary for the stated purpose and define clear retention schedules. Retaining customer data beyond the defined period without justification is a direct violation.
Cross-Border Data Transfers: Article 29 restricts transferring personal data outside Saudi Arabia unless the destination country provides adequate protection or SDAIA approval is obtained. This is especially critical for banks using offshore cloud providers or international payment processors.
Data Breach Notification: In the event of a breach affecting personal data, institutions must notify SDAIA within 72 hours of discovery and inform affected individuals if significant harm is likely.
Practical Steps: Conduct a Data Protection Impact Assessment (DPIA) for high-risk processing activities, maintain a comprehensive Records of Processing Activities (RoPA) register, appoint a Data Protection Officer (DPO) if processing is large-scale, and align your PDPL program with your existing ISO 27001 information security controls for an integrated governance approach.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO) and overseen by the Saudi Data and Artificial Intelligence Authority (SDAIA), imposes significant obligations on all organizations operating in the Kingdom that process personal data.
Core Obligations for Financial Institutions:
1. Lawful Basis for Processing (PDPL Article 5): Organizations must establish a valid legal basis before processing personal data. For banks and fintechs, this typically includes contractual necessity (e.g., account opening), legal obligation (e.g., AML/KYC requirements), and — less preferably — explicit consent. Relying solely on consent for operational data processing is risky since individuals may withdraw it at any time.
2. Data Subject Rights (PDPL Articles 4–9): Individuals have rights to access, correct, and request deletion of their personal data. Financial institutions must establish clear processes to respond to these requests within 30 days. Note: data retention requirements under SAMA and FATF may override deletion requests for regulatory records.
3. Cross-Border Data Transfer Restrictions (PDPL Article 29): Personal data may only be transferred outside Saudi Arabia if the destination country provides an adequate level of protection, or if NDMO approval is obtained. This has significant implications for cloud-hosted applications and offshore customer service operations.
4. Data Breach Notification: Organizations must notify SDAIA/NDMO within 72 hours of discovering a personal data breach that poses a risk to data subjects. Affected individuals must also be notified without undue delay.
5. Privacy by Design: New systems and processes must incorporate privacy controls at the design stage — not as an afterthought. Conduct Data Protection Impact Assessments (DPIAs) for high-risk processing activities.
Practical Tip: Map all personal data flows — including employee HR data, customer onboarding records, and marketing databases — before conducting a gap assessment against PDPL requirements. Appoint a Data Protection Officer (DPO) if your organization processes sensitive data at scale.
Saudi Arabia's Personal Data Protection Law (PDPL) and its Executive Regulations impose specific obligations on fintechs leveraging customer personal data for AI-powered credit scoring, behavioral analytics, or personalized financial product recommendations. This is an area of growing regulatory scrutiny.
Lawful Basis for Processing (PDPL Article 6 & 13): Fintechs must establish a clear lawful basis before processing personal data for AI/ML purposes. Consent is the most common basis, but it must be:
- Explicit, informed, and freely given
- Granular — separate consent for scoring versus marketing
- Easily withdrawable at any time
Automated Decision-Making (PDPL Article 15): PDPL restricts fully automated decisions that significantly affect individuals (e.g., credit denial). Customers have the right to:
- Request human review of automated credit decisions
- Receive a meaningful explanation of the decision logic
- Challenge outcomes they believe are inaccurate
This aligns with SAMA's Open Banking and consumer protection frameworks, which require transparent algorithmic decision disclosures.
Data Minimization & Purpose Limitation: Only data directly relevant to the scoring purpose may be processed. Using behavioral data collected for one purpose (e.g., app usage) to feed credit models without fresh consent likely constitutes a PDPL violation.
Cross-Border Data Transfers: If AI models are hosted outside KSA (e.g., on international cloud platforms), PDPL Articles 29–30 require either SDAIA-approved adequacy decisions or appropriate contractual safeguards.
Practical Steps for Fintechs:
- Conduct a Data Protection Impact Assessment (DPIA) before deploying AI scoring models
- Maintain an updated Record of Processing Activities (RoPA) covering all AI use cases
- Appoint a Data Protection Officer (DPO) if processing is large-scale or high-risk
- Publish a clear AI/data use disclosure in your privacy notice
- Implement model governance controls to detect and remediate bias
The Saudi Personal Data Protection Law (PDPL) grants individuals a set of enforceable rights over their personal data, and financial institutions must have a structured, documented process to honor these rights within legally mandated timeframes. Under PDPL Articles 4 and 7–9, data subjects have the right to access their data, request correction, demand deletion (where applicable), and object to certain processing activities. Here is how to build a compliant process: (1) Establish a dedicated intake channel — a secure portal, email address, or in-branch form — specifically for data subject requests (DSRs), ensuring it is accessible and clearly communicated in your privacy notice; (2) Define internal SLAs aligned to PDPL requirements: responses must generally be provided within 30 days, extendable by an additional 30 days in complex cases with notice to the requestor; (3) Implement identity verification protocols before processing any request to prevent unauthorized data disclosure — balance security with accessibility; (4) Map which systems hold personal data so that your team can locate, retrieve, or delete records efficiently — a data inventory and Record of Processing Activities (RoPA) is essential here; (5) Log every DSR with timestamps, actions taken, and outcomes for accountability and regulatory audit readiness; (6) Train customer-facing staff and the compliance team on DSR handling procedures. For Saudi banks, be aware that some deletion requests may conflict with CBE/SAMA record retention requirements — document your legal basis for retention clearly when declining a deletion request. The PDPL's supervisory authority (NDMO/SDAIA) may audit your DSR handling, so evidence of a functioning process is critical.
The Saudi Personal Data Protection Law (PDPL), enforced by the Saudi Data and AI Authority (SDAIA), imposes specific and stringent obligations on fintech companies handling customer financial data. Non-compliance can result in fines up to SAR 5 million. Here is what fintech CISOs and compliance officers must address:
1. Lawful Basis for Processing: Under PDPL Articles 5 and 6, fintechs must establish a clear lawful basis before processing any personal data. For financial services, this typically includes contractual necessity, legal obligation, or explicit consent. Consent must be specific, informed, and revocable — pre-ticked boxes are not acceptable.
2. Data Minimization and Purpose Limitation: Fintechs may only collect data that is strictly necessary for the defined purpose (e.g., credit assessment, KYC, payment processing). Repurposing data without new consent is prohibited under PDPL Article 7.
3. Sensitive Financial Data: PDPL classifies financial data as sensitive personal data requiring heightened protection. This means implementing strong encryption (AES-256 at rest, TLS 1.2+ in transit), strict access controls, and comprehensive audit logging.
4. Data Subject Rights: Fintechs must provide mechanisms for customers to access, correct, and request deletion of their personal data. Responses to data subject requests must be handled within 30 days.
5. Cross-Border Data Transfer: Transferring customer financial data outside Saudi Arabia requires SDAIA approval or confirmation that the recipient country provides an adequate level of protection — critical for fintechs using global cloud providers.
6. Privacy by Design: New products and features must undergo a Data Protection Impact Assessment (DPIA) before launch, embedding privacy controls from the outset.
Practical Tip: Map your data flows end-to-end, document your lawful bases for each processing activity in a Records of Processing Activities (RoPA) register, and align your privacy notices with PDPL Article 11 disclosure requirements.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), establishes a heightened protection regime for 'sensitive personal data' under Article 2. This category explicitly includes genetic and biometric data, health and medical records, financial and credit information, religious beliefs, criminal records, and any data relating to minors.
For Saudi banks, fintechs, and financial institutions — which routinely process credit scores, transaction histories, biometric authentication data (e.g., fingerprints for mobile banking), and KYC documents — virtually all core datasets fall under this sensitive classification.
The additional obligations triggered for sensitive data under PDPL include:
1. Explicit Consent (Article 5): Processing requires explicit, informed, and purpose-specific consent — not merely implied consent embedded in general terms and conditions.
2. Data Minimization & Purpose Limitation (Article 9): You may only collect the minimum data necessary and must not repurpose it without renewed consent.
3. Privacy Impact Assessments (Article 14): High-risk processing activities involving sensitive data require a formal Data Protection Impact Assessment (DPIA) before commencement.
4. Breach Notification (Article 24): Breaches involving sensitive personal data must be reported to SDAIA and affected individuals promptly — regulators expect notification within 72 hours.
5. Cross-Border Transfer Restrictions (Article 29): Transferring sensitive data outside Saudi Arabia requires SDAIA approval or adequate safeguard mechanisms.
Non-compliance exposes institutions to fines of up to SAR 5 million for standard violations and up to SAR 10 million for aggravated breaches. Integration with SAMA CSF Domain 2 (Cybersecurity Risk Management) is essential to ensure technical controls match PDPL's legal obligations.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO) and overseen by the Saudi Data and AI Authority (SDAIA), imposes binding obligations on all fintech platforms that process personal data of Saudi residents — regardless of where the company is headquartered.
Pre-Launch Obligations:
- Lawful Basis for Processing: Under PDPL Article 5, fintechs must establish a valid legal basis for every data processing activity — typically explicit consent, contractual necessity, or regulatory obligation. Consent must be informed, specific, and freely given.
- Privacy Notice: A clear, Arabic-language privacy notice is required per PDPL Article 11, explaining data categories collected, purposes, retention periods, and data subject rights.
- Data Protection Impact Assessment (DPIA): Required before launching any high-risk processing activity — such as credit scoring algorithms, biometric authentication, or behavioral profiling — per PDPL implementing regulations.
- Data Minimization and Purpose Limitation: Fintechs may only collect data strictly necessary for the declared purpose. Repurposing data without re-consent is prohibited.
- Cross-Border Transfer Controls: PDPL Article 29 restricts transferring personal data outside Saudi Arabia. Transfers require NDMO approval or must meet adequacy standards. This is critical for fintechs using international cloud providers or global analytics platforms.
- Data Subject Rights Mechanism: Systems must support rights to access, correction, and erasure with defined SLA windows.
Intersection with SAMA: Fintechs licensed by SAMA must also align PDPL compliance with SAMA CSF data classification and protection controls (Domain 3.2), creating a unified data governance program.
Non-compliance carries fines up to SAR 5 million and potential license implications.
Saudi financial institutions face dual notification obligations when personal data breaches occur — one under the Personal Data Protection Law (PDPL) enforced by the Saudi Data & AI Authority (SDAIA), and another under SAMA CSF's incident reporting requirements. Managing both effectively is critical.
PDPL Obligations (Article 24): Upon discovering a breach affecting personal data, organizations must notify SDAIA without undue delay — SDAIA's implementing regulations specify notification within 72 hours of becoming aware of the breach if it poses a risk to individuals' rights or interests. The notification must describe: the nature of the breach, categories and approximate number of data subjects affected, likely consequences, and measures taken or proposed to address it.
Data Subject Notification: If the breach is likely to result in high risk to individuals — such as exposure of financial data, national ID numbers, or sensitive personal data — affected data subjects must also be notified directly and promptly, unless law enforcement considerations apply.
SAMA CSF Requirements (Control 3.4.3 & 3.4.4): SAMA requires regulated entities to report cybersecurity incidents — including data breaches — to SAMA within defined timeframes. Critical incidents impacting customer data require immediate escalation. Institutions must maintain a documented Cyber Incident Response Plan (CIRP) that explicitly covers personal data breach scenarios.
Practical Steps:
- Activate your CIRP immediately upon breach detection.
- Conduct a rapid data impact assessment to determine PDPL applicability.
- Engage your Data Protection Officer (DPO) and Legal team simultaneously.
- File notifications to SDAIA and SAMA within required windows.
- Document all decisions, timelines, and communications meticulously.
Institutions should conduct tabletop exercises simulating data breach scenarios to ensure cross-functional readiness across IT, Legal, Compliance, and Communications teams.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO) and now overseen by the Saudi Data and AI Authority (SDAIA), imposes significant obligations on fintechs processing personal data of Saudi residents.
Core Processing Obligations:
- Lawful Basis (Art. 5): Processing must be based on explicit consent, contractual necessity, legal obligation, or legitimate interest. Consent must be clear, specific, and withdrawable.
- Purpose Limitation (Art. 6): Data collected for KYC cannot later be used for marketing without separate consent.
- Data Minimization: Only collect data strictly necessary for the stated purpose.
- Retention Limits (Art. 18): Personal data must be deleted or anonymized once the processing purpose is fulfilled, unless otherwise required by SAMA or AML regulations.
- Data Subject Rights (Art. 4): Individuals have rights to access, correct, and request deletion of their data. Fintechs must respond within 30 days.
- Cross-Border Transfer (Art. 29): Transferring personal data outside Saudi Arabia requires SDAIA approval or that the recipient country ensures adequate protection.
SAMA Intersection: SAMA CSF and Open Banking Framework layer additional requirements on customer data confidentiality, mandating encryption in transit and at rest.
Penalties for Non-Compliance: Violations can result in fines up to SAR 5 million, rising to SAR 50 million for repeat offenders or deliberate breaches. Reputational damage and regulatory license risk compound financial penalties.
Practical Tip: Conduct a Data Protection Impact Assessment (DPIA) before launching new products, and maintain a Records of Processing Activities (RoPA) register to demonstrate accountability.
Data classification and access control form a critical intersection between Saudi Arabia's Personal Data Protection Law (PDPL) and the NCA Essential Cybersecurity Controls (ECC). Here's how to build a unified, compliant approach:
Data Classification (NCA ECC Control 2-1 & PDPL Article 5): Establish a formal data classification policy with at least four tiers: Public, Internal, Confidential, and Restricted. Personal data and sensitive personal data under PDPL (health, financial, biometric) must automatically classify as Restricted. Label all data assets accordingly and enforce handling procedures per classification level.
Access Control Architecture (NCA ECC Control 2-5): Implement Role-Based Access Control (RBAC) aligned with least-privilege principles. Privileged Access Management (PAM) solutions must govern administrator accounts. NCA ECC mandates multi-factor authentication (MFA) for all privileged access and remote connections.
PDPL-Specific Obligations: Under PDPL Articles 12–14, access to personal data must be limited to authorized personnel with a documented legitimate purpose. Data processors must operate under formal agreements restricting use beyond the stated purpose. Maintain access logs for personal data systems and review them periodically.
Practical Implementation Steps:
- Deploy a Data Loss Prevention (DLP) solution to enforce classification policies automatically.
- Conduct quarterly access reviews for systems housing personal or sensitive data.
- Map personal data flows and document them in a Record of Processing Activities (RoPA) as required by PDPL.
- Cross-reference your access control matrix with NCA ECC Annex controls for audit readiness.
A unified data governance framework serving both PDPL and NCA ECC reduces duplication and strengthens your overall security posture.
Cross-border data transfers are one of the most operationally impactful aspects of Saudi Arabia's Personal Data Protection Law (PDPL), governed under Article 29 and its implementing regulations issued by the Saudi Data & AI Authority (SDAIA).
When is a cross-border transfer permitted?
A transfer of personal data outside Saudi Arabia is only lawful if one or more of the following conditions is met:
- The destination country offers an adequate level of data protection as determined by SDAIA.
- The transfer is necessary to fulfill a contractual obligation to the data subject.
- The transfer is required to protect the vital interests of the data subject.
- The data subject has given explicit, informed consent to the transfer.
- The transfer serves a compelling public interest approved by SDAIA.
Practical compliance steps:
- Data Mapping: Identify all personal data flows leaving KSA — including SaaS platforms, cloud backups, and analytics tools processing Saudi resident data abroad.
- Transfer Impact Assessment (TIA): Conduct a formal assessment evaluating the legal framework, security standards, and enforcement capability of the destination country.
- Contractual Safeguards: Where no adequacy decision exists, implement binding data transfer agreements containing SDAIA-approved standard contractual clauses (SCCs).
- SDAIA Notification: Certain sensitive data transfers may require prior notification or approval from SDAIA. Track regulatory guidance updates as implementing regulations continue to evolve.
- Record Keeping: Maintain a Register of International Transfers documenting the legal basis, data categories, destination, and safeguards applied — auditable upon request.
Non-compliance penalties under PDPL can reach SAR 5 million for violations involving cross-border transfer infractions. Organizations should treat international data flows as a high-priority compliance risk.
Data classification is a foundational control that sits at the intersection of PDPL compliance obligations and SAMA CSF requirements. Getting this right protects institutions from both regulatory penalties and operational security breaches.
PDPL Requirements: Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO), requires organizations to identify all personal data, define lawful processing bases, implement proportionate protection controls, and restrict access on a need-to-know basis. Special categories of data — including health, financial, and biometric data — require heightened protection and explicit consent in most cases.
SAMA CSF Alignment: SAMA CSF Control 3.1.1 mandates a formal Information Asset Management program, which includes maintaining an asset register with data classification labels. The framework requires at minimum three classification tiers: Public, Internal/Confidential, and Restricted/Secret — though institutions may adopt more granular schemes.
Practical Implementation Steps:
- Conduct a data discovery exercise to map all data stores, including structured databases, unstructured files, and cloud repositories.
- Apply classification labels based on sensitivity, regulatory scope (PDPL personal data, SAMA-regulated financial data), and business impact.
- Implement technical controls per classification: encryption at rest and in transit for Restricted data (AES-256 minimum), DLP policies, and access controls enforced via IAM systems.
- Define retention and disposal policies aligned with PDPL Article 19, which limits personal data retention to the period necessary for the original processing purpose.
- Conduct annual classification reviews and integrate classification into data lifecycle processes.
Failure to comply with PDPL can result in fines up to SAR 5 million, with repeat violations attracting doubled penalties per Article 35.
Saudi fintechs leveraging AI for credit scoring, fraud detection, customer onboarding, or loan decisioning face specific PDPL obligations that many organizations overlook. This is an emerging and critical compliance area.
Automated Decision-Making Under PDPL The Saudi Personal Data Protection Law (PDPL), enforced by the Saudi Data and AI Authority (SDAIA), addresses automated processing in Article 15. When a fintech uses AI to make decisions that significantly affect individuals — such as denying a loan, flagging fraud, or setting credit limits — the following obligations apply:
1. Transparency and Disclosure Data subjects must be informed that automated decision-making is occurring. Your privacy notice (required under PDPL Art. 11) must clearly disclose the use of AI systems, the type of data processed, and the logic applied in general terms.
2. Right to Explanation Customers have the right to request a meaningful explanation of how an automated decision was reached. Your AI system must be designed to provide human-interpretable outputs — black-box models with no explainability mechanism create direct PDPL exposure.
3. Human Review Mechanism For high-impact decisions, PDPL expects that individuals can request human review of automated decisions. Build an escalation workflow where compliance or operations teams can review and override AI decisions.
4. Data Minimization (PDPL Art. 9) AI models should only process personal data that is necessary for the stated purpose. Audit your model's feature set to ensure no excessive or sensitive attributes (e.g., gender, location proxies) are used in ways that could create discriminatory outcomes.
5. SAMA CSF Alignment SAMA's guidance on technology risk (Control 3.3.10) also requires risk assessment of automated financial decision systems. Conduct a Data Protection Impact Assessment (DPIA) before deploying any customer-facing AI system.
Engage your DPO and legal counsel early when deploying AI in customer journeys to ensure PDPL readiness.
Effective data classification is the foundation of both PDPL compliance and SAMA CSF's data governance domain (Control 3.2). Saudi financial institutions must implement a structured, enterprise-wide data classification framework that satisfies both regulatory regimes simultaneously.
Classification Tiers to Implement:
- Confidential/Restricted: Personal financial data, credit scores, national ID numbers, biometric data, and transaction records — classified as sensitive personal data under PDPL Article 23, requiring explicit consent for processing.
- Internal: Operational data, internal policies, non-public business information.
- Public: Marketing materials, published financial reports.
SAMA CSF Requirements (Controls 3.2.1–3.2.4): Institutions must document a data classification policy, assign data owners for each category, apply technical controls (encryption, access restrictions, DLP tools) proportionate to classification level, and conduct periodic data inventories.
PDPL Obligations: Per PDPL Articles 5 and 6, financial institutions must identify a lawful basis for each personal data processing activity. For sensitive categories, explicit consent or specific legal necessity is required. Data minimization principles must be embedded in classification decisions.
Practical Implementation Steps:
- Conduct a data discovery and mapping exercise across all systems and third-party integrations.
- Deploy Data Loss Prevention (DLP) tools integrated with your classification labels.
- Encrypt all Confidential data at rest (AES-256) and in transit (TLS 1.2+).
- Establish data retention and deletion schedules per PDPL Article 18.
- Document the data register and make it available for SAMA and SDAIA inspections.
Align your classification taxonomy with ISO 27001 Annex A Control 5.12 for a unified governance approach.
Saudi financial institutions face overlapping data governance obligations under PDPL and SAMA CSF, requiring a unified data classification and handling framework. Data Classification Tiers: SAMA CSF Control 3.2.1 mandates a formal classification policy. Best practice aligns four tiers — Public, Internal, Confidential, and Restricted — with PDPL's distinction between general personal data and sensitive personal data (Article 23 PDPL), which includes financial records, health data, and biometric information. PDPL Obligations: Sensitive personal data requires explicit consent for processing (Article 6), purpose limitation, and storage only for as long as operationally necessary. Financial institutions must appoint a Data Protection Officer (DPO) if processing is large-scale or involves sensitive categories. SAMA CSF Data Handling Controls: Per SAMA CSF 3.2.3, classified data must have documented handling procedures covering storage encryption (AES-256 minimum), secure transmission (TLS 1.2+), clean-desk policies, and secure disposal aligned with NIST SP 800-88. Data Inventory: Maintain a live data inventory or Record of Processing Activities (RoPA) mapping data types to systems, custodians, retention periods, and legal basis — a requirement under both PDPL and ISO 27001 Annex A.8.1. Practical Steps: Implement a Data Loss Prevention (DLP) solution integrated with email and endpoint controls; tag documents using classification labels enforced by Microsoft Purview or equivalent. Annual data classification audits are recommended to ensure alignment with evolving regulatory expectations.
Saudi financial institutions face overlapping obligations from both PDPL (Personal Data Protection Law) and SAMA CSF when it comes to data classification and protection. Getting this right is foundational to overall compliance posture.
Under PDPL Article 5 and Article 29, organizations must identify all categories of personal data they process, with special categories—such as financial records, biometric data, and health information—requiring heightened protection measures. Consent must be obtained for processing, and data must only be retained for as long as necessary for the stated purpose.
SAMA CSF Control 3.2 (Information Asset Management) requires banks to maintain a formal data classification policy with at minimum four tiers: Public, Internal, Confidential, and Restricted. Customer financial data, payment card information, and authentication credentials must be classified as Restricted, triggering the highest levels of encryption, access control, and audit logging requirements.
Practical implementation steps include:
- Conduct a full data discovery and mapping exercise to identify where personal and sensitive financial data resides across on-premises and cloud environments.
- Label all data assets according to your classification policy and enforce controls through Data Loss Prevention (DLP) tools.
- Encrypt all Restricted-class data at rest (AES-256) and in transit (TLS 1.2 or higher), per SAMA CSF Control 3.6.
- Implement data masking and tokenization for non-production environments.
- Establish a formal data retention and disposal schedule aligned with PDPL Article 18 and SAMA record-keeping requirements.
- Ensure your Data Protection Officer (DPO), required under PDPL Article 30 for high-risk processors, is empowered to oversee these controls.
Regular audits of data flows and third-party data sharing arrangements are also critical to maintaining compliance.
Building a compliant data governance framework for Saudi financial institutions requires harmonizing PDPL obligations with SAMA CSF data classification requirements and NCA ECC data protection controls.
Data Classification (SAMA CSF 3.6.1): SAMA requires banks to define a formal data classification policy with at least the following tiers:
- Confidential / Restricted: Customer PII, financial records, authentication credentials
- Internal: Operational data, internal communications
- Public: Marketing materials, published reports
PDPL Obligations (Articles 5, 8, and 21):
- Personal data must be collected for a specific, legitimate purpose and not retained beyond what is necessary
- Sensitive categories (health, financial, biometric data) require explicit consent under PDPL Article 6 and additional safeguards
- Data processors (third parties) must be bound by contractual data processing agreements ensuring PDPL compliance
Practical Implementation Steps:
- Deploy a Data Discovery and Classification tool (e.g., Microsoft Purview, Varonis) to identify and tag sensitive data assets automatically
- Establish a Data Retention and Disposal Schedule aligned with SAMA CSF 3.6.3 — financial records typically require 10-year retention per SAMA banking regulations
- Implement Data Loss Prevention (DLP) controls on endpoints, email, and cloud environments
- Map all personal data flows in a Record of Processing Activities (RoPA) as required by PDPL Article 15
- Appoint a Data Protection Officer (DPO) — mandatory for organizations processing large-scale or sensitive personal data
NCA ECC Alignment: ECC-1: 3-4 mandates data classification and handling procedures for all critical sector entities.
Conduct annual data governance audits and include data classification compliance in your ISO 27001 internal audit scope under Annex A Control 5.12.
Data classification is a foundational control required by both SAMA CSF (Control 3.2.1) and the Personal Data Protection Law (PDPL Article 5), and it directly underpins data protection, access control, and incident response capabilities.
Step 1 – Establish a Data Classification Policy: Define at minimum four tiers: Public, Internal, Confidential, and Restricted. Under PDPL, any data that qualifies as 'personal data' or 'sensitive personal data' (e.g., financial records, national IDs, biometrics) must be mapped to the Restricted tier with enhanced protections.
Step 2 – Conduct a Data Discovery and Inventory Exercise: Map all data assets across on-premises systems, cloud environments, and third-party processors. SAMA CSF requires that this inventory be maintained and reviewed at least annually. Include data flows to identify cross-border transfers, which require explicit PDPL Article 29 compliance assessment.
Step 3 – Apply Technical Controls by Classification Tier:
- Restricted: Encryption at rest and in transit (AES-256 minimum), strict role-based access, DLP enforcement, and audit logging.
- Confidential: Encryption, need-to-know access, and periodic access reviews.
- Internal/Public: Standard access controls and monitoring.
Step 4 – Label and Handle Data Consistently: Implement automated labeling tools integrated with document management systems and email platforms to enforce classification at the point of creation.
Step 5 – Review and Audit: SAMA CSF requires periodic reviews of classification accuracy. Conduct semi-annual audits and align findings with your ISO 27001 Annex A.8 asset management controls.
Our GRC platform includes a pre-built data classification framework mapped to PDPL, SAMA CSF, and ISO 27001, with workflow automation to track classification reviews and exceptions.
No matching questions found.
Didn't find what you're looking for?
✉️ Contact Us