PDPL and patient enquiries: what the law asks of a clinic

The moment a patient sends a clinic their name and a question about a treatment, that is personal data under Saudi law. That status does not wait for the enquiry to become an appointment, or for the details to reach a medical record. It applies from the first message.

This is a plain-language orientation and not legal advice, so take anything that touches patient data past your own counsel before you rely on it.

Under PDPL the controller is whoever decides why and how personal data is used, and for patient enquiries that is always the clinic. If a marketing agency, a call centre or a service like ours answers those messages, that party is a processor: it acts on the clinic's instructions and nothing more.

This matters because the obligation does not move with the work. A vendor answering your WhatsApp takes the labour, not the responsibility, and it adds a party you now have to be able to account for.

Data minimisation is the part clinics most often get wrong, usually by being helpful, and a booking conversation needs a small set of fields:

1. 1A name, so the patient can be addressed and found again
2. 2A contact number, on the channel they wrote from
3. 3The treatment they asked about, which is a service interest and not a diagnosis
4. 4The appointment, once there is one
5. 5A record of consent, so you can show what they agreed to and when

Nothing in that list is a medical record. A conversation that starts collecting symptoms, history or images has stopped being an enquiry, and it has become something with a much higher duty of care attached. Anything clinical should reach the clinic's own staff rather than sit in an enquiry inbox.

The documents matter more than the intentions, because the documents are what you can produce later.

• A processing agreement naming the clinic as controller and the vendor as processor, signed before any data moves
• A written scope of what the processor may see and what it may never touch
• A breach procedure with a stated window for telling the clinic and the regulator
• A retention and deletion position: how long enquiry data is kept, and what happens at the end
• An export route, so the clinic can take its data out at any point

If a vendor cannot produce these before starting, the honest reading is that they have not been asked before.

Data residency and cross-border transfer are the questions that most often get answered vaguely. Ask directly where enquiry data is stored, and ask whether any part of the chain, including any model or subprocessor, sits outside the Kingdom.

A vendor who answers with a brand name rather than a location has not answered. The location is a fact about a server, and anyone operating the system knows it.

A patient who messages to ask a price has not consented to being marketed to for the next two years. If enquiry data is later used for campaigns, that is a separate purpose and needs its own basis.

Keep the record of what was agreed and when, because the value of a consent record is entirely in being able to produce it. That means it has to exist as data rather than as a policy someone wrote once.

The short version: who is the controller, what exactly do you see, where does it live, what happens on a breach, and how do I get it all back. If those five have clear answers in writing, most of the rest follows.

A vendor who answers a data residency question with a brand name has not answered it.