Saudi Personal Data Protection Law
Saudi PDPL Readiness & Data Protection
Make personal-data protection work across your business. Connect Saudi PDPL readiness to governance, technology, evidence and day-to-day operations.
Last reviewed: 4 November 2026
PDPL / KSA
Personal data moves through recruitment, sales, customer support, cloud platforms, security monitoring and AI tools. A privacy policy alone cannot show where that information goes, who can access it or whether it is deleted when its purpose ends. Readiness starts by connecting those everyday decisions to clear ownership and evidence.
IRIS Technology supports governance, risk assessment, security architecture and technical implementation. A PDPL engagement should establish the applicable requirements with your legal and privacy owners, then translate them into a practical improvement plan for your actual systems and workflows. The objective is an operating capability that people can maintain after the assessment.
Personal data includes information that identifies a person directly or indirectly, such as contact details, employee records and identifiable photographs. Sensitive data receives additional treatment under the law. Classify information using the statutory definitions rather than assuming that every confidential business document is sensitive personal data.
A controller determines why and how personal data is processed. A processor handles it on the controller’s behalf. Your role can change between activities: your organization may control employee records while processing customer information under another organization’s instructions. Document the role for each relationship and allocate responsibilities in contracts and operating procedures.
PDPL covers relevant processing in Saudi Arabia and can also apply to parties outside the Kingdom processing personal data of individuals residing there. Do not assess applicability solely by where a company is incorporated or where its servers sit. Consider the individuals, processing activities, purposes, locations and relevant sector requirements.
Maintain a processing inventory and data-flow map covering collection, use, storage, sharing, support access, transfers and disposal. Identify the business owner, purpose, legal basis, affected individuals, systems, processors, retention period and safeguards. Validate the inventory with HR, sales, IT and security rather than relying only on an automated discovery tool.
Explain processing through appropriate notices. Document the lawful basis for each activity and manage consent where required, including withdrawal. Establish a route for requests concerning access, obtaining a copy, correction and destruction, subject to applicable conditions. Assign responsibility for identity verification, locating records, evaluating exceptions and recording the response.
Collect the information needed for a defined purpose and restrict reuse. Set retention rules by record type and legal need, including exceptions such as legal holds. Translate approved decisions into system settings, archive processes and deletion workflows. Include exports, attachments and backup recovery practices in the design instead of treating the production database as the entire data estate.
Assign privacy responsibilities, evaluate whether a DPO must be appointed, and assess processors before granting access. Put documented instructions, confidentiality, incident escalation and disposal arrangements into supplier governance. Review new platforms, substantial processing changes and higher-risk uses through the applicable impact-assessment requirements. Revisit decisions when suppliers, data use or operating locations change.
Connect security response with privacy assessment and notification decisions. Article 24 of the Implementing Regulation requires notification to the competent authority within 72 hours of awareness when the specified potential harm or rights/interests threshold is met. Notification to affected individuals has its own conditions and must occur without undue delay where required. Prepare escalation contacts, decision records and evidence collection; a technical incident ticket alone is insufficient.
These are implementation examples, not a mandatory product list. Select controls for the applicable obligation, data flow and risk, then test whether they work.
| Privacy objective | Implementation examples | Evidence to maintain |
|---|---|---|
| Know where personal data exists | Data discovery, classification, processing records and validated data-flow mapping. | An inventory with owners, locations, purposes, processors and review dates. |
| Limit access and sharing | IAM, MFA, privileged access, least privilege, access reviews and controlled external sharing. | Approved access, review results, revoked privileges and supplier instructions. |
| Protect information in use and transit | Encryption, key management, DLP, secure APIs, endpoint protection and appropriately scoped monitoring. | Configuration records, policy decisions, test results and incident escalation paths. |
| Honor lifecycle and rights decisions | Retention rules, request handling, deletion workflows and documented backup recovery controls. | Request logs, retention schedules, verified deletion and approved exceptions. |
| Govern cloud and overseas processing | Processor reviews, subprocessor mapping, transfer assessment and appropriate safeguards where required. | Data-flow diagrams, contracts, assessment records and approved safeguards. |
| Demonstrate operational effectiveness | Named control owners, privacy-aware incident response, training and periodic assurance. | Evidence registers, training records, exercises and tracked corrective actions. |
Cloud decisions should map where information is stored, processed and accessed. Review SaaS services, telemetry, overseas administration, support teams, subprocessors, backups and disaster recovery. A Saudi data-center location does not, by itself, resolve every privacy or transfer question.
PDPL and the transfer regulation provide a framework for permitted transfers subject to the relevant conditions, safeguards and assessments. There is no useful universal answer of “all cloud is prohibited” or “local hosting makes us compliant.” Evaluate the specific processing and transfer arrangements, together with any additional sector or contractual restrictions.
Before signing a platform agreement, ask for a clear data-flow description, processing locations, subprocessor arrangements, access model, deletion commitments and available contractual safeguards. Record the decision with the accountable business, legal and privacy owners. Reassess when the service or its delivery model changes.
Treat an AI assistant, analytics platform or retrieval system as a processing workflow, not simply a software license. Check what staff submit in prompts, which repositories the tool can retrieve from, where logs are retained and whether providers use submitted information for model improvement. The answer depends on the service, configuration and contract.
Prefer approved use cases, minimized inputs, controlled identities and data access that follows the requesting user’s authority. Assess output disclosure, retention, supplier access and human oversight. Include privacy and security review before connecting an agent to CRM, HR or customer systems; an internally hosted model still needs appropriate data governance.
Map CV submissions, employee files and screening services. Limit recruiter access, define retention and document how requests and deletion are handled.
Review CRM exports, lead forms, marketing use and chat providers. Separate an enquiry’s purpose from other uses and control sharing with agencies or suppliers.
Review collaboration platforms, remote administration, backup locations and external support. Document processing boundaries and who can retrieve or restore personal information.
Consider personal data in logs, investigations, recordings and alerts. Limit access, define appropriate retention and ensure response teams can escalate privacy incidents.
Examine prompts, training and evaluation datasets, retrieval sources and generated output. Minimize data, test access boundaries and document approved processing purposes.
Scope is agreed around your priorities and environment. Technology implementation supports your organization’s accountability; it does not replace legal interpretation or a regulator’s decision.
Review the agreed processing scope, governance, controls, evidence and dependencies. Capture gaps with responsible owners and business context.
Map data flows and design improvements across discovery, identity, sharing, cloud, encryption, retention and monitoring. Work with your legal and privacy teams on approved requirements.
Configure and integrate agreed technical controls, validate representative workflows, document operating procedures and transfer knowledge to the teams who will run them.
Organize evidence, track remediation, test selected controls and define a review cadence. Keep unresolved decisions and residual risks visible to accountable owners.
Deliverables, depth, access needs and acceptance criteria are confirmed in the statement of work. Timing depends on the number of systems, processing activities, suppliers and remediation dependencies.
Assess the processing rather than the company label. Relevant processing in Saudi Arabia, and processing outside it involving personal data of individuals residing in the Kingdom, can be in scope. Confirm the facts, exemptions and sector overlays with qualified legal and privacy owners.
Do not assume a universal localization rule. PDPL and the transfer regulation set conditions for transfers and disclosures outside the Kingdom. Additional sector, national-security or contractual requirements may impose restrictions. Review the actual data flow and applicable requirements before selecting an arrangement.
Potentially, subject to an appropriate assessment of purposes, legal basis, security, processors, locations and transfers. A provider’s marketing statement or regional data-center option does not replace that assessment. Review contracts, configuration and the real processing model.
Consent is not the only basis contemplated by the law. Other permitted grounds have conditions and limitations, and sensitive-data rules require particular attention. Identify and document the correct basis for each purpose rather than using a single consent box for every activity.
The appointment rules cover specified cases: public entities providing services involving large-scale personal-data processing, core activities requiring regular and systematic monitoring, and core activities based on sensitive-data processing. Assess the detailed rules and processing characteristics; appointment is not automatically mandatory for every company.
No. An information-security management system can support security and evidence, but PDPL also addresses lawful processing, transparency, rights, purposes, retention, processors and transfers. Certification does not automatically establish that all applicable privacy requirements are met.
No single product provides the whole operating model. Tools can enforce controls and improve visibility, but they need approved policies, accountable owners, proportionate configuration, review and evidence. Start with requirements and risks before selecting products.
Prepare system and supplier lists, available processing records, privacy notices, policies, contracts, access models and retention schedules. Identify business, IT, security and privacy owners. Initial discussions should use descriptions and anonymized examples rather than unnecessary personal records.
This page offers readiness, architecture and implementation support. It does not offer regulatory accreditation, statutory certification or a guarantee of compliance. Any formal certification or accreditation requirement must follow the applicable authorized scheme.
This page focuses on Saudi Arabia. Organizations operating in Jordan need a separate applicability and requirements mapping. Our linked Saudi/Jordan briefing explains how a shared operating model can support distinct legal regimes without treating them as identical.
Requirements should be checked against the current law, regulations and applicable official rules. The links below support this page’s legal context; the control examples and engagement approach are practical recommendations.
General readiness and technology information, not a legal opinion. Applicability, exceptions and sector obligations depend on your circumstances. Your organization and its qualified advisers remain responsible for legal decisions; implementation support is not a guarantee of compliance.
Related reading: Saudi and Jordanian data protection →Frameworks, laws & controls
Explore readiness by country and subject. Applicability depends on the entity, sector, systems and data; shared controls do not make distinct requirements interchangeable.
Bring your business priorities, systems and data-flow questions. We will help define an appropriate readiness and implementation scope.
Discuss your PDPL readiness