A.4.3 Data resources: requirements and evidence

What ISO 42001 A.4.3 data resources requires

A.4.3 asks the organization to document the data resources its AI systems use. If an audit is coming and the team cannot say which datasets feed each AI system, where they came from, or who may use them, this control is the gap. It sits inside the Annex A area for resources, alongside the controls for the resource record itself (A.4.2), tooling (A.4.4), system and computing resources (A.4.5) and human resources (A.4.6). Each of those controls covers a different kind of dependency, so the data record should be built to fit into the wider resource record rather than stand alone. The risk this addresses is easy to describe and hard to manage. An AI system may be trained, tuned, evaluated or fed at run time with data whose origin is unknown, whose license does not permit the use, or which contains personal data that nobody flagged. When a model behaves badly or a regulator asks where an output came from, the organization cannot trace the input. The difficulty is practical: datasets sit in object storage buckets, notebooks, shared drives, retrieval indexes and vendor platforms, and most of them have no named owner and no entry in any register.

Start with an inventory exercise. For each AI system in scope, list every dataset it touches across development, testing and operation, then record the owner, source, licensing position and whether personal data is present. Where a dataset comes from a supplier, record the contract or terms that govern it. Ask the teams that built each system which resources they used, and check those answers against storage logs and pipeline configurations, because the people who remember a dataset are not always the people who loaded it. Keep the record separate from the detailed controls for data management, acquisition, quality, provenance and preparation in A.7. A.4.3 asks you to know what data exists and how it is used as a resource. A.7 asks how that data is governed and prepared. Auditors will look for the two to agree, so a dataset that appears in the resource record should be traceable to the A.7 evidence for its acquisition and quality. The Annex B guidance and the ISO/IEC 42001:2023 standard page are the places to confirm the exact expectations, and the auditor you engage should confirm how they will test the record.

Which data resources belong in the record

A.4.3 asks for documented information about the data resources an AI system uses, so the first decision is which datasets count. The six categories below cover the common sources, and each card names the scoping choice that changes the work and who should make it. Final scope must follow the statement of applicability under clause 6.1.3, which records the controls you include and justify the ones you exclude.

Training, validation and test datasets

These are the datasets used to build or calibrate the model, and they are the core of the record. Each entry should identify the dataset, its version, the source, the volume and the time period it covers, so the organization can show which data produced which model version. The scoping question is whether datasets used only for an earlier model version stay in the record after retirement. The AI system owner decides this, with records retained for as long as the model can be traced back to them.

Fine-tuning and evaluation sets

Fine-tuning data and evaluation sets often change faster than the base training data, and they are easy to lose track of. Record each set separately, with the model it adapted, the date it was created and who approved its use. Evaluation sets used to accept a release need the same treatment as training data, because they support the decision to deploy. The product or model owner should decide whether internally written prompts and test cases count as data resources.

Retrieval and knowledge sources

In retrieval-augmented systems, the documents, indexes and knowledge bases the system queries shape its answers as much as training data does. Record each source, its owner, the index build date and the process that adds or removes content. The scoping decision is whether internal wikis, ticket archives and public web content are indexed at all, and the data protection owner should confirm which of these hold personal data before they are added.

Licensed and third-party data

Datasets bought, licensed or scraped from third parties carry terms that limit how the AI system may be trained, shared or commercialized. Record the licence or contract reference, the permitted uses, the expiry date and any attribution duties next to each dataset. Procurement and legal should own this entry, and vendor-hosted corpora should be included in the record if the organization relies on them for training, retrieval or evaluation, even when the organization does not store them directly.

Synthetic and generated data

Synthetic data is generated by a model, a script or a simulator, and it is often used to fill gaps in sensitive or rare cases. Record the generator, its version, the seed or prompts used, and the real datasets it was derived from. The scoping decision is whether synthetic data counts as a separate resource or is folded into the dataset it augments. The team that generates the data should propose the scope, and the AI governance owner should approve it.

Operational data at run time

Operational data is the input and feedback the system receives in production, such as user prompts, sensor readings, transaction streams or feedback labels that feed later retraining. Record the source, the fields used, the retention period and whether the data is used to update the model. The decision is whether operational data that is only logged, and never used for learning, falls inside A.4.3 or belongs to the logging controls in A.6. The operations owner should decide this and document it in the statement of applicability.

How to build the data resource record step by step

This sequence turns the A.4.3 requirement into a maintained record that names each dataset an AI system uses, who answers for it, and which A.7 data controls govern it. Each step ends with a handover the next step depends on.

Identify the AI systems in scope
Start from the AI system inventory or the scope statement that the organization defined under its AI management system. List every AI system that falls inside the boundary, including systems built in-house, systems bought from suppliers and systems that only consume an external model. The owner of the AI management system or a delegated product lead should confirm the list. The output is a dated register of in-scope AI systems, with one row per system and the name of the accountable person. Do not move to the next step until the register matches the scope statement, because every dataset record traces back to a system on this list.
List each dataset each system uses
For each in-scope system, ask the engineering team to name every dataset involved in training, validation, testing, fine-tuning, retrieval or evaluation. Include datasets that come from outside the organization, such as licensed corpora or data bought from brokers, and datasets that feed live inference, such as reference tables and retrieval indexes. Use source repositories, pipeline configurations and data catalogs to confirm the list rather than relying on memory. The output is a list of dataset identifiers linked to system identifiers. A dataset used by two systems appears once with two links.
Record the attributes for each dataset
Create one entry per dataset with the attributes an assessor will need to trace it: a unique identifier, a description of content and purpose, the source or supplier, the format and storage location, the volume and time range covered, the legal basis or license that permits use, and whether the data contains personal data or other sensitive categories. Record the version or snapshot used for each system, since a model trained on one snapshot cannot be explained by a later one. The output is a completed dataset entry for each identifier. Where an attribute is unknown, mark it as an open item with a named owner rather than leaving it blank.
Assign a named owner to each dataset
Assign one accountable owner to every dataset entry, normally a person in a business or data function rather than a team alias. The owner confirms the attributes recorded in the previous step, approves changes to the dataset and answers questions from assessors and customers about it. Where a supplier provides the data, the owner is the internal person responsible for that relationship, and the supplier's own documentation is attached. The output is an owner field completed for every dataset, plus a short list of who may approve a change. A dataset without an owner is not complete.
Link each dataset to its A.7 data controls
Map each dataset entry to the A.7 controls that govern it. A.7 covers data management processes, data acquisition, data quality, data provenance and data preparation, so each dataset should show where its acquisition decision, quality checks, provenance evidence and preparation steps are recorded. A.4.3 tells the reader what data exists and who answers for it; A.7 holds the detailed control evidence. Keep the links as references, not copies, so there is one source of truth for each detail. The output is a cross-reference column in the dataset register that points to the A.7 evidence location for each dataset.
Set a review trigger tied to model changes
Define the events that require the dataset entry to be reviewed. Events usually include a new training, fine-tuning or evaluation run, a change in data source or license, a change in the model version that consumes the dataset, a new category of personal or sensitive data, and a supplier change. Write the triggers into the change process for the AI system so that a model release cannot ship without a check on its linked datasets. The output is a written trigger list attached to the record, plus a note on who performs the check and where the result is stored.
Store the record under document control
Place the register, the dataset entries and the trigger list in the controlled document system used for the AI management system, with a version number, an approval date and a document owner. Each change should record what changed, who approved it and the date. Give the record a stable location that auditors and customers can be granted access to. An internal audit or management review should sample a few datasets and confirm that the entries match the systems in production. The output is an approved, versioned record that an independent assessor can sample during an audit.

How an assessor tests the data resource record

This table compares each test step an assessor is likely to run against the A.4.3 data resource record, the evidence it requests and the gaps it commonly finds. Read it as a checklist to run internally before the assessor arrives, since most findings come from a record that was never tied back to the live system inventory and pipelines.

Test step	Evidence requested	Common findings
Sample AI systems and trace each to its listed datasets	The data resource record, the AI system inventory entries for the sampled systems, and the training, validation and inference dataset names each system uses	Datasets used in production are absent from the record; a dataset is listed but cannot be traced to any system
Compare the record with the system inventory and data pipelines	Pipeline configurations, data catalog exports, asset inventory exports and the inventory of AI systems, side by side	Pipelines ingest sources that the record does not mention; inventory shows a system with no matching data entry
Check that each entry has an owner and a last-reviewed date	Named owner per dataset, review dates, and the review log or change history for the record	Owner has left the organization with no reassignment; entries have no review date or show a date older than the last retraining
Check that changed datasets triggered a record update	Change tickets or pipeline run logs for dataset changes, retraining records, and the matching record revisions with dates	Stale entries after retraining: the model was rebuilt on new data but the record still describes the old dataset version
Confirm each entry records its source and provenance basis	Source system or supplier name, acquisition route, licence or permitted-use note, and links to the A.7 data records where they exist	Records that name a dataset but omit its source, so the assessor cannot tell where it came from or whether use is permitted
Confirm the record matches the A.7 data controls	Cross-references from each entry to the A.7 data management, quality, provenance and preparation records	Resource record and A.7 files describe different dataset versions or use different dataset names
Check the record is kept within the documented information process	Document control metadata, version history and approval of the record under the organization's documented information process	Record exists only as a spreadsheet snapshot with no version history or approver

Where A.4.3 ends and the A.7 data controls begin

A.4.3 asks the organization to document the data resources its AI system uses, and the practical boundary is simple: A.4.3 is the inventory entry, and the A.7 controls are the evidence behind it. The resource record names each dataset, says where it came from, who owns it, what it is used for and which AI systems depend on it. A.7.2 to A.7.6 cover the processes behind that entry: data management, acquisition, quality, provenance and preparation. An assessor who reads a dataset line in the resource record should be able to follow it to the acquisition decision, the provenance check and the quality results that support it. If that trail does not exist, the entry is a claim without support, whatever its format.

Write the entry so that it points to evidence rather than restating it. For each dataset, record an identifier, a plain description, the owning role, the storage location, the AI systems and life cycle stages that use it, and a reference to the A.7 records that cover its acquisition and provenance. Where your data inventory already lives in a configuration management database or asset register, the resource record can link to it instead of copying it. The NIST AI Resource Center publishes a crosswalk between the NIST AI RMF and ISO/IEC FDIS 42001, contributed by Microsoft, that maps AI RMF GOVERN 1.6 (mechanisms to inventory AI systems) and MAP 2.1 (tasks and methods the AI system supports are defined) to B.4.3, the implementation guidance for this control. NIST states that posting the crosswalk is not an endorsement, so treat it as one reviewed mapping to check against your own reading of the standard, not as an authoritative equivalence.

Do not duplicate quality analysis in the resource record. Completeness rates, label error findings, bias measurements and drift results belong in the A.7 quality and preparation records, where they can be versioned and tied to a specific data set. Copying them into the resource record creates two versions of the same fact that drift apart the first time someone retrains a model. Confirm with your assessor, before fieldwork, where they expect each kind of evidence to sit, and keep a short cross-reference table in your statement of applicability workpapers so the boundary is documented once and applied consistently.

Evidence that passes A.4.3 and how to keep it current

Auditors testing A.4.3 look for a record that matches what is actually running, not a document written once for the audit. The artifacts below work together: each one answers a different question about the data an AI system depends on. None of them is sufficient alone, and each needs a named owner and a trigger that updates it between assessments.

Dataset register entries

A dataset register holds one entry per dataset the AI system uses, covering the source, purpose, scope, format, storage location, sensitivity classification and the version in use. Check that every entry names the dataset version, not just its label, so a retrained model can be traced to the exact data it saw. Refresh an entry whenever its source, schema or retention changes, and tie that update to the data pipeline's change ticket rather than to a calendar reminder alone.

System-to-dataset mapping

This mapping shows which datasets feed which AI system, including training, validation, fine-tuning, retrieval and evaluation sets. It answers the question an assessor asks first: if a dataset is found to be problematic, which systems are affected. Build it from the pipeline configuration where possible, and reconcile it against the system inventory quarterly so a new retrieval source added in a sprint does not sit outside the record.

Owner and approval records

Each dataset needs a named data owner who approved its use for a specific AI system and purpose. Keep the approval record with a date, the approver's role and the scope granted, so that reuse of a dataset for a new purpose triggers a fresh approval. Review ownership when people change roles, because an approval given by someone who has left is hard to defend during an assessment.

Change history after retraining

Change history records what changed in each dataset and when the AI system was retrained or re-evaluated against it. Pipeline logs, dataset version tags and model registry entries can supply much of this, provided they link the two. Check that every retraining event leaves a record that points back to the dataset versions consumed, and that gaps caused by manual copies or ad hoc notebooks are closed by policy.

Links to A.7 evidence

A.4.3 records the data resources, while the A.7 controls cover how the data was managed, acquired, checked for quality, traced for provenance and prepared. Each register entry should point to the A.7 evidence for that dataset, such as acquisition agreements, quality checks and provenance records, so an assessor can move between the two without reconstructing the chain. Verify these links during each internal audit, since a moved file or renamed repository breaks them silently.

Review log with dated decisions

A review log records each scheduled review of the data resource record, who attended, what was found and what actions followed. Set the review cadence in the management system and record each run, including reviews that found no changes, since a log with no entries for a long period suggests the control is not operating. Tie reviews to the internal audit and management review cycles described in clause 9 so the log feeds those meetings.

What meeting A.4.3 costs in money and effort

This table compares the cost components of documenting AI data resources under A.4.3, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Read it as a checklist for a written quote, since no price or duration is published for this control and every figure depends on the organization's own datasets and pipelines.

Cost component	One-time or recurring	What drives it and how to keep it down
Tooling or licenses	Recurring if commercial	Commercial catalogs and governance suites carry license fees. Self-hosted open-source tools can remove that spend for supporting records, but the register still needs an owner and a review process.
Engineering time to build the register	One-time, then recurring upkeep	Effort rises with the number of datasets, source systems and pipelines. Start from a fixed template with required fields per dataset and automate capture where pipelines already log data.
Data owner review	Recurring	Each dataset needs a named owner who confirms its purpose, source and restrictions. Limit review to changed or high-impact datasets and schedule it with existing data governance cycles.
Evidence upkeep after model or data changes	Recurring	Retraining, new data sources or new use cases make the record stale. Tie record updates to change management and pipeline events so the record changes with the system.
External review of the record	Recurring, tied to audit cycles	A readiness reviewer or consultant may check completeness before an audit. Ask for the number of review rounds, the systems in scope and whether the reviewer will also test sampled records.
Auditor sampling time	Recurring, per audit	Auditors select datasets and trace them to the record. Time grows with the number of datasets and missing or inconsistent entries. Keep one current record and a clear link to each dataset's source.
Written quote items to request	Before work starts	Ask for the datasets and systems in scope, which tools are licensed or open source, named roles for each review step, expected recurring tasks after go-live and any out-of-scope items such as A.7 data controls.

Open-source tools that support data resource evidence

A.4.3 asks for documented information about the data resources an AI system uses, and the register itself has to be maintained by your organization. The four tools below can produce supporting records: where datasets sit, what runs against them, and what data flows through a model. Each covers part of the picture, and none of them replaces a dataset register.

GLPI asset inventory

GLPI's Assets module records computers, software, network equipment, printers and racks, entered by hand or pushed by the GLPI Agent through native inventory built into GLPI since version 10. For A.4.3, it can show which systems and storage hosts hold the datasets your register names, which gives the register a verifiable location. It does not know what data a server contains, so the link between a host and a dataset must still be written down by your team. License: GPL-3.0-or-later. Confirm that your asset fields can hold data-location references and that the agent covers your storage hosts.

Wazuh Syscollector inventory

Wazuh's Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services and users from each endpoint, then stores them in the Wazuh indexer for dashboard views and reports. Auditors can use these records to confirm that the database servers and data pipelines named in your register are running where you say they are. It reports system state only, so it cannot identify which datasets a service reads. License: GPL-2.0-only. Confirm coverage for every host class that stores or processes training or operational data.

garak data leakage probes

garak probes language models for weaknesses including data leakage, and writes a JSONL report of every attempt and evaluation along with a hit log of attempts that found a vulnerability. Where a model was trained or fine-tuned on sensitive records, these reports give you dated evidence of what the model did and did not disclose. garak does not inventory datasets or prove what the training corpus contained. License: Apache-2.0. Confirm that your probe selection matches the data categories listed in your register.

Langfuse retrieval traces

Langfuse records traces for each request, including retrieval steps, tool executions, inputs, outputs, token usage and metadata. When a model draws on retrieved documents, these traces show which data sources were queried and what passed into the prompt, which supports the data-flow part of your A.4.3 record. Traces can contain personal or confidential data, so retention and access settings are part of the evidence. License: MIT. Confirm your masking configuration before enabling traces on production data.

Who owns the data resource record, and who prepares it

Your organization owns A.4.3. Someone accountable for the control must be named, usually within AI governance or the team responsible for the AI management system, and that person decides what the data resource record must contain and signs off on its content. Data owners, the people accountable for each dataset's source, permitted use and retention, supply the business facts that no tool can infer. Engineering owners, who train, fine-tune, evaluate or feed data into AI systems, keep entries current when pipelines change.

Control owner: holds the accountability for A.4.3, approves the register format and resolves gaps.
Data owners: confirm purpose, origin, legal basis and restrictions for each dataset they are responsible for.
Engineering owners: update entries when datasets are added, replaced, refreshed or retired in a pipeline.
Reviewers: check that the record matches the statement of applicability and the A.7 data controls.
Records custodian: keeps versions and dates so an assessor can see how the record changed over time.

Confirm that each named owner knows the record is theirs to keep current, not a document a consultant produces once.

Questions buyers ask about A.4.3 cost, effort and outside help

How much effort does a data resource register take for a typical AI portfolio?

The effort scales with how many AI systems the organization runs, how many datasets each one touches and how often those datasets change. A portfolio with a handful of systems built on stable, well-known data sources is far lighter than one where teams fine-tune models on fresh extracts every month. Before estimating anything, ask for a count of AI systems, a list of datasets already held in catalogs or data platforms, and a view of how often data sources are added or retired. Those three inputs drive most of the cost in both internal and outsourced work.

Can our team build the A.4.3 data resource record without an outside partner?

Yes, an internal team can build the record if it has someone who knows the data estate and someone who understands what the control asks the organization to document. The harder part is usually not the template but the gathering: finding every dataset, confirming its origin and getting it classified consistently across teams. An outside partner can help by preparing the inventory tooling, running the collection and drafting the record, but the organization keeps ownership of the content and its accuracy. Decide early which of these tasks you will staff internally and which you will scope out in writing.

What do data owners need to contribute to the record?

Data owners provide the facts that no scanning tool can confirm: what a dataset is for, where it came from, who is accountable for it and which AI systems depend on it. They also need to flag restrictions such as licensing terms, personal data content or retention limits so the record reflects real constraints. Plan for a short, structured review with each owner rather than an open request for documentation, because owners who receive a clear list of fields answer faster and more accurately. Name the owner for each dataset in the record itself so the question of who signs off never stalls an assessment.

How long does it take to set up the data resource record?

Timeline depends on the size of the estate, how much dataset information already exists in a catalog, and how quickly owners respond to review requests. Organizations with a current data catalog and clear owners move faster than those discovering datasets in spreadsheets and shared drives. Ask any provider for a timeline built from a written list of systems, datasets and owners, and check which steps depend on your staff's availability. A quote that does not show those dependencies is hard to plan against.

What does a fixed-scope engagement for this control include?

A fixed-scope engagement sets out, in writing before work starts, which AI systems are covered, which data resource fields the record must hold, which tools will collect facts and what the final deliverables are. For A.4.3 that typically means agreeing the record structure, configuring inventory collection where it is useful, drafting entries with owners and handing over the completed record with its maintenance steps. Anything not listed, such as remediating data quality or rewriting A.7 procedures, should be a separate item with its own scope. DeployOpen plans and delivers engagements on this basis, and a quote follows from the written scope.

Can the auditor help us build the data resource record?

No. An independent auditor or certification body tests whether the record exists, matches the systems in use and is kept current, and it cannot prepare that record for you without compromising its independence. The organization owns the control and its content, and an implementation partner may prepare systems and evidence under a written scope. Ask any partner to confirm in writing that it will not issue assessment conclusions, and ask your certification body what preparation work it considers acceptable.

How DeployOpen prepares the A.4.3 data resource record

DeployOpen plans, builds and documents the data resource record that A.4.3 Data resources asks for, inside your own infrastructure. The organization keeps ownership of its controls, while DeployOpen prepares the systems, records and evidence that an independent auditor will review.

How we scope

Agree in writing which AI systems and datasets the A.4.3 record will cover before work starts.
Confirm which data sources, storage locations and owners the written scope includes and excludes.
Engagements are fixed-scope, and ongoing support for the record can be added as a retainer.

How we build

Set up a data resource register with fields for each dataset's source, owner, location and purpose.
Connect the register to asset inventory tooling such as GLPI so storage locations stay traceable.
Link each dataset entry to the A.7 data controls so provenance and quality records are cross-referenced.

How we hand over

Deliver the data resource record with a short guide explaining how each field is completed and reviewed.
Document who maintains each entry and how changes to datasets trigger an update to the record.
Provide a list of open items the organization must confirm with data owners before an assessment.

How we support

Review the data resource record on a schedule agreed in the written scope or retainer.
Update entries when new datasets, data sources or AI systems are added to the environment.
Prepare the record for internal audit and for the independent auditor's review, which DeployOpen does not perform.