ISO 42001 data governance: provenance, quality and privacy
Implementing ISO 42001 data controls — provenance, quality, preparation and labelling — and reconciling them with Australian Privacy Act obligations.
The data controls are where implementations stall
ISO/IEC 42001 requires a documented organisational approach to data for AI systems, and specific controls covering data for development and enhancement, acquisition, quality, provenance and preparation. These are the controls where implementations most often stall, because they require knowledge of data the organisation already holds and has never had to describe formally.
The controls are not satisfied by a data policy. They are satisfied by per-system records that state which data the system uses, where it came from, whether the organisation had the right to use it that way, what condition it is in, and what was done to it before use.
Start with the systems already in production. Retrofitting provenance for a live assistant is uncomfortable, but it surfaces the gaps that would otherwise appear in an audit or a customer questionnaire.
Provenance: where the data came from and on what terms
Provenance means an auditable record of origin. For each dataset used to train, tune, ground or evaluate a system, record the source, the date acquired, the acquisition mechanism, the licence or contractual terms, whether it contains personal information, and any restriction on use.
Third-party and open datasets need the same treatment as internal ones. A dataset with an unclear or non-commercial licence embedded in a customer-facing product is a commercial risk long before it is a compliance one.
Provenance also covers derived data. Synthetic data, embeddings and model outputs used as inputs to other systems inherit constraints from their source, and the record should say so.
Retrieval and grounding data is in scope
Most Australian organisations deploy AI by pointing a general model at their own content — a document library, a ticket history, a CRM, a knowledge base. They then conclude that the data controls do not apply because no model is being trained. That reading is wrong and it is the single most common scoping error.
Grounding data determines what the system can say and to whom. Its quality determines answer accuracy; its permissions determine whether the assistant becomes an efficient route to information a user was never entitled to see.
Treat the retrieval corpus as a governed dataset: documented sources, an owner, a refresh cadence, classification inherited from the source, and permission trimming enforced at query time rather than assumed.
Quality expectations you can actually test
Define quality per system rather than in the abstract. The dimensions that matter for AI use are accuracy, currency, completeness, consistency of format, and representativeness of the population the system serves.
Set thresholds and a measurement method. For a policy assistant that might be: no source document older than its review date, coverage of every published policy, and a monthly sample check that answers cite a current document. For a forecasting model it will be different, but it must still be measurable.
Record what happens when quality falls below threshold. Usually the answer is to narrow the system's scope or to disable it for the affected domain — decided in advance, not during an incident.
Preparation, labelling and the record of what you did
The preparation control asks for documented data preparation: cleaning, transformation, de-identification, augmentation, labelling and splitting. The record matters because preparation choices encode assumptions that later explain model behaviour.
Labelling deserves particular attention where labels come from human judgement. Record who labelled, against what instructions, with what inter-rater agreement, and how disputes were resolved. Unexamined labelling is a common root cause of biased behaviour that no amount of model tuning corrects.
For de-identification, record the technique and its limits. De-identified data recombined with a retrieval corpus can be re-identifying, and the record should show the organisation considered that.
Want this assessed against your environment?
Send us the specifics and a senior advisor will respond within one business day.
Reconciling with the Privacy Act and OAIC expectations
Where personal information is involved, the ISO 42001 data records and the privacy position must agree. Record the lawful basis and the primary purpose for which the information was collected, and assess whether AI use is a secondary purpose the individual would reasonably expect.
Notice and transparency obligations attach to the use, not to the technology. If personal information is being processed by an AI system, privacy notices should say so in terms a person can understand, and the organisation should be able to explain how an automated or semi-automated decision was reached.
Cross-border disclosure is the practical trap. Sending personal information to a model hosted offshore is a disclosure, and the organisation must be able to point to the mechanism relied upon and the data residency terms in the supplier contract.
Access, retention and the log problem
AI systems create new data stores: prompt and response logs, embeddings, caches, evaluation sets and fine-tuning corpora. Each inherits the sensitivity of its source and each needs an owner, a classification, an access rule and a retention period.
Embeddings are not anonymisation. Treat a vector store built over sensitive documents as sensitive, with the same access controls as the source repository.
Set retention deliberately. Indefinite prompt logs are convenient for debugging and a liability in discovery, in a breach, and under the minimisation expectations of the Privacy Act.
A ninety-day data governance sequence
Weeks one to three: inventory the data each in-scope AI system touches, including retrieval corpora and derived stores, and identify the owner of each source.
Weeks four to eight: complete provenance records for every dataset in production use, fix the permission model on retrieval corpora, and set quality thresholds with a measurement method.
Weeks nine to twelve: document preparation and labelling for the systems that have it, reconcile the privacy position for every system touching personal information, set retention on the new AI data stores, and take the residual gaps to the executive with owners and dates.
Sources and further reading
- ISO/IEC 42001 AI management systems
- OAIC guidance on privacy and the Privacy Act
- ISO/IEC 27001 information security management systems
- NIST AI Risk Management Framework
This article provides general information and decision support. It is not legal advice, audit assurance, certification advice or a guarantee of outcome.
Related reading
Securing enterprise AI adoption: a practical AI security control set
The AI security controls that matter first — identity, data boundaries, model access, logging, human oversight and supplier assurance.
Read articleAI risk assessment: how to assess an AI system before it ships
A repeatable AI risk assessment covering purpose, data, model behaviour, integration, human oversight, failure modes and evidence.
Read articleISO 42001 vs ISO 27001: how the two management systems interlock
What each standard covers, where they overlap, and how to run one integrated management system instead of two parallel programmes.
Read article