PDPL for foreign suppliers: comply by architecture, not by paperwork.

Three facts that frame everything

First, you are in scope. The PDPL explicitly reaches processing of data relating to individuals residing in the Kingdom by entities outside it. There is no foreign-supplier exemption to hide behind, and pretending the law is someone else's problem is the one posture guaranteed to fail a procurement review.

Second, enforcement is live, not theoretical. The law became enforceable in September 2023 with a grace period to September 2024, and the regulator's committees issued dozens of enforcement decisions in the first year that followed. The violations that actually got punished are mundane: processing without a lawful basis, insufficient security controls, and marketing messages sent without consent. Administrative fines run to SAR 5 million, doubling for repeat offences, and the procedure moves fast, with days rather than months to respond to a notification.

Third, the cross-border question has no easy exit. The regulator has not published an adequacy list, so no jurisdiction gets a free pass. Transfers out of the Kingdom run on safeguards: the Saudi standard contractual clauses issued in 2024, binding common rules for intra-group transfers, and a documented transfer risk assessment, for which a guideline followed in 2025. If your development happens outside Saudi Arabia, this is the machinery that applies to you.

Decision one: be a processor, not a controller

The PDPL, like most modern data protection law, splits the world into controllers, who decide why and how data is processed, and processors, who process it on a controller's instructions. Almost everything heavy sits on the controller: registration expectations, lawful-basis decisions, data subject rights handling.

A software supplier building a system for a Saudi client should be a processor, and should be able to prove it. That means the contract says so, the client decides the purposes, and you process only on documented instructions. It also means resisting the drift that quietly turns suppliers into controllers: keeping copies of client data for your own purposes, reusing it across clients, or holding it after the engagement ends.

The commercial upside is direct. A clean processor posture is a shorter procurement conversation, because the client's own compliance team can slot you into a framework they already understand.

Decision two: host production in the Kingdom, on the client's account

The PDPL itself does not contain a blanket data-residency mandate. Residency pressure comes from sector rules, cloud classification frameworks, and, more than anything, from what Saudi buyers and their auditors expect to see. Arguing with that expectation is a losing trade.

The clean answer is to host production in a Saudi cloud region, on the client's own account. One decision resolves four problems at once:

• The transfer question largely dissolves. Production data that never leaves the Kingdom needs no adequacy analysis and no transfer safeguards for its day-to-day life.
• The procurement objection disappears. "Where is our data?" has a one-word answer.
• Ownership is honest. The client holds the keys, the billing and the infrastructure. Handover is real, not contractual fiction.
• Adjacent regimes get easier. E-invoicing archives, sector cloud rules and audit requests all prefer the same answer.

Development is a different matter. You cannot develop from inside the Kingdom if you are not there, and you should not need to. Develop and test on pseudonymised or synthetic data, so what crosses the border for engineering purposes is not personal data at all. Where a support task genuinely requires touching production data from abroad, that is a defined, logged, documented transfer under the standard contractual clauses, with a transfer risk assessment behind it, not a standing pipe.

Decision three: hold nothing you do not need

The strongest data protection statement a system can make is that the sensitive payload never comes to rest. In the bilingual document platform this practice shipped for the Saudi market, generated documents stream to the user and no field values are persisted, anywhere, ever. There is no database of employees' contracts to breach, subpoena, migrate or argue about.

No-persistence design is not always possible, but it is possible far more often than teams assume, and every field you decline to store is compliance surface that stops existing. Where an audit trail is required, and compliance teams do ask, log metadata only: who generated which template, for which record, when. Never the values.

This is also where feature decisions become privacy decisions. Adding per-user activity tracking to a system that previously stored nothing is a legitimate, common feature, and it is also a deliberate weakening of the strongest claim the system could make. It should be a conscious choice made with the client, priced and documented, never a side effect.

The contract layer, kept small

With the architecture right, the paperwork that remains is short and standard:

• A data processing agreement naming you as processor: purposes, categories, duration, security measures, breach notification commitments, sub-processors, and deletion at end of engagement.
• The Saudi standard contractual clauses covering whatever genuinely crosses the border, which after the decisions above is little or nothing.
• A transfer risk assessment where transfers exist. Budget it as a real deliverable with a real document at the end, not a checkbox.
• Marketing discipline. Unconsented marketing is among the most-punished violations, so if the system sends anything promotional, consent is captured before the first send. This applies to your own outreach into the Kingdom too.

Why bother, commercially

Because this is a market where the buyer's compliance team has a veto, and most foreign suppliers walk into it with an architecture that guarantees a hard conversation. Turning up with the posture above does not just avoid the veto. It reads as evidence that you have done this before, which, in a market that runs on trust, is the sale.