What A.7.3 acquisition of data asks for in ISO 42001
A.7.3 asks the organization to determine and document how the data used in its AI systems is acquired and selected. The control sits under A.7 Data for AI systems, alongside A.7.2 (the umbrella data management process), A.7.4 (data quality), A.7.5 (provenance) and A.7.6 (data preparation). Its purpose is to stop an AI system from being built on data nobody can account for. Three risks drive it: unknown provenance, where no one can say where a dataset came from or who produced it; unclear rights and consent, where the organization cannot show it was entitled to use the data for this purpose; and undocumented selection bias, where the choices about which records were included or excluded shape model behavior but are never written down. An assessor reading this control wants to see that each acquisition decision was made deliberately and can be reconstructed later.
The control is hard in practice for reasons that are organizational as much as technical. Data for an AI system is often scattered across product, analytics and vendor teams, so no single owner knows every source. Third-party datasets, scraped web content and open collections arrive with licenses and terms that change over time, and the terms in force when the data was collected may differ from today's. Teams also reuse a dataset for a new model without updating any record, so the original selection criteria no longer describe what the model was trained on. Start by listing every dataset used in development, enhancement or operation of each AI system, then confirm for each one the source, the owner, the legal basis or license, the consent or contractual terms, and the selection criteria applied. Ask whether the reasons for excluding records were recorded, not only the records that were kept.
The record an auditor checks is the practical output of this control. For each dataset, expect to show the source and acquisition method, the date range and version acquired, the rights, consent or license position with the document that supports it, the selection criteria and who approved them, and the link to the AI system that uses it. Confirm with your own legal and privacy functions which rights questions apply in your jurisdictions, because this page does not give legal advice. Where a dataset comes through a supplier, the contract and the supplier's own statements about sourcing belong in the record too. Implementation partners can help build the register and collection process, but the organization owns the decisions, and an independent auditor or certification body is the only party that assesses whether the control is met.
Which datasets and teams A.7.3 applies to
A.7.3 reaches further than the data science team. The organization decides which datasets fall inside its AI management system through the statement of applicability, and each dataset type brings its own sources, rights questions and records. The cards below cover the dataset types that most often need a documented acquisition record and the teams that hold that information.
Training, validation and test data
These are the datasets that shape a model's behavior and measure it. A.7.3 expects the acquisition and selection of each split to be documented, including why records were included, which were held out and how the split was made. Check that validation and test sets are recorded separately from training data, because auditors often find that held-out data was later pulled into training without a record of the change.
Fine-tuning and grounding data
Fine-tuning sets and retrieval corpora are acquired after the base model is chosen, so they are easy to overlook. A.7.3 applies to them when they shape system output, which includes documents indexed for retrieval and examples used to adapt a model. Record the source, the owner and the selection criteria for each corpus, and confirm that updates to the corpus are logged the same way as the original load.
Customer data used for AI features
When a product uses customer records to train, tune or ground an AI feature, the acquisition record must show the contractual basis for that use, the categories of data taken and the selection filter applied. Procurement and product teams usually hold these terms, not data science. Confirm with legal whether the customer agreement and any privacy notices cover AI use before the dataset is loaded.
Purchased and licensed datasets
Licensed datasets bring usage limits that can change how a model may be deployed or sold. Keep the license, the licensor, the permitted purposes and the renewal date with the acquisition record. Ask the licensor whether derived model artifacts are covered, and flag any term that conflicts with the planned use. Procurement should own the contract file that proves the right to use each dataset.
Scraped and public web data
Public availability does not establish the right to use data for AI. Record the collection method, the sites or sources, the date of collection, any robots or terms restrictions observed and the filters that removed personal or sensitive content. Teams should confirm these points before collection, since reconstructing them after the fact is hard and auditors look for the record first.
Synthetic data
Synthetic data is generated, so its acquisition record must cover the generator, the seed or source data it was derived from, the generation parameters and the reviewer who approved it for use. A.7.3 expects you to show what real data informed the synthetic set, because rights and privacy obligations can follow the source data into the synthetic output. Keep the generator version and configuration with each generated set.
How an auditor tests acquisition of data records
This table sets out how an assessor samples AI training and operating datasets for A.7.3, what evidence they request for each step, and the findings that most often appear. Read it as a checklist of what your acquisition records must survive, not as a list of required formats.
| Test step | Evidence requested | Common finding |
|---|---|---|
| Sample datasets from the inventory | Current data inventory listing every dataset used by each in-scope AI system, with owner and system mapping | Inventory omits datasets used for fine-tuning, evaluation or retrieval, so the sample never reaches them |
| Trace each sample to its source | Source name, supplier or internal system, acquisition date and the contract, license or internal approval that allowed collection | Dataset has no recorded source, or the source is described only as internet or public data |
| Confirm the rights and consent basis | Licence terms, data processing agreement, consent records or legal assessment tied to the dataset and its intended AI use | Rights or consent basis is asserted in a policy statement but no document ties it to the specific dataset |
| Check selection criteria were documented | Written criteria for including and excluding data, with the version date and approver | Criteria exist but do not match what was selected, or they cannot show which records they filtered out |
| Check criteria were applied | Selection logs, filter configurations or sampling notes showing the criteria run against the acquired data | Criteria written after the fact to explain an existing dataset, with no record that the selection was performed against them |
| Confirm the record is current | Change history showing updates when sources, scope or the AI system's purpose changed | Acquisition record unchanged after a new source, a licence renewal or a change in use was added |
| Cross-check against related controls | Links from the acquisition record to data provenance, quality and privacy assessment outputs | Acquisition record exists in isolation, with no traceable link to the controls that rely on it |
Implementing acquisition of data records step by step
This sequence turns the A.7.3 requirement into a working record set: each dataset is inventoried, owned, traced to its source, cleared for rights and consent, selected against approved criteria, and tied to a review trigger so the record stays current as the data changes.
Inventory every dataset in use
Start by listing every dataset that trains, tunes, evaluates, grounds or otherwise feeds an AI system in your scope, including datasets pulled at runtime from retrieval stores and third-party feeds. Include datasets used only for testing, since auditors commonly ask about them. The output is a dataset register with a unique identifier, a short description and the AI system each dataset supports. Confirm completeness by comparing the register against the development pipelines, data stores and vendor contracts your teams actually use, not against what the architecture diagram says should exist. Asset inventory tooling can help with systems and software, but datasets usually need a dedicated register maintained by the data owners.
Assign a named owner to each dataset
Give every dataset in the register one accountable owner, a named person with the authority to approve its use and answer questions about it. Record the owner's role, the business function they represent and a backup contact. The output is the owner field in the register, reviewed by the AI governance lead so that no dataset is orphaned. Owners do not need to be the people who collect the data, but they must be able to explain its purpose and sign off on changes. A dataset without an owner should not be used for development until one is assigned.
Record the source and acquisition method
For each dataset, document where it came from and how it was obtained: internal system extract, customer-provided data, purchased dataset, public corpus, web collection, or data generated by another model. Record the supplier or origin, the collection date range, the transfer mechanism and any transformations applied before the data entered the AI pipeline. The output is a source record attached to each register entry. Where a third party supplied the data, keep the contract or licence reference next to the source record so the trail is complete when an auditor samples it.
Document rights and consent with the legal owner
Ask the legal, privacy or data protection owner to confirm, in writing, the basis on which the organization may use each dataset for AI purposes. This covers licence terms, contractual restrictions, personal data and any consent scope or lawful basis that applies. Record the basis, the conditions attached, the reviewer and the review date against each dataset. The output is a rights and consent entry that the privacy owner has signed off. Do not treat the engineering team's understanding of a licence as a legal determination. Where a dataset carries restrictions on training or on commercial use, flag it for a decision before any further processing.
Document selection criteria and their approval
Write down the criteria used to choose which data from each source enters the AI system, such as relevance to the intended purpose, representativeness, exclusion of categories the organization has ruled out, and minimum volume or recency needs. Record who approved the criteria, the approval date and the version. The output is a selection criteria document linked to each dataset, plus the sampling or filtering rules applied. Keep the criteria specific enough that a second engineer could reproduce the selection from the record, and note any manual exclusions along with the reason.
Set review triggers for dataset changes
Define the events that reopen an acquisition record: a change of source, a new licence or contract term, a change in consent scope, a material change in volume or content, a new purpose for the dataset, or a discovered issue with its origin. Assign who monitors each trigger and how the change is logged. The output is a review trigger list attached to the register and a dated change history for each dataset. Test the trigger by picking one dataset and confirming that a simulated change would produce a new approval, an updated rights entry and a new version of the selection criteria before the data reaches the model again.
Evidence for A.7.3 acquisition of data that passes audit
An assessor testing A.7.3 looks for a record that shows where each dataset came from, what rights attach to it, and why it was selected. The cards below cover the artifacts that make that record complete and the checks that keep it accurate after the first audit.
Dataset register with one entry per dataset
A single register lists every dataset used to develop, enhance or operate an AI system, with one entry per dataset. Each entry should name the dataset, its owner, the AI systems that use it, its acquisition date and its storage location. An assessor usually starts from this register and samples entries, so gaps here cascade into every other control. Check that the register matches what engineering actually uses, including datasets pulled in through retrieval pipelines or fine-tuning jobs.
Source and acquisition records
For each entry, keep the acquisition record that shows how the data was obtained: a contract, a license, a data-sharing agreement, a public dataset license reference, or a collection log for data the organization gathered itself. The record should identify the supplier or collection method, the date and the scope of use. Confirm with legal counsel that the terms permit AI training or evaluation, because a license written for analytics may not cover it.
Rights and consent records
Where a dataset contains personal data or content created by people, keep the consent or lawful basis record that supports its use for AI. This includes consent scope, withdrawal handling and any restrictions the source imposed. Note which entries require a privacy review and link the review outcome to the dataset entry. Treat these records as inputs for legal review rather than as a legal opinion of their own.
Documented selection criteria with approval
Write down the selection criteria that decide which data enters an AI system, such as relevance to the intended purpose, representativeness, exclusion rules and minimum volume. Each criterion needs a named approver and an approval date. An assessor will ask why a dataset was chosen and whether the criteria were applied before the data was used, so the approval should predate the first training or evaluation run.
Change log for acquisition decisions
A change log records each addition, removal, renewal or exclusion of a dataset, with the date, the person responsible and the reason. Keep it under version control or in a system that preserves history, so the record shows the state of the register at any past date. This is the evidence that the record was kept current rather than rewritten for the audit.
Design support from the NIST crosswalk
The NIST AI RMF to ISO/IEC FDIS 42001 crosswalk, contributed by Microsoft and not endorsed by NIST, maps AI RMF MAP 2.3 (data collection and selection considerations documented) and MEASURE 2.10 (privacy risk examined and documented) to B.7.3. Use it to decide which fields the acquisition record should hold. It supports the design of the record but does not replace legal review of the rights behind each dataset.
How open-source tools support acquisition evidence
GLPI (GPL-3.0-or-later) is an IT asset and service management platform. Its Assets module manages computers, software, network equipment, printers, phones and racks, entered manually or pushed automatically by the GLPI Agent through native inventory built into GLPI since version 10. For acquisition evidence, its value is locating where datasets and the storage systems that hold them sit, so an auditor can connect a dataset record to a managed asset. GLPI can show that a storage platform exists, who owns it and when it was last inventoried. It does not describe what data was acquired, from whom, under which terms or why it was selected.
- Storage asset entries: Record database servers, object storage hosts and file shares that hold acquired data as managed assets with owners.
- Software and version records: Keep the data platform software and its versions attached to the asset, so changes can be traced.
- Location and status fields: Show where each storage asset is hosted and whether it is active or retired.
- Agent-based inventory: Use the GLPI Agent to refresh hardware and software data instead of relying only on manual entry.
- Links to tickets: Connect asset changes to change or acquisition tickets where your process uses them.
Confirm with your own GLPI administrator which asset types and custom fields your instance uses before designing the dataset-to-asset mapping.
Wazuh (GPL-2.0-only) is an open-source security monitoring platform. Its Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups from each endpoint and stores the results in the Wazuh indexer for inventory views and reports in the dashboard. For acquisition evidence, this shows which systems that hold acquired data are present, what software they run and who can access them. It is a current-state inventory, not a history of decisions. It cannot tell an auditor whether a dataset was lawfully obtained.
- Host inventory for data systems: Confirm that servers holding acquired datasets are enrolled and reporting.
- Software and service listings: Show database engines, ETL tools and data services running on those hosts.
- User and group records: Evidence who holds local accounts on systems that store acquired data.
- Open port and network views: Show which network paths reach data stores, supporting the storage record.
- Scheduled inventory reports: Export inventory snapshots to show the state of data systems at a point in time.
Check that the Syscollector scope in your deployment covers every host named in your dataset register, because an unenrolled host will not appear in the inventory.
Langfuse (MIT) is an open-source observability platform for LLM applications. Each trace captures every operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. For acquisition evidence, traces show which data sources an application actually drew on at runtime, such as a retrieval index or an external feed. This matters when a retrieval source was not documented at design time. Traces show use, not approval. They do not show whether the organization had the right to use that source.
- Retrieval step records: Show which retrieval index or document collection answered each request.
- Input and output capture: Record the inputs and outputs of steps that touch acquired data, subject to your privacy settings.
- Metadata tagging: Attach dataset or source identifiers to traces so they can be matched to the dataset register.
- Timing and volume data: Show how often and when each source was used, supporting review of unexpected sources.
- Trace retention settings: Define how long traces are kept, aligned with your evidence retention policy.
Confirm your data minimization and redaction settings before enabling trace capture on personal data, because traces can themselves become records that need protection.
garak (Apache-2.0) is an open-source vulnerability scanner for language models. It probes models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks, and writes a JSONL report of every attempt and evaluation plus a hit log of attempts that found a vulnerability. For acquisition evidence, its leakage probes can test whether a model reveals material that should not have been in its training or fine-tuning data. A clean result is a point-in-time test against the probes run. It does not prove that the acquired data was lawful, consented or selected correctly.
- Data leakage probe runs: Run leakage probes against models trained or tuned on acquired data and keep the run output.
- JSONL attempt reports: Retain the full attempt and evaluation records as test evidence.
- Hit log review: Keep the hit log and record how each finding was triaged and resolved.
- Versioned test records: Tie each run to the model version and garak version tested.
- Repeat runs after changes: Rerun probes after retraining or changing the data source list.
Confirm which probes match the data risks in your register, because the default probe set may not cover every leakage scenario you need to test.
None of the four tools records rights, consent or selection criteria for a dataset. Acquisition evidence under A.7.3 depends on decisions and approvals that happen outside any system: why a source was chosen, what licence or contract governs it, whether personal data consent or another lawful basis applies, and who approved the acquisition. The organization owns these records, and an implementation partner can help design the register and workflow, but an auditor will test whether the register is complete, approved and consistent with what the tools show.
- Dataset register: Record each dataset's source, owner, acquisition date, licence or contract reference and selection criteria.
- Rights and consent record: Document the basis for use, including licence terms, contract clauses or consent scope.
- Approval trail: Keep sign-off by the accountable owner and any privacy or legal review.
- Mapping to technical evidence: Link each register entry to its asset, inventory, trace or probe records.
- Change history: Track updates to sources, terms and selection criteria over time.
Before relying on any tool output, confirm with your legal and privacy teams which register fields they require, because the tools cannot supply them.
What meeting A.7.3 acquisition of data costs
This table breaks the cost of meeting A.7.3 into its components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to build the questions you put to any quote, since no price or duration is stated here.
| Cost component | Who is paid and for what | One-time or recurring, and main drivers |
|---|---|---|
| Tooling or licenses | Vendor for commercial data catalog or consent management software; open-source alternatives carry no license fee but still need hosting and staff time | Licenses recur annually or per seat; open-source removes license spend but not hosting. Drivers: number of datasets and users |
| Engineering time to build the register | Internal data engineers or an implementation partner to build the acquisition register and link each entry to pipelines | Mostly one-time build, then recurring updates. Drivers: number of datasets, number of third-party sources, degree of pipeline automation |
| Legal and privacy review of rights and consent | Internal counsel, privacy office or outside counsel reviewing licenses, terms of use and consent records for each source | Recurring per new source and on terms changes. Drivers: number of third-party sources, personal data in scope, cross-border transfers |
| Evidence upkeep | Internal owners or a partner keeping acquisition records current as datasets are added, refreshed or retired | Recurring for as long as the AI system runs. Drivers: dataset churn, automation of logging, number of AI systems sharing data |
| External review | Independent specialists who test the register and rights records before the formal assessment, if you choose to buy this step | Typically one-time per cycle, optional. Ask whether scope covers all datasets or a sample |
| Auditor sampling | The independent certification body, which selects datasets to sample and examines their acquisition records | Recurring at each audit cycle. Drivers: number of datasets in scope, how well records are organized, number of sites |
Who owns A.7.3 and what a partner can take on
Your organization owns A.7.3. Someone inside the company must decide which data sources may be used for AI systems, under what legal basis, and with what consent or licence terms. Those decisions depend on contracts, privacy obligations and business judgment that an outside party cannot make on your behalf, so they should be signed off by people accountable for legal, privacy and the AI system itself.
- Rights and consent decisions: Confirm for each source whether you hold a licence, contractual right, consent or another lawful basis to use the data for training, tuning or operating the AI system.
- Selection criteria: Define and approve the criteria that decide which data is included or excluded, such as relevance, representativeness, recency and sensitivity.
- Exclusions and restrictions: Record which data categories are prohibited, and who may approve an exception.
- Review cadence: Set how often sources and selection criteria are re-examined when the AI system or its purpose changes.
- Sign-off: Name the role that approves each acquisition decision and keeps the approval on file.
Before relying on any record, check that the named owner can explain each rights decision without referring to the partner who documented it.
An implementation partner can prepare the systems and evidence that support A.7.3, but cannot take ownership of the control. The partner works from decisions your team has made and turns them into durable records, pipeline checks and tooling configuration. Scope and deliverables should be agreed in writing before work starts.
- Source register: Build the register of data sources and acquisition records in a form your team maintains.
- Pipeline wiring: Connect acquisition events and dataset metadata to your data pipelines so that records are created when data enters the system.
- Self-hosted tooling: Configure and harden self-hosted tools inside your own infrastructure, for example an inventory platform such as GLPI to track data stores and systems that hold the data.
- Evidence assembly: Collect logs, approvals and dataset records into an evidence pack organized by control.
- Documentation handover: Explain how the records are produced and maintained so your staff can run them without the partner.
When reviewing a proposal, confirm that the partner's deliverables are records and configurations, and that the statement of applicability and control decisions remain with your organization.
Only an independent auditor or certification body can issue an assessment result for A.7.3 or for an ISO/IEC 42001 certificate. ISO does not certify organizations, and accreditation of certification bodies is voluntary, so confirm that any body you engage is accredited for ISO/IEC 42001 in the relevant jurisdiction before you rely on its outcome.
- Independence: The auditor should not be the partner that designed the records, configured the tooling or assembled the evidence.
- Testing: The auditor samples datasets and checks that each acquisition record matches the stated rights, consent and selection criteria.
- Evidence access: Provide the auditor direct access to source records and logs rather than only summaries prepared for the audit.
- Scope agreement: Agree with the auditor which datasets and systems fall inside the assessment.
- Findings ownership: Your organization responds to any nonconformity, with corrective actions owned internally.
Before engagement, ask the certification body how it separates consultancy from assessment and who on its team will judge your evidence.
Where acquisition records usually fall short
Most A.7.3 findings come from records that describe the intent behind a dataset but not the facts an assessor can test. The cards below cover the gaps that appear most often and the fix for each, so the acquisition record matches the data the AI system actually uses.
Datasets used but never registered
Teams often pull data into notebooks, feature stores or fine-tuning jobs without an entry in any register, so the dataset exists but has no documented acquisition record. Fix this by making dataset registration a gate before training or evaluation jobs run. Check that the register is compared against storage buckets, data warehouse schemas and experiment logs, and that every dataset identifier used in a model's training record appears in it.
Sources recorded with no rights basis
A source name in the record, such as a public website or a partner feed, does not show that the organization may use the data for AI development. For each source, record the license, contract clause, terms of use or legal basis relied on, with the owner who approved it. Confirm the basis still covers the AI use case, because a license written for analytics may not extend to model training.
Consent claims that do not match the data
Consent or notice wording often describes a narrower purpose than the data actually collected, such as a form that mentions service delivery while the records feed model training. Compare each consent or notice text against the fields and purposes in the dataset. Where they diverge, either narrow the dataset, obtain a new basis, or document why another lawful basis applies, with input from privacy counsel.
Selection criteria applied informally
Engineers frequently choose records by filters, date ranges or sampling that exist only in code or in someone's memory. Write the inclusion and exclusion criteria, the reason for each, and the person who approved them, then keep the filter logic in version control. An assessor who reruns the selection should get the same subset from the documented criteria.
Records that go stale after refresh
A dataset refresh can change the source, volume, collection period or excluded fields, while the acquisition record still describes the previous pull. Assign each dataset a refresh owner and make the record versioned, so each refresh creates a new entry that links to the prior one. Stale entries are a common reason an auditor cannot tie a deployed model to the data it learned from.
Third-party data without supplier terms on file
Data bought from brokers, scraped by vendors or supplied by partners often arrives with terms that are never stored with the dataset. Keep the signed agreement, the usage restrictions, the delivery date and the supplier's own collection disclosures alongside the record. Ask the supplier to confirm in writing that the data may be used for AI system development, since this is the first document an assessor will request.
Questions buyers ask about A.7.3 cost, effort and outside help
How much effort does A.7.3 acquisition of data take?
The effort depends on how many datasets feed your AI systems and how well those datasets are already documented. A.7.3 asks you to determine and document how data is acquired and selected, so the work is mostly record keeping for each dataset: where it came from, the rights and consent behind it, the selection criteria applied and who approved its use. Teams that already keep a data inventory need far less time than teams that must reconstruct acquisition history from emails, vendor contracts and engineers' memories. The biggest drivers are the number of sources, the number of owners who must confirm facts, and whether any data was scraped, bought or inherited from a previous project. Ask any consultant to show how they would scope the register before quoting.
Can we prepare the A.7.3 records in-house with open-source tools?
Yes, the core record can be kept in-house, and open-source tools help with the evidence around it. A spreadsheet or wiki page can hold the acquisition record, but it becomes hard to maintain once datasets change. Asset inventory tools such as GLPI can track the systems that store and process data, and Wazuh's system inventory can show the hosts and software involved. For AI pipelines, Langfuse traces can show which data sources a request touched, which supports the selection story. Confirm each tool's fit with your own environment before relying on it, because none of them decides rights or consent for you. The rights analysis remains a legal and business task.
What does A.7.3 need from our compliance and legal teams?
Legal and compliance teams own the judgments that the technical record cannot make. They need to confirm that each dataset's license, contract or consent permits its use for the purpose of the AI system, and they need to review how personal data was obtained where privacy law applies. Their input also shapes the selection criteria, such as excluding data with unclear rights or sensitive attributes. Plan for a review cycle with named approvers, and ask them to sign off on each dataset entry rather than only the policy. Engineers should not record a rights position they cannot support with documents. Outside help can organize these reviews, but the decisions and sign-offs stay with your organization.
How long does A.7.3 preparation take when we have many datasets?
Preparation time grows with dataset count, but the relationship is not linear because many datasets often share sources and owners. Start by grouping datasets by origin, such as internal systems, licensed vendors, public sources and user-generated data, then document each group once and record exceptions individually. The drivers that lengthen the work are missing provenance, datasets that were copied or transformed several times, and unclear ownership inside the business. Ask a provider to explain how they would batch datasets, which owners they expect to interview, and what they need from you before the schedule is fixed. Fixed-scope engagements usually start with an agreed dataset list, which makes timing easier to judge.
Can a partner own and maintain the A.7.3 data register for us?
A partner can build and maintain a register as part of an implementation, but ownership of the register and the controls stays with your organization. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and it can prepare the systems and records that feed a compliance assessment. It does not issue audit reports or certifications. Ongoing upkeep is typically handled through a retainer, while the initial build is fixed in a written scope. Before signing, confirm who approves entries, where the register is stored, who can edit it, and how changes are logged. Make sure an internal owner is named so the register survives staff changes.
Will an auditor accept a self-prepared A.7.3 record?
An auditor decides whether the record is adequate, and a self-prepared record can be acceptable if it is complete, consistent and backed by evidence. Auditors typically look for a documented acquisition process, a list of datasets used by each AI system, the source and rights basis for each dataset, the selection criteria applied, and proof that the records are current. Your own team can produce all of this, but the auditor will test it against the actual systems, so every claim should trace to a contract, log or approval. Independent auditors and certification bodies are the only parties that issue reports or certificates, so ask your certification body early which evidence it expects.
How DeployOpen prepares acquisition of data evidence
DeployOpen prepares the systems, records and evidence that show how data for AI systems was acquired and selected under A.7.3 Acquisition of data. The organization keeps ownership of its controls, its rights decisions and its data, while DeployOpen builds the self-hosted tooling and documentation that makes the acquisition record reproducible for an independent assessor.
How we scope
- Engagements are fixed-scope, with the datasets, AI systems and acquisition sources in scope agreed in writing before work starts.
- The written scope names which dataset acquisition records, rights and consent sources and selection criteria the organization will evidence.
- We confirm which owners approve data sources and who signs off on selection criteria, so accountability is clear before build begins.
- Scope also states which assessor or certification body the evidence is prepared for, since only that body issues any report or certificate.
How we build
- We deploy self-hosted inventory tooling in the client's own infrastructure to record datasets, their origins and the systems that consume them.
- We configure a dataset acquisition register template covering source, legal basis, consent status, selection criteria and approval history.
- We connect tracing from AI workloads so the data an application retrieves or trains on can be linked back to its recorded source.
- We run security testing against data pipelines and AI interfaces to check for leakage of data that should not have been acquired or retained.
How we hand over
- Deliverables include the configured tooling, the acquisition register, the written procedure and a mapping of each record to the A.7.3 requirement.
- We document how each dataset record is created, reviewed, updated and retired, so the organization can run the process after handover.
- Handover includes a walkthrough of the evidence an auditor will request, such as approvals, source records and selection rationale.
- Where the organization wants an outside view, we identify the gaps but leave the readiness judgment and any certification decision to the independent auditor.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work is complete.
- A retainer can keep acquisition records current as new data sources are added, retired or reclassified by the organization.
- Support can cover re-running tests and refreshing evidence before a surveillance or recertification review by the certification body.
- Ask any provider to confirm in writing who owns the register, the rights decisions and the final evidence package after handover.
