Saudi Arabia's PDPL Implementing Regulations, What M&A, Cloud and Saas Teams Must Do Now

Saudi Arabia’s data protection framework continues to reshape how multinationals store, transfer and protect personal data across the Kingdom. The Personal Data Protection Law (PDPL), issued under Royal Decree No. M/19 of 1443H and later amended, is supervised by the Saudi Data & Artificial Intelligence Authority (SDAIA), which has issued Implementing Regulations and separate Regulations on Personal Data Transfer Outside the Kingdom. SDAIA periodically publishes draft amendments for public consultation on the Kingdom’s “Istitlaa” (Istitlaa. ncc. gov. sa) public consultation platform. Three areas dominate the practical debate for transactional and technology teams: data‑localisation and storage expectations, breach‑notification timelines to SDAIA, and registration and transfer obligations where personal data leaves the Kingdom.

Where any particular provision is still at draft or consultation stage, counsel should treat it as a proposal, not enacted law, and verify the current text against SDAIA’s official publications before acting on specific article numbers or deadlines.

Quick summary (in 3 bullets)

• The framework in force. The PDPL and its Implementing Regulations (administered by SDAIA) govern the processing, storage, transfer and breach‑handling of personal data in Saudi Arabia, with separate Regulations governing transfers outside the Kingdom.
• The three high‑impact themes. Data‑localisation and in‑Kingdom storage expectations, prompt breach notification to SDAIA, and registration and documentation obligations triggered by cross‑border transfers and disclosures.
• Immediate actions. Monitor and respond to SDAIA consultations, update incident playbooks to meet SDAIA notification timelines, map data flows and transfer mechanisms, and prepare contract redlines for cloud and SaaS arrangements.

Practical M&A and cross‑border data guidance for counsel and corporate teams. This article is general information, not legal advice; where it references consultation‑stage proposals, confirm the current position against SDAIA’s official publications.

What SDAIA publishes, a quick overview of how changes happen

When SDAIA proposes changes to the PDPL Implementing Regulations, draft text is typically posted on the Istitlaa public consultation platform for a stated comment period. Proposals and refinements in recent cycles have touched the provisions that matter most to multinationals, cloud providers and transactional teams, including:

• Privacy‑policy clarity. Requirements that privacy notices be drafted in clear, simplified language that is genuinely accessible to data subjects.
• In‑Kingdom storage expectations. Wording addressing where controllers store personal data, while still permitting lawful transfers abroad under the transfer regulations.
• Breach notification. Obligations and timelines for notifying SDAIA, and separately affected data subjects, of a personal data breach.
• Direct marketing and consent. Consent‑evidencing requirements and the handling of consent withdrawal.
• Registration and cross‑border transfers. Documentation and compliance obligations where a controller transfers or discloses personal data outside Saudi Arabia.

The sequencing matters. Where amendments are finalised, they take effect as stated in the enacting instrument and its publication in the Official Gazette (Umm al‑Qura); any transitional runway should be read from the final published text. Until a draft is finalised, the public consultation is the moment to shape the outcome. For organisations that advise on M&A matters in Saudi Arabia, the regulatory‑impact dimension of these changes is significant.

In‑Kingdom storage and data localisation: wording, interpretations and immediate impacts

Localisation is among the most consequential issues in Saudi data protection. Where draft wording directs controllers to “store” personal data in‑Kingdom while preserving the ability to make lawful transfers abroad, that combination can produce genuine interpretive uncertainty, and counsel should treat any ambiguity as a priority comment point during consultation.

Two plausible readings of a storage requirement

Where such wording appears, there are commonly two defensible interpretations:

• Baseline local‑copy reading. Controllers must keep a copy of relevant personal data on infrastructure located inside Saudi Arabia, but may continue to process or transfer that data abroad under lawful transfer mechanisms. On this view, a dual‑copy or primary‑in‑Kingdom architecture would satisfy the rule.
• Non‑absolute localisation reading. Storage must be in‑Kingdom as a rule, with outbound transfers permitted only where a lawful basis applies, a soft localisation model rather than a hard prohibition on any data leaving the country.

The practical and commercial consequences of each reading diverge sharply, which is why consultation is the right forum to seek clarity on the intended scope.

Practical impact on data flows, cloud and SaaS

For cloud and SaaS providers hosting Saudi personal data, storage expectations raise immediate architecture questions. Providers without an in‑Kingdom region may need to deploy local storage, replicate data to a Saudi region, or redesign their service to support a split architecture. Customers, in turn, will push contractual obligations down the supply chain to subprocessors. A common practical effect is renewed demand for regional cloud capacity and for clearer data‑residency commitments in vendor agreements.

Contract and technical controls

Whichever interpretation prevails, several technical and contractual controls help organisations respond proportionately:

• Regional cloud regions. Prioritise in‑Kingdom hosting regions or local data‑centre capacity for Saudi personal data.
• Split architecture. Separate the authoritative in‑Kingdom store from processing environments located elsewhere, with controlled replication.
• Encryption and key management. Encrypt data at rest and in transit, and consider keeping encryption keys in‑Kingdom to strengthen residency arguments.
• Hybrid models. Combine local primary storage with offshore analytics or backup under documented transfer bases.

Breach notification to SDAIA: scope and operationalisation

Breach notification is among the most operationally demanding areas of the PDPL framework. The Implementing Regulations require controllers to notify SDAIA of a personal data breach within the period and in the manner specified by the regulations, and separately to notify affected data subjects where the breach may cause harm. Because the exact notification window and its scope can change with amendments, confirm the current timeframe against SDAIA’s published Implementing Regulations before finalising internal playbooks.

What events trigger the clock

Breach‑notification obligations are typically triggered by a breach of personal data, including loss, damage, leakage, or unauthorised access or disclosure. Where the regulations require notification regardless of likely harm, organisations cannot wait to complete a full harm assessment before deciding whether to inform SDAIA, making early, conservative escalation important.

SDAIA notice versus data‑subject notice

The two notification streams should not be conflated. The obligation to notify SDAIA operates on the regulator‑facing timeline. The separate requirement to notify affected data subjects turns on whether the breach is likely to cause harm. In practice, an incident may require prompt regulator notification while the decision to inform individuals follows a more deliberate harm analysis.

Practical implications for detection and escalation

A short notification window places pressure on detection, triage and cross‑border coordination, particularly where the technical incident is discovered by a subprocessor or by a security team located outside the Kingdom. Multinationals need clear escalation paths that reach the Saudi legal and privacy function quickly, along with a local contact able to engage SDAIA. Global incident‑response runbooks should carry a dedicated Saudi branch with its own timeline.

A workable escalation timeline

Organisations can operationalise the obligation around a structured timeline keyed to the applicable SDAIA deadline:

• Immediately on detection. Detect, contain and preserve evidence; convene the incident response team (CISO, DPO, legal, local contact); open a factual timeline and begin a preliminary classification.
• Early assessment phase. Confirm whether the event constitutes a reportable personal data breach; coordinate with subprocessors and offshore teams; prepare the SDAIA notification content and assess the data‑subject harm threshold.
• Before the deadline. Finalise and submit the SDAIA notification within the required window; decide on data‑subject notice where harm is likely; document the rationale for all decisions.
• Follow‑up. Provide supplementary information to SDAIA as the investigation matures, remediate root causes and update the incident log and lessons learned.

Cross‑border transfers, registration and the controller register

Where a controller transfers or discloses personal data outside Saudi Arabia, the PDPL and the Regulations on Personal Data Transfer require a lawful basis and appropriate safeguards. SDAIA also operates a national data controller register (the National Data Governance Platform), and registration and record‑keeping obligations can apply to controllers. Confirm the precise registration triggers and thresholds against SDAIA’s current guidance, as these have evolved across regulatory cycles.

Who is affected

For most multinationals, routine operations, group HR systems, shared customer databases, centralised analytics, involve cross‑border transfers of Saudi personal data. Any such transfer must satisfy the transfer regulations, and relevant controllers should assess whether registration or notification to SDAIA is required for their activities.

Interaction with foreign parents and group controllers

Cross‑border and registration obligations raise structural questions for corporate groups. Where a Saudi subsidiary transfers data to a foreign parent, or where group controllers share a common platform, each organisation must identify which entity is the controller for the relevant processing and whether any registration or transfer‑assessment obligation applies. Group data‑sharing arrangements should be mapped against these triggers to avoid gaps.

Practical steps and evidence to prepare

Organisations should assemble the materials compliance is likely to require:

• Data‑flow map. A clear inventory of what personal data leaves the Kingdom, to whom, and for what purpose.
• Transfer basis and assessment. Documentation of the lawful basis and any required transfer risk assessment for each outbound transfer.
• Data processing agreements. Executed DPAs with processors and subprocessors handling transferred data.
• Entity mapping. Identification of the controller responsible for each transfer, including group entities.

Direct marketing, consent and privacy‑policy clarity

The PDPL framework also addresses consent and transparency obligations that directly affect marketing, CRM and customer‑experience teams.

Consent and withdrawal handling

The Implementing Regulations address the evidentiary standard for consent used in direct marketing and the consequences of withdrawal, including the obligation to stop processing on withdrawal and to handle resulting data appropriately. Privacy policies are expected to be written in clear, simplified language.

Suggested operational and drafting steps for marketing teams include:

• Consent capture. Record the exact wording shown, the timestamp, the channel and the specific purpose consented to, so consent can be evidenced on demand.
• Withdrawal workflow. Build a process that halts processing promptly on withdrawal and addresses data derived from the withdrawn consent in line with the regulations.
• Privacy policy language. Write notices in plain, accessible language, avoiding dense legal terminology.
• CRM configuration. Ensure the CRM can log consent provenance and execute withdrawal instructions reliably.

How the PDPL obligations interact, combined compliance risks

The headline obligations do not operate in isolation. Storage expectations, breach notification and cross‑border transfer rules interact to create compound obligations. Three scenarios illustrate the overlap.

• Scenario 1, SaaS host outside the Kingdom and a breach discovered offshore. Storage expectations may put the hosting arrangement under pressure; the SDAIA notification clock begins once unauthorised access is confirmed; and because the data sits abroad, transfer and registration obligations are also likely engaged. Several obligations collide in a single incident.
• Scenario 2, an M&A deal transferring employee and customer data abroad. Moving Saudi personal data to a foreign acquirer is a cross‑border transfer that must satisfy the transfer regulations and any registration obligation, must respect storage expectations, and should be covered by post‑closing compliance covenants. Due diligence must surface all three risks.
• Scenario 3, a cross‑border marketing campaign. Running a campaign that transfers CRM data abroad engages the transfer rules and the consent requirements simultaneously, while any security incident in the campaign platform would start the SDAIA notification clock.

A simple decision path helps: first, ask where the data is stored and whether an in‑Kingdom copy exists; second, ask whether the data is transferred or disclosed abroad, which may require a transfer assessment or registration; and third, maintain an incident process capable of notifying SDAIA within the required window wherever the event is detected.

What to raise in SDAIA consultations, suggested comment themes

Public consultation is a practical lever for shaping final rules. When SDAIA opens a consultation on the Implementing Regulations, counsel should prioritise the following comment themes. The sample language below is for guidance only and should be adapted to each organisation’s circumstances.

• Clarity on “store” versus “keep a copy.” Sample comment, for guidance only: “We respectfully request clarification of whether any storage obligation is satisfied by maintaining a copy of personal data in‑Kingdom, or whether full localisation is intended, to enable proportionate architecture planning.”
• Scope and timing of the breach trigger. Sample comment: “We suggest that the breach‑notification provisions allow a reasonable period to confirm that an event constitutes a reportable breach, and accommodate necessary forensic containment steps.”
• Harmonisation with existing incident reporting. Sample comment: “We recommend aligning the SDAIA notification with other applicable incident‑reporting obligations to avoid duplicative or conflicting timelines.”
• Scope and form of transfer obligations and registration. Sample comment: “We ask that the rules specify the form, content and threshold of any registration, and clarify the treatment of intra‑group transfers and routine operational disclosures.”
• Standards of proof for consent. Sample comment: “We request guidance on acceptable evidence of consent, including record‑keeping formats and retention periods.”
• Transitional provisions and enforcement timing. Sample comment: “We propose clear transitional provisions and a realistic implementation runway following publication, given the architectural changes required.”

Immediate operational checklist, what multinationals, cloud/SaaS providers and M&A teams should do now

Organisations should sequence their response across short, medium and longer horizons.

• Short term. Map Saudi personal data and its storage locations; identify whether any in‑Kingdom copy exists; assign an owner for monitoring SDAIA consultations and guidance.
• Medium term. Inventory transfer mechanisms and subprocessors; update the incident playbook to meet the applicable SDAIA notification timeline; prepare and submit consultation comments when windows are open.
• Longer term. Prepare template registration and transfer‑assessment materials; update vendor contracts and questionnaires; deliver training to local teams on breach escalation, consent and registration.

Responsibilities should be allocated clearly: security and IT own data mapping and architecture; the DPO and legal own consultation comments, consent and registration; and transaction teams own diligence and deal‑specific covenants.

Draft contract and due‑diligence language (practical redlines)

The following short, practical clause concepts can be adapted by counsel for cloud, SaaS and M&A arrangements. They are illustrative and not legal advice.

• Cross‑border transfers. “The Processor shall only transfer Saudi personal data outside the Kingdom on a lawful transfer basis under the PDPL and its transfer regulations, and shall maintain documentation of that basis for inspection.”
• Breach cooperation and notification alignment. “The Processor shall notify the Controller without undue delay, and in any event within a timeframe enabling the Controller to notify SDAIA within the period required by the PDPL Implementing Regulations following a personal data breach.”
• Data‑localisation accommodation. “The Processor shall, on the Controller’s request, maintain an in‑Kingdom copy of Saudi personal data and support split‑architecture or regional hosting arrangements.”
• Registration and transfer warranty. “The Target warrants that it has identified all transfers of personal data outside Saudi Arabia and has completed any required registration, notification or transfer assessment under the PDPL framework.”
• Post‑closing compliance covenant. “The Seller shall procure that, following completion, the Target maintains compliance with PDPL storage, incident‑notification and cross‑border transfer obligations as in force.”

Conclusion, risk posture and next milestones

The Saudi PDPL framework, overseen by SDAIA, continues to mature through implementing regulations, transfer rules and periodic consultations. Organisations should treat compliance as an ongoing programme rather than a single deadline. The sensible posture is to monitor and respond to SDAIA consultations, update incident plans to meet the applicable SDAIA notification window, map data flows against storage and transfer triggers, and prepare contract redlines for cloud, SaaS and transactional arrangements. Where a proposal is at draft stage, verify the current text and timelines against SDAIA’s official publications before acting. Engaging specialist counsel helps multinationals shape the final rules and reduce the cost of adjustment later.

Sources

1. Saudi Data & Artificial Intelligence Authority (SDAIA)
2. Istitlaa, Saudi public consultation platform
3. European Union, General Data Protection Regulation (Regulation (EU) 2016/679)
4. OECD, Guidance on cross‑border data flows and data governance
5. UNCTAD, Reports on data protection and digital trade
6. World Bank, Reports on data governance and the digital economy