NDMO Data Governance Compliance in Saudi Arabia

Most organisations in the Kingdom meet the National Data Management Office framework the same way: a consultant produces a gap assessment, the gaps are logged, and the document goes into a folder. A year later the annual audit arrives and almost nothing has moved, because nobody owned the work between the assessment and the audit.

That gap — between knowing what the framework requires and having data that actually behaves that way — is where the real cost sits. This article is about closing it.

What the NDMO framework is, in plain terms

The National Data Management Office is the Kingdom’s national data regulator. It issues the national data management and personal data protection standards, organised into fifteen domains that follow data across its whole life: how it is created, described, classified, secured, shared, retained and eventually destroyed.

Two of those domains tend to absorb most of the attention — data classification, and personal data protection — because they carry the clearest consequences. But they are the two hardest to satisfy if the domains underneath them were skipped, and that is the trap most programmes fall into.

Covered entities include government bodies, government-affiliated organisations, and private-sector entities that work with public-sector data. If you hold a government contract that involves their data, the framework reaches you.

Compliance is not a one-off exercise. Covered entities complete an annual compliance audit and return the results to the NDMO — which means governance has to survive the eleven months when nobody is watching, not just the month when someone is.

Why the classification domain is where programmes stall

Data classification sounds like a labelling exercise. In practice it is the point where every unresolved question about your data becomes visible at once.

To classify a field you have to know what it contains, where it came from, who owns it, who may see it, and how long it must be kept. Most organisations can answer those questions for the systems they built recently. Almost none can answer them for the systems they inherited — the ones that actually run the business.

So classification exposes the real problem: the absence of a data catalogue, undefined ownership, and lineage that exists only in the heads of three people. Those are separate domains in the framework, and they are prerequisites, not parallel work.

The practical consequence: if you start your programme with classification because it feels most urgent, you will stall within weeks. Start with catalogue, ownership and lineage, and classification becomes mechanical.

Where NDMO and PDPL meet — and why treating them separately costs money

The Personal Data Protection Law came into force on 14 September 2023, with a compliance deadline of 14 September 2024. SDAIA is the regulator, while the Saudi Central Bank retains jurisdiction over the financial sector.

The obligations are concrete. Most controllers must register on the National Data Governance Platform. A data protection officer is mandatory for public entities processing personal data at scale, for controllers whose core activity involves large-scale monitoring, and for those whose core activity involves sensitive data. Breaches must be reported to SDAIA within 72 hours of discovery. Cross-border transfers are governed by their own rules. Fines reach SAR 5 million for standard violations, and intentional disclosure of sensitive data carries up to two years’ imprisonment and fines up to SAR 3 million.

Here is the part organisations get wrong. PDPL compliance is usually assigned to legal or compliance, and NDMO alignment to IT. Two teams, two budgets, two sets of consultants — and both are asking the same underlying question: what personal data do we hold, where is it, and who can reach it?

Answer that question once, properly, and you have satisfied the evidence requirement for both. Answer it twice, in two formats, and you have paid twice for the same inventory and created two versions that will disagree within a quarter.

What an implementation that survives the year looks like

Four things separate programmes that hold from programmes that decay.

1. Ownership that names a person, not a department

“The data office owns customer data” is not ownership. A named individual who signs off on definitions, approves access and is asked when the quality rule fails — that is ownership. Every domain in the framework assumes someone can be asked. If nobody can be named, the control does not exist regardless of what the policy says.

2. Rules that run, not rules that are documented

A quality rule written in a policy document is a statement of intent. The same rule implemented in the pipeline, failing the load and raising an alert, is a control. Auditors can be shown the document; the business only benefits from the second. Build the rules where the data moves.

3. Lineage captured automatically

Lineage maintained by hand is accurate on the day it is written and wrong a month later. If your platform can emit lineage from the pipelines themselves, that is the version that will still be true at audit time. Manual lineage diagrams are the single most common thing we find out of date during assessments.

4. Classification applied at the source

Classify a field once, where it enters the estate, and let the label travel with it through every downstream copy. Classify at each report and dashboard instead, and you will spend the rest of the programme reconciling labels that disagree.

A sequence that works

If you are starting now, this order avoids the usual stalls:

1. Inventory before assessment. You cannot assess maturity in domains you have not inventoried. Catalogue the systems and the data they hold first, even roughly.
2. Ownership next. Assign named owners per data domain. This is an organisational decision, not a technical one, and it is usually the longest pole — start it early and run it in parallel with everything else.
3. Lineage and quality together. They share the same instrumentation. Doing them in one pass costs far less than two.
4. Classification and personal data controls last. With the three above in place, these become configuration rather than investigation.
5. Then assess. A maturity assessment run against a governed estate produces a gap list you can act on. Run against an ungoverned one, it produces a list of things you already knew.

The question worth asking before you commit budget

Not “are we compliant?” but “if the regulator asked us today where a specific customer record came from, who owns it, who has accessed it and when it will be deleted — how long would it take us to answer, and would two teams give the same answer?”

If the honest answer is weeks, or that the two teams would disagree, the gap is not in your policies. It is in the data layer underneath them, and no amount of documentation will close it.

Smart Way Technology builds that layer. Our data management practice covers catalogue, ownership, lineage and quality as engineering work rather than documentation, and our technology consulting team helps sequence the programme so the regulatory deadline and the operational benefit arrive together rather than years apart.

If you are scoping an NDMO or PDPL programme and want a view on sequencing before you commit budget, talk to us — we are happy to look at the scope on its own.