Data governance in plain English: a working glossary for growing businesses

A plain-English glossary of data governance terms for growing businesses using Power BI and Fabric, covering ownership, meaning, trust, permissions, and adoption.

Data governance has an image problem. Say the words to most business owners and they picture committees, policy documents nobody reads, and a level of bureaucracy that only makes sense if you are a bank. For a growing business that is not where the value is.

But the vocabulary still matters, because when a report disagrees with the finance system, or two teams argue over which customer number is right, what you are really running into is a governance question. You just did not call it that.

So here is a plain-English guide to the terms worth knowing. No framework worship, no jargon for its own sake. Just what each term means, and what it looks like when your data lives in Power BI and Fabric rather than in a forty-person data office.

What you are really running into is a governance question. You just did not call it that.

Who owns the data

Most data problems are really ownership problems in disguise. These are the roles that decide who answers for what.

• Data owner. The person accountable for a set of data and the decisions about it. Not the person who built the report, the person who carries the can if it is wrong. Usually a business lead, for example the head of sales owning customer data.
• Data steward. The person who does the day-to-day looking after. They keep definitions straight, chase down quality issues, and act as the point of contact when something looks off.
• Data custodian. The technical role that stores and secures the data and keeps the plumbing running. Often sits in IT or with your data partner. Owns the how, not the what.
• Data governance group. A small, cross-functional group that sets priorities and settles the arguments individual teams cannot. It works best as a short standing meeting with the right people in the room, not a standing army.

In a Microsoft estate, ownership shows up whether you name it or not. Every Power BI workspace has an admin, every semantic model has a contact, every Fabric domain has someone responsible for it. The trick is to make those match your real business owners rather than defaulting to whoever happened to set the thing up. That question gets sharper, not softer, once AI agents start acting on the data as well as reporting on it.

What the data means

Half of all data disputes are really language disputes. Two people using the same word to mean different things. These terms are about agreeing what the words mean.

• Business glossary. The agreed set of business terms and their definitions. What counts as an active customer, how you define revenue, when a lead becomes an opportunity. Boring to write, invaluable when two departments disagree.
• Data dictionary. The technical companion to the glossary. It describes the actual fields, tables, and formats in your systems, so a definition can be traced to where it physically lives.
• Metadata. Data about your data. Where a figure came from, who owns it, when it last refreshed, how it is calculated. It is the context that turns a number into something you can trust.
• Critical data element. The handful of fields your business genuinely runs on. Customer identifier, product code, order value. Worth governing tightly, because an error here is expensive. The rest can be looser.

Microsoft Purview is where much of this becomes real for Fabric and Power BI users. It holds the glossary, records lineage, and surfaces metadata across your estate. You do not need all of it on day one. Start by writing down the ten terms your leadership team argues about most, and you have made more progress than most.

Whether you can trust it

A report is only as useful as the confidence people have in it. These terms are about earning that confidence.

• Data quality. How fit the data is for the job you need it to do. Complete, accurate, timely, consistent. Perfect is rarely the goal. Good enough to decide on is.
• Data quality rule. A specific check that tells you when quality has slipped. No order without a customer, say, or no negative stock. The value is in catching problems before a director does.
• Data lineage. The story of where a number came from and everything that happened to it on the way. When someone asks why two reports disagree, lineage is how you answer without guessing.
• Master data. The core shared records everything else hangs off, your customers, products, and suppliers. When each system holds its own slightly different version, you get the classic problem of nobody agreeing how many customers you actually have.

Power BI gives you more of this than people tend to use. Lineage view shows how sources, models, and reports connect. Endorsing a dataset as certified tells the business which version to trust. And most single-source-of-truth arguments are really master data problems that a shared, well-owned model in Fabric is meant to solve. Trust matters even more now that some reports can write data back into the source system, not just read it.

What people are allowed to do with it

Governance is not only about trust, it is about permission. These terms cover the rules and who they apply to.

• Data policy. The high-level rules for how data is handled across the business. Usually short, usually about retention, privacy, and acceptable use. The kind of thing you write once and point to often.
• Data standard. The agreed conventions that keep things consistent. Date formats, naming, how a country is recorded. Unglamorous, but they are what stop two systems failing to talk to each other.
• Data classification. Labelling data by how sensitive it is, so everyone knows what needs protecting. Public, internal, confidential, and so on.
• Access control. Deciding who can see and change what. The principle worth holding onto is that people should have access to what their job needs, and not by default to everything.

In the Microsoft world this is mostly about sensitivity labels and Entra ID groups rather than spreadsheets of permissions. Labels applied in Purview follow the data into Power BI and Excel. Row-level security lets a single report show each manager only their own region. Done well, security stops being a barrier and just becomes how the thing works. If AI tools are in the mix, those same access questions sit alongside your UK data protection obligations, not instead of them.

Whether anyone actually uses it

The best-governed data in the world is worthless if people go back to their own spreadsheets. This last set is about adoption, which is where most governance quietly succeeds or fails.

• Data catalogue. A searchable inventory of what data you have and where to find it. Its job is to stop people rebuilding something that already exists because they did not know it was there.
• Data literacy. The everyday ability of your people to read, question, and use data without needing an analyst to translate. Often the highest-return investment on this whole list.
• Change management. The unglamorous work of helping people actually adopt new ways of working. New reports, retired spreadsheets, different habits. Governance is as much about this as it is about policy.

Adoption is the part no tool solves for you. Purview and Fabric give you a catalogue and a home for trusted content, but people use what they trust and understand. That is why we treat literacy and the quiet business-change work as part of the job rather than an afterthought. It is really the same question we ask at the start of every project, just asked about data instead of people.

Where to start

None of this needs to arrive as a programme with a capital P. For most growing businesses, governance is better done in small, deliberate steps. Name the owners. Agree the ten terms that matter. Certify the reports people should trust. Build from there. For the wider vocabulary beyond governance, our data, analytics and AI glossary covers the rest.

Get those right and the rest tends to follow. If you would find it useful to talk through where your own reporting sits against this, that is the sort of thing we do. You can reach us at hello@hoptonanalytics.com.