PDPL Compliance for Clinics: A Practical Checklist
Patient data is sensitive data under the law. Compliance isn't a document you write once — it's daily controls: who sees what, how long data is kept, and what happens on a breach. Here's a working checklist.
Saudi Arabia's Personal Data Protection Law (PDPL) governs the collection and processing of personal data, and is overseen by the Saudi Data and AI Authority (SDAIA). Health data is classified as sensitive data, which carries stricter controls than ordinary personal data.
For a clinic, the practical translation is simple: everything you collect about a patient has a lawful basis, an access boundary, a retention period, and a deletion path. This article turns that into an executable checklist.
Note
This is general explanatory content, not legal advice. The law and its implementing regulations evolve, and application varies by organisation size and activity — work with qualified counsel when building your compliance programme.
1. Know what you actually collect
You can't protect what you don't know exists. The first practical step is a data inventory: where patient data lives in your clinic today — not where it's supposed to live.
- The clinic management system (patients, records, invoices)
- Paper appointment books, if any remain
- WhatsApp threads on staff devices
- Excel files on front-desk machines
- X-ray images and reports on the imaging devices themselves
- Email containing patient reports
- Backups, and wherever they are stored
WhatsApp on personal phones
The single most common leak source in regional clinics. Photos of reports and lab results sit in a staff member's camera roll long after they've left the job. The rule: patient communication goes through the system, not through personal devices.
2. Establish lawful basis and minimise collection
Every field you collect needs a reason. The practical test: "if asked why I require this field, do I have an answer?" If not, the field is surplus and should be removed — data you never collect can't leak.
| Data type | Legitimate purpose | Note |
|---|---|---|
| Name and ID number | Patient identification, billing, insurance | Necessary |
| Mobile number | Appointment reminders and communication | Necessary, with opt-out for marketing messages |
| Medical history | Delivering care safely | Sensitive data — highest protection level |
| Before/after photos | Clinical documentation | Needs separate explicit consent, especially for any marketing use |
| Payment details | Collection | Card data should not be stored by the clinic — leave it with the payment provider |
| Next-of-kin details | Emergency contact | Collect the minimum only |
3. Access controls: who sees what
This is where most clinics fail, because the easy answer is to give everyone full access. The result: a receptionist can open any patient's complete medical history for no reason.
- Separate roles: front desk, nursing, physician, accounting, management — each with a different scope.
- Apply least privilege: the front desk needs name, appointment, and payment status, not the diagnosis.
- Scope access by branch: staff at one location shouldn't see another location's patients by default.
- Log every access: who opened which file and when. An audit log isn't a luxury — it's what lets you answer when a complaint arrives.
- Review permissions regularly: especially after any staff departure.
- Enable two-factor authentication on accounts with broad privileges.
A practical test
Ask your system for a report of everyone who opened a specific patient's file in the last month. If you can't produce it within a minute, you don't have a working audit log regardless of what the vendor says.
4. Patient rights and how to answer them
The law grants data subjects specific rights. A clinic needs a defined path for each request rather than improvising when one arrives.
- Right to be informed: patients should know what is collected and why — via a privacy notice written in plain language, in Arabic.
- Right of access: obtaining a copy of their data. Export must be a system function, not a manual project.
- Right to correction: fixing inaccurate data, with the change retained in the audit trail.
- Right to destruction: requesting deletion, within the bounds of other legal record-keeping obligations.
- Withdrawal of consent: particularly for marketing uses — opting out of messages must be immediate and easy.
5. Retention and deletion
Keeping everything forever isn't a policy — it's the absence of one. Conversely, deleting early can violate separate medical record-keeping obligations. What's required: a defined, written period per data type, enforced automatically when it expires.
- Set a retention period per category: clinical records, billing data, communication logs, job applicant data.
- Check the medical record retention obligations applicable to healthcare providers before fixing any period.
- Automate deletion after expiry rather than leaving it as a task someone must remember.
- Apply the policy to backups too — an eternal backup silently voids the whole deletion policy.
6. Vendors and data transfers
Using a cloud system, a messaging provider, or a payment processor means a third party processes your patients' data on your behalf. Your responsibility to the patient does not transfer with it.
- Require a written data processing agreement from every vendor that touches patient data — our Data Processing Agreement is one example of the expected shape.
- Ask explicitly: where is the data stored geographically?
- Check the controls on transferring data outside the Kingdom before adopting any provider that stores it abroad.
- Get clarity on how and how quickly they will notify you of a security incident on their side.
- Keep an up-to-date list of every vendor processing your patient data.
7. Incident readiness
A security incident isn't a remote hypothetical. The most common one in clinics isn't a sophisticated intrusion — it's a lost device or an email sent to the wrong recipient. The difference between a contained incident and a catastrophic one is a plan written in advance.
- Name one person who is notified immediately when any incident is suspected.
- Write the first containment steps: disable the account, rotate passwords, isolate the device.
- Document what happened, when, and which data was affected — from the audit log.
- Know in advance the reporting requirements to the competent authority and the applicable deadline.
- Notify affected individuals where required, in clear language, with what they can do about it.
The short checklist
- A complete inventory of where patient data lives
- An Arabic privacy notice visible to patients
- Removal of fields collected without a clear purpose
- Separated roles and permissions, not one shared account
- A working audit log you can actually run a report from
- Two-factor authentication on administrative accounts
- A written retention policy, enforced automatically
- Data processing agreements with every vendor
- A written incident response plan the staff knows
- Permission review on every staffing change
Privacy controls built in, not bolted on
3yadtk provides role- and branch-scoped permissions, an audit log on every access to patient data, and full data export on request.
Read about our security approach