12 data governance best practices to implement in 2026

A model was trained on customer records that came from an unverified source. When a team member asked why the system flagged a loyal customer as high risk, nobody could give a reliable answer. This scenario represents a governance failure rather than a modelling failure. It is the leading cause of artificial intelligence pilots not reaching production.

Effective data governance starts with a realistic assessment of an organisation's current state instead of creating unused policy documents. Successful programmes give governance responsibility to a specific executive and designate clear owners for each dataset. These programmes create practical policies that employees can follow, use the same standards for artificial intelligence models and their results, and monitor specific performance metrics.

Shipshape Data builds data and AI systems. We observe the same pattern with almost every client we work with.

The algorithms are seldom the source of the issue. The underlying data is frequently unreliable, poorly managed, or hard to locate, and changing the models does not fix these problems. Companies that obtain real results from AI have usually made data governance a practical priority rather than treating it as a policy document that no one reads.

None of this needs to be bureaucratic.

Effective governance cuts operational delays. It lets data scientists rely on data tables without contacting multiple colleagues for verification, and it lets compliance officers answer regulatory enquiries within a few hours. The following twelve practices are listed in the order we usually implement them for new clients. You can start some of these tasks right away, while others need several months to finish. Apply the practices that match your current needs and skip those that do not apply, since most organisations do not need all twelve at once.

1. Start with an AI readiness assessment

Assess your current situation before writing policies or appointing stewards. An AI readiness assessment gives a factual baseline of your data estate, shows where governance is failing, and determines your internal capability to address these issues. If you skip this step, you will probably create policies for problems that have not been confirmed to exist.

We complete this work as a focused project within a set timeframe, usually lasting about one month; this structure is required. Assessments that take longer often lose focus and produce long reports that are not read. Extended timelines also cause the project to lose the momentum it had at the start.

• Identify which datasets generate revenue, create compliance risks, or provide no value.
• Duplicate or conflicting data exists in systems that were not designed to communicate with each other.
• Whether your infrastructure can support real model training and deployment
• Identify the teams that currently use informal data governance and the teams that have no controls.

Use numbers to describe your findings whenever possible. Calculate the hours you spend reconciling different versions of a customer table, the revenue lost because of incorrect segmentation, or the specific fine a regulator would impose for a compliance error today. A finding supported by data receives funding. A finding that only says "data quality is poor" is ignored.

2. Link governance to business results

Governance that operates without a business outcome is ignored, and it deserves that. Instead, tie it to a specific target such as launching an AI product, meeting a GDPR deadline, or reducing customer churn. When the outcome is identified, you can trace back to the datasets, owners, and standards that the outcome relies on.

Unclear goals do not produce practical decisions. The statement "Improve data quality" gives no concrete guidance for everyday tasks. Conversely, the objective to "Cut churn by 15 per cent using a predictive model by Q3" pinpoints the dataset that needs an owner, the fields that must be cleaned first, and the required compliance checks.

• Data must fit the particular AI application where it is employed.
• Privacy outranks convenience, every time, with no exceptions negotiated at 5pm on a Friday
• Lineage must be traceable for anything that touches a regulated decision

These principles enable a team to settle disagreements on its own, removing the need to send each decision to a committee. Link governance straight to the AI lifecycle, covering collection, training, deployment, and monitoring, so that training data quality and output validation become part of the same system as all other processes.

3. Get a named executive behind it, with real decision rights

Governance without a senior sponsor is theatre.

You require an individual who can settle inter-departmental disputes over data ownership and who has the credibility to enforce policy when a team puts a deadline ahead of established procedures. If this individual is absent, anticipate shadow systems such as undocumented spreadsheets, unauthorised data exports, and other workarounds that arise when the official process lags behind unofficial methods.

Write decision rights down properly. "The data team decides" resolves nothing when there's a dispute at 4pm. Better: the Chief Data Officer signs off on external data sharing, domain owners control access to their own datasets, and everyone knows which of the two applies before the disagreement happens.

Keep the council small

A governance council composed of six to eight senior members that meets monthly outperforms a committee of twenty that meets weekly. Assign it genuine decisions, such as major policy changes, cross-domain conflicts, and budget matters, and keep it away from routine approvals that would drown it in minutes each quarter. Provide reports to it. Do not channel every decision through it.

4. Define who owns, stewards, and looks after each dataset

Unclear ownership is the leading cause of waning momentum in governance initiatives.

Unclear responsibility for a dataset leads people to assume others are managing it. This assumption lasts until an audit or a system failure shows the gap. Assign ownership based on business domains instead of technical systems. The commercial director defines the term "customer." A steward within the CRM team performs daily quality checks.

• The specific decisions a role makes. Using vague verbs such as "ensures" leads to roles that lack accountability.
• The number of hours required each month, so that people can make an informed decision before agreeing.
• Who it escalates to when something is outside its authority
• Provide the person with specific tools and templates. If you ask someone to monitor quality without a dashboard, they will not succeed.

Build a RACI matrix across your governance activities, approving access, certifying quality, managing retention, and check two things: that every activity has exactly one accountable person, and that no single person is carrying five roles because nobody else volunteered. Then actually onboard your stewards. A ten-minute intro email is not training.

5. Write policies that people will read

A framework requires written policies to be effective. Without these documents, the framework consists only of intentions.

Write down how data gets created, accessed, shared, and deleted, and keep the document short enough that someone reads it in one sitting.

• A classification policy defining sensitivity levels
• An access control policy stating who can view or change what
• A retention policy setting how long you keep records before deletion
• A data quality policy with minimum standards for completeness and accuracy
• An AI usage policy covering model development and deployment

Ensure every principle is measurable. The phrase "Data must be accurate" provides no specific guidance to an engineer who is building an alert. Instead, use a specific requirement such as "Customer records must match source systems within 24 hours, with no nulls in mandatory fields" to provide clear direction. Limit each policy to two or three pages and write them for the individuals responsible for following the rules. Establish a formal exception process that requires a business justification, a mitigation plan, and an expiration date. Review these exceptions every quarter to prevent them from becoming permanent policy by default.

6. Find out what data you have, including the unstructured mess

You can't govern what you haven't found.

Most organisations understand their primary databases but lack visibility into other areas. This includes software services purchased by finance without informing the IT department, shared drives containing contracts, and chat channels where customer email lists were shared in the past. Unstructured content of this type frequently contains the most sensitive business information while receiving the least amount of supervision.

Start with the systems IT already manages, then expand outward to cloud platforms and SaaS applications where business teams quietly build their own shadow estate. Automated discovery tools help here, scanning storage and APIs for datasets nobody remembered to log. For each one, record where it lives, roughly how big it is, and why it exists.

Classify what you find by sensitivity: public, internal, confidential, restricted, weighed against both regulatory exposure and what it would cost you if it leaked or got deleted by accident. Extend the same classification thinking to unstructured data, documents, emails, chat exports, because retention rules should apply there too.

7. Give everyone the same definitions

Marketing's "active customer" and finance's "active customer" rarely mean the same thing, and the gap between them wastes far more time than anyone admits. A shared glossary, consistent metadata, and traceable lineage fix this, and they fix it cheaply compared with the meetings lost arguing over whose number is right.

Create the glossary using terms the business currently uses in its reports and presentations, rather than the terms preferred by engineers. Define each term in clear language with a practical example, obtain approval from the people who use the data, and require that every important dataset include specific metadata: an owner, a purpose, a refresh frequency, a sensitivity tag, and a quality expectation. Prevent new datasets from being registered until all of these fields are completed. This may seem strict, but it prevents "we'll add that later" from turning into "nobody ever did."

Metadata provides the documentation necessary to transform files into assets that people can use reliably.

Track the path of data from its source through every transformation to its final destination. Use automatic tracking if your pipeline tools support it, and use an approved workflow diagram if they do not. This record allows you to investigate quality issues quickly and provides the evidence auditors require to verify the origin of a specific number.

8. Include quality checks in the pipeline

A quality policy is only effective if it is automated. You must convert your policies into rules that a machine can verify. Examples include ensuring order values are greater than zero, confirming customer emails contain an @ symbol, and checking that product codes match the master reference list. Establish a threshold for alerts, such as an error rate exceeding 2 per cent or a sudden increase in null values in a mandatory field. Place these checks at the point where data enters the pipeline. This prevents issues from reaching later reports where they are harder to correct.

Direct failed routes to a functional location. Log any rejected records and include the specific reason for the rejection. This allows a data steward to identify the original source of the error. Assign a specific owner to every alert category. Every quarter, review these rules to ensure they remain aligned with current business operations and AI models. Rules created for previous versions of a product may incorrectly validate data that is no longer accurate.

9. Make privacy and access controls the default

Build privacy and security into your systems from the beginning instead of adding them after a failure occurs. Give access only to individuals who require it for their specific job duties. Configure permissions to end automatically when a project concludes or a team member changes roles. Use an approval process that includes a complete audit trail for all sensitive data. Prevent bulk exports by default and require a justification for any exceptions.

• We establish retention periods for each dataset based on specific regulatory requirements. The system automatically deletes data when these periods end. This process includes all backups and copies that are often overlooked.
• We encrypt all data while it is stored and during transmission. We also use column-level encryption for the most sensitive data fields.
• We monitor access logs for patterns that indicate a compromised account.
• Perform a quarterly review of UK GDPR requirements for consent, subject access requests, and breach notifications. Include any additional requirements specific to your sector.

Manual retention policies fail when teams become busy. Because teams are consistently busy, you should automate the deletion process.

10. Govern the whole lifecycle

Governance that stops at "who can access this table" misses most of the actual risk. Data has a life: it gets created, transformed, shared, archived, and eventually it should be deleted, and each of those stages needs its own controls. Map the stages for your critical datasets, note who approves each handoff, and you will usually find gaps nobody had noticed, such as a dataset that gets copied into three tools with no owner tracking any of the copies.

Inform the downstream users before you modify a schema or a refresh schedule for critical systems. Perform an impact assessment and provide a testing environment so consumers can verify that the changes do not cause errors. Maintain a version history to allow for a rollback if a failure occurs. Apply encryption and contractual protections to data that crosses borders or is shared with third parties. Review these vendor agreements annually.

11. Expand governance to include models, prompts, and the resulting outputs

Standard data governance does not account for the specific requirements of AI. Models that generate content, make decisions, or learn from user interactions require specific controls. These controls must manage training data, the prompts and knowledge bases that influence responses, and the checks performed on outputs before they reach customers. This set of practices is called AI governance. Most organisations only recognise the need for these measures after a failure occurs.

Obtain formal approval before deploying any AI system that affects customers, employees, or regulated processes. This requirement applies to systems involving automated decision-making, the use of personal data, or public-facing output. Record which datasets were used to train and evaluate each model by following standard data classification and lineage rules. Ensure that evaluation data is kept separate from training data to verify that the model performs accurately on new information.

• Record every source that provides data to a retrieval-augmented or knowledge-base system. State how often each source is refreshed.
• You must require approval before you add a new source that could introduce sensitive or unreliable content.
• Monitor for changes in the knowledge base that alter system outputs without intentional oversight.
• Identify shadow AI tools that teams have adopted without official approval. You should find these tools before they cause security or operational incidents.

AI governance that does not address the quality of training data creates models that replicate existing governance failures more quickly.

12. Measure what matters, and act on it

A governance programme that does not have measurable results will eventually lose funding, and this is appropriate. Track metrics that leaders consider important: the time saved from resolving data disputes, the number of AI projects successfully deployed to production, and any fines avoided. Also track operational metrics such as the time it takes to approve access requests, the speed of quality issue resolution, and the percentage of datasets with complete metadata. Report both costs and benefits each quarter to demonstrate the return on investment.

Perform a lightweight maturity assessment once a year. Evaluate a few specific areas, such as quality, access, and lifecycle, using objective evidence. Identify the two or three largest gaps. Review your policies twice a year based on current metrics and make small adjustments. Test any significant changes with a single team before implementing them across the entire organisation.

Next steps

You do not need to implement all twelve practices by January. You should begin with the readiness assessment and address the two or three specific gaps that are currently causing financial losses. These initial results will provide the justification for the remaining steps. In our experience, most organisations achieve better outcomes by fully implementing three practices rather than partially implementing twelve.

If you want a straight answer on where your own gaps are before you spend anything on tooling, that's exactly the conversation to have. Talk to us and start with a clear picture of your data estate.

If your internal reporting no longer meets your needs, you can use our data consulting services for assistance.

Frequently asked questions