You can do everything the playbook says — crawl the warehouse, inventory the columns, classify what you find — and still end up with a catalog nobody trusts and questions nobody can answer. It's one of the most common and expensive places a governance effort gets stuck. If that sounds familiar, the problem usually isn't effort or tooling. It's the starting point.
Most governance starts with the data: thousands of columns waiting to be labeled. But a column on its own can't tell you why it matters, who depends on it, or what breaks if it's wrong. Those answers live in how the business actually works — in its processes. Start there instead, and the rest of governance gets a lot easier. Here's what changes, and how to put it into practice.
Let ownership follow the work
Ask “who owns this table?” and you'll get a shrug. Ask “who runs the monthly close?” or “who's responsible for outage restoration?” and someone answers right away. Ownership is nearly impossible to assign in the abstract and obvious the moment you attach it to a process.
Try this: instead of chasing owners table by table, list your key processes and name the person accountable for each. Let the data each process touches inherit that owner. You'll assign more real ownership in an afternoon than in months of asking “whose is this?”
Give policies something concrete to attach to
A retention or access rule written against “customer data” in general is an intention. The same rule attached to the specific activities that create, read, and report on that data is something you can actually enforce — and explain to someone who asks why.
Try this: for each policy you have, write down the processes it applies to. If you can't name them, the policy isn't ready to enforce yet — and knowing that is far better than assuming it's covered.
Prioritize by what breaks, not by what's alphabetical
You can't govern everything at once, and teams that try tend to burn out before they finish. Processes give you a ranking the raw data can't: govern the assets your most critical work depends on first. A classification gap on data feeding a regulatory report is not the same as one on a scratch table nobody reads.
Try this: pick the two or three highest-stakes processes you have — the ones tied to revenue, safety, or a regulator — and trace the data they depend on. That short list is your first governance backlog, already in priority order.
Make the audit a story you can tell
Auditors don't really want a list of controls; they want to follow a thread: this process, run by this person, uses this data, governed by this rule, and here's the record of what changed. When your governance is organized around processes, that narrative mostly already exists.
Try this: take one important process and try to tell that story end to end today. Wherever the thread breaks — an unnamed owner, a policy with no teeth, a missing log — you've just found your next piece of work.
Where to start this week
You don't need a new platform or a reorg to begin. Pick one process that matters and map it simply: the steps, the systems each step uses, the data that flows through, and who's accountable. Then answer four questions about it:
- Who owns the data this process depends on?
- What policies should apply — and are they actually in force?
- If this data were wrong or late, what would break?
- Could you show someone the chain from process, to data, to the control that governs it?
The gaps you find are your roadmap. Do it for one process and you'll have a template — and a much easier argument — for the next.
The takeaway
Governing data without the work it serves gives you an inventory. Connecting the two gives you something people actually use. If your catalog is finished but nobody trusts it, the missing piece usually isn't more data — it's the business context that makes the data mean something. Start with one process, and let the work show you what to govern next.