Auditing Data Governance and Training Data Provenance

Data governance is foundational to AI conformity. Poor data means poor outcomes, biased outcomes or outcomes that fail silently. Auditing data governance means verifying that the organisation knows what data it uses, where it came from, whether it is suitable and what risks it introduces. Data governance failures cascade through to model failures.

Start by requesting a data inventory. The data inventory is a living register of all datasets used in AI systems: training data, validation data, test data and production data. For each dataset, the inventory should record the source (external provider, internal collection, third-party aggregator), the data subjects (customers, employees, public figures), the size (number of records or volume), the date collected, and the date last updated. If your organisation cannot produce a data inventory, that is a major finding. Clause 8 requires organisations to define operational controls for data, and you cannot control what you do not know you have. An inventory is the foundation of data governance.

Verify that data sources are documented and approved. If a model was trained on customer transaction history, the data source is the customer transaction database. Verify that someone explicitly approved using that source for AI training. If data came from a third party (a commercial data provider, a government agency), verify that there is a data sharing agreement and that the agreement permits AI use. A data sharing agreement that says “use data for analytics” does not permit AI model training. That is a conformity gap. Third-party data use must be contractually authorised.

Audit data validation and quality assessment. Has the data been examined for completeness, accuracy and potential bias? Ask questions like: “Are there missing values? How many records have null values in critical fields? How was that handled? Were any records excluded? If so, on what basis?” Examine the data quality assessment. Does it exist? Is it documented? Has bias been assessed? If a dataset used to train an employment or credit model was derived from historical decisions that were themselves biased, the data science team needs to know and need to document the risk and the mitigation. Quality assessment must precede model training.

Examine data retention and deletion. Organisations should not retain data indefinitely. Clause 8 requires documented information for operational controls, and retention policy should be documented. Questions like these work: “How long is training data retained? What is the retention policy? Is there a process to delete data no longer needed?” If data is retained indefinitely, retention controls are missing. Indefinite retention creates data security risks.

Check whether data access is restricted. Not everyone should have access to raw training data, especially if it contains sensitive information about individuals. Verify that access controls exist and are enforced. Questions like: “Who has access to the training data? Is access logged? How are access rights reviewed and revoked when people leave the team?” Access controls prevent unauthorised use or exposure of training data.

Audit data use tracking. If data is used across multiple AI systems, is that tracked? If a dataset is used in a model, then the data governance team changes it, does the model owner get notified? Questions like: “If you update a training dataset, how do model owners know? Is there a process to notify users of data changes? Do you re-evaluate models when data changes?” Data changes can invalidate models, so notification is critical.

Examine whether sensitive data is handled appropriately. Sensitive data includes personal data (names, contact information, biometric data), health information, financial data, employment records. Sensitive data requires additional controls. Verify that sensitive data is encrypted, that access is logged, that retention periods are restricted. If sensitive data is used but not protected, that is a control failure. Sensitive data is a regulatory concern under GDPR and other regulations.

Finally, check whether the organisation can trace back from a deployed model to the datasets it was trained on. This traceability is critical for incident investigation. If a model fails and you need to understand why, you need to be able to trace the model to its training data. Traceability allows root-cause analysis.

A data governance audit often uncovers that data exists in silos. One team has raw data, another has cleaned data, another has aggregated data. Traceability between these versions can be weak. Good data governance maps these relationships explicitly. A dataset version register (showing what data exists, where, in what version, and when it was created) is a powerful control that many organisations lack.

Documentation of data decisions is often overlooked. When data is excluded from a dataset, why? When a dataset is updated, what changed and why? When data quality issues are discovered, how are they tracked and resolved? These decisions are governance in action, and they should be documented and tracked so that auditors can verify that data governance is being applied consistently, not just on paper.