A data governance framework you can run without a full-time team

Most governance frameworks are written for global banks. A 200-person business does not need eleven roles and a council. It needs four decisions, one page per domain, and fifteen minutes a month.

Search for a data governance framework and you will find documents written for organisations with thousands of staff. They describe councils, charters, stewardship committees and a dozen named roles. For a business of 100 to 500 people, that structure cannot be staffed and will not be used.

This is a smaller framework. It keeps the parts that stop reports disagreeing and audits dragging on, and drops the parts that only exist to coordinate a very large organisation. It is built for operations owners, data leads and compliance buyers who have no spare headcount and need something that runs alongside the day job.

The well-known frameworks are not wrong. They were written for a different problem. A global bank has hundreds of systems, dozens of regulators and thousands of people touching the same data. It needs a formal structure to coordinate all of that.

A mid-market business has a different problem. It usually has a handful of core systems and a small number of people who know where the numbers come from. Nobody's job title includes the word governance. Applied at that scale, the enterprise framework produces meetings and documents, and very little else.

The symptoms are familiar. A steering committee that meets twice and dissolves. A data policy nobody has opened since it was signed. A governance tool bought before anyone agreed what it should govern.

Governance at mid-market comes down to four decisions, made for one data domain at a time. Who owns the domain. What its key terms mean. Which report is the canonical one. Who corrects bad data at the source. Write the answers on one page, review them monthly, and add the next domain when the first one is working.

Everything below is detail on those four decisions.

A domain is a set of data the business talks about as one thing. Customer, product, finance, people and operations are the usual starting list. Each one gets a single named owner from the business side.

The owner does not do the data work. They decide what good looks like, settle arguments about definitions, and are accountable when the numbers are wrong. In practice this takes an hour or two a month.

Ownership sits with whoever depends on the data most. The head of operations owns operational data. The finance lead owns finance data. If ownership defaults to whoever administers the system, you have systems ownership, which is not the same thing.

Most disputes about numbers are disputes about definitions. Sales counts an active customer one way, finance another, and the board pack quietly uses a third.

For each domain, list the ten or so terms that appear in reports and decisions. Write a one-line definition for each, agreed by the owner. Active customer. Open order. Headcount. Gross margin. Where two teams disagree, the owner picks one meaning and the other team adjusts its report.

This is the cheapest work in the framework and the most valuable. A short glossary per domain removes a whole class of recurring argument.

Every duplicated report is a fork in the truth. Two versions of the sales number will drift apart, and someone will spend a morning reconciling them before every board meeting.

For each domain, name one report as the canonical view. Other reports may exist, but when the numbers differ, the canonical one is right by definition and the others are corrected to match. Naming it costs nothing. Not naming it costs a reconciliation every month.

When a record is wrong, there are two places to correct it. In the system where it was entered, or in the report where it was noticed. Correcting it in the report is faster today and more expensive forever, because every downstream consumer inherits the error again next month.

The framework rule is simple. Bad data is corrected at the source, by a named person, inside an agreed time. The owner decides who that person is and how quickly it happens. A weekly list of records failing the domain's quality rules is usually enough to make this work.

The whole framework for a domain fits on one page.

• Owner. A name, not a team.
• Definitions. The key terms and their agreed meanings.
• Canonical report. Its name and where it lives.
• Source of truth. The system every other system reconciles to.
• Quality rules. The handful of checks a record must pass, and the current pass rate.
• Correction rule. Who corrects failures, and how quickly.
• Access rule. Who can see the data, and who can change it.

If the page runs to a second screen, it is too long. Short pages get read and kept current. Long ones drift.

The framework needs three roles, and none of them is a new hire.

The owner is an existing business lead, as above. A couple of hours a month.

The steward is the person who already knows the data best, usually an analyst or a systems administrator. They keep the page current, run the weekly quality list, and chase corrections. A few hours a week for the first quarter, less after that.

The forum is the existing operations or leadership meeting. Governance gets a fifteen-minute standing item once a month. Which domains are working, which quality rules are slipping, what the next domain will be. There is no separate council.

Monthly, the forum reviews each governed domain for fifteen minutes. Quarterly, the business adds one new domain. Annually, the pages are reread and anything stale is removed.

That rhythm means a business governs its four or five core domains inside eighteen months, without a project, a programme or a full-time team.

For finance, health and insurance businesses, the same pages answer the questions auditors and regulators ask. Who is accountable for this data. How do you know it is accurate. Who changed it, and when.

A governed domain produces that evidence as a by-product of running the framework. There is no separate compliance programme to maintain.

Every AI project depends on the data underneath it. Before an assistant or an agent is connected to a domain, the owner, the definitions and the correction rule should already exist. Otherwise the AI inherits every disagreement the business has not yet settled.

Our readiness assessment scores exactly this. Ten questions, ten minutes, and a view of whether your data is ready for anything to act on it: take the readiness assessment.

If you are starting from scratch, pick the domain where confusion costs the most and draft its one page. The decision-maker's guide to data governance covers what to decide first and what results to expect inside a quarter. For how governance connects to the systems that carry your data, see data management services.

If you would like a second pair of eyes on your first domain page, get in touch. The first conversation is short and there is no pitch.

Four decisions, one page per domain, fifteen minutes a month. That is a governance framework a mid-market business can actually run.