ID.AM-02: Inventories of software, services, and systems managed by the organization are maintained

To meet the id.am-02: inventories of software, services, and systems managed by the organization are maintained requirement, you must keep a current, owned, and reviewable inventory of the systems you run, the software you deploy, and the services you operate (including third-party and cloud services you administer). Operationalize it by defining scope, assigning an owner, standardizing required fields, automating feeds where possible, and producing recurring evidence of updates and review ¹.

Key takeaways:

• Maintain three connected inventories: systems, software, and services, with clear ownership and update triggers ¹.
• Auditors will test completeness and currency, not just whether a spreadsheet exists; tie inventory updates to change workflows.
• Keep evidence of how the inventory is built, updated, and reviewed, plus point-in-time exports that prove operation over time.

ID.AM-02 sits in the “Identify” function of NIST CSF and is a requirement-level expectation: you cannot secure, patch, monitor, or decommission what you cannot name. For a CCO or GRC lead, the fastest path to a defensible position is to treat asset inventory as a governed record, not a one-time discovery project. That means you define what “managed by the organization” includes, specify minimum attributes, and make updates routine through IT workflows rather than quarterly scrambles.

This requirement also has a practical boundary that trips teams up: it covers software, services, and systems you manage. “Services” includes cloud services and externally hosted platforms where your organization configures security settings, manages identities, or handles sensitive data. You do not need perfect discovery on day one, but you do need a credible operating model: a system of record, accountable owners, defined update triggers, and evidence that reviews happen.

Use this page as an implementation checklist. It focuses on what to build, what to keep as evidence, and what examiners typically challenge, mapped directly to the ID.AM-02 requirement language ².

Regulatory text

Requirement (excerpt): “Inventories of software, services, and systems managed by the organization are maintained” ¹.

Operator interpretation: You must maintain an inventory that is (1) complete for in-scope assets, (2) current enough to support security operations, and (3) governed (ownership, review cadence, and change control). “Maintained” implies an ongoing process: updates, reconciliation, and reviewable evidence, not a static list ¹.

Plain-English interpretation (what this means in practice)

Maintain a living catalog of:

• Systems: endpoints, servers, network devices, virtual machines, containers, OT/IoT where applicable, and key network/security infrastructure you administer.
• Software: installed applications, server packages, agents, firmware where you control deployment, and internally developed applications in production.
• Services: SaaS, PaaS, IaaS accounts/subscriptions, managed services, and externally hosted platforms where you manage configuration, identities, integrations, or data.

The inventory must answer, quickly and consistently:

1. What is it?
2. Who owns it?
3. Where does it run / who hosts it?
4. What data does it touch?
5. What is the security operational posture (patching, logging, access)?

Who it applies to (entity and operational context)

Applies to: Any organization operating a cybersecurity program aligned to NIST CSF 2.0, including regulated and non-regulated organizations that adopt CSF for governance ¹.

Operational contexts where ID.AM-02 becomes high-friction:

• Hybrid environments (on-prem + multiple clouds).
• Rapid SaaS adoption with decentralized purchasing.
• M&A or business unit autonomy (multiple IT stacks).
• Heavy third-party operational dependence (managed IT, managed security, outsourced app hosting).

Scope boundary to decide and document: “Managed by the organization” should include assets you administer directly and assets administered by a third party on your behalf, when you still own the risk and must govern configuration and access.

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

Step 1: Set scope and definitions (write them down)

Create a one-page scoping statement that defines:

• What counts as a system, software, and service in your environment.
• What “managed” means (admin access, configuration responsibility, identity control, data stewardship).
• In-scope environments (prod, corp IT, dev/test, OT if applicable). This document becomes an audit anchor for why the inventory looks the way it does ¹.

Step 2: Assign ownership and a system of record

Decide the “source of truth” for each inventory domain:

• Systems: CMDB or endpoint management platform export.
• Software: software asset management (SAM) tool, EDR inventory, or package manager reporting.
• Services: SSO catalog, CASB/SSE inventory, cloud account/subscription registry, procurement/TPRM list.

Assign:

• Control owner (accountable for the requirement).
• Data stewards for each domain (responsible for updates and reconciliation).
• Approvers (for periodic review and exceptions).

Step 3: Define minimum required fields (make it enforceable)

Use a required-field standard so every record is actionable. Minimum fields that hold up in exams:

Systems inventory (minimum fields)

• Unique asset ID
• Hostname/resource name
• Environment (prod/non-prod)
• Location (cloud region/site)
• Owner (business + technical)
• Asset type (server, endpoint, network, container host, etc.)
• Criticality tier (your internal scale)
• Authentication authority (domain/IdP)
• Logging/monitoring status (yes/no + tool)

Software inventory (minimum fields)

• Software name
• Version/build (where feasible)
• Install location/host association
• Owner/team
• License/support status (where relevant)
• Deployment mechanism (MDM, package manager, golden image)

Services inventory (minimum fields)

• Service name
• Service category (SaaS/PaaS/IaaS/managed service)
• Tenant/account/subscription identifier
• Business owner and technical admin group
• Data classification handled
• User auth method (SSO/local)
• Key integrations (API connections)
• Logging availability and status

Do not aim for perfection. Aim for a consistent minimum that supports risk decisions.

Step 4: Build reliable intake and update triggers (avoid “spreadsheet rot”)

“Maintained” means updates happen because operations force them. Implement triggers such as:

• Procurement intake: new software/service cannot be purchased without creating an inventory record and assigning an owner.
• Change management: new systems and major changes require updating system inventory fields (owner, environment, logging, criticality).
• Joiner/mover/leaver: new SaaS/service onboarding must be tied to SSO group creation and recorded in the services inventory.
• Decommissioning: change tickets require marking assets as retired with a retirement date and data disposition note.

Map each trigger to a workflow artifact (ticket type, form, approval step). This is the operational backbone auditors look for.

Step 5: Reconcile for completeness (sampling beats guessing)

Run periodic reconciliation between independent sources, for example:

• Endpoint manager vs. EDR vs. directory for corporate endpoints.
• Cloud asset inventory vs. IaC repositories vs. billing accounts.
• SSO application list vs. procurement records vs. CASB discoveries.

Document your reconciliation method and keep the outputs. Even if gaps exist, a repeatable reconciliation process demonstrates “maintained.”

Step 6: Establish review cadence and exception handling

Set a review schedule that fits your change rate (monthly for fast-changing environments, quarterly for stable). During review:

• Confirm owners for crown-jewel systems and critical services.
• Identify stale records (no updates, unknown owner).
• Track exceptions (legacy systems, unmanaged subsidiaries) with remediation plans.

Step 7: Map to policy, procedure, and recurring evidence collection

Tie ID.AM-02 to:

• A written standard (inventory requirements and minimum fields).
• A procedure (how updates happen and who does them).
• A control owner and an evidence calendar (exports, review sign-offs, reconciliation outputs) ².

Where Daydream fits naturally: Daydream helps you turn this requirement into a control with an owner, mapped procedures, and scheduled evidence collection so you can produce point-in-time exports and review attestations on demand, without rebuilding the story during audits.

Required evidence and artifacts to retain

Keep evidence that proves the inventory exists and is maintained over time:

1. Inventory standard / policy (scope definitions, minimum fields, ownership model).
2. Procedures and workflows (procurement intake, change management triggers, decommission workflow).
3. Current inventory exports for systems, software, and services (dated).
4. Historical point-in-time snapshots (demonstrate ongoing maintenance).
5. Reconciliation reports (source comparisons, gap lists, remediation tickets).
6. Review sign-offs (meeting notes, approvals, attestations, or GRC task completion).
7. Exception register (known gaps, compensating controls, remediation owners).

Common exam/audit questions and hangups

Expect examiners/auditors to ask:

• “Show me your authoritative inventory for systems/software/services and explain how it stays current.”
• “How do you ensure new SaaS is captured before sensitive data is introduced?”
• “Who can approve a new service, and where is that approval recorded?”
• “How do you identify and remove unauthorized software or shadow IT services?”
• “Prove maintenance: show exports from multiple points in time and the review evidence.”

Hangups:

• Inventory exists but lacks ownership fields, so risk remediation stalls.
• Cloud services are missing because teams treat “asset inventory” as only hardware.
• Multiple conflicting inventories exist with no system of record.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating CMDB as “done,” even when it’s stale.
   Fix: Define freshness criteria and reconcile against operational tools (EDR, cloud inventory, SSO).

2. Mistake: Leaving “services” out of scope.
   Fix: Build a services register anchored to SSO, procurement, and cloud accounts.

3. Mistake: No decommission workflow.
   Fix: Require retirement updates in change tickets; keep a retired status with dates.

4. Mistake: Inventory fields are optional.
   Fix: Make minimum fields mandatory for production systems and high-risk services; enforce via ticket forms.

5. Mistake: Evidence is accidental.
   Fix: Schedule recurring exports and review tasks; store them in an audit-ready repository.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Still, inventory failures regularly create downstream control failures: unmanaged assets evade patching, logging, vulnerability scanning, access reviews, and incident containment. From a governance perspective, ID.AM-02 is a “dependency control” for large parts of a security program ¹.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Publish scope definitions for systems, software, and services managed by the organization.
• Assign a control owner and data stewards.
• Select system(s) of record for each inventory domain.
• Define minimum required fields and create templates.
• Produce baseline exports for all three inventories and store them as evidence ¹.

Next 60 days (wire into operations)

• Add procurement and change-management triggers that require inventory updates.
• Implement a services intake path tied to SSO onboarding.
• Start reconciliation between at least two sources per domain (example: EDR vs endpoint manager; SSO vs procurement).
• Run the first formal review and capture sign-off artifacts.

Next 90 days (prove maintenance and close gaps)

• Reduce “unknown owner” and “unknown data classification” records through targeted campaigns.
• Build exception handling with remediation tickets and due dates.
• Establish recurring evidence collection (scheduled exports, recurring review tasks).
• Prepare an audit packet: scope statement, procedures, latest exports, prior exports, reconciliation output, and review attestations.

Frequently Asked Questions

Do I need one inventory or three separate inventories?

You need coverage for software, services, and systems; that can be one integrated CMDB or separate registers. Auditors care that you can produce accurate lists and show how they are maintained ¹.

What does “services managed by the organization” include?

Include SaaS/PaaS/IaaS and managed services where your organization administers configuration, identities, integrations, or data. If a third party operates it but you remain accountable for security outcomes, keep it in scope.

How current does the inventory need to be?

NIST CSF doesn’t prescribe a specific update interval in the provided excerpt, so define “freshness” based on your change rate and risk. Then prove you meet your own standard with recurring exports and review records ¹.

We have shadow IT. Can we still pass an audit on ID.AM-02?

Yes, if you can show a maintained process to discover, triage, and either onboard or block unauthorized services. Keep reconciliation outputs (SSO, CASB/SSE, procurement) and remediation tickets as evidence.

What’s the minimum evidence an auditor will accept?

A written scope/standard, current inventories, and proof of maintenance over time (prior snapshots plus review sign-offs). Add workflow artifacts that show inventory updates are embedded in procurement/change processes.

How do I handle subsidiaries or partially integrated acquisitions?

Put them in scope explicitly as exceptions with boundaries (what is known, what is not, and why), assign an owner, and track a remediation plan. Auditors are less tolerant of “we don’t know” than “we know the gap and have a plan.”

Footnotes

1. NIST CSWP 29

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