Saudi Arabia’s Personal Data Protection Law (PDPL) applies to ERP and AI projects whenever they process information about identifiable people, such as employees, customers, supplier contacts or website users. To stay compliant, a project needs to know what personal data it holds and why, rely on a valid lawful basis, collect only what is needed, keep it only as long as necessary, protect it, honour data subject rights, report breaches on time and control transfers outside the Kingdom. This checklist maps those obligations to practical checkpoints for ERP implementations and AI systems such as retrieval-augmented generation (RAG) assistants.
This is general information, not legal advice. The PDPL, its Implementing Regulation and SDAIA’s guidance are detailed and are updated over time. Confirm how they apply to your organization with qualified legal counsel and your data protection officer, and check the official texts on SDAIA’s National Data Governance Platform.
PDPL at a glance
The PDPL was issued by Royal Decree M/19 in September 2021 and amended by Royal Decree M/148 in 2023. The official Arabic text is published by the Bureau of Experts at the Council of Ministers.
| Item | What the official texts say |
|---|---|
| Regulator | The Saudi Data & AI Authority (SDAIA) supervises application of the law and receives complaints |
| In force | 14 September 2023 |
| Compliance period | Controllers had one year from entry into force to adjust, to 14 September 2024 |
| Scope | Processing in the Kingdom of personal data relating to individuals, including processing by entities outside the Kingdom of data relating to individuals residing in it |
| Supporting texts | The Implementing Regulation, the Regulation on Personal Data Transfer outside the Kingdom, standard contractual clauses and SDAIA guidelines |
The law distinguishes the controller, which decides the purpose and means of processing, from the processor, which processes data on the controller’s behalf. In most ERP and AI projects, your organization is the controller and the ERP vendor, cloud provider or AI model provider acts as a processor.
The core principles and what they mean for projects
Lawful basis and consent
Consent is the default basis, and the 2023 amendments require it to be explicit in the cases the regulations specify. The law also allows processing without consent in defined cases, including when processing is required by another law, to perform a prior agreement to which the data subject is a party, or for the controller’s legitimate interests, provided this does not prejudice the data subject’s rights and the data is not sensitive. Data subjects can withdraw consent at any time.
Project checkpoint: record the lawful basis for each processing purpose. ERP processing for payroll, invoicing or contracts usually rests on a different basis from marketing or AI analytics.
Purpose limitation and data minimisation
The purpose of collection must relate directly to the controller’s purposes, and the content of personal data must be limited to the minimum necessary to achieve it. If data is no longer necessary, collection must stop and what was collected must be destroyed without delay.
Project checkpoint: challenge every personal data field in the ERP design and every data source feeding an AI system. “We might need it later” is not a purpose.
Retention and destruction
Personal data must be destroyed without delay once the purpose of collection ends, unless a legal requirement obliges you to keep it for a set period or it relates to a case before a judicial authority. Data may be kept after the purpose ends only if everything that identifies the individual is removed, under the controls set by the regulations.
Project checkpoint: define retention periods per data category, aligned with other legal retention obligations such as tax and labour records, and build destruction or anonymisation into the system rather than leaving it to manual clean-ups.
Data subject rights
The amended law gives individuals the right to be informed of the legal basis and purpose of collection, to access their data, to obtain a copy in a readable and clear format, to request correction, completion or updating, and to request destruction of data that is no longer needed. Under the Implementing Regulation, controllers must respond within 30 days, extendable by up to another 30 days in defined circumstances with prior notice to the individual.
Project checkpoint: make sure you can find, export, correct and delete one person’s data across the ERP, integrations, reports and AI stores within those timelines, and know how backups are handled.
Security and breach notification
Controllers must take organizational, administrative and technical measures to protect personal data, and the Implementing Regulation refers to the National Cybersecurity Authority’s controls. Under Article 24 of the Implementing Regulation, a controller must notify SDAIA within 72 hours of becoming aware of a breach that may harm personal data or data subjects or conflict with their rights or interests. Affected individuals must be notified without undue delay where the breach may harm them.
Project checkpoint: logging and monitoring must be good enough to detect a breach, and your incident plan must name who decides on notification and who files it.
DPO, records of processing and impact assessments
- Data protection officer (DPO). Required in defined cases, including public entities processing personal data at large scale, controllers whose core activities involve regular and systematic monitoring of individuals, and controllers whose core activities involve sensitive data. SDAIA publishes rules on DPO appointment.
- Records of processing activities. Controllers must keep written records covering purposes, data categories, recipients, transfers outside the Kingdom, retention periods and security measures, for as long as processing continues plus five years.
- Impact assessments. A written assessment is required in specified cases, including processing sensitive data, linking datasets from different sources, large-scale or repeated processing involving emerging technologies or decisions based on automated processing, and processing likely to cause serious harm to privacy.
That last point matters for AI: projects that use emerging technology or automate decisions about people should expect to complete an impact assessment.
Transfers outside the Kingdom
Article 29 of the amended law and the Regulation on Personal Data Transfer outside the Kingdom set the conditions for transfers. Transfers must not prejudice national security or the Kingdom’s vital interests, must be limited to the minimum data needed, and need an adequate level of protection in the destination based on SDAIA’s assessment. The regulations set out when a controller can rely instead on appropriate safeguards. SDAIA has published standard contractual clauses, guidance on binding common rules for group transfers, accreditation certificate rules and a guideline on assessing transfer risks.
Project checkpoint: know where every vendor stores, processes and supports your data, including backups, logs and AI model endpoints.
Checklist for ERP projects
- Build a data map. List personal data in each module: HR and payroll, customers, supplier contacts, CRM, service, and any portals. Note the source, purpose, lawful basis and owner.
- Minimise in the design. Remove fields nobody uses, and avoid collecting national ID or other sensitive data where a reference number will do.
- Design role-based access. Restrict HR, payroll and health-related data to the smallest group of users who need it, and review roles before go-live.
- Log access and changes. Keep audit logs of who viewed, exported or changed personal data, and protect the logs themselves.
- Configure retention. Set retention and archiving rules per data category, and plan how destruction or anonymisation reaches backups and archives.
- Plan rights requests. Agree how a request is received, verified, fulfilled across modules and integrations, and answered within the deadline.
- Check vendors and hosting. Confirm data location, support access from outside the Kingdom, subprocessors and contractual commitments with your ERP and cloud providers.
- Protect migration data. Treat data extracts used for migration and testing as personal data: mask them where possible and delete them after go-live.
- Update the records of processing. Add the new system to your records and to your privacy policy where the purposes or recipients change.
Our Business Process Consulting work maps processes and requirements before a system is chosen, which is the natural point to build this data map.
Checklist for AI and RAG projects
AI projects raise the same obligations in less familiar places. A RAG assistant copies text from source documents into chunks, embeddings and indexes, and an AI agent may read and write personal data through tools.
| Checkpoint | ERP question | AI and RAG question |
|---|---|---|
| Data map | Which modules hold personal data? | Which documents, tables and chat logs feed the index or agent? |
| Purpose | Is each field needed for the business process? | Is personal data needed to answer the questions the assistant is for? |
| Access control | Do roles limit who sees what? | Does retrieval respect each user’s permissions, so the assistant never returns what the user could not open? |
| Logging | Are views, exports and changes logged? | Are prompts, retrieved sources, answers and agent actions logged, and are those logs themselves protected? |
| Vendor and location | Where is the ERP hosted and supported? | Where are the model endpoint, vector store and logs hosted, and could data leave the Kingdom? |
| Training use | Not usually relevant | Do provider terms allow your prompts or data to be used to train their models? |
| Retention | Are retention rules configured? | How long are chunks, embeddings, caches and conversation logs kept? |
| Deletion | Can one person’s data be deleted? | When a source record is deleted or corrected, is the index updated too? |
Practical steps for AI projects:
- Exclude or mask personal data at ingestion when it is not needed for the use case.
- Carry permissions into retrieval, filtering results by the user’s access rights rather than relying on the prompt.
- Keep the index in sync with source systems so deletions and corrections propagate, and re-index on a schedule you can evidence.
- Review provider terms for data location, retention and training use before production, not after.
- Put a human in the loop for agent actions that change records about people, and log every action.
- Complete an impact assessment where the processing involves emerging technology, automated decisions or sensitive data.
Our AI Agents & Automation service builds RAG pipelines and agents scoped by role and permission, with guardrails and human approval steps.
Common mistakes
- Treating PDPL as a legal-only task. The obligations are met, or missed, in system design: fields, roles, logs and retention rules.
- Forgetting copies. Test environments, migration extracts, reports, exports, backups and vector indexes all hold personal data.
- Assuming the vendor is responsible. As controller, you remain responsible for choosing processors that provide adequate guarantees and for checking their compliance.
- Ignoring support access. Remote support from outside the Kingdom can involve disclosure of personal data to a party outside the Kingdom.
- No breach clock. Without monitoring and a named decision-maker, 72 hours passes quickly.
- Indexing everything for AI. Loading whole file shares into a RAG index without filtering imports personal data the use case does not need.
Frequently asked questions
When did the PDPL take effect?
It entered into force on 14 September 2023. Controllers had a one-year period to adjust their operations, which ended on 14 September 2024. SDAIA supervises its application.
Does the PDPL apply to employee data in our ERP?
The law covers personal data of identifiable individuals, and employee records in HR and payroll modules are personal data. Your lawful basis may differ from consent, for example a legal obligation or the employment contract, so confirm the basis for each purpose with legal counsel.
How quickly must we report a personal data breach?
The Implementing Regulation requires the controller to notify SDAIA within 72 hours of becoming aware of a breach that may cause harm, and to notify affected individuals without undue delay where the breach may harm them. SDAIA’s platform provides a breach notification service.
Can we use a cloud AI service hosted outside Saudi Arabia?
Possibly, but a transfer or disclosure outside the Kingdom must meet the conditions of the law and the Data Transfer Regulation, such as an adequate level of protection or appropriate safeguards like SDAIA’s standard contractual clauses. Check the current rules with your legal adviser before sending personal data.
Do we need a data protection officer?
It depends on your activities. The Implementing Regulation requires one in defined cases, such as large-scale processing by public entities, systematic monitoring or sensitive data as a core activity. SDAIA provides an online tool to check whether appointment is mandatory.
Building privacy into the project
AIMLTS is based in Jeddah. Our Business Process Consulting service maps as-is and to-be processes, requirements and controls before you commit to a system, and our AI Agents & Automation service builds RAG assistants and agents with access controls, guardrails and human approval built in. Legal interpretation should come from your counsel; we help turn the agreed requirements into processes and systems. Book a discovery call to talk through your ERP or AI project.