PDPL in Practice: What a Saudi Company Actually Has to Do

Most companies respond to the PDPL by writing a privacy policy and putting it in the footer. That is the easy part and the least of it. The law creates obligations your software has to be able to carry out — finding a person's data, correcting it, deleting it, and explaining why you held it at all.

Start by knowing what you hold

You cannot protect, produce or delete what you have not listed. A data inventory sounds bureaucratic until the first request arrives and nobody can say whether the marketing platform, the old CRM and the support inbox each hold a copy of the same customer. In most companies they do.

• What personal data you hold, where it lives and who can see it
• Why you hold each item — the lawful basis, written down
• How long you keep it, and what deletes it when that expires
• Who else receives it: processors, analytics, messaging providers
• Where it is stored, and whether it leaves the Kingdom

The requests are the real test

A person may ask what you hold about them, ask you to correct it, withdraw consent or ask for deletion. Each of those has to be answerable within the time the law allows. If it takes three people and a week of database queries, that is not a compliance programme — it is a compliance risk.

Collecting a field because it might be useful one day is the most common way companies create an obligation they gain nothing from.

Design it in, rather than bolting it on

The practical version of this is unglamorous: collect less, log access, set retention on every table that holds personal data, encrypt what matters, and build the export and delete routines while you are building the feature. Adding them to a live system two years later costs many times more.

None of this is legal advice — take that from a lawyer who knows your sector. But the engineering work behind it is predictable, and it is far cheaper to do while the system is being written.