Asset and service inventory: knowing what you actually run

An organisation cannot judge how much protection a component needs until it can say what it runs. The documented answer is the system component inventory: the record of the discrete, identifiable assets — hardware, software and firmware — making up each system, required by SP 800-53r5 control CM-8 with four properties, an accountability field and a review frequency. This sheet asks what that record must contain, what keeps it true, and where a list stops being coverage.

Two records, two questions

SP 800-53r5 keeps two inventories apart. PM-5, SYSTEM INVENTORY, requires an “inventory of organizational systems” kept current at a defined frequency, and its discussion draws the line: “System inventory refers to an organization-wide inventory of systems, not system components as described in CM-8” (lines 13787, 13792). CM-8 works one level down, inside each system. CSF 2.0 names a wider set in the same family — “Inventories of hardware managed by the organization are maintained” (ID.AM-01), “Inventories of software, services, and systems managed by the organization are maintained” (ID.AM-02, lines 871–873). “Asset and service inventory” is the programme covering both levels; CM-8 is the record one system must produce.

What CM-8 requires the record to contain

CM-8 asks for an inventory that accurately reflects the system, includes all components within it, adds no duplicate accounting, and is “at the level of granularity deemed necessary for tracking and reporting” (lines 7806–7818). Its fifth property is what makes the record a governance artefact rather than an asset list: the organisation-defined information needed to “achieve system component accountability” (line 7820), narrowed by CM-8(4) to identifying “individuals responsible and accountable for administering those components” (lines 7918–7919). The discussion sketches that content — “the system name, software owners, software version numbers, hardware inventory specifications, software license information” and, for networked components, “the machine names and network addresses” (lines 7831–7834). The list is a default, not a schema: which fields a record carries is a decision to make and write down.

PM-5   organisation-wide   inventory of organizational systems

CM-8   one system          inventory of its components  (hardware, software, firmware)
         |- a.1-a.4  accurate, complete, no duplicate accounting, granularity for tracking
         |- a.5      accountability information -- who administers it (CM-8(4))
         \- b        review and update at a defined frequency, plus CM-8(1)'s triggers

       each component sits inside one system, therefore inside one authorisation boundary (SP 800-128)

Granularity is a decision, and it has a price

SP 800-128 treats granularity as deliberate: “one organization may track a workstation (with all peripherals) as a single component while another may document each peripheral as a separate component in the inventory” (lines 1193–1195). Fine granularity buys tracking and costs upkeep; coarse granularity is cheap and hides what a later decision needs. A component cannot sit in two records — “the authority over and responsibility for each component is with only one system owner (i.e., every item in the component inventory falls within the authorization boundary of a single system)” (lines 1197–1199) — because ownership and system association are then unknown (lines 7838–7839).

Keeping the record true

CM-8(b) requires review and update at an organisation-defined frequency, and CM-8(1) puts a trigger under it: “Update the inventory of system components as part of component installations, removals, and system updates” (line 7858). The discussion explains why the trigger matters: without it, “there is a greater likelihood that the information will not be appropriately captured and documented” (lines 7863–7864). CM-8(2) then asks for automated mechanisms to “Maintain the currency, completeness, accuracy, and availability of the inventory of system components” (lines 7872–7873).

Who keeps it true

The duty is assigned, not assumed. SP 800-137 lists “establishing and maintaining an inventory of components associated with the information system” among the information system owner’s continuous-monitoring responsibilities (line 957), and treats the record’s accuracy as itself observed: inventory information “is used to determine compliance with CM-8” and assessed “to determine whether or not the control is effective, (i.e., if the inventory is accurate)”, with an inaccurate inventory triggering a root-cause analysis and a response by “responsible parties” (lines 535–542). Which role carries the duty is a sibling sheet’s question; here the duty has a holder, a trigger and a check.

Why “we have a spreadsheet” is not coverage

A spreadsheet is a container; an inventory is a record with properties that can be checked. Each requirement fails recognisably: the record is never reviewed and no installation triggers an update (CM-8 b, CM-8(1)); a component belongs to no system at all, where CM-8(9) warns that it “may be unmanaged, lack the required protection, and become an organizational vulnerability” (lines 7978–7979); or nobody is named as its administrator, which is the field CM-8 a.5 and CM-8(4) exist to carry. The tool is not the evidence; the properties are.

Where the coverage stops

The sources state the limits. Automation has a documented blind spot — “virtual machines can be difficult to monitor because such machines are not visible to the network when not in use” (lines 7876–7877) — and so has scanning, where systems implementing several network protocols “can result in duplicate components being identified in different address spaces” (lines 7846–7848). Accuracy is also defended: CM-8(3) requires finding “the presence of unauthorized hardware, software, and firmware components within the system” and acting — disable network access, isolate, or notify defined personnel or roles (lines 7892–7898).

Level and prerequisites

L2 — operational: what a component record must contain, how it stays true, and where its coverage ends. It assumes the L1 vocabulary of assets, services and ownership (the L1 sheets on assets and dependencies, and on asset ownership). The roles behind the accountability field, prioritisation and the asset’s life stages each belong to a sibling sheet.

Where to go next

Knowledge — the index.
Cybersecurity Governance — the area this sheet belongs to.
Security governance foundations — this sheet’s node.

References

NIST — SP 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations (September 2020) — https://doi.org/10.6028/NIST.SP.800-53r5 — the PM-5 separation of a systems inventory from a component inventory; the CM-8 statement (the four properties, the accountability information, the review frequency); the definition of system components and the default accountability information; the duplicate-accounting, protocol-scanning and granularity discussion; and controls CM-8(1), CM-8(2), CM-8(3), CM-8(4) and CM-8(9).
NIST — SP 800-128, Guide for Security-Focused Configuration Management of Information Systems (August 2011) — https://doi.org/10.6028/NIST.SP.800-128 — §2.3.4: the component inventory, granularity as a deliberate organisational choice, and the rule that every item falls inside the authorisation boundary of a single system.
NIST — SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations (September 2011) — https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-137.pdf — the information system owner’s duty to establish and maintain the component inventory, and the assessment of inventory accuracy with its root-cause follow-up.
NIST — The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 (26 February 2024) — https://doi.org/10.6028/NIST.CSWP.29 — the ID.AM Asset Management category and the inventory subcategories ID.AM-01 and ID.AM-02.