On this page
- What is personal data discovery under the PDPL?
- Why does the PDPL require you to know where personal data is?
- What counts as personal data and sensitive data under the PDPL?
- Where does undocumented personal data usually hide?
- How do you run a PDPL data discovery project step by step?
- How do you turn discovery results into PDPL records of processing?
- How do you keep a PDPL data map current?
- How Sumrite helps
- Frequently asked questions
Delivered with a verified NCA-registered partner
Sumrite runs PDPL readiness and VAPT for Saudi organisations end to end with our verified NCA-registered partner firm, and has served 100+ Saudi clients across Riyadh, Jeddah, Dammam and other cities. Talk to our team.
Most PDPL programmes begin with questionnaires sent to department heads. They produce a tidy record of the data people remember. The data that causes trouble is usually the data nobody remembered: a forgotten export, an old marketing list, a test database copied from production. This guide shows how to find that data first. For the wider framework, see our Saudi PDPL compliance guide.
What is personal data discovery under the PDPL?
Personal data discovery under the PDPL is the work of locating, classifying and mapping all personal data an organisation controls, so that its records of processing, rights handling, security and transfer controls cover reality rather than assumptions. It combines three activities: discovery (finding the data), classification (labelling what it is, including sensitive data) and mapping (recording purposes, flows and recipients).
The terms are often used loosely, so it helps to separate them:
- Data discovery
- Finding where personal data is stored: databases, file shares, SaaS tools, email, logs, backups and endpoints
- Data classification
- Labelling each data set: personal or not, sensitive or not, which data subjects, which identifiers
- Data mapping
- Recording how data moves: collection points, systems, processors, transfers abroad and destruction
- Records of processing
- The written record the PDPL requires, built from the three activities above
Why does the PDPL require you to know where personal data is?
The PDPL requires you to know where personal data is because records of processing, data subject rights, destruction, security, breach notification and transfer rules all depend on an accurate picture of the data. Article 31 of the PDPL requires a written record of processing activities, and SDAIA can ask for it.
Each core duty fails quietly without discovery:
| PDPL duty | What goes wrong without discovery |
|---|---|
| Records of processing (Article 31) | The record lists the CRM but not the spreadsheet exports taken from it |
| Data subject rights (Articles 4 and 5) | An access or destruction request misses copies in analytics, support and backups |
| Minimisation and retention | Data collected “just in case” is never identified, so it is never deleted |
| Security (Article 19) | Untested systems hold personal data nobody knew was there |
| Breach notice (Implementing Regulation Article 24) | Nobody can say within 72 hours whose data was in the breached system |
| Transfers (Article 29) | Support tools and backups abroad are never assessed as transfers |
SDAIA’s enforcement shows the risk is real. On 16 January 2026 the Saudi Press Agency reported that SDAIA’s violation committees had issued 48 decisions in the previous year, including for collecting and processing personal data in breach of the law and for failing to implement safeguards. Both are hard to defend when the controller did not know the data existed. Our guide to PDPL penalties and SDAIA enforcement explains the procedure and its five-day response window.
What counts as personal data and sensitive data under the PDPL?
Under Article 1 of the PDPL, personal data is any data, regardless of its source or form, that may lead to identifying an individual directly or indirectly, and sensitive data is a defined subset that needs explicit consent and stronger controls. Discovery rules must look for both direct identifiers and combinations that identify someone indirectly.
SDAIA’s Guide to the Saudi Personal Data Protection Law lists the sensitive categories:
- Racial or ethnic origin
- Religious, intellectual or political belief
- Criminal convictions and offences
- Biometric or genetic data used for identification
- Health data
- Data indicating that one or both parents are unknown
Two classification rules save time later. First, pseudonymised data is still personal data; SDAIA guidance treats it that way, according to the OneTrust DataGuidance and Clyde & Co comparison. Second, truly anonymised data is outside the PDPL under the Implementing Regulation, but the anonymisation itself is processing and belongs in your record.
For Saudi data, build detection patterns for national ID and Iqama numbers, Saudi mobile numbers, IBANs, Arabic and English names, and free-text fields where staff record health or family details.
Where does undocumented personal data usually hide?
Undocumented personal data usually hides in copies: exports, test environments, logs, backups, shared drives, email and the SaaS tools that teams adopt without IT involvement. The primary systems are rarely the problem; their offspring are.
| Location | Typical finding |
|---|---|
| Non-production databases | Test and staging copies of production customer data |
| File shares and cloud storage | CSV exports, HR spreadsheets, scanned ID documents |
| Application and web server logs | National ID numbers, mobile numbers and tokens in request parameters |
| Backups and archives | Data deleted from live systems but kept for years in backups |
| Email and chat | Customer documents attached to support threads |
| Marketing tools | Imported lists with no record of consent |
| Analytics and session replay | Form inputs captured by third-party scripts |
| Endpoints | Downloaded reports on laptops |
| Vendors and sub-processors | Copies held by agencies, call centres and IT support abroad |
Logs and session-replay scripts deserve special attention, because they collect personal data from web forms and APIs automatically. A web application penetration test or API security test often surfaces personal data in URLs, error messages and API responses that the data map never recorded.
How do you run a PDPL data discovery project step by step?
Run a PDPL data discovery project by combining interviews with technical scanning, classifying what you find, confirming ownership and purpose with the business, and closing gaps before you write the records of processing. Interviews alone miss copies; scanning alone misses purpose.
- Set the scope. List entities, systems and vendors that may hold data about people in Saudi Arabia, including group systems abroad. Article 2 of the PDPL reaches processing outside the Kingdom.
- Inventory the systems. Start from asset registers, cloud accounts, SSO application lists, finance records of SaaS subscriptions and an external view of your internet-facing hosts.
- Interview data owners. Ask each owner what data they collect, why, from whom, who receives it and how long they keep it.
- Scan structured data. Run pattern and dictionary searches against databases and warehouses for Saudi identifiers and sensitive fields.
- Scan unstructured data. Search file shares, cloud storage, email archives and ticketing systems, including Arabic text.
- Check logs and non-production. Review log samples and test environments for live personal data.
- Trace the flows. Follow APIs, integrations and exports to processors and to destinations outside the Kingdom.
- Classify and assign. Label each data set, confirm an owner and a purpose, and flag sensitive data.
- Close gaps. Delete data with no purpose, mask non-production copies and stop flows with no lawful basis.
- Write the record. Turn the verified results into records of processing.
Protect the discovery output itself. A data map listing where every sensitive data set lives is a valuable target, so restrict access to it and scan with read-only service accounts.
How do you turn discovery results into PDPL records of processing?
Turn discovery results into PDPL records of processing by grouping data sets into processing activities and filling in, for each activity, the fields that PDPL Article 31 and Implementing Regulation Article 33 require. One activity, such as payroll or customer onboarding, usually spans several systems.
- Controller details
- Name and contact details, plus DPO details where one is appointed
- Purpose
- The specific purpose of the activity and its lawful basis
- Data subjects
- Categories such as customers, employees or applicants
- Personal data
- Categories of data, with sensitive data flagged
- Recipients
- Internal teams, processors and third parties
- Transfers
- Any transfer or disclosure outside the Kingdom and its mechanism
- Retention
- Retention period, by category where possible
- Security
- Organisational, administrative and technical measures, where possible
The field list above follows the OneTrust DataGuidance and Clyde & Co comparison of PDPL Article 31. Keep the record in writing for as long as the processing continues and for five years after it ends, as Clyde & Co summarised when the Implementing Regulation was issued.
The same record supports other duties. It is the starting point for registering on the SDAIA National Register of Controllers, for deciding which activities need an impact assessment, and for the transfer register described in our guide to PDPL cross-border data transfers.
How do you keep a PDPL data map current?
Keep a PDPL data map current by tying updates to change events, such as new systems, vendors, purposes or transfers, and by re-running discovery scans at least annually. A record that was accurate last year is evidence of a programme that lapsed.
- Add a data protection question to change management, procurement and vendor onboarding
- Re-scan high-risk stores, such as file shares and logs, on a fixed cycle
- Trigger an impact assessment when discovery finds new sensitive data, linked data sets or monitoring
- Retain superseded versions of the record rather than overwriting them
- Report discovery metrics to the PDPL owner: new data sets found, data deleted, flows closed
Change is coming on the rules side too. SDAIA’s October 2026 draft amendments to the Implementing Regulation, open for comment until 5 November 2026 according to the Saudi Press Agency, would add an in-Kingdom storage duty and widen registration. They are proposals, not law, but an accurate data map is what will let you assess their impact quickly. Our analysis of the draft amendments explains the detail, and our PDPL compliance checklist shows where discovery fits in the wider programme.
How Sumrite helps
Sumrite runs PDPL data discovery and mapping engagements that combine owner interviews with technical review of databases, file stores, logs and cloud environments, then turns the results into records of processing you can hand to SDAIA. Our cloud security assessment and application testing find personal data exposed where it should not be. We deliver end to end with our verified NCA-registered partner firm and have served 100+ Saudi clients across Riyadh, Jeddah, Dammam and other cities. Our Saudi PDPL compliance page describes the engagement, and our Saudi Arabia page explains how we deliver a Sumrite VAPT report for Saudi reviews in 48 hours.
Find the data before anyone else does
Tell us which entities and systems handle Saudi personal data and we will scope a discovery and mapping engagement around them. Book a scoping call.
Frequently asked questions
What is personal data discovery under the PDPL?
Personal data discovery under the Saudi Personal Data Protection Law (PDPL) is the process of finding every place an organisation stores or processes personal data, classifying it, including sensitive data, and recording who uses it, why and where it goes. The output feeds the records of processing that Article 31 of the PDPL requires controllers to keep.
Does the Saudi PDPL require a data inventory?
The Saudi PDPL does not use the term data inventory, but Article 31 requires controllers to keep a written record of processing activities covering purposes, categories of personal data and data subjects, recipients, retention periods and transfers outside the Kingdom. A controller cannot complete that record accurately without first finding where personal data is held.
What counts as sensitive data under the Saudi PDPL?
Sensitive data under the Saudi PDPL includes data revealing racial or ethnic origin, religious, intellectual or political belief, criminal convictions and offences, biometric or genetic data used for identification, health data, and data indicating that one or both parents are unknown. Sensitive data needs explicit consent and can trigger impact assessments and SDAIA registration.
Is pseudonymised data still personal data under the PDPL?
Pseudonymised data is still treated as personal data under the Saudi PDPL, according to SDAIA guidance summarised by OneTrust DataGuidance, because the key that links it back to individuals still exists. Anonymised data falls outside the PDPL, but the act of anonymising it is itself processing.
How often should a PDPL data map be updated?
A PDPL data map should be updated whenever systems, vendors, purposes or transfers change, and reviewed in full at least once a year. Records of processing must be kept for as long as processing continues and for five years after it ends, so superseded versions should be retained rather than overwritten.
