Data governance in the Kingdom began as a response to regulation. The national data management standards issued by NDMO and the Personal Data Protection Law gave organizations a clear obligation and a timetable, and many answered the way institutions answer an audit. Policies were drafted, a data council was convened, a catalog was licensed and a maturity score went to the board. Those steps were necessary. In too many organizations, they are also where the program stopped.
The symptoms are familiar to anyone who sits on an executive committee. The governance office reports steady progress. The business experiences governance as forms, approvals and a new vocabulary. And the meeting still opens with two versions of the same number and a debate about which one to believe. The lesson is consistent: a program built to satisfy a regulator rarely improves a decision, while a program built around decisions usually satisfies the regulator along the way.
Begin where the stakes are highest
Conventional programs begin with an inventory. They set out to catalog, classify and assign a steward to every dataset at once. The effort is enormous, the payoff is invisible to anyone outside the data office, and by the time the catalog is complete the executive sponsor has often moved on.
A better starting point is a short list of decisions where leadership most needs confidence in the numbers. Which beneficiaries qualify for a service. Where next year’s budget should go. How much capital a loan book requires. Which suppliers carry unacceptable risk. Each of these decisions rests on a small set of critical data elements, and those elements, together with the processes that create them, are where governance belongs first.
This sequencing also settles a tension most programs never resolve. The data behind major decisions is usually the data with the greatest regulatory exposure: personal records, financial positions, information shared between agencies. Govern that data well and a single investment improves decisions and satisfies the regulator. Scope then grows outward from demonstrated control, which is a far stronger story for a board than the share of datasets cataloged.
Treat critical data as a product
The most useful shift we see is one of category. Critical datasets are managed as products, each with customers who depend on it. A data product has a named owner, a published definition, a stated quality standard, known consumers and a clear route for requesting change. It is built once and used many times: the beneficiary register that drives eligibility decisions is the same one that feeds planning dashboards and, later, the AI models that depend on lawfully sourced, well-described data.
The product framing changes behavior in ways a policy document cannot. Owners start asking who relies on their data and what breaks when it arrives late or wrong. Consumers stop building private copies because the shared version can be trusted. Privacy obligations such as purpose limitation, retention and access control are engineered into the product once, so they no longer have to be renegotiated with every new request. Compliance is then built into the data itself, and the evidence a regulator asks for becomes a byproduct of normal operations.
The test of data governance is whether leadership meetings start from numbers nobody disputes. Everything else is activity.
Put ownership where the data is made
Ownership is where most programs quietly fail. It is tempting to hand data ownership to IT or to the data office, because they are willing and the business is busy. The result is predictable: the people held accountable for quality have no authority over the processes that create the data, so they spend their days correcting errors they cannot prevent.
Ownership belongs with the executive who runs the process that produces the data. Finance owns financial positions. Human resources owns workforce records. The service owner owns the beneficiary record. The data office has a different and equally important job: it sets standards, provides shared tooling, arbitrates disputes over definitions and reports to leadership on the health of each data domain. Separating the referee from the players gives both a job they can actually do.
Owners also need explicit decision rights. A short written answer to each of the following questions settles most disputes long before they reach the executive committee:
- Who defines the meaning of a critical data element, and who approves a change to that definition.
- Who sets the quality threshold for a data product and declares it fit for a given use.
- Who grants access to personal data, for which purpose and for how long.
- Who decides when two domains claim the same record or publish conflicting figures.
Match quality to consequence
Enterprise-wide quality targets sound rigorous and almost always disappoint. Uniform standards spread effort thinly and exhaust the stewards asked to meet them. Quality effort should follow consequence. An error in a reference table behind an internal report is an irritation. An error in a national identifier, a patient record or a payment instruction is a material risk, and sometimes a legal one.
The discipline follows directly from the product model. Set quality rules for each data product according to the decisions it serves. Measure them continuously, as close to the point of creation as possible. Route every failure to the owner of the process that caused it. Cleansing data downstream, in a warehouse or a report, treats the symptom and guarantees that the same defect returns next month. Quality is a property of the process that creates the data, and it improves only when that process changes.
Build literacy into the work
Literacy is the element most programs underfund, and the one they can least afford to. Governance asks people across the organization to work differently: to capture data carefully at the source, to respect classification and consent, to question a figure before it is forwarded to a minister or a chief executive. Generic awareness courses rarely change those habits.
Literacy takes hold when it is specific to the role and taught through real work. Executives need to know how to interrogate a dashboard and what to expect from a data owner. Front-line staff need to understand why a particular field matters and what happens downstream when it is skipped. Analysts and engineers need working fluency in the privacy obligations attached to the data they handle. Programs that use the organization’s own data products as teaching material do double duty: they build skill, and they build demand for the products.
Literacy at the top starts with asking the governance program better questions. Which decisions has it made more reliable this year? Which data products have owners who can name their consumers? Will the evidence for the next regulatory review come from routine operations or from a last-minute scramble? A program that can answer all three will meet its regulatory obligations as a matter of course. More to the point, it will have earned its place on the executive agenda.