PDPL in Practice: The First 5 Steps for Your Data Team

The Personal Data Protection Law (PDPL) is no longer on the horizon — it has been fully enforced since September 2024, with the Saudi Data and AI Authority (SDAIA) as the enforcement authority. Penalties can reach SAR 5 million per violation, and up to SAR 10 million for repeat violations.

Most PDPL guidance, however, is written for legal and compliance teams. It explains what the law requires, not how a data team operationalizes it across hundreds of databases, pipelines, and APIs. This article offers the missing engineering view: the first five steps your data team should take, in order, and what "done" looks like for each.

Step 1: Map where personal data lives (discovery)

You cannot protect — or lawfully process — data you do not know you have. Every PDPL obligation, from consent to retention to breach notification, starts with one question: where is the personal data?

In practice, personal data sprawls far beyond the systems people name first:

• Production databases and the analytics warehouse
• BI extracts, dashboards, and downloaded reports
• Development and test environments seeded with production copies
• Object storage, shared drives, and spreadsheets
• Message queues, logs, and backup snapshots
• SaaS tools — CRM, support desks, marketing platforms

Manual surveys ("please list the personal data in your systems") go stale before the responses are collected. The alternative is automated discovery: connect to your data sources, scan schemas, profile column contents, and flag fields that look like personal data — names, national and iqama ID numbers, mobile numbers, email addresses, IBANs, home addresses, dates of birth.

What "done" looks like: a living inventory of personal data assets in a data catalog, refreshed automatically as systems change — not a spreadsheet that was accurate for one week and then quietly decayed.

Step 2: Classify PII consistently

Discovery tells you where personal data is. Classification tells you what kind it is and how sensitive — which drives everything downstream: access controls, retention periods, masking, and transfer decisions.

Two principles matter here.

One scheme, applied everywhere

Define a single classification scheme aligned with the National Data Management Office (NDMO) classification guidance and the PDPL's categories — including its sensitive data categories such as health data, credit data, and genetic and biometric data. Then apply it at the column level, not just per system. A table is rarely uniformly sensitive; a single column of national IDs changes the handling rules for the entire pipeline that consumes it.

Shared language, not tribal labels

If ten teams invent ten different tags for "national ID," your compliance reports are noise. Anchor classifications to a shared business glossary so that the same concept carries the same label — and the same policy — across the warehouse, the lake, and operational systems. Wherever possible, automate propagation: when a classified column flows into a derived table, the classification should travel with it.

What "done" looks like: every column known to hold personal data carries a classification tag from a single approved scheme, and new datasets inherit classifications automatically.

Step 3: Know the flows — lineage, including APIs

The PDPL governs processing, and processing is movement: pipelines that copy customer records into the warehouse, transformations that join HR data with payroll, integrations that send personal data to third parties or across borders.

This is where data lineage becomes a compliance instrument rather than an engineering convenience. Lineage answers the questions regulators and data subjects actually ask:

• Where did this personal data originate, and on what legal basis was it collected?
• Which downstream systems, reports, and models consume it?
• If a data subject requests destruction, where are all the copies?
• If a breach hits one system, what is the blast radius?

One blind spot deserves special attention: APIs. In most organizations, the highest-volume personal data flows leave through APIs and integrations rather than batch pipelines — and they are rarely documented with the same rigor. Treat API governance as part of your lineage picture: which endpoints expose personal data, to whom, and under what agreement.

What "done" looks like: end-to-end lineage from source systems to every point of consumption — dashboards, exports, APIs, third parties — that updates as pipelines change.

Step 4: Assign ownership

An inventory without owners is a museum. Every dataset containing personal data needs two named roles:

• Owner — accountable for decisions: who may access the data, how long it is retained, whether it may be shared or transferred.
• Steward — responsible for the day-to-day: keeping metadata accurate, resolving classification questions, acting on quality issues.

This is not only a PDPL practicality. Ownership and stewardship is a core domain of the NDMO data management framework (15 domains, 77 controls, 191 specifications), so the same role assignments serve both NDMO compliance and the PDPL.

Tie these roles into your data management office structure, and record them against the assets themselves — in the catalog, next to the classification and lineage — so that when a question arises about a specific table, the responsible person is one click away, not one email chain away.

What "done" looks like: no personal data asset without a named owner and steward, visible exactly where the data is documented.

Step 5: Build standing evidence

The PDPL requires controllers to maintain records of their processing activities, and SDAIA may request them. Breach notification timelines are tight — 72 hours under the implementing regulations. A compliance posture assembled by hand for an annual review cannot answer on that clock.

The alternative is standing evidence: documentation generated as a by-product of daily work rather than reconstructed under pressure.

• The personal data inventory is the catalog itself, refreshed continuously
• Classifications are tags on real columns, not rows in a slide deck
• Flows are lineage graphs generated from actual pipelines and APIs
• Ownership is recorded on every asset
• Changes — who classified what, who approved access, when policies changed — are versioned and auditable

When an auditor, a regulator, or a data subject asks a question, the answer is an export from the system of record, not a two-week scramble across teams.

What "done" looks like: you can produce your processing records, classification coverage, and flow documentation on demand — dated today.

Where to start this week

Do not try to boil the ocean. Pick one high-risk domain — customer data or HR are the usual candidates — and run the five steps end to end: discover, classify, trace, assign, evidence. The first domain teaches you the method; everything after it is repetition with better tooling.

And if you are looking for a platform built for exactly this sequence — automated discovery, column-level classification, lineage that includes APIs, ownership and stewardship, and audit-ready evidence aligned with Saudi requirements — see how Goava supports PDPL compliance or talk to our team.