Who Owns This Data? A Field Guide to Data Governance

A colleague emails you a simple request. She wants a dashboard that combines enrollment numbers with financial aid data and a few advising notes, nothing exotic, just three sources she already has access to in separate systems. You say yes, of course, and then the questions land: who approves pulling those together? Is the advising note confidential or internal? Who fixes it if a number is wrong? Two weeks later the request is still sitting in someone’s inbox, not because anyone objected, but because nobody could say who was supposed to decide.

That gap, the silence where an answer should be, is what data governance fills. Not a committee, not a policy binder, not a piece of software. A working agreement about how the institution treats its most valuable asset, so that the next time someone asks “who owns this data,” there is an answer, and it does not take two weeks to find.

This is the data governance framework we developed at UC Santa Barbara, and I built a website to lay it out and show how to apply it. What follows is the short tour. Think of it as a field guide: enough to recognize the terrain and start walking it.

Most governance efforts die because they begin with tools and rules instead of purpose. The framework starts the other way around, with three goals that sound almost too plain to argue with. Set clear standards so data is easier to access, more accurate, and better secured. Get more value out of data while spending less to manage its risk. And give staff, faculty, and students what they need to use data well.

Underneath the goals sit the principles, the lens every decision gets weighed against. A few of them carry most of the weight. Accountability means every data asset has a named owner, and that ownership lives as close to the data as possible, not parked with a central office that has never touched it. Data as a strategic asset means we treat information the way we treat money or facilities, as something with real value to steward. Empowerment means responsibility goes to the people with the most direct knowledge to act, not the highest title. Get the principles right and most of the day-to-day calls make themselves.

The machinery of governance comes down to five components. They are not exotic, and that is the point. Almost every mature program in higher education has some version of them.

Two of them are about knowing what you have. Roles and responsibilities defines who is accountable, who executes, and how a hard call escalates. The data catalog is the searchable inventory of what data exists, what each term means, and how sensitive it is, so people can find data and trust what they find.

The other three are about keeping it usable. Access lifecycle management governs the full path by which access gets requested, granted, reviewed, and eventually revoked. The data quality framework sets the rules and thresholds that keep the data honest, and fixes both the bad data and the broken process that produced it. And the technology framework is what enables the rest. Five parts, no mystery.

Notice what is not on that list: compliance. FERPA, GLBA, and HIPAA are not a sixth component bolted on at the end. They thread through all five, and the thread is classification. You sort data by sensitivity into Public, Internal, Confidential, or Restricted. The classification tells you which laws apply, and those requirements flow into who gets access and what gets audited. Classify well and compliance mostly takes care of itself.

The component people ask about most is the roles, because this is where governance either earns trust or loses it. The framework names six, and they sort into two layers.

The first layer sets direction. A Data Governance Committee holds final authority for institution-wide calls, a Work Group turns that direction into consistent practice across domains, and Advisory Teams translate strategy into day-to-day standards inside each domain. The second layer does the work close to the data. A Data Trustee is the accountable owner for data in their domain, the one who answers for how it is used. A Data Steward is the subject-matter expert and the Trustee’s delegate, making the everyday calls and keeping the catalog current. A Data Custodian handles the technical side: storage, security, provisioning.

The distinction that matters most is simple. Authority can be delegated. Accountability cannot. A Steward or Custodian can make a call, but the Trustee still answers for it. That single line keeps the whole structure honest.

A framework that only lives on a website is decoration. The point is to apply it, and that happens at two very different scales.

The big scale is a project. A new system, a data warehouse, a CRM rollout. You start not with tooling but with a conversation: what data are we governing, which domains does it span, how is each piece classified? From there the initiative follows a repeatable lifecycle. You name the roles in a RACI chart, set the access and quality rules, build the catalog entries, confirm compliance, and only then launch. When the data crosses domains, the same steps still apply, with the Work Group coordinating shared standards so nothing falls through the seams.

The small scale is where governance lives or dies. Most data decisions never become projects. A spreadsheet lands in your inbox. Someone wants a one-off export. A duplicate record turns up. The same framework still applies, compressed into a loop you can run in about two minutes. Classify the data. Find the owner, the Trustee and Steward. Check what the catalog and policy already say. Route the call, Steward for the routine, Trustee for the real decision. Then record it, so the choice is auditable later. Govern those small moments well and the big projects mostly take care of themselves, because the instincts are already built.

This is also where something like AI enters the picture. An autonomous agent that reads data and acts on it is, in governance terms, just a powerful new Custodian: it executes under delegated, bounded authority, while a human Trustee stays accountable for what it does. The framework does not need to be rewritten for AI. It just has to be applied with more discipline, which is true of every new tool that has ever touched institutional data.

The last thing worth saying is that governance is never finished. The framework includes a maturity model, built on the long-established Capability Maturity Model and on Stanford’s 2011 data governance maturity model designed for higher education, that maps the climb from initial and ad hoc up to optimizing. Nobody starts at the top. The value is not in scoring high. It is in knowing honestly where you stand and what the next rung looks like.

If your institution cannot yet answer “who owns this data,” that is not a failure. It is a starting point, and it is a more common one than most leaders admit. The work of getting to an answer, naming the roles, classifying the data, building the catalog, is unglamorous and slow and exactly the kind of thing that separates institutions that merely collect data from those that put it to use.

That dashboard request from the start of this piece should take an afternoon, not two weeks. Good governance is mostly the difference between those two.