Erasing customer data under the Saudi PDPL, in practice

The Saudi personal data protection law gives an individual the right to request destruction of their data. Legal guides explain the right itself. How that right gets executed inside a working system is left to whoever runs the system.

The first discovery: the data is not in one place

The first time I ran an erasure I found traces of the customer scattered well beyond the obvious spot. The customer row itself. The orders attached to it. The email threads, inbound and outbound. The notification log holding their phone and email. The private link that opens their file.

Deleting the customer row alone leaves the phone number sitting in the notification log. That is not compliance.

What must remain, and why

Not everything gets deleted, and the law itself accounts for this. An invoice is a financial record bound by a statutory retention period, and a contract is a document in its own right. The audit trail also has to survive.

The law names the strong action "destruction": an action making the data impossible to view or recover. Records under statutory retention need the softer companion, anonymisation. The invoice stays, and every field identifying its subject gets destroyed within it. The record keeps its number, date and amount, with nothing left in it pointing to a person.

In practice the order row keeps amount and date, while the name, email and phone fields become a marked value recording that erasure happened under a request. A blank field would read as a bug to the next developer who opens the table.

The decision I am glad about

The erasure itself is written to the audit trail: who requested it and when it was carried out, along with the record it touched.

At first this sounds contradictory, erasing data while writing a record about the act. The record states that an erasure happened, not what was erased. Which is exactly the evidence you need when someone asks you to demonstrate compliance.

The trap

Erasure cannot be undone. Put the control behind an explicit confirmation that spells out what is about to happen. A button styled like every other button in the interface is dangerous in this one spot.

The personal data map: make it before you promise

Map your personal data before promising anyone a right to erasure. A promise without the capability behind it is worse than no promise at all, because you cannot destroy what you cannot locate.

Sit down and write out where a customer's name, email and phone actually live in your system. In my case the answer was six places. I expected two of them, and the remaining four turned up through search, since memory alone would have missed them.

Searching by the value itself is the fastest route: take a test customer's email address and run it through every table. Whatever comes back is your map.

The request itself: how it arrives and who executes it

A person needs a declared path for submitting the request; hunting for a contact email address does not count as one. The request also needs a named owner, because "whoever is free" in practice means nobody. Then commit to a time limit, and record both the date the request arrived and the date it was executed.

What the system must prevent

Partial erasure. A customer erased from one table who survives in another is worse off than one never erased at all, because you declared compliance you did not achieve.

So erasure runs as one action passing over every location, not as a button on every screen.

A question that reveals your readiness

If an erasure request arrived today, how long would it take, who would do it, and how would you prove you did?

If any of those answers is "I do not know", start with the map above and work forward from there.

Related reading