In your first course, you learned what data governance is and why the business (not just IT) owns it. This course is where governance stops being an idea and starts running in your everyday work: real roles, clear decision rights, workable standards, and shared records people actually trust. As a Data Governance Analyst, this operating layer is where you'll spend most of your time, so getting it right pays off every single week.

By the end of this course, you'll be able to:

• Assign clear data ownership and stewardship so decisions actually get made
• Clarify who decides what using the RACI model
• Convert broad principles into testable standards with named owners
• Curate glossary and catalog records a newcomer can trust without asking anyone
• Trace business lineage to predict the impact of a change before you make it

This first unit starts with the foundation everything else rests on: who owns data, who stewards it, and what goes wrong when no one does.

When a data problem drags on for months, it's almost never because the data is uniquely broken. It's because no one is clearly in any of the roles that would fix it. So before you can solve anything, you need a shared vocabulary for who does what. That's the Core Governance Roles framework, and it has five parts.

The data owner is accountable for the business meaning of a dataset and the decisions about it. Think of the owner as the editor-in-chief: they don't write every word, but they have the final say on what a term officially means and when the rule changes. Working alongside them, the data steward handles the day-to-day: clarifying definitions, watching quality, and chasing down issues when something looks off. If the owner sets the rule, the steward keeps the rule running.

The other three roles round out the picture. The data custodian is usually a technical colleague who manages the environment and controls where the data lives, like the building superintendent who keeps the plumbing working but doesn't decide who moves in. The data consumer is everyone who uses the data to do their job and gives feedback when it's wrong.

Finally, the governance lead keeps the whole system in rhythm: running the forums, maintaining standards, and making sure decisions don't quietly stall. Most people in your organization are consumers; the trouble starts when nobody is clearly the owner or steward.

Here's the pattern you'll see again and again: lots of teams use a piece of data, every one of them feels the pain when it's wrong, and not one of them has the authority to decide the fix. When everyone uses it and no one owns it, the data drifts, the same argument reopens every month, and each team quietly assumes another team is handling it.

Your job in these moments is to diagnose the gap, not to grab the nearest team and blame them. Walk through the five roles and ask, for this specific dataset, who is actually playing each part right now. You'll usually find plenty of consumers and a custodian keeping the systems running, but an empty seat where the owner and steward should be. That empty seat is the root cause. Without an owner, there's no one authorized to set the official rule, and without a steward, no one coordinates the cleanup, so the inconsistency simply regenerates.

The discipline that matters here is tying each gap to a concrete consequence rather than a vague complaint. "Nobody owns this" doesn't move anyone. "Because no one owns the email rule, billing and support store it differently, so renewal notices bounce" does. Name the missing role, then name what it costs.

Once you've found the empty seat, the next move is harder than it sounds: getting someone to sit in it. People resist ownership because they imagine it means personally fixing every bad record forever and getting blamed for problems they didn't create. So when you draft stewardship expectations, your real task is to define the role's boundaries clearly enough that a reasonable person would accept it.

Three things make a role acceptable. First, decision authority: spell out exactly which decisions the owner gets to make, such as the official definition or the rule for what counts. Second, quality responsibilities: clarify what the owner and steward are expected to watch and coordinate, not what they must fix alone.

Third, an escalation path: a defined route for when teams still can't agree, so the role comes with a safety valve instead of a dead end.

• Chris: So if I "own" the regional sales numbers, does that mean I'm the one fixing every wrong entry from now on?
• Natalie: No. Owning it means you get to decide the official rule for what counts, and you're who teams come to when they disagree. The day-to-day fixes and coordination sit with a steward.
• Chris: And if two teams still can't agree?
• Natalie: Then it follows an escalation path up to the governance forum, not onto your shoulders alone. Ownership is decision authority with a safety valve, not solo cleanup.

Notice how Natalie defuses the fear by drawing boundaries: she separates deciding from fixing, and she names where the buck goes when agreement breaks down.

The takeaway for this unit is simple: data problems persist not because data is hard, but because no one holds the decision, and your job is to name the missing owner and steward and define their role so it's bounded and supported. Your path ahead has three steps. First, a quick matching exercise to lock in which role does what, so the five names become second nature. Then you'll write a real diagnosis of an unresolved data mess, tracing each accountability gap to its consequence. Finally, you'll take it live, sitting across from a wary colleague and offering them an ownership role they'll actually accept. Start practicing the move now: every time you hit a recurring data argument, ask "who owns this decision?" before you ask "how do we fix it?"