What A.4.5 system and computing resources asks for under ISO 42001
An auditor or a customer questionnaire asks where each AI system runs and what it consumes, and the answer should already sit in a record. Control A.4.5 System and computing resources, part of Annex A of ISO/IEC 42001:2023, asks the organization to document information about the system and computing resources used for the AI system. In practice that covers everything the system relies on to be trained, tested, served and hosted: training clusters, inference endpoints, storage, networks, managed AI services, and the cloud regions or data centers where they run. The record should be specific enough that someone can answer, for each AI system, which environment it runs in, who operates that environment, and what capacity it has been provisioned.
The risk this control addresses is an AI system whose infrastructure nobody can describe. Teams often provision GPU capacity, notebooks or hosted endpoints on their own, so capacity is unknown, hosting drifts into unmanaged accounts, and the energy and carbon footprint of training runs goes unrecorded. The difficulty is that compute is frequently shared between projects, elastic (scaled up and down automatically) or run by a cloud provider whose resource identifiers do not match the organization's own names. A workable record therefore maps each AI system to the cloud accounts, clusters and namespaces it uses, and it is refreshed whenever those change. Decide who owns that mapping before the first audit, and confirm with your auditor which evidence they will accept for resources the provider operates on your behalf.
A practical first step is to list every environment that trains, evaluates or serves a model and tag each one with the AI system it supports. Then decide which asset data your existing inventory tools can hold and which fields, such as environmental measurements, must be added by hand. Note that the Annex A control itself does not prescribe how energy use is measured; for the environmental point, the NIST AI RMF to ISO/IEC FDIS 42001 crosswalk maps the control to a measurement and documentation expectation for model training, and you should confirm with your certification body how far that expectation applies to your organization.
Which compute and hosting resources fall under A.4.5 in your organization
A.4.5 applies to whatever infrastructure actually runs your AI systems, so scope starts from the AI system inventory rather than from the infrastructure team's asset list. The cards below cover the environments and accounts that most often decide whether the record is complete, and how your statement of applicability under clause 6.1.3 settles whether the control is included.
Training clusters and batch compute
Training clusters are usually the largest and most variable compute resources behind an AI system, and they are often provisioned on demand for a single model run. For A.4.5, record the cluster or pool, its accelerator types, the systems and model versions it produced, and the dates it was active. Check whether ephemeral jobs are captured by your record or only the long-lived nodes. Confirm with the owning team which training runs must be traceable back to a documented resource.
Inference endpoints in production
Inference endpoints are where an AI system meets users, so they are the compute resources most likely to be relied on during an incident. Record each endpoint against the AI system it serves, the hosting location, the model version deployed, and the capacity it is configured to handle. Check that endpoint records change when models are redeployed or scaled, because a stale record shows an assessor a system that no longer exists.
Staging and evaluation environments
Staging and evaluation environments often run the same model artifacts as production under looser controls, which makes them easy to omit from the record. Decide whether they fall within the scope of the AI system they test, and document them if they hold real data, model weights or evaluation results you rely on. Confirm whether evaluation harnesses that call production-like models are recorded as resources in their own right.
Hosting for AI features in SaaS products
If your SaaS product embeds AI features, the hosting that serves those features is part of your A.4.5 scope even when customers never see the infrastructure. Document the tenancy model, the regions where AI processing runs, and whether features share compute with non-AI services. Check how the record handles customer-dedicated deployments, since each one may need its own entry.
Edge and on-premises GPU hardware
On-premises and edge GPU hardware is physically owned by you, so it appears in asset inventories, but those inventories rarely link hardware to the AI workloads it runs. Record which AI systems use each device, its location and ownership, and any dependency on specific hardware for the system to function. Confirm that hardware retirement or reassignment updates the A.4.5 record.
Third-party cloud and model-serving accounts
Third-party cloud accounts and managed model-serving services hold compute that you do not own but still depend on, so they must be recorded with the provider, account, region and service used. Document the contractual or shared-responsibility boundary for each, and confirm what evidence the provider supplies and what you must produce yourself. If an account is excluded from scope, record the reason in the statement of applicability.
How an assessor tests A.4.5 system and computing resources
This table shows how an assessor compares the A.4.5 resource record against the AI system inventory, traces sampled systems to their hosting and compute, and checks whether capacity and environmental footprint are recorded and current. Read each row as a test step, the evidence it needs, and the gap that most often causes a finding.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Record against inventory | Resource record entries matched to AI system inventory entries, with the same system names and identifiers | Systems in the inventory with no compute or hosting entry, or compute entries pointing to systems that are not in the inventory |
| Sample tracing to hosting | For a sampled AI system, the cloud account, cluster, data center or on-premises host where it runs, with the configuration or asset record | Records name a platform in general terms but not the environment, region or cluster where the model actually runs |
| Training and inference compute | Records separating training infrastructure from inference infrastructure, with instance types, accelerators and scheduling owner | Training runs recorded but inference endpoints missing, or retired hardware still listed as active |
| Capacity records | Documented capacity or sizing assumptions, and the monitoring data that shows actual utilization over time | Capacity stated once at deployment and never revisited, or no link between utilization data and the resource record |
| Environmental footprint | Where the organization says footprint is recorded, the stored energy, emissions or sustainability figures and their method or source | Footprint recorded for some systems only, or stored in a tool the resource record does not reference |
| Currency of records | Change history, asset discovery output or inventory export dated near the assessment period | Records last updated at system launch, with decommissioned systems and migrated workloads not reflected |
| Consistency with other controls | Cross-references to the resource record, data and tooling entries, and the statement of applicability | Compute records that do not align with the tooling or data resources an AI system is documented to use |
Which evidence satisfies A.4.5 and how to keep it current
A.4.5 asks for documented information about the system and computing resources an AI system uses, so the evidence is a set of linked records rather than one document. The cards below cover the artifacts an assessor is likely to sample, what each must show, and how to refresh it between audits.
System and computing resource register
This is the core record: one entry per AI system listing the training, inference, hosting and storage resources it depends on, with owner, location, environment and last review date. An assessor checks that each AI system in the inventory links to its compute entries and that no production system is missing. Refresh the register at every change to an AI system's infrastructure and at each internal review, and record who approved the update.
Infrastructure inventory exports
Asset and endpoint tools produce the raw inventory behind the register. Exports from a single authoritative inventory should show hardware, operating systems, installed software and network placement for hosts running AI workloads. Check that the export date is recent, that hosts match the register, and that unmanaged or untagged systems are investigated. For GLPI, Wazuh and similar tools, schedule exports and keep the dated files.
Cloud account and cluster records
For workloads in cloud accounts or Kubernetes clusters, the assessor expects configuration records showing accounts, regions, node pools, GPU instances and namespaces assigned to each AI system. Exports of resource tags and cluster manifests are useful evidence when they map back to the register. Confirm that tagging rules identify the AI system owner, and refresh these exports on a fixed schedule and after each infrastructure change.
Capacity planning records
Capacity records explain why the resources are sized as they are and when more will be needed. Keep utilization metrics for compute, memory, storage and accelerators, along with forecasts and the decisions taken from them. Prometheus and Grafana dashboards can supply the metric history, but the assessor will want the reviewed decision, not only the graph. Review capacity at a set cadence and record the threshold that triggers action.
Environmental footprint records
Where the organization tracks energy or emissions for model training and management activities, it should document the method, the data sources and the period covered. The NIST crosswalk maps the related AI RMF measure to B.4.5, so an assessor may look for this record even if the organization is not required to publish it. State the boundary of measurement and the estimation assumptions, and update the record after each major training run or hardware change.
Resource change records
Change records show when compute resources were added, resized, moved or retired, and which AI system each change affected. Assessors sample these to confirm the register was updated when the infrastructure changed and that retired resources were removed or archived. Tie each change ticket to a register entry, and run a periodic reconciliation between change logs, inventory exports and the register to catch gaps.
Steps to document system and computing resources for each AI system
This sequence turns A.4.5 into a working record: each AI system's compute, hosting and environments are identified, owned, kept current and checked against a sample, so an assessor can trace any system back to the infrastructure it depends on.
Confirm the AI system inventory
Start from the organization's list of AI systems, not from infrastructure. The AI system owner or governance lead confirms which systems are in scope, including systems built in-house, systems bought from a vendor and systems that only the organization uses. Each system gets a stable identifier that every later step references. The output is an approved inventory with one row per system and a named owner. The step is done when the inventory is signed off and any system missing from it has been added or formally excluded with a reason. This list also feeds the wider resource record described under A.4.2, so keep identifiers consistent with that record.
Map compute, hosting and environments per system
For each inventoried system, the engineering owner records where it runs across three activities: training, inference and evaluation. Capture the hosting model (cloud account, data center, air-gapped network or edge device), the compute types used (CPU, GPU or accelerator classes and the instance or node pools behind them), the storage and network segments involved, and any shared platforms it depends on. Note which environments exist (development, test, staging and production) and which are isolated from one another. The output is a per-system environment map. The step is complete when every system has an entry for each activity it performs, and a system with no training activity says so explicitly rather than leaving the field blank.
Build the resource register with named owners
Consolidate the environment maps into a single system and computing resource register. Each row is one resource or resource group linked to the AI system identifier, with a technical owner, an accountable business owner and the location of the source system of record. Ownership matters because capacity changes, decommissioning and incident response all depend on knowing who can approve them. The output is a register that an assessor can filter by AI system and by owner. The step is done when every resource in the register has both owners and every AI system in the inventory appears at least once.
Populate capacity and environmental footprint fields
For each resource in the register, record capacity figures where they are relevant to the system's operation, such as allocated compute, storage quotas, peak and baseline utilization limits and scaling bounds. Where the organization measures it, record the energy or emissions footprint of training and of ongoing model management. The NIST AI RMF crosswalk maps environmental impact and sustainability assessment of training and management to B.4.5, so an organization that reports on this should keep the figures and their method alongside the register. Confirm with the cloud provider or data center operator which footprint data they supply and at what granularity, because some organizations only receive account-level data. Blank fields should be explained, not left silent. The output is a capacity and footprint section per system with a source and date for each value.
Connect telemetry and asset inventories as sources
Rather than typing every value by hand, link the register to the systems that already observe the infrastructure. Asset inventory tools can record hardware, software and network devices, including those entered manually or pushed by an agent. Endpoint and host inventory tools can collect operating system, installed software and running services. Metrics platforms can provide utilization and capacity trends from instrumented workloads. Confirm for each tool which assets and fields it actually collects in your environment, since coverage varies with how agents are deployed and what is instrumented. The output is a mapping that states, for each register field, which source supplies it and how often it refreshes. Fields without a source remain manual and carry an owner.
Set a review cadence tied to change management
Define when the register must be updated: on every change to a system's hosting, compute class, environment or data center, on decommissioning, and on a scheduled review interval that the organization chooses and documents. Route these triggers through the existing change management process so that a new GPU pool or a moved workload cannot reach production without a register update. The output is a written procedure that names the trigger events, the owner responsible for each update and the record that proves the update happened. The step is done when a sample change ticket can be traced to a dated register revision.
Run an internal check against a sample of systems
Before any external assessment, select a sample of AI systems, including at least one that trains models and one that only runs inference if both exist. For each, trace the register entry back to its sources: the asset inventory record, the telemetry, the change ticket and the owner's confirmation. Record any mismatch, missing owner, stale value or untracked environment as a finding with an owner and a closing date. The output is a short internal check report that shows what was tested, what matched and what was corrected. The step is complete when the findings are closed or accepted by the accountable owner and the report is filed with the A.4.5 evidence set. Keep this check independent of the people who maintain the register where your size allows it.
Open-source tools that produce A.4.5 inventory and capacity evidence
A.4.5 is satisfied by a documented record of the systems and computing resources an AI system relies on, plus evidence of how capacity and footprint are tracked. The tools below can produce parts of that evidence from infrastructure you already run, but each covers a different slice, and none of them builds the AI resource record on its own.
GLPI Assets for hardware and hosting records
GLPI's Assets module records computers, servers, network equipment, racks and software, either entered by hand or pushed automatically by the GLPI Agent through native inventory available since version 10. This gives an auditor a dated asset record for the hosts that run training, inference or hosting workloads. It does not describe which model runs on which host, which GPU or accelerator pool is reserved for AI, or the energy use of those hosts, so you will need to add those fields yourself. GLPI is licensed under GPL-3.0-or-later; confirm that your use and any modifications fit that license with your legal team.
Wazuh Syscollector for running system inventory
Wazuh's Syscollector module reports hardware, operating system, installed software, network interfaces, open ports, running processes and services from each endpoint into the Wazuh indexer. This shows what is actually running on AI hosts at a given time, which helps you check the recorded inventory against reality. It does not capture the purpose of each workload, the training datasets it touched, or capacity planning decisions. Wazuh is licensed under GPL-2.0-only, so confirm the obligations that apply to your deployment before distributing any modified agent.
Grafana Alerting for capacity thresholds
Grafana Alerting builds rules from queries across several data sources and alerts on metrics and logs together, so one view can show when AI compute, memory or storage crosses a limit you have defined. Those alert definitions and their history can serve as evidence that capacity is monitored and acted on. Grafana does not decide what your capacity limits should be; you must document the thresholds, their owners and the response steps. Grafana is licensed under AGPL-3.0-only, which carries network-use obligations when you modify and offer it to users, so confirm this with counsel before deploying a modified version.
Prometheus metrics for resource trends
Prometheus collects metrics from instrumented jobs over HTTP and stores them as time series identified by metric name and labels, which you query with PromQL. Retained series for CPU, GPU, memory, storage and network use give a factual trend record that supports capacity statements and footprint estimates when you add energy or utilization metrics. Prometheus does not collect data from systems that expose no metrics endpoint, and its local storage is not a long-term archive unless you add one. Prometheus is licensed under Apache-2.0, a permissive license with fewer redistribution conditions. Confirm which exporters and retention settings your evidence period requires.
What meeting A.4.5 costs in money and effort
This table lists the cost components of documenting system and computing resources for A.4.5, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to compare internal effort with outside help and to shape what you ask for in a written quote. No figures are given because none were supplied for this control.
| Cost component | One-time or recurring | What drives it up or down | What to request in a quote |
|---|---|---|---|
| Tooling and licenses | Recurring where licensed; one-time for setup | Self-hosted open-source inventory and monitoring tools remove most license spend, but hosting, storage and retention still carry cost | Itemized list of every licensed product, hosting assumptions and who pays for each |
| Engineering time to build the register | One-time | Number of AI systems, environments and cloud accounts to discover; how many compute assets are already inventoried | Discovery phase deliverables, named systems in scope and the register structure agreed in writing |
| Engineering time to maintain the register | Recurring | Rate of change in compute, hosted endpoints and model deployments; whether inventory updates are automated | Who keeps the register current, how often it is reconciled and what triggers an update |
| Telemetry and capacity evidence upkeep | Recurring | Telemetry maturity; number of metrics sources and alert rules; retention periods set for capacity and energy records | Metrics that feed the record, retention settings and the owner of each dashboard or report |
| Environmental footprint recording | One-time setup, recurring reporting | Whether energy or emissions data is available from providers; number of training runs and hosting regions | Data sources used, calculation method and how gaps in provider data are documented |
| External review or testing | Recurring or per engagement | Scope of the systems reviewed, depth of configuration checks and whether a second reviewer validates the record | Fixed scope, sample of systems tested, deliverables and retest terms in writing |
| Auditor sampling time | Recurring per assessment cycle | Number of systems the auditor samples and how easily the record can be traced to live infrastructure | Auditor's sampling approach and evidence list agreed before fieldwork; the auditor sets its own fees |
Who owns A.4.5, who can help, and where the auditor stops
Your organization owns the A.4.5 record and every decision about what goes into it. The control asks you to document the system and computing resources an AI system relies on, so the people accountable for the AI system must decide which environments count, which owners are named, and how capacity and environmental footprint are recorded. Those decisions are governance decisions, and they stay with you even when outside help builds the tooling.
- Scope decisions: Decide which training, inference, hosting and development environments belong in the record for each AI system.
- Ownership: Name an accountable owner for each compute resource, including cloud accounts, clusters and on-premises hardware.
- Recording criteria: Define the fields you will keep, such as location, capacity, hosting model and dependencies, and whether capacity and environmental footprint are captured.
- Review cadence: Set how often the record is checked against actual infrastructure and who signs off changes.
- Management evidence: Keep the approvals, scope statements and change decisions that show the record is governed rather than assembled once.
Before relying on the record, confirm that a named internal owner can explain every entry and answer an auditor's questions without a partner present.
An implementation partner such as DeployOpen can prepare the systems that produce A.4.5 evidence, under a scope and deliverables agreed in writing before work starts. Typical work connects asset inventory and telemetry sources, such as GLPI for asset records, Wazuh system inventory for endpoint detail, and Prometheus or Grafana for capacity signals, then documents how the evidence is produced. The partner builds and explains the pipeline; your team still decides what the record means.
- Inventory integration: Connect asset and system inventory sources so compute resources can be listed and reconciled.
- Telemetry setup: Configure metrics and alerting that show utilization and capacity over time, where the scope includes them.
- Evidence documentation: Write runbooks that explain where each field comes from, how it is refreshed and who reviews it.
- Hardening and backup: Secure the tooling that holds the record and back up its data as part of the agreed scope.
- Knowledge transfer: Hand over configurations, documentation and training so your staff can operate the system after delivery.
When you request a quote, ask the partner to state in writing which tasks it performs, which it does not, and who holds administrative access to the tooling after handover.
An independent auditor, assessor or certification body tests the A.4.5 record and any surrounding management system, and only it can issue a report or certificate. The auditor samples entries, compares the record with infrastructure evidence, and asks how the organization decides what is recorded and how changes are approved. A partner that helped build the record cannot perform that assessment or sign off its results, because that would remove the independence the assessment depends on.
- Sampling: The auditor selects AI systems and checks whether their compute resources appear accurately in the record.
- Cross-checking: The auditor compares record entries with inventory and telemetry exports to confirm they match.
- Governance review: The auditor examines approvals, scope statements and review records that show the record is maintained.
- Certification decisions: Only the certification body decides whether the management system meets the requirements and issues any certificate.
- Independence: Keep the implementation partner separate from the assessment team, and confirm that the certification body is accredited for the scope it covers.
Before engaging any assessor, confirm its accreditation status and its conflict-of-interest rules with the certification body directly, and check the current guidance from ISO on certification.
Where A.4.5 records usually fall short and how to close each gap
A.4.5 records tend to fail in predictable places: they sit apart from the AI system inventory, they stop at training, or they go stale after the infrastructure changes. Each card below names one gap, the evidence an assessor will ask for, and the fix that produces it.
Resource records not linked to the inventory
A compute record that lists clusters and instances but does not name the AI systems running on them cannot show which resources a given system depends on. Assessors often start from the AI system inventory and trace downward. Link each system entry to its training, inference and hosting resources by identifier, and confirm that both records share the same asset names. Check that a sample system can be traced in both directions within a few minutes.
Provider capacity with no exported record
GPU and cloud capacity held by a provider often exists only in the console or the invoice. An assessor needs a record that shows instance types, regions, accelerator counts and the workloads placed on them. Ask the provider or your platform team for a scheduled export of inventory and resource configuration, store it with the resource record, and confirm that the export still reflects reserved capacity that is not in active use.
Training compute recorded, inference missing
Many teams document the hardware used to train a model and nothing about the infrastructure that serves it. Production inference, batch scoring and hosting dependencies (load balancers, vector stores, logging pipelines) carry the operational risk the standard cares about. Extend the record to every life cycle stage, listing the serving environment separately from the training environment, with its owner and location.
Environmental footprint not recorded
A.4.5 guidance links system and computing resources to environmental impact, and the NIST crosswalk maps this to an assessment of the sustainability of model training and management. Where no footprint figure exists, the record has a gap an assessor will notice. Start by recording energy or compute hours per training run and the region where it ran, then document how those figures were estimated and what the organization decided to do with them.
Stale records after infrastructure changes
Records drift when clusters are resized, models move to new hardware or a region is retired, and nobody updates the document. A dated record with no change history invites questions about whether it reflects the environment that produced the evidence. Tie record updates to change management tickets, and collect host and workload inventories on a fixed schedule so the record can be compared with what actually runs.
Unclear ownership between platform and AI teams
Platform engineers usually own the clusters, while AI teams own the models that run on them. When neither team owns the record, it falls between them and nobody answers the assessor's questions. Assign one named owner for each resource entry, with the platform team responsible for capacity data and the AI team responsible for the systems that consume it, and write both responsibilities into the resource record.
Questions buyers ask about A.4.5 cost, effort and outside help
How much effort does A.4.5 take for a small team?
For a small team, the effort is mostly the one-time work of building a complete inventory of the compute, hosting and network resources behind each AI system, then keeping that record current. The volume depends on how many environments exist, whether training runs on rented GPU capacity or owned hardware, and how many AI systems share the same infrastructure. A team with one hosted model, a single cloud account and documented deployments has far less to record than a team running separate training, staging and inference clusters across several providers. Ask any partner to estimate effort from the written list of systems and environments in scope, not from a generic template.
Can we document A.4.5 in-house without a consultant?
Yes, a capable internal team can document A.4.5 without outside help, because the control asks for a clear record of the system and computing resources an AI system relies on, not a specialist technique. The work is usually owned by platform engineering, with input from security and the AI product owners. Outside help tends to add value where the records are scattered across cloud consoles, asset tools and spreadsheets, or where someone needs to prepare evidence for an assessor. Whichever route you choose, the organization keeps ownership of its controls and the record itself.
What must our organization supply before an engagement starts?
The organization must supply the access and the knowledge that only it holds. In practice this means:
- A list of the AI systems in scope and the environments each one uses, such as development, training, staging and production.
- Read access to cloud accounts, data center inventories, or air-gapped network records that show compute and hosting resources.
- Named owners for each system who can confirm what runs where and what changed recently.
- Existing policies, change records and any inventory data already held in asset or monitoring tools.
Without these inputs, any scope and timeline is unreliable. Confirm the list of inputs in writing before the work is quoted.
How long does A.4.5 documentation take to complete?
The duration depends on scope: the number of AI systems, environments, providers and existing records to reconcile. DeployOpen's timeline follows the written scope, which is agreed before work starts. Ask for a schedule that lists each deliverable, the inputs it depends on and the points where your team must review or approve. A schedule that does not name dependencies on your staff or on access approvals is unlikely to hold. Separately, ask your certification body or auditor when they expect the records, because assessment timing can set the real deadline.
Is recording the environmental footprint mandatory for every AI system?
A.4.5 asks you to document system and computing resources, and the implementation guidance for this control references environmental impact and sustainability of model training and management. Whether an environmental footprint record is needed for every system is a question to settle with your own risk assessment and the scope statement you submit under clause 6.1.3. For a low-impact system with modest compute, a short, justified exclusion may be defensible, but the reasoning must be documented. Confirm the position with your certification body, since interpretation can vary between assessors.
What should we ask a partner to include in a quote?
A useful quote states the scope in writing and separates the work into deliverables. Ask it to name the AI systems and environments covered, the resource record format, the tools used to collect inventory data, and the evidence each deliverable produces. It should list what the organization must provide, who approves the final record, and whether ongoing updates are included or handled as a retainer. Also ask what the partner will not do: a partner that prepares evidence does not issue audit reports or certificates, and only an independent auditor or certification body does that. Compare quotes on the same written scope, not on headline totals.
How DeployOpen prepares A.4.5 resource records for assessment
DeployOpen works on A.4.5 System and computing resources as part of a fixed-scope engagement inside the client's own infrastructure. The organization keeps ownership of the control and its record, while DeployOpen prepares the systems, inventories and evidence an independent auditor will review.
How we scope
- The written scope lists which AI systems, environments and compute platforms the resource record for A.4.5 must cover.
- Scope defines training, inference, hosting and supporting infrastructure, with the owner of each resource named in writing.
- Deliverables, timelines and responsibilities are agreed before work starts, so the client knows what it must supply.
How we build
- Asset inventory is configured in GLPI so hardware, software, network equipment and racks are recorded against each AI system.
- Endpoint system inventory is collected with Wazuh Syscollector to capture operating systems, installed software and running services.
- Capacity and utilization metrics are gathered with Prometheus and alerted on in Grafana so the record reflects how resources are used.
How we hand over
- The client receives the system and computing resource record, with the data sources, owners and review dates documented.
- Handover includes a runbook explaining how each dashboard, inventory and alert rule is maintained and exported as evidence.
- Environmental footprint fields are documented where the client can source them, with gaps listed for the client to confirm.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can keep the resource record current as hardware, cloud accounts and AI workloads change.
- Questions about the independent assessment itself go to the auditor or certification body, which issues any report or certificate.
