Saudi PDPL study note · 7 July 2026
Mapping the Saudi PDPL into Business Operations
Study notes on processing activities records and the point where a legal structure becomes a live map of systems, vendors, retention and responsibility.
- Reading time
- 3 minutes
- Published through
- Topic
- Privacy and Markets
- Series
- Mapping the Saudi PDPL
About this edition. First published on LinkedIn on 7 July 2026. This site edition preserves the published argument while improving web navigation.
View the original publicationI have been studying the Saudi Personal Data Protection Law through a practical lens: how does a legal framework turn into something an organisation can actually operate?
The point I keep returning to is the record of personal-data processing activities. Many privacy teams would call it a RoPA. I prefer the fuller Saudi wording here because it keeps the focus on the activity itself.
The record is not only a document with fields to complete. It is a way to see how personal data moves through an organisation.
Start with the processing activity
For each activity, ask what actually happens: what data is collected, whose data it is, why it is needed, which system holds it, who can access it, who receives it, how long it remains, whether it leaves the Kingdom and which safeguards apply.
Only then does the legal role become meaningful. The same organisation may act as controller for one activity and processor for another. A single label for the whole business can hide the real structure.
Keep Saudi terminology and direct identifiers visible
Local terminology is part of the discipline. It reduces the risk that a familiar concept from another regime is imported with the wrong assumptions.
The record also needs enough detail to show which data can identify a person directly or in combination. A broad label such as "technical data" may conceal account identifiers, device information, location signals or other elements that matter to the route and risk.
Connect the internal map with transparency and disclosure
The internal record and the information given to people should describe the same operating reality. If a processing activity is absent from the map, it is difficult to explain accurately in a notice. If a notice describes a recipient or purpose the system cannot trace, the gap is operational as well as editorial.
Cross-border flows deserve particular weight because a business-facing tool can look local while its storage, support access or subprocessor chain extends beyond the Kingdom.
Treat retention and responsibility as system questions
A retention field is not complete when it contains a number. The organisation also needs to know what starts the period, which copies it reaches, which exception may pause deletion, who executes the action and what evidence remains.
The same map supports other decisions, including responsibility, officer assessment, vendor review and any applicable registration layer. The record becomes valuable because several governance questions begin from the same factual base.
Keep the record alive
A good record starts ageing immediately. A new vendor is added. A product collects another field. A processor changes its subprocessor chain. Marketing introduces tracking. A retention rule changes.
Vendor onboarding, system changes, launches, incidents and data-subject requests need a route back into the map. Without that routine, the document can be formally correct for one moment and operationally outdated soon afterwards.
The legal requirement creates the record. Governance creates the routine that keeps the record true.