Data quality and data governance for small teams: definitions, owners and validation

Ask three people in a small company how many active customers you have and you may get three answers. Sales counts anyone with an open deal, finance counts anyone billed this quarter, and marketing counts anyone who opened an email. Each number is correct by its own definition. Together they make every meeting slower and every decision shakier.

Data governance sounds like something only large organisations need. In practice, a small team needs a light version of it: agreed definitions, a named owner for each important dataset, and simple checks that catch bad data at the door. This guide draws on the UK Government Data Quality Framework, ICO guidance on accuracy and Microsoft’s documentation on data validation.

What data quality and governance mean

The Government Data Quality Framework, published by the Government Data Quality Hub in December 2020, defines quality as fitness for purpose. Data is good enough when it serves the use you have in mind. A rough customer count may be fine for a team update and not good enough for an invoice.

Governance is the set of decisions about who is responsible for data and how it should be handled. The Wikipedia article on data governance describes it as the principles, policies and processes that guide the effective and responsible use of data, from creation to disposal. Governance decides the rules; data management carries them out through work such as quality checks and metadata.

Six dimensions to check against

The framework uses six dimensions from DAMA UK to describe quality. They make a useful checklist for any dataset:

The framework says these dimensions are not a fixed list and can be adapted. For a small team, pick the two or three that cause the most trouble and measure those.

Write definitions down

Most arguments about numbers are arguments about definitions. Keep a short data dictionary: a single shared document or sheet that lists each important metric and field, with:

• the name, written once and used everywhere;
• a plain-English definition, including what is excluded (test orders, refunds, internal accounts);
• where the data comes from and how often it updates;
• the owner, who settles disputes and approves changes.

This is the kind of metadata the framework asks teams to document and share, because it reduces ambiguity and makes data easier to reuse. Start with the ten numbers that appear most in meetings. Twenty well-defined terms are worth more than two hundred half-filled ones.

Give every dataset an owner

An owner is the person accountable for a dataset’s quality and use. That does not mean doing all the data entry. It means deciding the rules, fixing the process when errors keep appearing, and approving who can access the data. The framework’s principles include committing to data quality through accountability and capability, knowing your users and their needs, assessing quality throughout the data lifecycle, communicating quality clearly, and anticipating changes that affect quality. In a small team, the owner is the person who makes those principles happen for their dataset.

Name owners by role and person: “Customer list: head of sales (Asha)”. Review the list when people join or leave.

Validate at the point of entry

The framework’s fifth principle includes fixing problems at source. It is far cheaper to stop a bad value being typed than to clean it later. In Excel, data validation lets you restrict a cell to a list, a range of numbers, dates within a window, a text length, or a custom formula. You can add an input message that explains what to enter and an error alert. A Stop alert blocks invalid entries; Warning and Information alerts let people override.

Know the limits. Microsoft notes that validation acts only when someone types directly into a cell, so copied or filled data does not trigger the messages, and existing data is not checked until you use Circle Invalid Data. Pair validation with a periodic check, such as a COUNTIFS for blanks or duplicates, rather than relying on it alone. Google Sheets and most CRM and form tools offer similar controls.

Personal data has a legal accuracy duty

For personal data, accuracy is a legal requirement in the UK, not only good practice. The ICO’s guidance on the accuracy principle explains that personal data must be accurate and, where necessary, kept up to date, and that you must take every reasonable step to correct or erase inaccurate data without delay. Reasonable steps include recording information accurately with its source, checking data you create, and acting on signs that a record is wrong, such as returned mail. The more a decision affects someone, the more care is expected. The ICO notes that this guidance is under review following the Data (Use and Access) Act, so check the current version before relying on details.

A worked example and common mistakes

An example (illustration only): a ten-person training company finds its course bookings sheet, its CRM and its accounts disagree on monthly revenue. The founder runs a one-hour session and agrees that “monthly revenue” means invoiced course fees, excluding VAT and refunds, dated by course start. Finance owns the definition. Bookings get dropdown validation for course codes and a date window, a weekly COUNTIFS flags blank emails and duplicate bookings, and a short data dictionary tab records the agreed terms. Within a month, the three reports match, and when they drift, everyone knows who to ask.

Common mistakes to avoid:

• Writing a long governance policy nobody reads instead of a one-page dictionary people use.
• Making “everyone” responsible for a dataset, which in practice means no one.
• Cleaning the same errors every month instead of fixing the form or process that creates them.
• Trusting validation to catch pasted or imported data.
• Keeping personal data you no longer need, or not acting when you learn it is wrong.

Start light. Definitions, owners and entry checks for your most important data will solve most problems. Formal roles, tools and committees can wait until the team and the data have grown enough to need them.