Saudi PSP Data Privacy and Consent: A Procurement Checklist

Saudi PSP Data Privacy and Consent: A Procurement Checklist

Patient support programs in Saudi Arabia process sensitive health data about identifiable individuals. Under the Saudi Personal Data Protection Law (PDPL), health data is classified as sensitive personal data, subject to heightened protection requirements, mandatory consent, and specific rules governing its processing, transfer, and retention.

For pharmaceutical sponsors evaluating PSP platforms or operators, data privacy capabilities are not an IT procurement checkbox — they are a legal and patient safety requirement. A platform that cannot demonstrate PDPL-compliant consent architecture, in-Kingdom hosting capability, and a defensible data processing agreement creates liability for the sponsor from day one of program operation.

This checklist covers the twelve questions that every Saudi PSP procurement team should be able to answer before contract signature.

---

Key Takeaways

• Saudi PDPL classifies health data as sensitive personal data, subject to requirements that differ from general personal data protections — PSP platforms must demonstrate they understand and implement these distinctions.
• The sponsor is the PDPL data controller; the PSP platform and operator are data processors. This allocation of responsibility cannot be contracted away and must be reflected in all agreements.
• Consent in a Saudi PSP must be specific, informed, and freely given — bundled consent covering all processing purposes in a single checkbox does not meet PDPL requirements.
• In-Kingdom data hosting is not automatically provided by all platforms; it must be verified, not assumed.
• Keywords are unvalidated editorial hypotheses (H); no search volume claims are made.

Editorial note: Specific references to Saudi PDPL regulatory requirements, SDAIA guidance, and consent architecture requirements should be reviewed by a Saudi-licensed legal professional before this checklist is used in regulatory or procurement contexts. [HOLD — expert review: legal professional sign-off required for PDPL-specific claims]

---

Understanding the PDPL Framework for PSPs

Saudi Arabia's Personal Data Protection Law (PDPL), effective September 2021 and amended in March 2023, establishes the legal framework governing personal data processing in the Kingdom. For PSP purposes, the most significant provisions concern: the definition and heightened protection of sensitive personal data; the conditions under which consent constitutes valid legal basis for processing; data subject rights; and cross-border transfer restrictions.

Health data in the PSP context — including diagnosis, medication, treatment history, adverse event reports, and health status changes — falls within the PDPL's sensitive personal data category. Processing sensitive personal data requires explicit consent from the data subject, and the standard for that consent is higher than for general personal data.

SDAIA (the Saudi Data and Artificial Intelligence Authority) is the regulatory body overseeing PDPL implementation and enforcement. SDAIA has published implementing regulations that clarify several consent and data processing requirements. As these regulations continue to develop, PSP platforms and sponsors should monitor regulatory updates actively. [VERIFY WITH BRAND — specific current SDAIA guidance requires legal review and verification against published implementing regulations]

---

Checklist Section 1: Consent Architecture

Question 1.1: Does the platform capture consent separately for each processing purpose?

PDPL requires that consent be specific to the processing purpose. A single consent checkbox covering enrollment in the program, processing of health data, receipt of communications, disclosure to the sponsor, and potential future research use does not constitute purpose-specific consent. The platform must present and capture consent for each distinct processing activity.

Question 1.2: Can the platform version and timestamp consent records?

Consent records must demonstrate when consent was given, to what specific processing, and in what version of the consent notice. Platforms that capture consent as a single unversioned boolean field cannot demonstrate consent history — which becomes critical when a data subject exercises their right to withdraw consent or when SDAIA requests evidence of compliant consent capture.

Question 1.3: How does the platform manage consent withdrawal?

PDPL recognizes data subjects' right to withdraw consent. The platform must have a mechanism for processing withdrawal requests, documenting the withdrawal, and immediately stopping processing activities for which consent was the legal basis. This withdrawal capability must extend to all downstream processors (coordinators, sub-contractors) with a documented propagation timeline.

Question 1.4: Is the consent notice available in Arabic?

For Saudi patients, consent notices must be in a language the patient understands. For the majority of Saudi PSP enrollees, this means Arabic. Consent notices that exist only in English, or where the Arabic version is a machine translation of an English original, raise questions about whether consent is genuinely informed.

---

Checklist Section 2: Data Controller and Processor Designation

Question 2.1: Does the platform have a standard Data Processing Agreement (DPA)?

A DPA must exist between the sponsor (data controller) and every party processing health data on the sponsor's behalf (platform vendor, operator, sub-contractors). The DPA should address: the scope and purpose of processing; security measures; sub-processor restrictions and approval rights; data subject rights fulfillment; breach notification; and data return or deletion on contract termination.

Request the platform's standard DPA template as part of the RFP process. Review it with legal counsel before contract signature. [HOLD — expert review: specific DPA requirements require legal professional review]

Question 2.2: How does the platform manage sub-processor relationships?

PSP platforms typically use sub-processors — cloud infrastructure providers, communication services, analytics tools. Each sub-processor processes personal data on behalf of the platform, which processes it on behalf of the sponsor. The sub-processor chain must be disclosed, and each sub-processor must meet the same data protection standards as the platform itself.

Question 2.3: What data retention and deletion policies does the platform apply to PSP health data?

PDPL prohibits retention of personal data beyond what is necessary for the purpose for which it was collected. Health data in a PSP context may need to be retained for specific periods to satisfy pharmacovigilance requirements — but this retention must be explicitly justified and documented. The platform should demonstrate a retention schedule that reflects both PDPL requirements and pharmacovigilance obligations, without defaults to indefinite retention. [VERIFY WITH BRAND — specific retention requirements require legal and PV professional review]

---

Checklist Section 3: Data Hosting and Localization

Question 3.1: Where is patient health data hosted?

This question has a simple answer requirement: a specific data center location or region. "Global cloud infrastructure" is not an acceptable answer for a Saudi PSP procurement decision. Health data processed in a Saudi PSP involves Saudi residents' sensitive personal data; its hosting location has PDPL implications.

Question 3.2: Is in-Kingdom hosting available, and what is its standard configuration?

PDPL contains provisions governing cross-border transfer of personal data. For sensitive personal data — which health data is — the bar for cross-border transfer is higher. Some sponsors and program designs require in-Kingdom hosting as a standard requirement; others may accept specific cross-border transfer mechanisms. Either way, the platform's hosting capability and configuration must be verified before contract signature. [VERIFY WITH BRAND — specific PDPL cross-border transfer requirements for health data require legal review]

Question 3.3: What data isolation is in place between different sponsor programs on the platform?

Most PSP platforms operate as multi-tenant environments, where multiple pharmaceutical sponsors' programs run on the same infrastructure. The platform must demonstrate that patient health data for different sponsors' programs is fully isolated — that a data breach affecting one program cannot expose another sponsor's patients' data, and that platform administrators cannot access one sponsor's data while servicing another.

---

Checklist Section 4: Security and Breach Response

Question 4.1: What security certifications does the platform hold?

ISO 27001 (information security management), SOC 2 Type II, and regional equivalents provide third-party validation that the platform has implemented security controls and had them verified. Request current certificates, not historical certificates. [VERIFY WITH BRAND — specific current certifications require verification against platform documentation]

Question 4.2: What is the platform's breach notification process and timeline?

PDPL requires personal data controllers to notify SDAIA of data breaches within specific timeframes. The platform (as data processor) must commit to notifying the sponsor (as data controller) within a timeframe that allows the sponsor to meet its notification obligations to SDAIA and affected data subjects. A DPA that specifies only "prompt notification" without a specific timeframe is insufficient. [VERIFY WITH BRAND — specific PDPL breach notification requirements require legal review against current SDAIA guidance]

Question 4.3: How does the platform manage data subject rights requests (access, rectification, erasure, portability)?

PDPL grants data subjects specific rights over their personal data. The platform must have a workflow for receiving, documenting, and fulfilling data subject rights requests within the timeframes PDPL specifies. This workflow must work for Arabic-language requests from Saudi patients. [VERIFY WITH BRAND — specific PDPL data subject rights requirements and timelines require legal review]

---

Using This Checklist in RFP Evaluation

Treat this checklist as a mandatory pre-qualification layer. Vendors who cannot answer Questions 1.1, 2.1, 3.1, and 4.2 specifically and in writing should be eliminated from consideration before scoring begins — these are not negotiating points, they are baseline legal requirements.

For the remaining questions, evaluate the specificity and verifiability of vendor responses. A vendor who states they are "PDPL compliant" without demonstrating how compliance is implemented and documented is not providing an evaluable answer. PDPL compliance is not a product feature — it is an ongoing operational and legal practice that must be demonstrated, not claimed.

---

FAQ

Who is responsible for PDPL compliance in a PSP — the sponsor or the platform vendor? The sponsor is the PDPL data controller and bears ultimate accountability for PDPL compliance in the PSP program. The platform vendor and operator are data processors — they are contractually obligated to process data in accordance with the sponsor's instructions and PDPL requirements. Responsibility cannot be delegated to the platform; the sponsor's accountability persists regardless of which party manages day-to-day data processing. [HOLD — expert review: specific PDPL controller/processor allocation requires legal professional review]

Does our PSP need to register with SDAIA? SDAIA has established notification and registration requirements for certain categories of data controllers and processing activities under PDPL. Personal data controllers processing sensitive personal data may have specific obligations. Consult current SDAIA guidance and legal counsel. [HOLD — expert review: specific SDAIA registration requirements require legal professional review against current regulations]

What happens to patient data if we terminate the PSP contract? Contract termination provisions must address data return and deletion. The DPA should specify that upon contract termination, the platform provides the sponsor with a complete export of all patient data in a structured, interoperable format, then deletes all copies of that data within a specified timeframe. Failure to include explicit termination data provisions is a significant procurement risk. [VERIFY WITH BRAND — specific data portability requirements require legal review]

Are consent requirements different for Saudi nationals versus expatriate patients enrolled in a Saudi PSP? PDPL applies to all personal data about individuals processed in Saudi Arabia, regardless of nationality. All patients enrolled in a Saudi PSP — Saudi nationals and expatriate residents — are entitled to the same PDPL protections. [HOLD — expert review: specific PDPL applicability scope requires legal professional review]

Can we use PSP health data for secondary purposes such as market research or clinical research? Secondary use of PSP health data requires separate, specific consent for each secondary use purpose. Data collected under a PSP consent for program delivery cannot be repurposed for market research or clinical research without additional consent from each data subject. Any platform that facilitates secondary use of PSP health data without documented separate consent creates compliance risk. [HOLD — expert review: specific requirements for secondary use of sensitive personal data require legal professional review]

---

Published: 2026-11-05 · Author: CareSync Team · This article provides general guidance on PDPL considerations for patient support programs in Saudi Arabia. It does not constitute legal advice. All data privacy and consent practices should be designed with qualified legal and regulatory advisors and reviewed against current SDAIA guidance and PDPL implementing regulations.

---

Review your PSP data privacy framework with CareSync. Request a data privacy consultation →