Most Saudi Companies Think They’ve Done Data Mapping. They Haven’t.

The gap between having a spreadsheet and having visibility is bigger than most teams realise.

A field note for DPOs, IT leaders, and data architects working through PDPL in 2026.

Here’s a conversation I keep having with compliance leads in Saudi Arabia.

“We’ve done data mapping.”

I ask to see it.

They send a spreadsheet. Sometimes it’s a polished one — colour-coded tabs, a data dictionary, vendor list, processing purposes documented. Other times it’s the rough draft someone built in a week six months ago that nobody’s touched since.

Both versions have the same problem.

They’re not data maps. They’re snapshots.

And under the Saudi PDPL, snapshots are not what SDAIA is looking for.

The question every privacy programme rests on

Let me start with the question I think every Saudi organisation should be able to answer in 90 seconds:

Where does personal data actually exist in our environment?

Most teams can’t answer this cleanly. And it’s not because they don’t care. It’s because the question is genuinely harder than it sounds.

Customer information lives in the CRM. Employee records sit in the HR system. Marketing teams use SaaS tools that IT didn’t approve. Vendors process data externally. Then there are the copies — email archives, shared drives, cloud storage, backup repositories, the ad-hoc Excel files someone built two years ago that nobody deleted.

The personal data is everywhere. The visibility is nowhere.

This is the gap PDPL data mapping is supposed to close. And it’s the gap most organisations think they’ve closed when they actually haven’t.

Why this is about to become an enforcement problem

The PDPL is built around accountability.

That word does a lot of heavy lifting. In practice, it means: if you can’t show SDAIA where personal data lives, who has access to it, why it’s being processed, and how it moves — you cannot defend your compliance programme.

I’d put it more bluntly. Nearly every other PDPL requirement assumes accurate data mapping is in place:

• Data Subject Rights requests require knowing where someone’s data exists in order to retrieve, correct, or delete it
• Consent management requires knowing which processing activities need consent
• DPIAs require knowing what data flows through which systems
• Vendor oversight requires knowing which vendors process what
• Cross-border transfers require knowing where data is moving
• Breach response requires knowing what’s been exposed

A weak data map quietly breaks all of these. Not all at once. Slowly. Until an audit or a breach exposes the entire stack.

The six questions your team should be able to answer

If I had to compress everything PDPL data mapping is meant to deliver, I’d reduce it to six questions. If your team can answer all six confidently for any data category in your business, you have a working data map. If you stumble on any of them, you have a documentation problem dressed up as compliance.

1. What personal data do we actually collect?

Customer data, employee data, vendor information, marketing data, website visitor data, sensitive personal data. The first time most organisations sit down to list these, they’re surprised by how much enters the business through informal channels.

2. Where is it stored?

Not just the obvious systems — databases, SaaS applications, cloud platforms. Also the unobvious ones: file shares, email archives, backups, employees’ personal accounts being used for work. Most organisations underestimate the second category by a factor of three.

3. Who has access?

Department-level access. System-level access. Vendor access. Who in the organisation is actually accountable for the data category? In a lot of cases, the answer is “nobody specifically” — which is itself the answer.

4. How does it move?

Personal data rarely stays in one place. Internal transfers between systems, third-party processors, vendor integrations, cross-border movements. Mapping movement is often more important than mapping storage, because movement is where most compliance failures happen.

5. Why is it being processed?

Every processing activity should have a documented purpose and a lawful basis. This isn’t a tickbox exercise. SDAIA asks. So do data subjects exercising their rights.

6. How long is it retained?

The honest answer in most organisations is “indefinitely, because nobody owns retention decisions.” This is one of the gaps that costs the most to fix and the most to ignore.

If your team can’t answer these for any major data category in under five minutes, what you have isn’t a data map. It’s an inventory that’s already gone stale.

The data mapping trap

Here’s the part nobody warns you about.

The first time you build a data map is the easy part. You have momentum. The privacy team is engaged. Business owners are answering questions. You produce a document. Everyone agrees it’s accurate.

Six months later, three things have happened:

• Marketing onboarded two new SaaS tools
• HR migrated to a new payroll system
• A business unit started using a generative AI platform that processes customer queries

None of this made it into the data map.

This is why I push back hard on the idea that data mapping is a project. It isn’t. It’s an operational capability. The moment you treat it as one-and-done, the map starts decaying.

The organisations that get this right have a few things in common: clear ownership for keeping the map current, a change-management process that updates the map when new tools are adopted, and a quarterly review cadence with the business. The ones that don’t have these end up rebuilding the entire map every audit cycle — which is expensive, slow, and reactive.

Where most organisations are quietly failing

When I look at where Saudi data mapping efforts are weakest, four patterns recur:

• Unstructured data. Teams map their databases and core applications. They don’t map their email archives, SharePoint, shared drives, or collaboration tools. Which is where a remarkable amount of sensitive data actually lives.
• Shadow IT. Business teams adopt tools without involving IT or privacy. These tools often process personal data and don’t appear in any official inventory. The map looks complete. It isn’t.
• Vendors. Organisations know their own systems better than they know their vendors’. But third parties process huge volumes of personal data. Every data map needs vendor flows in it.
• Cross-border transfers. Global cloud platforms, international service providers, multinational affiliates — data moves across borders constantly. Without visibility into this, transfer risk is invisible. And invisible risk is the kind that becomes a regulatory problem.

The relationship between data mapping and ROPA

A lot of organisations begin their compliance journey by building a Record of Processing Activities. It’s the obvious deliverable. SDAIA expects to see one. Auditors ask for it.

But a ROPA PDPL programme is only as accurate as the data mapping underneath it.

Data mapping tells you: what systems exist, what data flows where, who owns it.

The ROPA documents: processing purposes, legal bases, data categories, recipients, retention periods.

The sequence matters. Map first. Document second. Organisations that try to build the ROPA without doing the mapping discover gaps later — usually during an audit, which is the worst possible time.

A realistic 90-day plan

If you’re starting now, here’s the plan I’d run:

Days 1–30: Discover. Identify your major systems, business processes, data owners, third-party processors, and cross-border transfers. The objective is visibility, not perfection.

Days 31–60: Document. Build data flow diagrams, system inventories, data classifications, and processing records. Start consolidating into a centralised view.

Days 61–90: Operationalise. Assign ownership, set review cycles, build governance controls, integrate change management. This is the part most programmes skip — and it’s the part that determines whether the map stays alive.

The 90 days isn’t the end. It’s the foundation that lets everything else (DSRs, consent, vendor oversight, breach response) function.

The Bottom line

The organisations making real progress under PDPL aren’t the ones with the most polished data inventory documents. They’re the ones treating data mapping as a living operational capability.

Spreadsheets decay. Snapshots go stale. Static documents fail under audit pressure.

Visibility — actual, current, operational visibility into personal data — is what PDPL compliance rests on. Everything else is built on top of it.

If you’re not sure where personal data lives in your organisation right now, that’s the project that needs to start this month. Not the consent banner. Not the privacy notice rewrite. The map.

Without the map, everything else is theatre.

Cyber RT helps organisations across the GCC build privacy compliance programmes that actually work — practical, scalable, and aligned with SDAIA expectations. Learn more at cyberrt.com.

If you’ve worked on data mapping in your own organisation — what’s been the hardest part to keep accurate over time? I’d love to hear in the comments.