A.4.2 Resource documentation: requirements and evidence

What A.4.2 resource documentation asks an organization to record

A.4.2 asks the organization to identify and document the resources needed for the activities at each AI system life cycle stage and for other AI-related activities. When an auditor or customer asks for proof of what an AI system depends on, this is the control they are testing. The record is the umbrella: it names the data, tooling, system and computing, and human resources that an AI system relies on, and it shows where each one is used. The sibling controls A.4.3 through A.4.6 cover those four resource types in detail, so the A.4.2 record should point to them rather than repeat them. A useful test is whether someone outside the team could trace a production AI system back to every dataset, model, framework, hosting environment and accountable person it depends on.

The main risk is unknown dependencies. A model that calls a third-party API, a retrieval index built from a shared data store, or a fine-tuning job that runs on a cloud account nobody listed will all be missing from a record that was written once at launch. Records also go stale quickly, because models are swapped, libraries are upgraded, hosting moves between regions or providers, and staff change roles. Assign an owner for each AI system, tie record updates to change management and release approval, and review the record at each life cycle transition. Confirm with your certification body or auditor how they expect review dates and version history to be shown, since the standard does not prescribe a format.

Which AI systems, resources and teams the A.4.2 record must cover

Before an A.4.2 record can be written, the organization has to settle what counts as an AI system, which life cycle stages need entries, and who keeps each entry current. Each decision below changes how much documentation is needed and which teams must sign off on it, so the statement of applicability should show how each one was resolved.

Built, bought or only used systems

Decide whether the record covers AI systems the organization builds, systems it buys from a vendor, and systems employees only use. A model built in-house needs entries for training data, code, compute and maintainers. A purchased system needs entries for the vendor's documented resources that the organization relies on, plus its own configuration and integration. Simple use of a vendor tool usually needs a lighter entry. Confirm the rule in writing so auditors see one consistent boundary.

Life cycle stages that need a record

Identify which stages of the AI system life cycle, from design and development through deployment, operation and decommissioning, produce resource needs that must be written down. Retraining, monitoring and retirement often create resource needs that teams forget, such as archived datasets or logging storage. A stage without a documented resource need is a gap an assessor can test. Map each stage to its owner and its resource dependencies.

Third-party models and APIs

Decide whether externally hosted models, pre-trained weights, hosted inference APIs and vendor-managed datasets appear in the record. Most organizations rely on them, so excluding them leaves the record incomplete. Record the provider, the version or model identifier, the contract or terms that govern use, and the data or compute the organization depends on. Confirm with the procurement team which contracts already contain these details.

Shadow AI tools

Employees may use AI tools that IT has not approved, such as browser-based assistants or unlicensed code tools. Set a rule for how these are discovered, logged and either approved, restricted or removed. Discovery usually relies on network and endpoint telemetry, expense records and access reviews, which is where asset inventory tooling helps. An unrecorded tool used for a regulated decision is the kind of gap that appears in a finding.

Team ownership of each entry

Assign a named owner for each resource entry, separating the business owner of the AI system from the technical owners of data, tooling, compute and people. Ownership decides who updates the record when a model is retrained or a vendor changes. Without named owners, the record goes stale within a review cycle. Check that each owner has agreed to the responsibility and knows the review interval.

Linking the record to the AI inventory

Decide whether the A.4.2 record is the master list of AI systems or whether a separate AI system inventory sits above it. The record should reference each inventoried system by a stable identifier, so that resource entries can be traced back to a system and its risk assessment. Confirm which document is authoritative and how changes flow between them, since two lists that disagree are a common audit issue.

How an assessor tests A.4.2 resource documentation

This table sets out how an assessor typically tests the A.4.2 resource record, what evidence they ask for, and the findings that most often appear. Read each row as a test step: the approach shows what the assessor does, the evidence column shows what the organization should have ready, and the findings column shows where gaps usually surface.

Test approach	Evidence requested	Common findings
Confirm the resource record exists and is scoped to the AI systems in the statement of applicability	Resource record or register, scope statement, and the statement of applicability entry for A.4.2 with its justification	No single record exists, or resources are documented in several places with no owner; scope does not match the AI systems actually listed
Sample AI systems and trace each listed resource back to a real asset	Sample of AI systems, linked entries for data sets, tools, compute and people, and the asset records they point to	Listed resources cannot be found in asset inventories or cloud accounts; entries name a tool or dataset that is no longer in use
Check that each AI system life cycle stage has resource entries	Entries mapped to design, development, verification, deployment, operation and retirement stages, or the organization's own stage model	Stages such as monitoring, retraining or decommissioning have no entries; the record reflects only development
Check that resources for other AI-related activities are recorded	Entries for activities outside the life cycle, such as impact assessments, audits, vendor reviews or incident response	Governance and assessment activities depend on people or tools that never appear in the record
Verify the record is reviewed when resources change	Change log, review dates, approval records, and tickets or change requests that triggered updates	Reviews are not dated; a model, vendor or team change is absent from the record for months
Verify that the record links to the AI system inventory and to related controls	Inventory cross-references, links to A.4.3 to A.4.6 records, and the owner named for each AI system	Inventory and resource record disagree on system names, versions or owners; no owner is named for an entry
Interview the record owner and a system owner about how the record is kept current	Documented procedure, role assignments, and evidence that staff know where the record lives	Owners describe an informal process; updates depend on one person who is not backed up

Steps to build the resource record for each life cycle stage

This sequence turns A.4.2 into a working record: it scopes the AI systems, maps each life cycle stage to the resources it consumes, assigns owners, and keeps the register tied to the inventory and current as the systems change.

Define the AI system scope
Start by listing every AI system the organization builds, buys, hosts or operates, including systems provided by third parties and internal tools that make or support decisions. Record a short scope statement for each one: its purpose, its business owner, and the boundary of what is in or out. Agree the list with the AI governance lead, since the statement of applicability under clause 6.1.3 will need to match it. The output is a scoped system list that names each system and states why it is in scope. Confirm with your own risk or legal team which edge cases, such as embedded vendor features, belong on the list before moving on.
List the life cycle stages for each system
For each scoped system, record the stages it passes through, such as design, data preparation, development, verification and validation, deployment, operation, monitoring, change and decommissioning. Use the stages your own AI life cycle process defines so the record matches how teams actually work, and note where a system skips a stage or where a vendor controls it. A.4.2 asks for resources at each stage and for other AI-related activities, so include a line for those activities as well. The output is a system-by-stage grid that shows which stages apply to which systems.
Identify the resources each stage needs
Walk each stage with the people who run it and list the resources it depends on across four categories: data, tooling, system and computing, and people. Reference the sibling controls for detail, so data sources go to A.4.3, frameworks and evaluation tools to A.4.4, infrastructure to A.4.5, and competences to A.4.6, while the umbrella record notes which resource feeds which stage. Ask the teams to name the concrete item, such as a repository, a model artifact or a hosting account, rather than a general category. The output is a stage-by-resource matrix for each system.
Assign an owner to each resource
Give every resource in the matrix a named owner who is accountable for keeping its entry accurate, and a backup owner for continuity. Ownership usually follows the function that provisions or controls the resource, such as platform engineering for compute or the data team for datasets, but the AI governance lead should hold the record itself. Where a third party supplies a resource, record the contract or service owner inside the organization as well. The output is a register column for owners that shows no blank entries for in-scope resources.
Consolidate the resources in a single register
Bring the matrices together into one register with a consistent entry format: resource name, type, stage or stages served, owner, location or provider, version where relevant, and a link to the supporting record. Store the register in the organization's controlled document system with a version history so auditors can see how it changed. Link each AI system entry to the AI system inventory so a reader can move between what the system is and what it needs. The output is a single controlled register that covers every in-scope system and resource.
Populate the record from discovery tools
Where possible, check manually recorded entries against automated sources. Asset inventories can confirm hosts, installed software and network components, and observability tooling can show which models, tools and services a running system calls. Use these outputs to find resources that teams forgot to list, such as shadow tools or unmanaged endpoints. GLPI and Wazuh cover infrastructure and endpoints, while Langfuse traces can show tool and retrieval use in an LLM application. Treat each discovered item as a candidate entry for the owner to confirm. The output is a reconciliation log that shows which entries came from discovery and which owners accepted them.
Set review triggers and keep the record current
Define the events that require the register to be updated, such as a new system, a change of model or framework version, a new dataset, a move to new infrastructure, a change in staffing for a stage, or a decommissioning. Set a routine review cycle as well, and record the date of each review and who approved it. Feed the findings into internal audit and management review so the record is tested the same way as other management system documentation. The output is a documented review procedure and a review log with at least one completed cycle. Confirm the review frequency that fits your risk profile with your certification body or auditor before you commit to it.

Evidence that passes A.4.2 and how to keep it current between audits

An assessor testing A.4.2 looks for a resource record that matches how the AI systems actually run today, not one that was accurate at the last audit. The cards below cover the artifacts that usually carry that proof and the update habits that keep them current between audits.

Resource register

The register is the umbrella record that lists each data set, tool, compute resource and person an AI system depends on, with an owner and a last-reviewed date for each entry. An assessor checks that every entry traces to a real asset and that nothing in production is missing from the list. Keep it current by requiring a register entry as part of every change that adds or removes a dependency, rather than refreshing it once a year.

Stage-by-resource matrix

This matrix maps each AI system life cycle stage, such as design, development, deployment, operation and decommissioning, to the resources it needs. A.4.2 asks for resources per stage and for other AI-related activities, so an assessor will look for empty cells and for stages that a system has reached but nobody has filled in. Review the matrix whenever a system moves to a new stage, because that is when resource needs usually change.

Linked AI system inventory

The inventory lists each AI system and points to its resource register entries, so a reviewer can move from a system to its data, tools, compute and people. Assessors check that the inventory and the register agree on system names and versions. Asset inventories from tools such as GLPI's Assets module or Wazuh's system inventory can supply the hardware and software records that the inventory links to, but confirm that each AI system is tagged explicitly.

Change records showing updates

Change tickets, pull requests or release notes that touch a resource show when the record was updated and why. An assessor samples recent changes, such as a new model version or a new retrieval source, and checks whether the resource record changed in the same cycle. Tying register updates to change tickets or release events gives a dated trail that an annual refresh cannot provide.

Owner sign-offs

Each resource entry should name an accountable owner who confirms the entry is accurate at set points, such as before a release or at a scheduled review. Assessors check that owners exist, that they hold the role described in the record, and that sign-offs are dated. Ask the owner to confirm the entry rather than a general team, so that someone can answer questions during the audit.

Review minutes

Minutes from periodic reviews of the resource record show that someone looked at gaps, stale entries and unowned resources and decided what to do about them. An assessor looks for named actions with owners and completion dates, and for evidence that the review also covered the inventory and the matrix. Confirm with your certification body how often it expects these reviews to occur, because that cadence is set by your own management system rather than by the standard alone.

What meeting A.4.2 costs in money and effort

This table breaks down what documenting A.4.2 resources costs, who is paid for each part, and whether the cost recurs. Read it to decide which parts to build in-house, which to buy, and what to request in a written quote. No price or duration is stated because none has been researched for this control.

Cost component	One-time or recurring	What drives it	How to reduce it
Internal engineering time to build the resource register	One-time, with later rework	Number of AI systems in scope, how many resource types are recorded, and whether source data already exists in CMDB or asset tools	Start from existing asset and inventory exports and limit the first version to in-scope systems
Owner time for updates	Recurring	How often tooling, models, datasets or hosting change, and how many named owners maintain entries	Tie register updates to change tickets and deployment pipelines so updates happen as a by-product of normal work
Register and asset discovery tooling or licenses	Recurring if commercial, often low or none if open source	Commercial per-seat or per-asset licensing, number of endpoints and whether discovery agents are needed	Evaluate self-hosted open-source asset management and endpoint inventory tools such as GLPI and Wazuh, and confirm their fit with your environment
AI-specific telemetry and tracing for tooling records	Recurring	Volume of traces, retention period and whether observability is already deployed for other purposes	Reuse existing observability stacks and set retention to what the documented evidence actually needs
External readiness or documentation support	One-time, sometimes with periodic reviews	Scope agreed in writing, number of systems, existing documentation quality and whether a gap review is included	Ask for a fixed scope that lists deliverables, and keep ownership of the register with your team
Auditor sampling effort	Recurring at each audit cycle	How many resource records the auditor samples, how complete the record is and whether links to evidence are current	Keep one record per AI system with dated owners and linked evidence so sampling does not require manual reconstruction
Management review time	Recurring	How often the register is reviewed and how many systems and owners must confirm entries	Combine register review with existing management review or change advisory meetings

Self-hosted open-source tools that can support the resource record

The four tools below each produce a different slice of the evidence behind a resource record: hardware and software inventory, runtime component detail, LLM traces and model probing results. None of them writes the record for you, and none replaces the documented ownership and review that A.4.2 expects. Confirm fit for your environment before relying on any of them as evidence.

GLPI Assets for infrastructure records

GLPI's Assets module tracks computers, monitors, software, network equipment, peripherals, printers, phones and racks. Entries can be typed in by hand or pushed automatically by the GLPI Agent through native inventory, which is built into GLPI from version 10. This gives you a dated register of the physical and virtual compute an AI system runs on, which can be linked to the system and computing entries in the resource record. It does not know which models, datasets or prompts sit on those machines. Check that GLPI's license, GPL-3.0-or-later, fits how you distribute or modify it.

Wazuh Syscollector for endpoint detail

Wazuh's Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups from each endpoint, then stores them in the Wazuh indexer for dashboard views and reports. For A.4.2 this shows what software and accounts actually exist on the hosts that run AI workloads, which you can compare against the documented record. It only sees what runs on monitored endpoints, so model artifacts, cloud-managed services and third-party APIs need their own entries. Wazuh is licensed GPL-2.0-only, so confirm that license terms suit your deployment.

Langfuse traces for runtime dependencies

Langfuse records traces that capture each operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. Traces show which models, retrieval sources and tools an application actually calls in production, which is useful evidence for the tooling and system entries in the resource record. Traces only cover instrumented applications, and they can contain personal data in inputs and outputs, so set retention and redaction before you collect them. Langfuse is MIT licensed.

garak reports for model testing

garak probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. Each run writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. For A.4.2 these reports document the test tools and test sets used to evaluate a given model version, which ties the tooling record to a specific model. They do not describe the broader resource set, and results only apply to the model and configuration tested. garak is Apache-2.0 licensed, so keep the license notice with any internal copies.

Who owns the A.4.2 record, who can help, and where the auditor stops

Your organization owns A.4.2. The control asks you to identify and document the resources each AI system life cycle stage needs, and only your people can decide what those resources are, who answers for them and whether the record still reflects reality. Your team is responsible for the decisions that give the record meaning, not for the mechanics of building it.

Register ownership: Name an accountable owner for the resource record and for each AI system entry, with a deputy who can act when that person is unavailable.
Scope decisions: Decide which AI systems, life cycle stages and AI-related activities the record covers, and document why anything is excluded.
Resource decisions: Confirm which data, tools, compute and people each system depends on, including third-party services that your staff do not operate directly.
Review decisions: Set the review trigger, such as a material change to a model, dataset, hosting location or vendor, and record who approved each update.
Sign-off on the statement of applicability: Your management decides whether A.4.2 is included and justified under clause 6.1.3.

Before any outside party touches the record, confirm that your own owners can explain every entry without reading the document aloud.

How the NIST AI RMF crosswalk maps to the B.4.2 guidance

A NIST AI Resource Center crosswalk maps four AI RMF items to the B.4.2 implementation guidance for A.4.2, so a team that already runs NIST AI RMF work may be able to reuse records it has built rather than start a separate resource register. The crosswalk, contributed by Microsoft and posted by NIST with a note that posting is not an endorsement, links GOVERN 1.6 (the inventory of AI systems), MAP 2.1 (tasks and methods defined), MEASURE 2.1 (test sets, metrics and tools documented) and MANAGE 2.1 (resources to manage AI risk) to B.4.2. This is a third-party alignment, not an official ISO/IEC mapping, so it should be cited as a working reference and checked against the standard itself before an auditor sees it.

In practice, the four AI RMF records become candidate evidence for the A.4.2 umbrella record. The inventory supplies the list of AI systems and their life cycle stages, the task and method definitions show the activities each stage needs, the test tool documentation covers evaluation resources, and the risk resources record shows the people, budget and tooling assigned to manage AI risk. Before reuse, confirm that each record names the AI system it covers, lists the resources at each life cycle stage, and carries a review date that is recent enough to show it is still maintained. A record that was accurate at the last NIST exercise but no longer matches the running system will fail the same test an auditor would apply to a stale register.

Mapping gaps are the other thing to check. The crosswalk does not tell you whether your MAP 2.1 task list covers data, tooling, compute and people in the way B.4.2 expects, so a gap review should compare each record against the four resource categories and against the life cycle stages your organization actually uses. Where a category is missing, record that gap in the statement of applicability reasoning for A.4.2 and assign an owner to close it. Ask any consultant who offers to reuse your NIST work to show this comparison in writing.

How much effort A.4.2 takes and what buyers ask before hiring help

How long does it take to build an A.4.2 resource record?

The duration depends on how many AI systems are in scope, how many life cycle stages each one moves through, and how well existing asset and software records already describe the environment. No duration figure is given here because it follows from the scope. A single system with well-maintained inventories and clear owners is far quicker to document than a portfolio of systems that depend on shadow tooling, undocumented pre-trained models and cloud resources spread across several accounts. Ask any partner to show how they will split the work into stages and which inputs they need from your team before the start date is set.

Can we document AI resources without outside help?

Yes, an organization can write the record with its own staff, and many do. The control asks for identification and documentation, so the work is mostly discovery and disciplined writing rather than specialist technical design. Outside help tends to add value when no one holds a complete view of the AI systems, when existing asset tools do not reach model or pipeline resources, or when the team needs a second reviewer before an assessor sees the record. An implementation partner prepares the systems and evidence, but the organization owns the controls and the decisions recorded in them.

What do engineering and business owners need to contribute?

Engineering owners supply the technical facts: which frameworks, pre-trained models, evaluation tools, data pipelines, hosting environments and compute the system uses at each life cycle stage. Business owners confirm the purpose of each system, who is accountable for it, and which decisions depend on its outputs. Both groups must review the draft, because a record that only engineering writes often misses the business purpose, and one that only the business writes often misses dependencies. Plan for named reviewers and a fixed review window in the project schedule.

Is one central register enough for AI resource documentation?

A single register is a good place to tie the resources together, but it rarely holds all the detail on its own. The usual pattern is an umbrella record per AI system that points to supporting records: data resources under A.4.3, tooling under A.4.4, system and computing resources under A.4.5 and human resources under A.4.6. Existing tools such as an asset management platform or a software inventory can feed some of those records automatically. Confirm with your auditor how they expect the links between records to be shown, since the standard does not prescribe a specific file format.

How do we keep an AI resource record current?

The record stays accurate only if changes trigger updates. Typical triggers include a new model version, a change in training or inference infrastructure, a new data source, a change in the people responsible for a system, and a retired tool. Tie those triggers to existing change management and release processes, assign an owner for each record, and review the full record at a fixed interval set by your management system. Asset inventory tools that collect hardware and software automatically reduce manual upkeep for the infrastructure part of the record, but they will not capture model or prompt changes on their own.

What should a partner put in a written quote for A.4.2 work?

A written quote should follow from a written scope, not a generic package. Ask the partner to list the AI systems in scope, the life cycle stages covered, the systems and inventories they will read, the deliverables (the record format, the linked supporting records and any review sessions), the inputs your team must provide and by when, and the assumptions behind the schedule. Ask which costs are one-time, such as the initial build, and which recur, such as updates and reviews. DeployOpen does not publish a price list, and a quote follows from the agreed scope. Make sure the quote states who issues any assessment report, since that is always an independent auditor or certification body.

How DeployOpen scopes and prepares the A.4.2 resource record

DeployOpen treats A.4.2 Resource documentation as a working record that the organization owns and keeps current, not a one-time spreadsheet. We help define what the record covers, populate it from systems that already hold resource data, and hand over a record your team can maintain as AI systems change.

How we scope

Agree in writing which AI systems, life cycle stages and AI-related activities the resource record covers.
Confirm which existing sources hold resource data, such as asset registers, endpoint inventories and model tooling records.
Define who in your organization owns each part of the record and approves changes to it.

How we build

Configure self-hosted inventory tools inside your own infrastructure so resource data is collected rather than retyped.
Link the umbrella record to the data, tooling, system and people records that sit under A.4.3 to A.4.6.
Test that entries can be traced from each AI system to its supporting resources and show the result to your reviewers.

How we hand over

Deliver the record structure, population procedures and update triggers as documented material your team keeps.
Provide a mapping of each record field to the evidence a reviewer would ask to see for A.4.2.
Walk your staff through maintaining the record and through how it feeds the AI system inventory.

How we support

Offer ongoing support, upgrades and maintenance of the tooling as a retainer, if your organization wants it.
Review the record after material changes to AI systems, tools or infrastructure, as agreed in the written scope.
Remember that an independent auditor or certification body, not DeployOpen, assesses the record and issues any report or certificate.