SAR 5 million is the maximum penalty the Saudi Personal Data Protection Law allows for a single category of violation, and it doubles on repeat. That number matters to anyone shipping a web application into the Kingdom, because the law does not care whether the code was written by a senior engineer over eighteen months or generated by an AI builder in a weekend. Enforcement has been live since 14 September 2024.
Getting this wrong is easier than it looks, and I have watched a good team do it.
The mistake is almost never a missing firewall. It is an assumption made in week one that nobody revisits until an auditor asks a question nobody on the team can answer.
What changed for teams shipping software into Saudi Arabia
Two things happened at once, and together they moved the goalposts.
The first is regulatory. Saudi Arabia now has a genuine, layered framework — the National Cybersecurity Authority for security controls, SDAIA and its National Data Management Office for data governance and personal data, and sector regulators like the Saudi Central Bank layering their own requirements on top of both. Five years ago much of this was advisory. It is not advisory now, and it has teeth.
The second is that building software got fast. According to the government's own published programme under Vision 2030, entities across the Kingdom are digitising services at a pace that makes AI-assisted development genuinely attractive, and teams are using it accordingly. A working internal portal in three weeks is no longer unusual.
Those two curves cross in an uncomfortable place. The speed of building has increased sharply; the speed of proving something is safe has not moved at all.
Everything below lives in that gap.
What are the NCA and the NDMO, and which one applies to your application?
The NCA is Saudi Arabia's national cybersecurity regulator, and it publishes the control frameworks a system must implement — most commonly the Essential Cybersecurity Controls. The NDMO, which sits under SDAIA, is the national data authority, and it governs how data is classified, catalogued, shared, retained and protected. Most applications handling Saudi personal data must answer to both.
The NCA side: controls you implement
As published by the NCA in 2018, ECC-1:2018 organises 114 controls across five main domains covering governance, defence, resilience, third-party and cloud, and industrial systems. If your application runs on cloud infrastructure, the NCA's Cloud Cybersecurity Controls apply as well, and they separate what the cloud provider owes from what you, the tenant, owe. That distinction is where teams get caught: buying a compliant platform does not make your application compliant.
The NDMO side: data you govern
The NDMO's Data Management and Personal Data Protection Standards run across fifteen domains — data governance, cataloguing and metadata, quality, architecture, reference and master data, security, sharing, classification, retention, open data and more.
Very little of that is code. Almost all of it is decisions written down, then implemented in code.
Fair objection, and I hear it often from founders: this reads like enterprise bureaucracy aimed at ministries, not at a twenty-person startup. That is true of the paperwork volume, and a small team genuinely should not attempt all fifteen domains in month one. It is not true of the substance. Classification, retention and residency are three decisions, they take an afternoon, and every later control depends on them.
Where does Saudi personal data actually have to live?
Saudi personal data must be processed inside the Kingdom by default. Under Article 29 of the Personal Data Protection Law, transferring personal data outside Saudi Arabia is permitted only in defined circumstances, with a documented lawful basis and, in most cases, a risk assessment. Residency is a decision you must be able to evidence, not a side effect of which cloud region your hosting provider picked.
This is the single most expensive assumption in a generated codebase.
An AI builder deploys to whatever region the platform defaults to — usually North Virginia or Frankfurt — and the application works perfectly. Nothing warns you. The defect stays invisible until a customer's compliance officer asks one question, and by then you have live users on the wrong continent.
| Check your backups, not just your database. Teams move the primary database into an in-Kingdom region and forget that snapshots, log aggregation, error tracking and analytics still ship data abroad. A residency claim is only as true as its least-examined pipeline. |
Encryption that satisfies an auditor, not just a checklist
"Encrypted at rest" is the phrase that ends most security conversations and begins most audit findings. Full-disk encryption on a managed database is genuinely useful — it protects you if someone walks out of a data centre with a drive. It protects you against nothing else, because the database decrypts every row for anyone the application can authenticate as.
What an auditor asks is narrower and harder: which fields are encrypted, with which algorithm, using keys held where, rotated how often, and who can read the plaintext. The NCA publishes National Cryptographic Standards precisely so those answers are not left to a developer's preference, and they define assurance levels rather than one universal setting. AES-256 at rest and TLS 1.2 or higher in transit is the floor, not the answer.
The pattern that survives review is envelope encryption.
Sensitive columns — national ID, IBAN, health data, salary — get encrypted individually with a data key; the data key is itself encrypted by a master key held in a managed key service or hardware security module inside the Kingdom; and the application never touches the master key. The key-management guidance published by the National Institute of Standards and Technology in its SP 800-57 series is the reference most Saudi reviewers will recognise, and PostgreSQL teams can start with pgcrypto before moving to a dedicated key service.
The moment this stopped being theory for me involved a healthcare portal that had passed its own internal security review comfortably. Every box was ticked. Then a reviewer asked a question no checklist contained: who, in the vendor organisation, could read a patient's national ID in plaintext? The honest answer was four support engineers, through an admin screen built for convenience during the pilot and never removed. No control had been violated. No log looked wrong. We spent eleven days building field-level encryption and a break-glass access flow that recorded every plaintext read, and the finding that forced it came from a single question, not from a scan.
A practical sequence that does not stall the product
Order matters here more than effort. Doing these out of sequence is how a four-week hardening job becomes a four-month one.
- Classify before you encrypt. Walk the schema table by table and assign one of the four levels to every column that holds personal or business data. An afternoon of this decides months of downstream work.
- Inventory every place data leaves the application. Backups, logs, error tracking, analytics, email providers, AI model calls. Write the list by reading configuration files, not by asking the team what they remember.
- Fix residency next, while the data is small. Moving a 40 GB database is a weekend. Moving a 4 TB one with live users is a project with a rollback plan.
- Then encryption and key management. Field-level for anything classified Confidential or above, keys in an in-Kingdom key service, rotation scheduled and documented.
- Access control and logging last, because they depend on everything above. Least-privilege roles, quarterly reviews, and an audit trail that records who read sensitive data rather than only who changed it. The Application Security Verification Standard maintained by the Open Web Application Security Project is a reasonable engineering checklist to run alongside the regulatory one.
Sector rules sit on top of all of this. A payments or lending product also answers to the Saudi Central Bank, and cloud arrangements fall within the framework maintained by the Communications, Space and Technology Commission. Check which apply before you design, not after.
What success looks like, and how to measure it
Compliance is not a certificate on a wall. It is a set of questions your team can answer the same day they are asked. Four measures tell you whether you are there.
- Time to answer a residency question. If someone asks where a specific customer's data is stored right now, including backups, can you answer within an hour with evidence?
- Plaintext reader count. How many humans could read a national ID today? The number should be small, named, and reviewed quarterly.
- Percentage of Confidential-and-above columns under field-level encryption. Anything below 100% needs a written reason.
- Third-party inventory drift — how many services appear in your configuration that are not on the approved list. Measure this monthly; it always grows.
The counterargument I respect most is about speed: every one of these steps slows a team down, and in a market moving as fast as this one, slow loses deals. Genuinely true in the short term. What I have seen across enterprise delivery in the Kingdom is that the same discipline wins the deals that matter, because a Saudi bank or ministry will not sign with a supplier who cannot answer the residency question — and answering it late costs more than answering it early ever did.
The security review does not test your code. It tests whether anyone was paying attention when the decisions were made.
My second lesson came from getting the sequence wrong ourselves. On one engagement we implemented encryption before classification, because encryption felt like the real engineering and classification felt like paperwork. We encrypted forty-one columns. Eleven of them held data classified Public, where the encryption bought nothing and cost query performance, and we had missed three columns that mattered because nobody had yet decided they were sensitive. We redid the work in the right order, and it took less time the second time.
So here is the question I would put to your team this week, and I would ask it out loud rather than in a document: if a customer's compliance officer emailed tomorrow morning asking exactly where their users' personal data is stored — including every backup and every log — how long would it take to answer, and would you be confident the answer is right? Bring the honest number to your next engineering meeting. It is the most useful compliance metric you will ever collect.
Frequently asked questions
Does the Saudi PDPL apply to a company based outside Saudi Arabia?
Yes, in defined circumstances. The Personal Data Protection Law extends to entities outside the Kingdom that process the personal data of individuals residing in Saudi Arabia. A foreign software company serving Saudi users therefore falls within scope and generally needs a documented lawful basis, a representative arrangement, and controls over cross-border transfers.
Is provider disk encryption enough to meet NCA requirements?
Rarely. Disk-level encryption protects against physical theft of storage media, but the database still returns plaintext to any authenticated caller. Sensitive fields such as national ID numbers, financial identifiers and health data generally need field-level encryption with keys held separately, so a compromised application account cannot read them.
Can Saudi personal data be processed on a cloud region outside the Kingdom?
Only with a documented lawful basis under Article 29 of the Personal Data Protection Law, and usually a risk assessment. In-Kingdom processing is the default expectation. Backups, logging, analytics and third-party integrations count as processing, so every pipeline that carries personal data abroad needs the same justification as the primary database.
