ID.AM-02 software inventory: NIST CSF 2.0 evidence guide

What ID.AM-02 asks for and why a software inventory is hard to keep current

ID.AM-02 asks the organization to keep current inventories of the software, services and systems it manages. When an auditor or customer asks how you know which software and services run in your environment, this Subcategory is the question behind the question. The outcome is paraphrased from NIST CSWP 29, and NIST's Implementation Examples spell out what that covers: commercial, open-source and custom software, API services, cloud applications, containers and virtual machines, and a running inventory of systems. The risk is simple to state. You cannot patch, monitor, back up or retire what you have not recorded. Unknown components, unpatched services with no owner, and shadow deployments set up by a team outside IT all become blind spots that an attacker or an assessor will find first.

The work is hard because the environment moves faster than a spreadsheet. A virtual machine can be cloned and forgotten within an afternoon, a container image can be rebuilt with a new open-source dependency on every pipeline run, and a SaaS integration can be switched on by a business unit with a corporate card. Cloud accounts add their own churn, since services are created, renamed and deprecated through APIs rather than purchase orders. Open-source dependencies compound this, because a single application may pull in hundreds of libraries that nobody on the team has ever listed. A manual inventory captures a snapshot on the day it was written, which is why the Subcategory asks for currency rather than a one-time list.

Which software, services and systems belong in the ID.AM-02 inventory

ID.AM-02 asks for current inventories of the software, services and systems an organization manages. The cards below separate the scope components that most often cause disputes during assessment, and each one names the decision that changes the work. Hardware sits in ID.AM-01, and external services sit in ID.AM-04, so the boundary cards at the end show where those inventories take over.

Commercial and open-source software

Licensed products and open-source packages installed on endpoints, servers and build systems both belong in the inventory, and the two are tracked differently because open-source components often arrive as dependencies rather than installers. The scoping decision is whether a library bundled inside an application counts as a separate entry. Check that your inventory records name, version, owner and where each package runs, and that it captures transitive dependencies. Tools such as OWASP Dependency-Track consume CycloneDX SBOMs, which helps keep that list current.

Custom applications and internal code

Applications your teams build or heavily modify are in scope even when no vendor sells them, and NIST's Implementation Examples for ID.AM-02 call out custom software explicitly. The decision that changes the work is whether an internal application that a business unit runs on its own servers is recorded by the platform team or by the owner. Confirm that every custom application has a named owner, a repository, a deployment location and a list of the third-party components it depends on. An application missing from the inventory cannot be patched, monitored or retired on schedule.

APIs and cloud services

APIs your organization exposes and cloud-hosted applications it operates are both inventory items, and NIST's examples cover API services and cloud applications. The scoping decision is whether a SaaS tenant administered by a business unit, with its own billing account and no IT ownership, is in scope. The working answer is yes when the organization stores its data or grants access to it, because ownership of the account does not change the risk. Ask each business unit for a list of tenants, and reconcile that list against single sign-on and expense records.

Containers and virtual machines

NIST's Implementation Examples for ID.AM-02 describe continuously monitoring platforms, including containers and virtual machines, for changes. The decision that changes the work is whether an ephemeral container image that lives for minutes counts as a system. A workable approach is to inventory the image definitions, the clusters or hosts that run them, and the registries that store them, then record running workloads through automated discovery rather than by hand. Confirm that your scanner, such as Trivy, can produce an SBOM for each image it inspects.

Systems the organization manages

The inventory of systems covers the operating systems, platforms and services that your teams configure, patch and operate, including the agents that report them. A system is in scope when the organization is responsible for its configuration, regardless of where it runs. Automated discovery from Wazuh Syscollector can record installed software, services, users and open ports from each endpoint, which gives the inventory a verifiable source. Decide in advance who reviews discovered systems that no owner claims, because those are usually the first findings an assessor raises.

Boundaries with ID.AM-01 and ID.AM-04

Physical devices such as servers, endpoints, network equipment and IoT or OT devices are recorded under ID.AM-01, so the ID.AM-02 inventory should reference those records rather than duplicate them. External services you consume, including IaaS, PaaS, SaaS and APIs you do not operate, belong to ID.AM-04 as supplier services. Confirm where each boundary sits in your own policy, because a SaaS tenant you administer may appear in both inventories and must be linked to one owner. Overlapping lists that disagree are a common cause of assessment exceptions.

How an assessor tests the software, services and systems inventory

This table sets out five test approaches an assessor commonly uses against an ID.AM-02 inventory, the evidence each one asks for, and the gaps that most often appear. Read each row as a test the organization should be able to pass before an assessment begins, since the inventory is only as credible as the sampling behind it.

Test approach	Evidence requested	Common findings
Confirm the inventory exists and has a named owner	Current inventory export, a documented owner and update procedure, and the date of the last review	No single owner, inventory split across spreadsheets and tools, or an export that predates recent changes
Sample systems seen on the network or in cloud accounts and check they appear in the inventory	Network discovery or cloud account listings for a selected sample, matched against inventory records	Internet-facing applications or cloud subscriptions absent from the inventory, or records lacking owners and versions
Check that custom and open-source components are recorded	Records for in-house applications, APIs and open-source packages, with versions and sources, plus dependency or SBOM outputs where they exist	Custom code and open-source libraries tracked only inside repositories, with no link back to the systems that run them
Check that containers and virtual machines are covered by a discovery or change process	Discovery job configuration, image registry or hypervisor inventory exports, and records of how new workloads enter the inventory	Short-lived containers and cloned virtual machines never reconciled, so the inventory reflects only long-running hosts
Check that the inventory is updated after changes	Change tickets or deployment records showing an inventory update, and dated inventory revisions compared with recent releases	Updates happen only at annual review, or new services are deployed before any inventory entry is made

How to build an ID.AM-02 inventory in six steps

This sequence turns ID.AM-02 from a policy statement into a software, service and system inventory that is scoped, discovered, enriched, reconciled and kept current, with a named output at each stage that an assessor can sample.

Define scope and name the inventory owner
Decide which environments, business units, subsidiaries and cloud subscriptions fall inside the inventory, and state what counts as a managed software item, service or system. Name one accountable owner and the teams that maintain each source. The output is a signed scope statement that lists in-scope and excluded environments, the owner, and the reasons for any exclusions. The step is complete when the owner accepts the scope in writing and an assessor could read it and know what the inventory is meant to cover.
Enumerate sources of truth across environments
List every place where software, services and systems are created or recorded: cloud accounts and subscriptions, data center hypervisors, source code repositories, CI/CD pipelines, container registries, package managers, procurement and SaaS admin consoles, and any identity provider that lists applications. Record which source is authoritative for which asset type, since the same application often appears in several places. The output is a source register with an owner and a retrieval method for each source. Confirm with each team which systems they consider authoritative, because that answer is often different from what the documentation says.
Automate discovery for endpoints, containers and virtual machines
Deploy discovery tooling that finds software and systems without relying on manual entries. Agent-based inventory can cover endpoints and servers, while scanners can read container images, operating system packages and dependency manifests. For open-source tooling, GLPI can hold the asset register with native inventory through its agent, Wazuh Syscollector can report installed software, services and running processes from endpoints, and Trivy can list OS packages and dependencies in images and filesystems. Confirm each tool's coverage for your operating systems and container runtimes in a pilot before relying on it. The output is a discovery report per tool and run date, showing what was found and where.
Record component data for each item
For each inventory item, record the attributes an assessor and an incident team will need: owner, version, license, deployment environment, hosting location, data classification, vendor or source (commercial, open-source or custom), and the business service it supports. For custom applications and APIs, add the repository and the team that maintains them. For software with third-party components, a software bill of materials in CycloneDX or SPDX form lets tools such as OWASP Dependency-Track track components and license IDs. The output is a populated register where every item has an owner and a classification, with gaps flagged rather than left blank.
Reconcile discovered items against approved records
Compare the discovery output with the approved register and the source register from step two. Each discovered item should match an approved record, and each approved record should be found by discovery. Classify every mismatch as unauthorized, unmanaged, decommissioned but still running, or missing a field, then assign an owner and a resolution date to each. The output is a reconciliation log that lists the mismatch, the decision and the evidence that the decision was carried out. Keep the log, because it shows an assessor how the organization finds and closes gaps.
Set a review cadence and change triggers
Write down how often the inventory is reviewed and which events force an update outside that schedule: a new cloud account, a new SaaS subscription, a container image promoted to production, a major version upgrade, a new custom API, or a decommissioning request. Connect these triggers to change management and procurement so that additions are recorded when they happen, not during the next annual review. Confirm the review frequency with the inventory owner and internal audit, since no fixed interval is set by the framework. The output is a documented procedure with an approved cadence and trigger list, plus the first review record showing it was run.

Open-source tools that produce ID.AM-02 evidence

ID.AM-02 asks for inventories of software, services and systems that stays current. The four tools below each produce a different slice of that evidence: a managed asset register, runtime software inventories from endpoints, component and license records from SBOMs, and package lists from scans. None of them decides what belongs in scope or approves a system; the owner review and that decision remain the organization's.

GLPI asset register

GLPI's Assets module records computers, software, network equipment, printers, phones and racks as managed items with owners and status. Since version 10, native inventory built into GLPI and the GLPI Agent can push software and hardware data automatically, so the register is refreshed rather than typed in once. Check that each software entry has an owner, a business purpose and a retirement state, because an automated list without those fields will not show whether a system is approved. License note: GLPI is licensed under GPL-3.0-or-later, so review the terms before modifying and distributing it.

Wazuh Syscollector inventory

The Syscollector module collects installed software, operating system details, network interfaces, open ports, running services, users and groups, and Windows updates from each endpoint. The data is stored in the Wazuh indexer and shown in dashboard inventory views, which gives a runtime record that can reveal software installed outside the approved list. Confirm which agents report to the manager, since an endpoint without an agent produces no evidence. License note: Wazuh is licensed under GPL-2.0-only, which carries copyleft obligations that your legal team should assess for your deployment model.

Dependency-Track SBOM records

OWASP Dependency-Track ingests and produces CycloneDX SBOMs and VEX documents, then maps each application to its components. It flags components with known vulnerabilities, outdated or modified versions, and license risk, and it tracks license use by component using SPDX license IDs. For ID.AM-02 this supplies a versioned component inventory for custom and open-source applications, which is the evidence an assessor will ask to see for software that is not in an endpoint scan. Check that every build pipeline uploads its SBOM, because a missing upload leaves a gap in the record. License note: Dependency-Track is licensed under Apache-2.0.

Trivy package and SBOM scans

Trivy identifies OS packages and software dependencies in container images, file systems and other targets, and it can export the results as a software bill of materials. It can also scan an SBOM that was produced elsewhere, which lets teams check components they did not build. For ID.AM-02, scan output records what is deployed in containers and images at a given time, so keep dated exports with the image references they describe. Scan results show components, not ownership or approval, so pair them with your register. License note: Trivy is licensed under Apache-2.0.

Keeping the inventory current between audits

ID.AM-02 is a continuous condition, not a yearly snapshot. The outcome asks that the inventory of software, services and systems the organization manages stays current, and NIST's Implementation Examples for this Subcategory call for continuously monitoring platforms, including containers and virtual machines, for changes. An inventory that is accurate on the day of an assessment but drifts for the rest of the year will fail the first question an assessor asks about a system that appeared in March. The practical question for the security or platform lead is therefore not whether the inventory exists, but which events are guaranteed to reach it. Start by writing down the events that create or change a system, then assign each one an owner and a record that proves it was captured.

The change triggers that matter most are usually the ones teams do not route through a ticket. A new cloud account or subscription, a new SaaS application bought on a corporate card, a rebuilt container image that pulls in different packages, and an emergency deployment made outside the normal change window all add or alter components without going through procurement. Each trigger needs a detection path: cloud organization or account listings compared against the inventory, identity provider application registrations, container registry and cluster inventories, and a standing rule that emergency changes are recorded within the same working cycle. Open-source inventory tools such as GLPI, Wazuh Syscollector, OWASP Dependency-Track and Trivy can supply part of this evidence, but you should confirm which of these sources your own environment actually feeds before relying on them.

A reviewer confirms that a previously unknown system was added by sampling it in both directions. Starting from an item found in a discovery feed, cloud listing or scan result, the reviewer checks that a matching inventory record exists, with an owner, a purpose and a date of first capture. Starting from the inventory, the reviewer checks that a recent change record or approval explains why each new entry appeared. A gap in either direction is the finding to plan for. The review cadence for these checks is a decision you must confirm with your auditor or your own written policy, because the framework does not set one for you, and any number you adopt from a secondary source should be treated as a suggestion until it is accepted by the people who will test it.

Which evidence shows the software, services and systems inventory is current

An assessor testing ID.AM-02 looks for proof that the inventory matches reality on the day of the test and that the organization can show how it stayed current. The six artifacts below work together: the inventory and its scope define what should be listed, discovery and SBOMs show what is actually running, and the reconciliation and change records show how gaps were closed over time.

Inventory export with date and owner

The inventory export is the primary artifact: a dated extract of every software product, service and system the organization manages, with a named owner for each entry. An assessor checks that the export date falls within the audit period, that each entry has an owner and a status, and that the record counts are plausible against the scope statement. Keep a dated export on a fixed schedule, store each version, and retain prior exports so the history can be shown. Record who generated the export and from which system.

Scope statement for the inventory

The scope statement defines which software, services and systems the inventory must cover, including commercial and open-source software, custom applications, APIs, cloud services, containers and virtual machines. An assessor compares the scope against the network diagrams, cloud accounts and procurement records to find categories left out without reason. Review the scope when the organization adopts a new platform type or enters a new cloud account, and version the document with an approval date and approver.

Discovery reports from agents and cloud APIs

Discovery reports show what the inventory finds automatically, such as installed software reported by endpoint agents, running containers and virtual machines from hypervisor or orchestrator APIs, and cloud resources from provider inventory interfaces. An assessor checks that the discovery runs cover all segments in scope, that the reports are recent, and that differences from the manual inventory are explained. Schedule discovery runs, keep the raw reports for the audit period, and confirm the agent coverage percentage in your own environment.

SBOMs for custom and open-source builds

A software bill of materials lists the components inside each custom application and open-source build, so the inventory reaches below the product level. An assessor checks that SBOMs exist for in-scope builds, that they are generated from the build pipeline rather than written by hand, and that they match the version deployed. Generate an SBOM for each release, store it with the build record, and check that the format and component identifiers your tools produce are supported by the systems that consume them.

Reconciliation log of unknown systems

The reconciliation log records each discrepancy between discovery results and the inventory, such as an unknown host, an unlisted SaaS account or a service running without an owner. An assessor looks for entries that show the item was investigated, classified and either added to the inventory, decommissioned or accepted as an exception with an approver. Review open items on a regular cadence, close each entry with a reason, and keep the log so that unresolved items from earlier periods remain visible.

Change records linking deployments to inventory

Change records show that new deployments, upgrades and retirements were entered in the inventory when they happened. An assessor samples recent changes and traces each one to a matching inventory entry with the correct version, owner and status. Require each change ticket to reference the inventory identifier, and run a periodic check that closed changes have matching inventory updates. Keep the links between tickets and entries so the trace can be replayed for any sample the assessor selects.

What an ID.AM-02 inventory costs in tools, engineering time and upkeep

This table compares the main cost components of keeping a software, services and systems inventory current, who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to build a quote request, since no figures are given here and every scope differs.

Cost component	One-time or recurring	What drives it	How to keep it down
Discovery and inventory tooling	Recurring (hosting, administration); one-time setup	Number of environments, endpoints and cloud accounts to cover; whether licenses are commercial or open source. Open-source tools remove license spend but still need servers, storage and staff time.	Pick tools that match the scope already in place; ask the partner to quote hosting, backups and upgrades separately from setup
Engineering time for cloud and pipeline integration	One-time, with recurring updates when pipelines change	Number of cloud accounts, Kubernetes clusters, virtual machine images and CI/CD pipelines that must report into the inventory	Standardize tagging and naming early; integrate by platform type rather than by individual system
Owner reviews and reconciliation	Recurring	Count of owners, rate of change in software and services, and how many records lack a named owner	Assign an owner field at creation; reconcile on a fixed cadence and only for changed records
SBOM generation and dependency tracking	Recurring; one-time pipeline setup	Volume of custom code, number of third-party components, and how often builds are released	Generate SBOMs in build pipelines so each release updates automatically; scope tracking to production components first
External review or testing of the inventory	One-time per cycle, recurring if repeated	Size of the inventory, number of unmanaged or shadow systems found, and whether the reviewer samples across environments	Run an internal reconciliation before the review; ask for the sample method and deliverable format in writing
Auditor sampling time	Recurring, per assessment cycle	How many inventory records and sources the auditor samples, and how well evidence is organized with timestamps and owners	Keep exports, change logs and reconciliation records in one location; confirm with the auditor which evidence formats they accept

Who owns the inventory, who builds it and who assesses it

Your organization owns ID.AM-02. That means it decides what counts as a managed software product, service or system, names the people accountable for each entry, and sets how often the inventory is reviewed and corrected. No partner or auditor can take over these decisions, because the inventory describes your environment and your risk appetite. Ownership also covers the day-to-day work that keeps the list true after the project ends.

Scope decisions: Define which custom applications, APIs, cloud services, containers and virtual machines are in scope, and record the criteria used.
Named owners: Assign an accountable owner and a technical contact to each entry, including open-source components maintained by internal teams.
Review cadence: Set and document how often the inventory is reconciled against cloud accounts, deployment pipelines and procurement records.
Exception handling: Decide how unapproved or shadow software is reported, triaged and either onboarded or removed.
Retained records: Keep dated versions of the inventory so you can show how it changed over time.

Check that every entry has a named owner and that the review schedule is written into a procedure someone is responsible for executing.

Questions buyers ask about ID.AM-02 cost, effort and outside help

Does NIST certify ID.AM-02 or issue a conformity assessment?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. Showing that ID.AM-02 is met means producing evidence that your software, service and system inventory is kept current, and that evidence can be reviewed by a customer, an internal auditor or an independent assessor. Any certificate or report about your alignment with the CSF has to come from an independent party, not from NIST and not from an implementation partner. Ask any provider to state this in writing before you rely on a document that claims otherwise.

Can a small IT team build an ID.AM-02 inventory in-house?

Often yes, for a bounded environment. NIST's Small Business Quick-Start Guide cites ID.AM-02 when it suggests that small businesses create and maintain an inventory of their hardware, software, systems and services, so the starting point is within reach of a small team. The effort grows with the number of cloud accounts, clusters, pipelines and third-party applications that have to be covered. A team can start with a spreadsheet, then move to a tool that collects inventory automatically, such as GLPI for managed assets or Wazuh Syscollector for endpoints. Whether to do the work yourself depends on how many environments you run and whether someone owns the inventory day to day.

What does an ID.AM-02 project need from our staff?

It needs named people more than it needs tools. Plan for system owners who can confirm which applications, APIs and cloud services they run and who is accountable for each. Engineers need read access to cloud accounts, container registries, orchestration platforms and CI/CD pipelines so that discovery can run against live sources. Someone must also review the first complete inventory, resolve conflicts such as duplicate entries or unknown services, and approve the process for adding new items. Ask the implementation partner to list these roles, the hours expected from each, and the access it will request before work begins.

How long does an ID.AM-02 inventory take to set up?

Duration depends mainly on the number of environments, how many applications and services they contain, and how fast containers and virtual machines change. An illustrative case: a single cloud account with a few stable applications may need a short discovery cycle, while several accounts with frequently redeployed containers need continuous discovery plus a review process that keeps up with churn. No duration figure is supplied for this topic, so ask any partner for a timeline tied to a written scope that names each environment and the discovery method for each. Ask how the inventory will be kept current after handover, because that work recurs.

Can we outsource ID.AM-02 completely to a partner?

No. A partner can design the discovery approach, deploy and configure tools, build the inventory structure, and document the process, but the organization owns the inventory and the controls behind it. Decisions about which systems are in scope, who is accountable for each one, and how changes are approved remain with your leadership and system owners. Independent auditors or assessors then test the result. DeployOpen plans and implements self-hosted platforms inside your own infrastructure and prepares evidence for assessments, but it does not issue audit reports or certifications.

What should a fixed-scope quote for ID.AM-02 include?

A fixed-scope quote should state, in writing, the environments covered, the asset types included (software, services, APIs, cloud applications, containers and virtual machines), and the tools to be deployed in your infrastructure. It should list deliverables such as the inventory structure, discovery configuration, runbooks for keeping it current, and handover documentation. Ask who pays for licenses and hosting, what access the partner needs, which owner signs off on acceptance, and which items are one-time versus recurring. Confirm whether ongoing support, upgrades or continuous monitoring are separate retainers, and ask how changes to scope are priced before work starts.

Which open-source tools support an ID.AM-02 inventory and what do they need?

Several self-hosted tools cover different parts of the inventory. Wazuh Syscollector gathers software, services, open ports and users from each endpoint into its indexer for inventory views. OWASP Dependency-Track tracks components from CycloneDX SBOMs and reports license risk by SPDX license ID. Trivy identifies OS packages and software dependencies and can produce an SBOM. GLPI manages assets and software entries, with native inventory since version 10. Each tool needs its own hosting, access and maintenance. Confirm license terms and current capabilities against each project's documentation before you select one, because capabilities change between releases.

How DeployOpen scopes and prepares an ID.AM-02 inventory

DeployOpen works on ID.AM-02 as an implementation partner: we help you define what the software, services and systems inventory covers, build it inside your own infrastructure, and hand over documented evidence. Your organization owns the inventory and its governance, and only an independent auditor or certification body can issue an assessment result or certificate.

How we scope

Agree in writing which environments, cloud accounts, clusters and business units the inventory must cover.
Define the asset types in scope, including commercial, open-source and custom software, APIs, cloud services, containers and virtual machines.
Confirm who owns each inventory source, how often it refreshes and who reviews exceptions before work starts.

How we build

Deploy self-hosted inventory tooling such as GLPI or Wazuh Syscollector inside your own network or cloud accounts.
Configure software bill of materials generation with tools like Trivy and load CycloneDX SBOMs into OWASP Dependency-Track for component tracking.
Test that discovered records match a sample of known systems, and document gaps where agents or scans cannot reach an asset.

How we hand over

Deliver the written configuration, data sources, scan schedules and inventory ownership model as documentation your team can maintain.
Provide exported inventory reports and sample records that show how ID.AM-02 evidence is produced and reviewed over time.
Walk your engineering and compliance staff through the runbooks so updates continue after the engagement closes.

How we support

Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts.
Ongoing support, upgrades and continuous testing of the inventory platform are available as a retainer.
Ask any partner to confirm which evidence the independent assessor will accept for ID.AM-02 before the scope is signed.

ID.AM-02 Software, services and systems inventory