ID.AM-04: Inventories of services provided by suppliers are maintained

ID.AM-04 requires you to maintain an inventory of the services your suppliers (third parties) provide, tied to your environment and decision-making. Operationalize it by defining what counts as a “supplier service,” centralizing a service register, mapping each service to owners/data/access, and proving updates happen as onboarding, changes, and offboarding occur ¹.

Key takeaways:

• Maintain a living, centralized inventory of supplier-provided services, not just a vendor list ¹.
• Record the details auditors care about: what the service is, where it connects, what data it touches, who owns it, and criticality ¹.
• Make updates event-driven (new service/change/offboard) and evidenced with tickets, approvals, and periodic attestations ¹.

The id.am-04: inventories of services provided by suppliers are maintained requirement is an asset management control aimed at one operational outcome: you can name and scope the supplier services that run your business, and you can show the list stays current ¹. Most organizations already track third parties for procurement and accounts payable, but that dataset rarely answers security and resilience questions such as: Which supplier-hosted services process regulated data? Which services have privileged access into production? Which supplier integrations create an outage blast radius?

ID.AM-04 closes that gap by shifting the unit of record from “supplier” to “service provided by the supplier” ¹. A single supplier may provide multiple services with different risk, data types, hosting models, and connectivity patterns. Examiners and internal audit teams typically get stuck on “prove completeness” and “prove freshness.” This page gives you a requirement-level implementation approach that is fast to stand up, defensible in audit, and easy to keep running.

Requirement: ID.AM-04 supplier service inventories (what it means)

Plain-English interpretation: Maintain an accurate, accessible inventory (a service register) of the services your suppliers provide to your organization, and keep it current as services are added, changed, or removed ¹. The inventory needs enough detail to support scoping, risk assessment, incident response, and continuity planning, not just naming the supplier.

Why operators care: Without a supplier service inventory, you cannot reliably:

• scope third-party risk assessments to the actual service in use,
• identify which supplier services touch sensitive data or production systems,
• prioritize monitoring and contract controls,
• execute incident response when a supplier is breached,
• understand concentration risk across critical business services ¹.

Regulatory text

Excerpt (framework requirement): “Inventories of services provided by suppliers are maintained” ².

Operator interpretation: You must (1) define your inventory standard, (2) maintain the inventory in a controlled system of record, (3) ensure it is updated on real operational triggers (onboarding, change, renewal, offboarding), and (4) retain evidence that the process operates consistently ¹.

Who it applies to

Entities: Any organization running a cybersecurity program that relies on third parties to deliver technology, business processes, or operational services ¹.

Operational contexts where ID.AM-04 becomes non-optional:

• SaaS and cloud services used for core workflows (HRIS, CRM, ERP, ticketing, finance).
• Managed service providers (MSPs/MSSPs), hosting providers, data processors, call centers.
• Embedded services and integrations (payment processors, identity providers, analytics tags).
• Contractors with network access, code access, or access to regulated data ¹.

What you actually need to do (step-by-step)

Step 1: Set the scope and definitions (fast, written, enforceable)

Create a one-page standard that answers:

• What is a “supplier service”? Example definition: any externally provided service that stores, processes, transmits, or can affect availability/integrity of organizational data or systems.
• What is out of scope? Example: one-time purchases with no ongoing service component (unless they include support access).
• What is the “system of record”? Pick one tool (GRC platform, CMDB, or a controlled spreadsheet with change control) and name it.
• Who owns the control? Assign a control owner in Security/GRC and data stewards in Procurement/IT.

Evidence target: approved standard or procedure with owner and review cadence ¹.

Step 2: Build the minimum viable supplier service register (start simple, but don’t stay shallow)

Create a register with fields that drive action. Minimum recommended fields:

Field	Why it matters in audit/response
Supplier legal name + service name	Prevents “one vendor = one record” confusion
Business owner + technical owner	Establishes accountability
Service description + intended use	Ties the service to business purpose
Data types handled (high level)	Drives privacy/security requirements
System connections/integrations	Defines pathways for compromise/outage
Access level (none/user/admin/API)	Determines control rigor
Hosting model (SaaS/IaaS/on-prem/managed)	Impacts shared responsibility
Criticality tier (e.g., critical/high/medium/low)	Enables prioritization
Contract status + renewal date	Drives re-assessment workflow
Subprocessors/4th parties (if known)	Supports supply chain visibility
Evidence links	Lets you prove the register is real

Keep field definitions in a data dictionary so different teams classify consistently.

Step 3: Populate the register using multiple “systems of truth” (completeness)

Do not rely on Procurement alone. Build the initial inventory by reconciling:

• Accounts payable vendor list
• SSO/IdP application catalog (SAML/OIDC apps)
• CASB/SSE or browser discovery (if you have it)
• Firewall/proxy logs for major SaaS domains
• IT service management catalog (requests/changes)
• Cloud accounts: marketplace subscriptions and IAM trust relationships
• Security tools: EDR exclusions, allowlists, API tokens, webhook destinations

Operational tip: track your sources in a “coverage” column (e.g., “AP + SSO + ITSM”) to explain why you believe the inventory is complete enough for its purpose ¹.

Step 4: Tie updates to lifecycle triggers (make it hard to bypass)

Implement three required triggers:

1. New supplier service onboarding

• Require the service to be entered in the register before go-live.
• Gate approvals: security review, privacy review (if data), architecture review (if integration).
• Assign owners and criticality before production credentials are issued.

2. Change management

• Update the register when any of these change: data types, hosting region, subprocessors, integrations, privileged access model, or business criticality.
• Use your ITSM change ticket to enforce “inventory update completed” as a closure condition.

3. Offboarding

• Mark service status (retired), termination date, data return/destruction confirmation, and access revocation.
• Keep historical records; don’t delete entries. Auditors often ask for proof you knew what existed at a prior point in time.

Step 5: Establish a recurring operating rhythm (prove it stays maintained)

Set an operational cycle that produces evidence:

• Periodic owner attestation: business and technical owners confirm records are accurate for their services.
• Renewal-driven review: tie contract renewals to record verification and risk re-assessment.
• Exception handling: define what happens if a team uses an unregistered service (temporary exception, remediation date, escalation path).

Daydream note (earned mention): Daydream can act as the workflow layer that links onboarding questionnaires, service records, control ownership, and recurring evidence requests so the register stays “maintained” without manual chasing.

Required evidence and artifacts to retain

Retain artifacts that prove design and ongoing operation:

Design evidence

• Supplier service inventory procedure/standard with definitions, scope, roles ¹.
• Data dictionary for required inventory fields.
• RACI showing control owner, procurement/IT/security responsibilities.

Operating evidence

• The supplier service register export (current snapshot) and prior snapshots or change history.
• Onboarding tickets showing inventory entry completed before approval.
• Change tickets with inventory updates and approvals attached.
• Offboarding tickets showing termination steps and record status updates.
• Periodic attestation records (emails, forms, workflow logs).
• Sample mapping of services to risk assessments and contract controls (proves the inventory is actually used).

Common exam/audit questions and hangups

1. “Show me your inventory of supplier services.” Auditors will reject an AP vendor list if it doesn’t identify the service and how it connects.
2. “How do you know it’s complete?” Expect to explain your source reconciliation approach and how you detect new services.
3. “How do you keep it current?” They will ask for evidence of updates tied to onboarding/change/offboarding.
4. “Who is accountable for accuracy?” If “Security owns everything,” the control often fails in practice. You need business/technical owners per service.
5. “Which supplier services are critical and why?” Criticality needs a definition, not gut feel.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Inventory equals vendor master. Fix: make “service” the record, supplier the attribute. One supplier can have multiple service entries.
• Mistake: No integration context. Fix: require a minimal connectivity note (SSO, API, VPN, data feed) for each service.
• Mistake: “Annual review” with no event triggers. Fix: lifecycle triggers in procurement and ITSM so updates happen when reality changes.
• Mistake: Unknown shadow SaaS. Fix: use SSO app catalogs and finance exports to spot unregistered services and force registration.
• Mistake: No evidence trail. Fix: store links to tickets, contracts, and assessments inside each inventory record.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement. Practically, failure modes show up as:

• missed scoping of third-party incidents (you don’t know which supplier services touch impacted systems),
• incomplete third-party risk assessments (assessed the supplier generally, not the specific service),
• contract gaps (missing audit rights, breach notification, subprocessors),
• operational outages with unclear dependency mapping ¹.

These translate into higher impact from supplier breaches and longer recovery times because teams lose time rebuilding basic facts during an incident.

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Name the control owner and approve the supplier service inventory standard ¹.
• Choose the system of record and build the register template with required fields.
• Pull initial candidate lists from AP and SSO/IdP app catalog; create service records for the top business-critical tools first.
• Implement an onboarding gate: no new supplier service goes live without a register entry.

Days 31–60 (prove completeness and embed workflows)

• Reconcile additional sources (ITSM catalog, cloud marketplace subscriptions, security tool integration lists).
• Add criticality tiers and data type labels across all inventoried services.
• Build change/offboarding triggers into ITSM workflows (closure requires inventory update).
• Run the first owner attestation and capture evidence.

Days 61–90 (make it durable and audit-ready)

• Link each critical supplier service to a current risk assessment and key contract controls.
• Document how you detect new services (finance + SSO + procurement intake).
• Create a monthly exception report for unregistered services and track remediation.
• Produce an “audit packet”: procedure, RACI, latest register export, and sample tickets showing updates across the lifecycle.

Frequently Asked Questions

Does ID.AM-04 require an inventory of suppliers or an inventory of services?

Services. You can list suppliers, but ID.AM-04 expects you to maintain an inventory of the services suppliers provide, with enough detail to manage cyber risk ¹.

What’s the minimum data I should capture per supplier service?

Capture service name, supplier, business and technical owners, data types, integration/access method, criticality, and contract/renewal info. If you can’t answer “what does it touch and who owns it,” the record is too thin.

How do I handle a supplier that provides multiple products (for example, HR plus payroll)?

Create separate service records for each distinct service with its own data types, integrations, and criticality. Keep one supplier profile, but do not force multiple services into a single record.

Are subcontractors and subprocessors part of the inventory?

ID.AM-04 focuses on services provided by suppliers; capturing known subprocessors strengthens the record because it improves supply chain visibility. Add them where you have contractual disclosure, and track gaps as part of due diligence ¹.

We have hundreds of SaaS tools. How do we start without boiling the ocean?

Start with services that are business-critical, have privileged access, or handle sensitive data. Then expand coverage by reconciling SSO and finance records to find the long tail.

What do auditors accept as proof the inventory is “maintained”?

They look for evidence of ongoing updates: onboarding and change tickets that show inventory updates, periodic owner attestations, and a controlled change history or snapshots of the register over time.

Footnotes

1. NIST CSWP 29

2. NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes