The Personal Data Protection Law changed what a Saudi organization has to be able to prove about its own systems. Not what it intends to do with personal data - what its databases, integrations, log files and backups actually do with it today, and whether that behaviour can be evidenced when a regulator, a customer or an internal auditor asks. That is the gap most PDPL programmes fall into: the policy set is written, signed and filed, while the systems underneath it still collect fields nobody consented to, retain records nobody scheduled for deletion, and grant access nobody reviews. This page sets out how we close that gap - a compliance assessment that ends in a set of changes your engineering team can actually make, not a document that describes a company you do not yet run.
PDPL is not a project you elect into. If your organization determines the purpose and means of processing personal data about people in Saudi Arabia, the law already applies to you, and the only open question is whether you can demonstrate it. The useful question is therefore not "do we need PDPL" but "which part of it are we currently unable to evidence" - and that answer is nearly always found in systems, not in the policy binder.
You do not need an advisory engagement if you have already done the work: a maintained record of processing, a retention schedule that a scheduled job actually enforces, a documented lawful basis per processing activity, an evidenced access-review cycle, and a breach procedure that has been rehearsed rather than written. In that case what you may need is a narrow second opinion on one question - a cross-border transfer, a specific vendor, a new product's data model - and we will scope that as a single session rather than sell you an assessment of controls you can already demonstrate.
You also do not need us first if your immediate problem is a security incident in progress. That is incident response, not compliance advisory, and it should be handled as such - see IT security consulting - with the PDPL notification and remediation questions picked up once the incident itself is contained.
Five named stages, run in order. The same five-stage method we use across our advisory practice, applied here to a regulatory obligation rather than a technology choice.
We start from what is actually driving the engagement, because it changes the shape of everything after it. A tender questionnaire with a date on it, a board that has asked for assurance, a new product about to launch on a data model nobody has reviewed, and a regulator enquiry are four different problems wearing the same name. We establish the real deadline, who has to be satisfied, and what evidence they will accept - then scope to that.
We map processing as it exists, not as it is described. That means working from the systems: data inventories pulled from the actual stores, integration and export paths, third parties and sub-processors who receive data, log and backup retention as configured, and access as granted. The output is a gap register - each requirement, the current position, the evidence that exists, and what is missing - ordered by exposure rather than by ease of fixing. We are neutral on tooling at this stage on purpose: a gap register that already assumes a product purchase is a sales document, not an assessment.
Each gap gets a named remediation, an owner, and an effort estimate, split into what must change in systems, what must change in process, and what must change in contracts. Where a control can be met by configuring something you already own, we say so - that is usually the cheapest and fastest half of the plan, and it is the half a vendor-led assessment tends to skip.
This is where our two practices meet, and it is the reason this page exists. Consent propagation, retention enforcement, access review, data-subject request handling and deletion are engineering work in your CRM, ERP, data platform and integration layer. We implement them with you - not a plan handed to a team that has no capacity to interpret it. Where the fix touches the wider control environment rather than one system, it belongs with our IT governance practice, and we run the two together rather than in sequence.
Compliance decays. New systems arrive, new fields get collected, new vendors get onboarded, and the record of processing that was accurate at sign-off drifts within a quarter. We hold a standing review cycle - re-validating the record of processing against what changed, re-testing the data-subject request path, and reviewing new processing before it ships rather than after.
The assessment stages move at the speed of access: how quickly we can reach system owners, data inventories and vendor contracts sets the pace far more than the size of the organization does. Remediation is then sized against the gap register - a programme that needs consent propagation rebuilt across four systems is a different scale of work from one that needs a retention job configured and an access review scheduled. We commit to a dated plan at the end of Stage 2, once we have seen the estate, rather than quoting a standard duration up front that would not survive contact with your actual architecture.
Three shapes, and we will tell you which one fits before you commit to any of them.
We do not publish a rate card for this service. Scope is the dominant variable - an assessment of one product line and an assessment of a multi-entity group are not the same engagement - and a published figure that we would have to requote for most enquiries is worth less than a written quote against a scope we have both read. You get that quote before work starts, not after.
This engagement is built for the organizations that hold the most personal data and have the least room to be wrong about it: banks and financial institutions, whose obligations stack on top of their sector regulator's requirements - see banking and financial services; government and public-sector entities handling citizen data; telecoms and large retailers with consumer-scale datasets; healthcare and education providers handling sensitive categories; and any organization operating a customer platform, a loyalty programme or a data warehouse that has grown faster than its governance.
Inside those organizations the engagement is usually owned by a CIO, a head of risk or compliance, a DPO where one has been appointed, or a general counsel - and it succeeds or fails on whether engineering is in the room. A PDPL programme run entirely out of legal produces documents; a PDPL programme run with engineering produces evidence.
We do not publish a figure here. A percentage improvement or a client count that a reader cannot check is exactly the claim a compliance buyer should discount in any advisor's pitch, and we hold our own copy to the standard we would apply to somebody else's. The real record is the set of documented engagements on our success stories page, updated as work is completed and cleared for publication. If a specific, comparable reference matters to your evaluation, ask for it on the first call and we will connect you where confidentiality allows.
The assessment is bounded by access rather than by headcount - how fast we can reach system owners, data inventories and vendor contracts. Remediation is bounded by the gap register: the organizations that take longest are not the largest, they are the ones whose personal data is spread across the most systems with the least documentation. We give you a dated plan at the end of Stage 2, when we have seen the estate. Any firm quoting a standard duration before that has not looked at your architecture.
There is no licence to buy - PDPL is a legal obligation, not a product - so the real question is what compliance costs to hold, not to reach. Over three years that is: the initial assessment; the remediation work, which is the largest and most variable line and cannot be sized before the gap register exists; the running cost of the controls themselves (retention jobs, access reviews, data-subject request handling, vendor due diligence); and re-assessment whenever the estate materially changes. Any tooling you choose to buy sits on top of those and does not replace them. We set out the recurring side explicitly at the end of the assessment, because the first-year figure on its own consistently understates what compliance actually costs to keep.
Worth naming the mismatch in the question: PDPL is the regulation - you comply with it, it does not comply with anything. The substantive question underneath is whether your architecture can meet it, and the sharpest part of that is cross-border transfer. Personal data leaving the Kingdom is governed separately from personal data processed inside it, and a cloud region, a support desk with offshore access, an analytics platform, or a group reporting pipeline can each constitute a transfer without anyone having decided to make one. We map every flow that leaves the Kingdom during Stage 2, name the mechanism each one relies on, and flag the ones that currently rely on nothing - which is the finding that most often changes an architecture decision. Sector rules can add residency requirements on top of PDPL; where your regulator imposes them, they are assessed alongside it rather than after.
PDPL is not chosen, so what is genuinely evaluated is how to meet it. For each material gap we set out the options and why one was recommended: configuring a control in a system you already own versus buying a dedicated tool; centralising personal data versus minimising and segregating it; building data-subject request handling into your own platform versus operating it as a manual process at your current volumes; and appointing an internal owner versus an external one. Each of those trades cost against speed against durability, and the rejected options are written down with the reason - a recommendation without its discarded alternatives is an assertion, not advice.
In most cases yes, and that is usually the recommendation. The controls PDPL requires - lawful-basis and consent capture, retention and deletion, access control and review, audit logging, data-subject request handling - are functions most modern CRM, ERP and data platforms already support and few organizations have switched on. Our first pass is deliberately configuration-first: what can be met with what you own. A replacement is recommended only where a system genuinely cannot enforce a control - most commonly an ageing store with no deletion capability and no usable audit log - and in that case we say so plainly and size it as its own decision rather than folding it into a compliance invoice.
The heading is the brief's, and we are going to be straight about it: we do not have a published number to put here that we could stand behind, so we are not inventing one. What we can point at is real and checkable - the engagements documented on our success stories page, which we update as work completes and is cleared for publication. A statistic you cannot verify is worth less than a reference call you can, and we would rather offer the second.
The organizations that bring us data-protection work are the ones with regulated data and distributed systems - financial services, government, telecoms and large consumer platforms among them. We do not list client names on a service page ahead of their own agreement to be named; the current permissioned list is maintained on our customers page and updated as relationships are confirmed for publication.
Individual engagements are published case by case rather than summarised here, because each has its own shape and because publishing detail requires the client's clearance first. Our projects page carries the work cleared for public reference, including compliance engagements as they become available to share.
We do not publish a client quote until the client has reviewed and approved the exact wording attributed to them, so this section will carry real, attributed testimonials - name, role and organization - as those approvals come in, rather than a composite standing in for one now. If a reference matters to your decision, raise it on the first call and we will arrange one where confidentiality allows.
Data-protection work sits on top of the platform relationships that make remediation possible - the CRM, ERP, data-platform and integration vendors whose products the controls actually get built in. Our current accreditations and partnerships are listed on our partners page. We do not claim a regulatory certification we do not hold: where an engagement needs a legal opinion on the law itself rather than an assessment of your systems against it, we say so and work alongside your counsel rather than in place of them.
Continue with the two practices this one is bound to. IT governance covers the control environment PDPL obligations have to live inside - ownership, policy, review cycles and the evidence trail that makes any of it auditable. IT security consulting covers the technical controls that protect the data itself, including the incident-response capability your breach procedure depends on. If your organization is in a regulated sector, our banking and financial services page sets out how sector supervision layers on top of the general obligation.
If PDPL is on your risk register this quarter, the most useful next step is not another gap-analysis template. It is an hour on your actual systems: which stores hold personal data, what leaves the Kingdom, what your retention is configured to do rather than stated to do, and where the evidence would come from if somebody asked tomorrow. Book a decision session and we will give you a plain answer on what is exposed, what is straightforward to close, and what is a genuine project - including if the honest answer is that your position is better than you feared and you need a second opinion rather than a programme.