Every organization I have worked with that faced a data-protection audit — whether from a regulator, a client, or an internal risk function — shared the same anxiety. Not about whether their intentions were good. About whether they could prove it. Because that is what PDPL, Saudi Arabia's Personal Data Protection Law, actually demands: not a policy on a shelf, but a system of controls that leaves evidence.
The law is not vague. It requires organizations to know what personal data they hold, why they hold it, who has access, how long it is kept, and how individuals can exercise their rights. It requires contracts with every third-party processor. It requires breach notification procedures. And it requires all of this to be documented and demonstrable — which is the part most organizations underestimate by a wide margin.
This article is a builder's checklist: the layers you need to stand up, in the order that makes sense, so that when the auditor walks in — or when a data subject exercises their rights — you are not scrambling.
01 — Data inventoryThe map before the plan
A data-protection program cannot be designed from a conference room. It has to be built from a ground-truth understanding of what personal data the organization actually handles — and that almost always reveals surprises: the HR spreadsheet on a shared drive, the customer list in a CRM that nobody administers, the backup tapes in a cupboard, the legacy system that nobody remembers but still holds employee records from a decade ago.
The first deliverable is a data map: a catalogue of every system, database, spreadsheet, cloud service, and physical file that contains personal data. For each one, you need to document what categories of data are stored (names, ID numbers, financial details, health data, biometrics), how many records, where it lives (server, jurisdiction, cloud region), who has access, how long it is retained, and whether it is shared with any third party. This is tedious work. There is no shortcut, and any vendor who promises an automated tool that will do it for you is selling a starting point, not an answer.
"We have a data-protection policy" and "We know where all our personal data lives" are two different statements. An auditor will ask for the second one.
The data map is not a one-time exercise. It needs to be maintained — every new system, every new vendor, every new process that touches personal data should update it. The organizations that treat it as a living document are the ones that pass audits without last-minute panic.
02 — Legal basisWhy you are processing each category
PDPL, like most modern data-protection frameworks, is built on the principle that processing personal data requires a lawful justification. There is no blanket permission to collect data because it might be useful later. Each use case needs a specific basis: consent, contractual necessity, legal obligation, vital interest, or legitimate interest.
Most organizations discover, during this exercise, that a significant portion of their data processing has no clear legal basis. It is happening because it always has — "HR has always collected emergency contacts," "marketing has always used the customer list for newsletters" — with no documented rationale. Fixing this means either finding the basis or stopping the processing. There is no middle ground that will satisfy an auditor.
Consent deserves special attention because it is the most commonly misused basis. A checkbox on a form is not valid consent unless it is freely given, specific, informed, and revocable. Pre-ticked boxes, implied consent, and consent bundled into a terms-of-service agreement do not meet the standard. If consent is your basis, you need to be able to show how it was obtained, what exactly the individual agreed to, and how they can withdraw it as easily as they gave it.
03 — Technical controlsEnforcement by design
A policy that says "access to personal data should be restricted" is not a control. A control is a technical configuration: role-based access in the system that prevents the payroll clerk from seeing health records, an automated retention rule that deletes files after the mandated period, an encryption setting that renders data unreadable if the storage is compromised.
This is where many programs stall, because it requires cooperation from IT and system owners that the compliance team cannot command. The data map from step one becomes the leverage: here is what exists, here is what the law requires, here is what needs to change in your system. Without the data map, the conversation stays abstract. With it, every gap has a location and a fix.
Three controls matter most: access (who can read, write, and delete each category), retention (how long each category is kept and how deletion is enforced), and encryption (at rest and in transit). If these three are technically enforced and auditable, the program has a foundation. Everything else is refinement.
The minimum technical controls
- Role-based access control mapped to data categories — not systems
- Automated retention and deletion schedules per data class
- Encryption at rest and in transit for all personal data
- Logging of all access to personal data, with alerts for anomalies
04 — Rights-response workflowsThe machinery of the law
PDPL gives individuals specific rights: to know what data is held about them, to request a copy, to correct inaccuracies, to request deletion, to restrict processing, and to port their data to another provider. Each of these rights implies a workflow that the organization must be able to execute on demand, within a statutory timeframe.
The most commonly underestimated right is the subject-access request. Responding to an SAR means finding every instance of a person's data across every system — including backups, archives, and third-party processors — and compiling it into a response. Without a data map, this is nearly impossible. With one, it is a methodical process. The difference between the two is the difference between a program that works and one that panics.
Each workflow needs: an owner, a documented procedure, a template response, an internal SLA that is tighter than the legal deadline, and a log of every request received and how it was handled. The log is what the auditor will ask for.
05 — Third-party riskYour vendors are your liability
PDPL holds the data controller responsible for the actions of every processor it engages. A breach at a payroll provider, a cloud host, or an email marketing platform is the organization's breach — not the vendor's. This changes the procurement conversation fundamentally.
Every vendor that touches personal data needs: a data-processing agreement with PDPL-specific clauses, a documented scope of what data they access and why, evidence of their own security controls (SOC 2, ISO 27001, or equivalent), and a contractual right to audit. The agreement should cover breach notification — the vendor must notify you within a defined window, not whenever they get around to it.
The practical challenge is that most organizations have dozens, if not hundreds, of vendors — and most existing contracts have no data-protection provisions. The program needs a remediation plan: high-risk vendors first, a deadline for compliance, and a clear escalation path if a vendor refuses to sign.
06 — Evidence and audit readinessProof, not promises
This is the layer that separates a program that looks good on paper from one that survives inspection. An auditor will not ask to see your policy. They will ask for the data map, the access logs, the retention schedules, the deletion records, the SAR log, the third-party agreements, the breach-reporting drill results. They will ask for evidence that each control is operating as designed.
Building audit readiness means designing for evidence from the start. Every control should produce a record: a log entry every time personal data is accessed, a timestamp every time a retention rule runs, a signed acknowledgement every time a processor agreement is updated. If it does not produce evidence, it is not a control — it is an intention.
"Trust us, we take data protection seriously" is not an audit response. "Here is the log, here is the policy, here is the signed agreement, here is the timestamp of the automated deletion" is an audit response.
The most practical advice I can give: run a mock audit six months before the real one. Pick a data category, a right, and a third party, and simulate the full inspection process. The gaps you find will be uncomfortable. They will also be fixable, because you still have time. Most organizations discover, during a mock audit, that their data map is incomplete, their access controls have exceptions they did not know about, and their vendor agreements are missing key clauses. Those are all problems you want to find in a simulation, not in a regulatory finding.
What this means in practice
The six layers are not sequential in the sense that you finish one and move to the next. They overlap and feed each other. The data map reveals gaps in controls. The controls reveal gaps in vendor agreements. The SAR workflow reveals gaps in the data map. The program is a cycle, not a checklist you complete once.
But the order matters. Start with the map. Without it, every other layer is guesswork. Build the technical controls next — they are the hardest to retrofit. Then stand up the rights-response workflows and vendor agreements. And throughout, design for evidence so that when the auditor walks in, the program speaks for itself.
PDPL compliance is not a project with an end date. It is an operating discipline.