Name an owner before you write the policy

Teams often start data governance by drafting a policy. The draft sounds complete. It covers quality, privacy, retention, and access. Then two departments disagree about what "active customer" means, and the policy has nobody in it who can decide.

An owner is the person who can settle that disagreement. The owner is accountable for one set of data the business already uses. A steward usually does the day-to-day work: checking a break, updating a definition, bringing an issue to the forum. The owner is the person who says which definition stands when the steward and another team cannot agree.

What the owner is asked to decide

Keep the list short. For the data in scope, the owner should be able to answer three questions.

• Which definition is the one the business will use?
• Who may change a critical field, and who must be told?
• Who closes a quality break, and how long may it stay open?

If the same person cannot answer those questions, the role is still a title. Write the name next to the data set, not next to a department. "Finance" cannot attend a meeting or close an issue. A person can.

Start with one domain

Do not assign owners for every system in the first month. Pick the data behind one decision the business already makes, such as the monthly forecast, a regulatory filing, or which orders are ready to ship. List the data sets that decision depends on. Put one owner and one steward on each set that would hurt the business if it were wrong.

The record of that work is an ownership matrix: the data set, the owner, the steward, and what happens when they find a break. A policy written after that matrix exists has someone to enforce it. A policy written before it is a document people can agree with and still ignore.