ID.AM-04 Supplier services inventory: requirements and evidence

What ID.AM-04 supplier services inventory asks for in NIST CSF 2.0

ID.AM-04 asks the organization to keep a current inventory of the external services it uses, including IaaS, PaaS, SaaS and APIs, and to update that inventory before a new external service is put into use. It is a Subcategory of the Asset Management (ID.AM) Category in the IDENTIFY Function of NIST CSF 2.0, and it carries forward CSF 1.1 ID.AM-4 under the same identifier. When an audit request, a customer questionnaire or a board member asks which outside providers hold company data, this inventory is the first document that should answer. NIST's Implementation Examples for the Subcategory name IaaS, PaaS and SaaS offerings, APIs and other externally hosted applications, so the scope is wider than the cloud contracts procurement tracks.

The risk behind the Subcategory is that the organization cannot say who holds its data or who can reach its systems through a third party. Shadow SaaS is the usual cause: a team signs up for a project tool or an AI writing service with a corporate email address and no contract review. API keys stored in source code, CI pipelines or configuration files create a second gap, because a service can be connected to internal systems without anyone recording it as a supplier. Procurement, IT and the business units each buy services, and in many organizations none of them owns the complete list. Confirm with your finance team whether expense and card data can surface unapproved subscriptions, and with your engineering leads which secrets and integration credentials exist outside the approved vault.

A practical first step is to assign one owner for the inventory, usually the function that already runs asset records, and to define the minimum fields each entry needs: the service, its type, the business owner, the data classes it touches, the integration method and the contract or review date. Then add an approval gate so that a new external service is recorded before the first user or integration goes live. The NIST Small Business Quick-Start Guide, SP 1300, cites ID.AM-04 as part of its advice to create and maintain an inventory of hardware, software, systems and services, which gives smaller teams a workable starting point. The inventory is only as good as its discovery method, so ask which sources, such as identity provider logs, expense data and network records, your team will use to find services no one reported.

Which external services and teams fall inside ID.AM-04 scope

ID.AM-04 asks for an inventory of the external services an organization uses, and the hardest part is deciding what counts as one. The cards below cover the scoping decisions that most change the size of the inventory, and the ones to settle in writing before the first pass.

IaaS and PaaS accounts

Cloud accounts, subscriptions and projects are the starting point, because each one can host workloads, storage and managed databases that the organization depends on. Record every account, including sandbox and development accounts, along with the owning team and the services enabled in each. Ask whether accounts created by engineers outside central procurement are visible to the inventory owner. Those accounts are often where the gaps sit.

SaaS bought on corporate cards

Business units often buy software-as-a-service tools with corporate cards or expense claims, which bypasses the procurement records that most inventories rely on. Finance card statements, expense exports and single sign-on application lists are useful cross-checks. Decide who reviews these sources and how often, and treat each newly discovered tool as an inventory entry rather than a one-off finding.

APIs consumed by internal applications

Internal applications frequently call external APIs for payments, identity checks, mapping, messaging or data enrichment. These calls rarely appear in procurement records, yet they create data flows and dependencies. Record the provider, the endpoint domains, the data sent and the credentials used. Confirm with application owners that the list reflects code in production, not only the architecture diagram.

Externally hosted applications

Some applications run on a provider's infrastructure under the organization's domain or branding, or are operated by a vendor on the organization's behalf. These are easy to miss because the organization may not hold the servers. Inventory the application, the hosting provider, the region where data is stored and the contractual owner. Confirm which party patches the application and who receives its alerts.

Services held by MSPs

Managed service providers may hold administrative accounts, monitoring platforms, backup services or remote management tools on the organization's behalf. The services exist in the organization's environment even when the organization did not buy them directly. Ask the provider for a list of the tools and third-party services it uses in your environment, and confirm that the inventory records both the provider and the underlying services.

Free tiers and trials

Whether free tiers, trials and open-source hosted services count is the decision that most changes the workload. Services used for production data, credentials or customer communication should be inventoried regardless of price. Set a written rule for low-risk tools, such as a trial with no data, so that the inventory stays manageable and the exceptions are documented and reviewed.

How an assessor tests the supplier services inventory

This table sets out each step an assessor takes to test ID.AM-04, what evidence each step produces, and where inventories usually fail. Read it as a sequence: the request and sampling steps establish whether the inventory is complete, and the trigger and mapping steps establish whether it stays current.

Test step	What the assessor checks	Evidence that passes and common findings
Request the inventory	Obtain the current list of external services, its owner, date of last update and the scope it covers	Dated register with named owner. Finding: no owner, or a spreadsheet last changed long ago
Sample from procurement and expense records	Compare services bought through purchase orders, contracts and card spend against the inventory	Every sampled paid service appears in the register. Finding: services paid by corporate card or by individual teams are absent
Sample from network and identity logs	Check egress, DNS, proxy and single sign-on logs for external services in use and compare them to the register	Observed services match registered entries. Finding: shadow SaaS and unsanctioned APIs seen in logs but not in the inventory
Check the update trigger	Confirm a documented step requires adding a service before it is used, such as an intake form or approval workflow	Procedure and sample of recent onboarding records. Finding: no update trigger, so entries are added after use or never
Check coverage of the Implementation Examples	Confirm the register includes IaaS, PaaS, SaaS, APIs and other externally hosted applications	Each category has entries or a documented reason for none. Finding: APIs and externally hosted applications omitted
Check for stale entries	Test whether listed services are still in use and whether decommissioned services were removed	Recent review records and disposal evidence. Finding: retired services still listed, or contract ended without an update
Map to informative references (illustrative)	Review how the register supports SP 800-53 AC-20, SA-9 and SR-2 and ISO/IEC 27001 Annex A 5.22, as listed in the Reference Tool	Mappings are informative only. The assessor tests the outcome, not the mapping itself. Confirm the mapping in the Reference Tool before citing it

Building an external services inventory step by step

This sequence turns scattered records of supplier services into one maintained register, with an owner, a business owner and a data classification for each service, and a gate that records new services before anyone starts using them.

Name an accountable owner for the register
Assign one person, usually in IT operations, security or a GRC function, to own the external services inventory and its update process. Name a deputy so updates continue during absences. Write the scope down: which external services count (IaaS, PaaS, SaaS, APIs and other externally hosted applications), which business units must report, and which systems are excluded and why. The step is done when the owner and scope appear in a signed-off document that the register's sources can be traced back to.
Pull candidate services from identity and application sources
Export the application catalog from your identity provider, including single sign-on applications and OAuth grants that users have approved. These records show many SaaS tools that never went through procurement. Add the list of enterprise applications and third-party integrations from your collaboration and developer platforms. The output is a raw list per source, with the source name, export date and the fields each record contains, so the next step can compare them.
Reconcile against finance, procurement and cloud billing
Extract supplier payments, contracts, purchase orders and subscription invoices from finance and procurement systems. Pull the service lists from each cloud billing account, since these show IaaS and PaaS consumption that may never appear in a purchase request. Match each billing line to a service name and a business unit. Records with no match are flagged for follow-up, not discarded. The output is a list of services that have a financial or contractual trail, with the unmatched items marked.
Discover unsanctioned services from network evidence
Review DNS query logs and egress or proxy logs to find destinations that internal systems contact but that are absent from the first two sources. Also review API gateway and API management records for external endpoints your applications call or expose. Group the results by domain and by the internal host that makes the calls. Confirm each candidate with the people who use it, because a domain alone does not show who owns the service. The output is a list of discovered external services with the evidence that revealed each one.
Consolidate into a single register
Merge the lists from the earlier steps into one register. Use a unique identifier for each service and record which sources confirmed it, so duplicates across sources collapse into one entry. Capture the service type (IaaS, PaaS, SaaS or API), the hosting location where known, and the contract or subscription reference. Store the register in a controlled system with access limited to the owner and approved editors. The output is one register where every entry has an identifier and at least one source, and a count of entries that still lack a business owner.
Assign a business owner and data classification
For each service, record the business owner who accepts its use and answers for its purpose, and the data classification of the most sensitive information that the service stores, processes or transmits. Use the classification scheme your organization already applies to data. Where a service has no identifiable owner, escalate it to the register owner and treat it as an open risk until someone accepts it. The output is a register in which every service has a named business owner and a classification, with open items listed for decision.
Add an approval gate before new services are used
Require that any new external service is recorded in the register and approved before users or systems start to use it. Connect this gate to purchasing, to the single sign-on approval workflow and to the change process for new API integrations, so that the request arrives through a channel where the register owner can see it. The gate does not need to be slow. Its purpose is that the register is updated before use, which is the expectation in the outcome and its Implementation Examples. The output is a documented intake procedure and a log of approvals, with the date each service was recorded.
Schedule reviews and confirm the register stays current
Set a recurring review of the register, with the frequency agreed by the owner and recorded in the procedure. Each review compares the register with the current identity provider catalog, billing accounts and log-based discoveries, then removes retired services and adds newly found ones. Ask a second person to test a sample of entries against the source systems. Confirm the register also appears as an input to supplier risk assessments and to incident response contact lists. The output is a dated review record and a list of changes made during the review.

Evidence that passes an ID.AM-04 review

ID.AM-04 asks whether the inventory of external services is current, so an assessor looks for proof that the inventory was complete and updated at the moment of adoption. The artifacts below show the inventory from several angles: the record itself, the intake process, independent discovery, financial records, owner confirmation and removal decisions. Each one should be dated and retained so the set can be compared against the others.

Dated inventory export

A point-in-time export of the supplier services register, showing each service's name, type (IaaS, PaaS, SaaS or API), hosting location, business owner, data categories processed and contract reference. Assessors compare the export date against the date of their sample, so the export must be generated from the system of record and carry a timestamp. Confirm that every field is populated for each entry and that the export covers all business units, not only IT. Keep one export per review period so changes can be traced over time.

Intake and procurement workflow records

The intake ticket or procurement approval that shows a new external service was added to the inventory before it went live. This is the direct evidence for the Implementation Example that calls for updating the inventory before a new external service is used. Check that the approval timestamp precedes the first production use or the first contract signature, whichever the organization treats as adoption. Sample recent purchases, including those made on corporate cards or by teams outside IT.

Discovery scan outputs

Results from network, DNS, proxy, identity provider or cloud account scans that identify external services in use, compared against the inventory. Discovery tells the assessor whether the inventory is complete, since a register built only from contracts misses services adopted informally. Keep the scan scope, date and configuration with each output so the review can test coverage. Unmatched results should be logged as findings with an owner and a resolution date, not silently removed.

Finance and inventory reconciliation

A periodic comparison between supplier payments, subscription charges and cloud billing lines and the entries in the inventory. Unpaid-looking services, such as free tiers or API keys billed to another account, often surface here. Record each unmatched charge, the investigation outcome and the inventory change it triggered. Ask finance to confirm which cost centers and card programs feed the reconciliation, because gaps usually sit in the programs that finance does not see by default.

Owner attestations

Signed or recorded confirmations from each named service owner that the entry is accurate, the data categories are correct and the service is still in use. Attestations give accountability to the inventory and create a dated record the organization can cite. Set a recurring attestation cycle and send reminders through the workflow tool, then retain each response with the export it confirmed. An attestation that is not answered is an open item, and assessors will ask what happened to it.

Change tickets for removed services

Tickets that record decommissioning of an external service, including the data return or deletion confirmation, access revocation, and the inventory update. Removal evidence matters because a register that only grows becomes unreliable and holds dormant services with live credentials. Link each ticket to the original intake record so the full lifecycle can be followed. Confirm with the owner that exit steps for stored data were completed before the entry is marked retired.

What an external services inventory costs to build and keep current

This table breaks down the cost components of building and maintaining an ID.AM-04 supplier services inventory, showing who is paid for each, whether it is one-time or recurring, and what drives it up. No fee figures are given because none are supplied, so use the drivers to shape a written quote. Open-source options are shown where they can reduce license spend.

Cost component	Who is paid or who spends time	One-time or recurring	What drives the cost
Discovery tooling or licenses	Software vendor or open-source project; internal team for hosting	Licenses recur; open-source tools carry no license fee but still need hosting and upkeep	Number of cloud accounts, SaaS tenants and API endpoints to discover; confirm whether a platform is licensed per asset
Register setup in a self-hosted GRC or asset tool	Implementation partner or internal platform engineers	One-time for schema, fields and integrations; recurring for maintenance	Number of business units, the depth of fields per service (owner, data types, contract, region) and approval workflows
Engineering time to integrate sources	Internal engineers or an implementation partner under a written scope	One-time per source, plus recurring effort when APIs or accounts change	Count of cloud accounts, identity providers, procurement systems and expense exports feeding the inventory
Procurement process change	Procurement, legal and security teams	One-time to add an inventory step to intake; recurring as each new service passes through it	Volume of new service requests and whether purchases happen outside central procurement (shadow SaaS)
Owner time for attestation	Named service owners in each business unit	Recurring, typically at each review cycle and when a new service is adopted	Number of owned services per person and how often owners change; confirm the review interval in your own policy
Independent review	Internal audit or an independent assessor, not the implementation partner	Recurring per assessment cycle	Scope of the sample tested, number of services and whether the review covers contracts and data location
Maintenance of network and host visibility	Internal operations team; GLPI and Wazuh are open-source with no license fee	Recurring for hosting, upgrades and agent deployment	Number of endpoints and servers running agents, and how many discovered SaaS or IaaS items must be matched to owners

Open-source tools that support the ID.AM-04 inventory

ID.AM-04 asks for a current record of the external services an organization uses. Open-source platforms can hold that record and produce evidence from it, but each covers a different part of the estate. The cards below show what each tool records, what it can prove for an assessor and where the gaps remain.

GLPI Assets as the service register

GLPI's Assets module manages computers, monitors, software, network equipment, peripherals, printers, phones and racks. It is the natural place to hold a register of supplier-provided services, with each entry linked to an owner, a contract and the systems that depend on it. Entries can be typed in manually or pushed by the GLPI Agent through native inventory, which has been built into GLPI since version 10. Ask whether your team will record external services as assets or in a separate item type, and who signs off when a new service is adopted.

Wazuh Syscollector for endpoint software

The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups from each endpoint. It stores this in the Wazuh indexer, where it appears in inventory views and reports. For ID.AM-04, this shows which externally facing or cloud client software is installed and which services are listening, so it can be compared with the register. It does not see services that are used only through a browser or an API key, so treat its output as one input to the register, not the whole register.

Reconciling the two inventories

An assessor will ask how the register stays complete, not only whether it exists. Compare GLPI records with Wazuh inventory on a set schedule and flag software or open ports with no matching service entry. Record the date of each comparison, who reviewed the differences and how each gap was closed. This reconciliation is the evidence that the inventory is kept current, which is the outcome ID.AM-04 describes. Ask your team to define the schedule and the trigger for an unscheduled comparison, such as a new contract.

SaaS and API discovery limits

Neither GLPI nor Wazuh discovers SaaS accounts or API integrations on its own. A user can sign up for a cloud tool on a laptop without any endpoint agent recording it, and an API connection may live entirely in a application configuration. Before relying on either tool for ID.AM-04, confirm which integration options exist for SaaS and API discovery in your environment, such as identity provider logs, expense or procurement records, or cloud account inventories. Document the source you use for each discovery channel.

What the evidence shows an assessor

For ID.AM-04, keep exports of the GLPI service register with timestamps, Wazuh inventory reports for the endpoints in scope, the reconciliation records and the approval trail for each newly adopted service. Together these show what external services exist, who owns them and when the record changed. Note that the organization owns the control and the evidence. An implementation partner can configure these tools and prepare the evidence, but only an independent auditor or assessor issues any report on the result.

Who owns the inventory and who can help build it

Your organization owns the ID.AM-04 outcome. Someone inside the business must be accountable for keeping the list of external services current, because only the organization knows which teams have signed contracts, which SaaS tools were approved and which APIs production systems depend on. The inventory is a living record of decisions your people make, so it cannot be delegated to a vendor in a way that removes internal accountability.

Named owner: Assign one accountable role, usually in security or IT governance, with deputies in procurement and each business unit.
Approval gate: Require sign-off from the owner before a new external service is used, which is the point the NIST Implementation Examples describe.
Vendor records: Keep contract, data location, business owner and renewal details for each entry in the register.
Shadow IT follow-up: Reconcile expense reports, identity provider application lists and network egress data against the register.
Periodic review: Set a review cadence that your policies define and record each review as evidence.

Confirm with your own policy owners who signs off the register and where the vendor records are stored.

Where supplier services inventories usually fail

A supplier services inventory under ID.AM-04 rarely fails because nobody wrote one. It fails because services enter the organization through channels the inventory never sees, and nothing removes them when they leave. The gaps below share one root cause: the inventory depends on someone remembering to add or remove a service, rather than on a trigger tied to how services are bought, built and retired.

SaaS bought outside procurement

Teams often sign up for SaaS tools with a corporate card or a free trial that later converts to a paid plan. These services hold business data but never pass through a contract review, so the inventory has no record of them. To check, compare card and expense statements against the inventory for software vendors, and ask department heads to name tools they use that IT has not approved. Action: add a standing expense-category review to the inventory update process.

APIs in code without records

Developers frequently connect applications to external APIs for payments, messaging, mapping or data enrichment. These integrations live in source code and configuration files, so an inventory built from procurement or asset records misses them entirely. Search repositories, service configuration and secrets stores for external endpoints, then record each provider, the data sent and the owning team. Action: require a new inventory entry as part of any merge that adds an external endpoint.

Inventory updated only at annual review

Many organizations refresh their service list once a year, which means a service adopted in February may go unrecorded until the next review. ID.AM-04 expects the inventory to be updated before a new external service is used, so an annual cycle leaves most of the year uncovered. Ask when each service was first recorded compared with its first use date. Action: tie inventory updates to the approval step that precedes first use, not to the calendar.

No link between contracts and services

Contracts often name a vendor but not the specific services, environments or data covered, so the inventory and the contract register describe different things. When a contract renews or ends, no one can say which services it governs or which must be removed. Confirm that each inventory entry references a contract or order form ID and that each contract lists the services it covers. Action: make the contract reference a required field before an entry can be saved.

MSP-managed services missing

Managed service providers often run hosting, backups, monitoring and SaaS administration on the organization's behalf. The services exist in the environment, yet the organization may see only the provider's invoice, not the individual platforms behind it. Ask each MSP to deliver a list of every external service it operates for you, including the tenants and accounts used, and reconcile that list monthly. Action: write the service list delivery into the MSP agreement.

Expired services still listed

Services that were retired, cancelled or migrated often stay in the inventory because removal is never triggered. Stale entries hide real exposure, since accounts, API keys and data copies may still exist at the provider after the business relationship ends. Compare active billing, identity provider application lists and API key inventories against the inventory, and confirm that each removed service has closed accounts and revoked credentials. Action: make offboarding a required step in the service retirement checklist.

Questions buyers ask about ID.AM-04 inventories

Does NIST certify that an organization complies with ID.AM-04?

No. NIST does not certify organizations, products or services against the Cybersecurity Framework, and it has no plans to create a conformity assessment program. The CSF is voluntary for most organizations, although some customers and suppliers require it contractually. An organization that maintains a supplier services inventory can say it is aligned to ID.AM-04, but no body issues a NIST certificate for that alignment. If a customer asks for proof, the usual evidence is the inventory itself, its update records and an independent assessment report from a qualified assessor. The organization owns that conclusion, and an implementation partner can prepare the inventory and evidence but cannot issue an attestation.

How long does it take to build a supplier services inventory?

The duration depends on how many external services the organization already uses and how well they are documented. No fixed timeline applies to every organization, so ask for one based on your own environment. The main drivers are the number of business units that buy cloud and SaaS services, whether procurement records and identity provider logs can be used as starting points, how many APIs and externally hosted applications need to be traced to an owner, and how quickly teams can confirm which services are still in use. Engagements are usually fixed-scope, so the timeline should appear in a written scope agreed before work starts, with deliverables listed separately.

What does the client team need to provide for the inventory?

The client team needs to supply access and knowledge, not only time. Typically this includes read access to cloud accounts, identity and single sign-on logs, expense and procurement records, and the contract register where it exists. Business owners must confirm which services their teams use and who is accountable for each one. Security and IT staff should approve the fields to record, such as service name, provider, data categories handled, integration method, and owner. A named decision-maker is also needed to resolve disputes about shadow services. Ask the implementation partner to list these inputs in the written scope so the organization can assign people before work begins.

Can we build a supplier services inventory in-house?

Yes, many organizations do. The NIST implementation examples describe the content to inventory: IaaS, PaaS and SaaS offerings, APIs, and other externally hosted applications, with the inventory updated before a new external service is used. An internal team with access to finance, identity and cloud data can build a first version. The harder parts are usually discovering services bought outside IT, keeping ownership current as staff change, and wiring the inventory into procurement approval so updates happen on time. Organizations that lack staff time or cross-department authority often bring in outside help for discovery and process design, while keeping ownership of the register and its approvals.

How often should the supplier services inventory be updated?

ID.AM-04 requires the inventory to be updated when a new external service is adopted, and the NIST implementation examples say the update should happen before the service is used. That makes adoption the trigger, not a calendar cycle. Most organizations also run a periodic review to catch services that were adopted without approval, to remove retired services, and to confirm owners are still in post. The review cadence is an internal decision, so set it in your own governance documents. Connecting the inventory to purchase approvals and identity provisioning gives the strongest evidence that updates happen on time.

Which parts of a supplier services inventory should we outsource?

Organizations often outsource the parts that need specialist tooling or fresh eyes. Common examples are discovery of external services from logs and cloud configurations, designing the data fields and ownership model, and testing whether the inventory matches reality through sampling. The organization should keep the approval of the final register, the decisions about which services are acceptable, and responsibility for supplier risk. Implementation partners such as DeployOpen can plan, deploy and document a self-hosted system that holds the inventory, and can prepare evidence for an assessment. They do not issue audit reports or certificates, and independent auditors perform that role. Ask for a written scope that separates each deliverable from the organization's own responsibilities.

Which tools can hold the inventory and record the evidence?

Two self-hosted open-source platforms are relevant to the inventory. GLPI's Assets module manages computers, software, network equipment, phones and other items, and it can record entries manually or receive data from the GLPI Agent, which is built into GLPI from version 10. Wazuh's Syscollector module collects software, services and other endpoint details, which helps verify what is installed, but it does not record which external SaaS or API services the business has adopted. For those, the inventory usually needs a contract or procurement register linked to the asset records. Confirm each tool's fit for your environment and licensing terms before choosing, and review the GLPI and Wazuh documentation directly.

How DeployOpen prepares an ID.AM-04 inventory for assessment

DeployOpen's part in an ID.AM-04 inventory starts with a written, fixed scope that names the external services in play, the systems that will hold the register, and the people who approve each entry. The organization keeps ownership of its supplier relationships and of the inventory itself. DeployOpen plans the register structure, agrees the fields it must hold (service name, type such as IaaS, PaaS, SaaS or API, business owner, data categories handled, contract reference, and review date), and records the decisions in the scope document before any integration work begins. DeployOpen does not issue audit reports, attestations or certifications, and it does not publish prices. A quote follows from the agreed scope, so the more precisely the organization defines its services and sources, the more precisely the quote can be built.

Where the client wants self-hosted tooling, DeployOpen integrates it inside the client's own infrastructure, whether that is their cloud accounts, data center or air-gapped network. For ID.AM-04 this usually means deciding which tool holds the supplier record. GLPI's Assets module can hold service and contract records alongside its hardware and software records, and Wazuh's Syscollector covers installed software and running services on endpoints, which helps detect services that were adopted without a register entry. Neither tool discovers every external SaaS or API use on its own, so the scope should name the additional sources, such as procurement records, identity provider application lists and cloud billing exports, that feed the register. The client should confirm each tool's current capabilities in its own environment before relying on them.