Consider what the rest of the Saudi healthcare reform agenda actually requires an organisation to do with data. The NPHIES intelligence opportunity requires interrogating patient-level diagnosis, procedure, and prescribing records across millions of transactions. AI deployment in clinical settings requires training and running models on patient data. Fraud detection requires pattern analysis across the full claims universe. Population health management requires risk-stratifying individual patients by their complete medical history. Every one of these capabilities, which the reform environment now treats as essential, is an act of processing the single most protected category of personal data under Saudi law. And the law governing that processing has been fully enforced, with criminal penalties, since September 2024.
The Personal Data Protection Law was enacted by Royal Decree M/19 in 2021, amended in 2023, and came into full force on 14 September 2024 after a one-year grace period. It is overseen by the Saudi Data and Artificial Intelligence Authority. It applies to every organisation processing the personal data of individuals in Saudi Arabia, public or private, domestic or foreign. Health data sits in its most protected tier: sensitive personal data, where unlawful disclosure can carry imprisonment of up to two years and fines up to SAR 3 million, with general violations attracting fines up to SAR 5 million, doubled for repeat offences. SDAIA is not waiting. Its enforcement committees issued 48 decisions confirming PDPL violations across 2025 and 2026.
The strategic problem this creates is specific and underappreciated. The healthcare organisations racing to build analytical capability are, by definition, the organisations increasing their processing of sensitive health data fastest. The analytics ambition and the compliance exposure grow from the same activity. An organisation that successfully advances from NPHIES Level 1 to Level 4 maturity has also, in the same motion, multiplied the volume and sophistication of its sensitive-data processing. If the data governance foundation has not been built in parallel, the analytics achievement is also a liability accumulation.
Why Health Data Is the Hardest Case
Health data is not merely one category of sensitive personal data under the PDPL. It is the category where the gap between routine operational handling and lawful processing is widest, because healthcare organisations have historically treated patient data as a clinical and billing asset rather than as regulated personal data with consent, retention, and disclosure obligations attached.
The PDPL requires a lawful basis for every act of processing. In a healthcare setting, the lawful basis for treating a patient is generally clear. The lawful basis for using that same patient's records to train a fraud detection model, to build a population health risk score, to benchmark provider performance, or to feed an AI diagnostic tool is a different question entirely, and one that most organisations have not formally answered. Secondary use of health data for analytics is precisely where the lawful-basis analysis becomes complex, and precisely what the analytics agenda depends on.
Consent is similarly more demanding in the health context. The PDPL sets requirements for how consent is obtained, recorded, and withdrawn. A patient consenting to treatment has not thereby consented to every downstream analytical use of their data. Organisations building analytics capability on the assumption that treatment consent covers analytical processing are making an assumption the regulation does not support.
The organisations advancing fastest on analytics are increasing their sensitive-data processing fastest. The ambition and the liability grow from the same activity. Building the analytical capability without building the data governance foundation in parallel does not avoid the exposure. It accumulates it.
The Controller Obligations Most Healthcare Organisations Have Not Mapped
Under the PDPL, an organisation that determines the purpose and means of processing personal data is a Controller, with a defined set of obligations. Most Saudi healthcare organisations are Controllers of vast quantities of sensitive health data and have not formally established what that status requires of them.
The obligations include maintaining records of processing activities, with data categories, purposes, legal bases, and retention periods documented. They include registration considerations under the National Register of Controllers. They include appointing or designating responsibility for data protection, with the Implementing Regulation setting expectations for a data protection function. They include conducting impact assessments for high-risk processing, of which large-scale sensitive health data analytics is a clear example. They include implementing technical and organisational safeguards proportionate to the sensitivity of the data. And they include defined breach notification obligations when personal data is compromised.
Each of these is a discrete piece of governance infrastructure. None of them is automatic. An organisation can have sophisticated analytics and no records of processing activities. It can run AI models and have no impact assessment. It can hold decades of longitudinal patient data with no defined retention policy. The analytical capability and the compliance infrastructure are independent, and in most organisations the former is now ahead of the latter.
The Third-Party Processing Exposure
The analytics agenda is rarely delivered entirely in-house. Healthcare organisations engage technology vendors, analytics providers, cloud infrastructure, AI developers, and consulting partners, many of whom process sensitive health data on the organisation's behalf. Under the PDPL, this is a Controller-to-Processor relationship with specific contractual requirements, and where data moves outside the Kingdom, the cross-border transfer provisions apply.
SDAIA has issued Standard Contractual Clauses governing transfers in four configurations: Controller to Controller, Controller to Processor, Processor to Processor, and Processor to Controller. Healthcare organisations using international cloud platforms, offshore analytics teams, or foreign AI vendors are conducting cross-border transfers of sensitive health data that require this contractual architecture to be lawful. The organisation that has signed a standard commercial vendor agreement without the PDPL-required data processing terms and transfer mechanism has a compliance gap embedded in its supply chain, and the Controller, not the vendor, carries primary accountability for it.
Data governance exposure points
- Lawful basis for using member claims data in fraud detection, underwriting models, and risk stratification beyond the original insurance purpose
- Controller-processor agreements with TPAs, analytics vendors, and reinsurers handling member health data
- Cross-border transfer compliance where claims data moves to offshore analytics or international group functions
- Retention policy for longitudinal member health records used in actuarial and PHM analysis
- Breach notification readiness for the large sensitive-data holdings a payer accumulates
Data governance exposure points
- Lawful basis for secondary use of patient records in AI deployment, benchmarking, and research
- Consent architecture distinguishing treatment consent from analytical and research processing
- Controller-processor terms with EHR vendors, AI diagnostic providers, and cloud hosts
- Impact assessments for high-risk processing such as AI clinical decision support
- Data subject rights handling: access, correction, and the operational capability to respond
Why This Is a Board Question, Not an IT Question
The instinct in many organisations is to treat data protection as a technical or IT matter, delegated below the executive level. The PDPL structure makes that instinct a governance error. The penalties include criminal liability. The accountability sits with the Controller as an organisation and, in the case of sensitive-data disclosure, can reach individuals. The exposure is not a systems configuration issue. It is an organisational liability that intersects every strategic analytics decision the board is being asked to approve.
This is the connection that makes data governance a board-level concern in the specific Saudi context. Every reform-driven analytics investment the board considers, whether NPHIES intelligence capability, an AI deployment, a fraud analytics platform, or a population health programme, carries an embedded PDPL dimension. A board approving the analytics investment without understanding the data governance obligation is approving the liability without pricing it. The organisations that have integrated data protection into their analytics governance, rather than running it as a parallel compliance function, are the ones positioned to advance their analytical capability without accumulating unpriced regulatory risk.
The data governance foundation is not a constraint on the analytics agenda. It is the precondition for pursuing it without liability. The organisations that build the two together will advance. The organisations that build analytics ahead of governance are building on a foundation the regulator has already demonstrated it will enforce.