Saudi PDPL Compliance for Software Teams: Data Mapping, Consent and Transfers

Saudi Arabia's Personal Data Protection Law (PDPL), issued by Royal Decree M/19 and amended in 2023, became enforceable on 14 September 2024 after a one-year grace period. It is supervised by the Saudi Data & AI Authority (SDAIA) and applies to processing of personal data of individuals in the Kingdom, including by entities outside it.

For software teams, PDPL is not just a legal document. It turns into concrete requirements on data models, user interfaces, logs, retention jobs and hosting choices. This guide translates the main obligations into engineering work. It is not legal advice: confirm interpretations with counsel and the latest SDAIA regulations and guidance.

Start with a data inventory

You cannot protect, delete or transfer data you have not mapped.

Every other obligation depends on knowing what personal data you hold, where and why. Build an inventory that lists, per system:

Field	Example
Data category	Name, mobile number, national ID / iqama, salary, health data
Data subjects	Customers, employees, job applicants, suppliers' contacts
Purpose	Invoicing, payroll, marketing, support
Lawful basis	Contract, legal obligation, consent, legitimate interest
Storage location	Database, region, backups, third-party SaaS
Retention	E.g. 10 years for tax records, 1 year for applicant CVs
Recipients	Payment provider, SMS gateway, cloud host, government portals

Engineers can automate much of this: tag sensitive columns in the schema (for example with extended properties in SQL Server or comments in PostgreSQL), and generate the inventory from code and infrastructure definitions so it stays current.

Lawful basis and consent

PDPL allows processing on several bases, including consent, performance of a contract, legal obligations and legitimate interests (with limits, and not for sensitive data). In practice:

• Do not ask for consent for everything. Invoicing a customer is necessary for the contract; consent there is meaningless and confusing.
• Where consent is the basis (marketing messages, optional analytics), it must be specific, informed and freely given, and withdrawing it must be as easy as giving it.
• Record consent as data: who, what purpose, which notice version, when, and through which channel. Store withdrawals the same way.
• Sensitive data (health, genetic, credit, religious beliefs and others defined in the law) needs extra care, stricter access and a clear basis.

Privacy by design in the architecture

Each layer has its own controls; together they show accountability.

Practical patterns that map well to PDPL obligations:

• Purpose tags on data. Attach a purpose to each personal data field so that features can check whether a new use is compatible with the original purpose.
• Data minimisation. Collect only fields a feature truly needs. Optional fields stay optional in the database, not just in the form.
• Masking by default. Show partial national ID or phone numbers in lists; reveal fully only to roles that need it, and log the reveal.
• Encryption. TLS everywhere, encryption at rest for databases and backups, and column-level encryption for the most sensitive fields.
• Access control and audit. Role-based access with periodic reviews; immutable audit logs for reads and changes of sensitive records.

Data subject rights as product features

Treat rights requests as workflows, not emails:

1. A request form or support category that identifies the requester securely.
2. A search across systems using the inventory, so nothing is missed.
3. Export of personal data in a readable format for access requests.
4. Correction and deletion functions that respect legal retention (for example, tax records you must keep), with the reason recorded when data cannot be deleted.
5. Tracking of deadlines and responses, with evidence kept for audits.

Systems built with a single customer or employee identifier across modules make this far easier than systems that copy personal data into many unrelated tables.

Retention and destruction

Keeping data forever is a liability. Define retention per category and implement it as scheduled jobs that delete or anonymise records after the period ends, including in data warehouses and logs. Backups need a documented approach, typically expiring naturally within a defined rotation rather than being edited.

Breach detection and notification

The implementing regulations require controllers to notify SDAIA of qualifying personal data breaches within 72 hours of becoming aware, and to inform affected individuals without undue delay when the breach may cause them harm. That timeline is only achievable with preparation:

• Centralised logging and alerts for unusual access or bulk exports.
• A runbook defining who decides, who investigates and who communicates.
• Pre-drafted notification templates and contact lists.
• Post-incident reviews that feed back into controls.

Cross-border transfers and hosting

PDPL restricts transferring personal data outside the Kingdom. Transfers are permitted under conditions set in the transfer regulations, such as adequate protection in the destination or appropriate safeguards (for example standard contractual clauses or binding corporate rules), and some cases require a risk assessment. For engineering, this means:

• Know which services send data abroad: cloud regions, email and SMS providers, analytics, AI APIs, support tools.
• Prefer in-Kingdom regions for core databases where available, especially for government-related and sensitive workloads, which may also fall under National Cybersecurity Authority controls.
• Document each transfer, its safeguard and its risk assessment.
• Pseudonymise or minimise data before sending it to external AI or analytics services.

Working with vendors (processors)

When a SaaS or outsourcing partner processes personal data for you, you remain accountable. Contracts should define purposes, security measures, sub-processors, breach notification duties and return or deletion at the end of the contract. Technically, give vendors the minimum data and access needed and revoke access promptly.

A checklist for your next release

• New personal data fields are documented in the inventory with purpose and retention.
• Forms show a privacy notice link; optional consent is unticked by default.
• Sensitive fields are masked in lists and encrypted where appropriate.
• Rights requests can find and export the new data.
• Logs do not contain full national IDs, card numbers or passwords.
• Any new third-party service has been checked for cross-border transfer.

Frequently asked questions

Does PDPL apply to companies outside Saudi Arabia? It applies to processing of personal data of individuals in the Kingdom, including by entities outside it, so foreign SaaS providers serving Saudi users should assess their obligations.

Do we need a Data Protection Officer? The regulations require appointing one in certain cases, for example for public entities, large-scale processing of sensitive data or regular and systematic monitoring. Check the criteria against your processing activities.

Is hosting outside the Kingdom forbidden? Not in general, but transfers must meet the conditions in the transfer regulations, and some sectors have stricter localisation rules. Assess each case and document it.

Key takeaways

• PDPL is enforceable since September 2024 and supervised by SDAIA.
• Start with an inventory; it drives lawful basis, rights handling, retention and transfer decisions.
• Build privacy into the architecture: minimisation, masking, encryption, audit and retention jobs.
• Prepare for 72-hour breach notification and document every cross-border transfer.

KHR Digital Solutions builds ERP, HR and customer systems for Saudi businesses with privacy by design, in-Kingdom hosting options and audit-ready data handling.