You Cannot Delete What You Have Not Inventoried: PDPL as an Engineering Problem

The Personal Data Protection Law was issued by Royal Decree M/19 dated 9/2/1443H and amended by Royal Decree M/148 in 2023. It came into force on 14 September 2023 with a one-year grace period that ended on 14 September 2024. Its Implementing Regulations and the Regulation on Personal Data Transfer Outside the Kingdom were issued on 7 September 2023, and the transfer regulation was replaced by a new version on 1 September 2024. Those are dates you can check, and what has happened since matters more than any of them: in the twelve months to mid-January 2026, the violations committees at the Saudi Data and Artificial Intelligence Authority issued 48 decisions confirming breaches of the law, on grounds including processing without a lawful basis, disclosure of personal data without legal justification, and failure to take the organizational, administrative and technical measures required to protect it.

Read that list of grounds again. Two of the three are engineering findings. Yet every time I have watched this law land, it arrived as a legal work package: a privacy policy, a consent notice, a records template, a training module, and a checklist handed to IT somewhere near the end with a request to confirm the controls are in place. That order is backwards, and the reason is not that legal did anything wrong. A privacy policy is a public claim about a system. It states which categories of personal data you hold, why you hold them, who you share them with, how long you keep them, and what happens when someone asks you to stop. Every one of those sentences is a factual assertion about databases, queues, object stores, log pipelines, third-party interfaces and backup media. Legal cannot verify a single one of them. Only the people who run the systems can, and until they have, the policy is a well-drafted guess.

Drafting the policy takes weeks. Building the map that makes the policy true takes quarters, and it competes for the same engineers who are shipping product. Organizations that reverse the sequence, mapping first and drafting against what the map says, spend more calendar time up front and far less on rework, because they never publish a commitment they cannot keep.

An inventory of systems is not a data inventory. A list saying we run a policy administration platform, a customer relationship system, a claims application and a data warehouse tells a regulator nothing. The unit of the inventory is a data element in a place: which column in which table, which field inside which payload, which object prefix in which bucket, which index in which log store, which column in which reporting extract.

The places people miss are always the same, and none of them are the primary database. Application logs that capture a full request body when a call fails. Error-tracking tools that ship a stack trace with a customer identifier attached. Analytics events. The reporting extract someone built for a monthly pack and never retired. Test and staging environments seeded from a production copy because that was the fastest way to reproduce a defect. Message queues with a retention window nobody set deliberately. A support ticket where an agent pasted a national ID to describe the problem.

The Implementing Regulations give you the shape of the artifact you are building toward. The record of processing activities has to carry the categories of personal data, the purposes, the recipients, the transfers outside the Kingdom, the retention periods and the security measures applied — and it has to be kept for five years after the processing it describes has ended. Notice what that means operationally: the record outlives the processing. A record assembled by interview will be wrong within a quarter and unmaintainable within a year. A record generated from a scanned and tagged catalog survives, because when the schema changes the record changes with it.

SDAIA has published the supporting material — a guideline on records of processing activities, a self-assessment guideline, a privacy policy guideline, and rules governing the National Register of Controllers — and it operates the National Data Governance Platform that carries that register. Private-sector entities whose main activity is the processing of personal data, and those processing sensitive personal data, sit inside the registration population. An insurer sits inside it twice over.

A controller must respond to a data-subject request within thirty days, extendable once by a further thirty where the request requires unusual effort or where the same person has submitted several. You will read that failure to honor data-subject rights is among the most commonly cited findings in SDAIA enforcement. Nobody outside the Authority knows that: it does not publish the reasoning behind individual decisions, and the grounds it has named in public are the ones in the section above. The breach clock is tighter: notification to the Authority within seventy-two hours of becoming aware, submitted through the National Data Governance Platform, and notification to the affected individuals without undue delay where harm is likely.

Both clocks do the same thing to an IT function. They convert a governance question into a distributed-systems question with a deadline attached. An access request is a fan-out query across every store that might hold that person, executed by people, under time pressure, and the answer has to be complete rather than plausible. A deletion request is the same fan-out with a write at the end of it and a proof obligation on top.

If your answer depends on one engineer remembering that a legacy quotation service kept its own copy, you do not have a process. You have a person, and people take leave.

Teams that miss the window almost never miss it because thirty days is short. They miss it because the window goes to establishing which systems are in scope, and the retrieval itself takes an afternoon. That is the inventory bill arriving with interest. Build the map first and the request becomes a query; skip the map and every request re-runs the discovery from the beginning, at the same cost, forever. So run it as a service with a service level, because that is exactly what it is: a named owner, a defined intake channel, an internal target set well inside the statutory window rather than at it, an escalation path, and a log of every request and how long each one took. I built a catalog of more than a hundred services at a Saudi holding group where every entry carried a service level, and the discipline transfers directly — except that a data-subject request is a service you owe a stranger, on a clock written into law rather than into a contract.

And if thirty days is the number most people quote, the number that decides the outcome is five. Once the Authority notifies you of an alleged violation, you have five days to file your response with the committee. The decision that follows is notified within fifteen days, and an appeal to the competent court runs sixty days from that notification. Five days is not enough time to go and find out where personal data lives. It is only enough time to report what you already know. Either the inventory exists on the day that letter arrives and you answer it, or it does not and you spend those five days writing an apology. Which is also why an intake channel routing to an unattended mailbox is a finding waiting to be written.

I lead integration delivery at Rasan, and the development under it, in a company whose product runs on other people's personal and health data. So take this as an operating position rather than a caution: every integration you build is a door personal data can leave through, and the number of doors grows faster than the number of people who remember they exist.

The contract is necessary and it is not sufficient. A processing agreement makes a third party accountable. It does not stop your service from sending them more than they need. The enforcement point is the payload, not the paperwork. If a partner needs to know whether a policy is active, send a status, not the policyholder object. If a print vendor needs a name and an address, do not hand over a full profile because the existing schema was easier to reuse. Field-level minimization belongs in the integration layer and in code review, where somebody can see it, rather than in a clause read once at signature.

For an insurer this stops being a general principle and becomes a specific instruction. Health data has its own treatment under Article 23 of the law and the regulations beneath it: access is restricted to the minimum number of employees necessary to deliver the service, and the processing of health data has to be documented at every stage. Credit data carries a comparable regime under Article 24. Read those two obligations as an engineer and they are role-based access control and end-to-end lineage, written in legal grammar. You cannot restrict access to the minimum number of people across systems you have not enumerated, and you cannot document every stage of processing when one of the stages is a middleware component that logs the request body on failure.

Then extend the map outward, because it does not stop at your perimeter. Your processor has processors. Your observability vendor sees whatever your traces carry. Your support tool holds whatever an agent pasted into it. Your mail security gateway holds message bodies. Each of those is a place, and each belongs in the same register as the claims database, scored the way I score any vendor against its commitments — because a processor who cannot tell you which region holds your data has already answered the question.

Article 29 sets the conditions for moving personal data outside the Kingdom: the transfer must serve a permitted purpose, it must not prejudice national security or the Kingdom's vital interests, the destination must offer an adequate level of protection as determined by the competent authority, and only the minimum necessary data may move. The amended Regulation on Personal Data Transfer Outside the Kingdom was published on 1 September 2024. SDAIA has since published four modular sets of standard contractual clauses — controller to controller, controller to processor, processor to processor, processor to controller — alongside binding common rules and accreditation as alternative safeguards, and in February 2025 a guideline on the risk assessment you must run before relying on those safeguards.

Here is the part I would rather not have to write, and it is the honest state of the question as I understand it in August 2026. SDAIA has not published the list of countries and international organizations deemed to provide an adequate level of protection. The mechanism exists in the regulation; the list is not there to read. So an architect cannot look up the answer to the simplest question there is: may this workload run in that region? The advice circulating among counsel is to stay inside jurisdictions already judged adequate under the European framework and to paper the transfer with the Saudi clauses regardless. That is prudent. It is not the same as knowing, and I will not present it as though it were.

Design, then, for a variable you cannot yet read. Region becomes configuration rather than assumption. You should be able to answer from a register, not from memory, which region every tenant of every service you buy is pinned to, whether that provider replicates to a second region for its own resilience, and whether its support organization can read production data from outside the Kingdom. That last one catches people. A workload can be hosted in-Kingdom and still be readable by an offshore support desk, and that is a transfer.

Your own sector often makes the decision earlier and firmer than the general law does. The Saudi Central Bank (SAMA) treats hosting regulated data offshore as something requiring its prior approval rather than an engineering preference, which is why many providers simply host in-Kingdom and remove the question. Insurance supervision has since moved to the Insurance Authority, and I have found no published instrument applying the same rule there, so that is a question I would put to the supervisor rather than settle by analogy with the SAMA position. The National Cybersecurity Authority's Cloud Cybersecurity Controls, CCC-2:2024, bind cloud service tenants and not only cloud service providers, and have been updated to reflect data-localization requirements, so buying the service does not move the obligation onto the vendor. Work out which rule is actually driving the decision before you argue about it in a design review.

SDAIA's guideline on the destruction, anonymization and pseudonymization of personal data, published on 3 September 2024, is clear about the standard: destruction means the data is permanently deleted and cannot be retrieved, and anonymization must be irreversible, so that the individual can no longer be identified. The same guideline goes further than the vendors will tell you. Archiving and backup do not count as destruction, data held that way stays personal data under the law and its regulations, and a destruction has to reach every copy held in the controller's systems, backup copies included.

That is the regulator saying, in its own words, that the copy you moved to cold storage is still the record.

The standard sits in direct tension with two things every regulated technology function is separately required to operate. The first is immutable backup. Write-once media, object-lock storage and air-gapped copies exist precisely so that nobody — including you, including an attacker holding your credentials — can selectively alter their contents. That property is the control. The second is the append-only audit log, which is worth what it is worth only because entries cannot be removed.

I own business continuity in my current role, so let me say the quiet part plainly: if you restore a backup taken before a deletion was executed, you have re-created the record you deleted, and unless something replays the deletion after the restore, it stays re-created.

You cannot solve that by editing the backup. One technique actually reaches media you are not permitted to modify: encrypt per data subject or per tenant and destroy the key, so the ciphertext survives on the immutable copy and the plaintext does not. Everything else is containment. Maintain a suppression register of executed deletions and replay it as a mandatory step in every restore runbook, exercised in the restore drill rather than assumed. Set backup retention windows short and deliberate, so a residual copy carries a known expiry date instead of an indefinite one. Separate the audit record from the personal data it refers to: the log has to prove an action occurred against a subject, which a token can do, not carry the subject's identity in the clear.

Where I stop is at the claim that this resolves the tension. I do not know of a published position from the Authority reconciling the erasure standard with immutable backup media and the retention obligations other regulators impose, and I am not going to construct one and present it as guidance. What I do instead is write the residual down: which copies survive a deletion, on what media, for how long, protected by what, and the date they expire on their own. That paragraph belongs in the record of processing and in the answer given to the data subject. The version I can defend names the object-locked copies that still carry the ciphertext, the key that was destroyed so that nothing can read them, and the date the last of them runs out.