The systems inventory: local machines are the easy half
Almost every security requirement contains a hidden dependency: the list of systems it applies to. A control can be implemented well, verified regularly, and still leave the organization exposed, because the verification ran against an inventory that was missing something. That makes the inventory worth treating as a deliverable in its own right, rather than as a spreadsheet someone assembles the week before an assessment.
The half that tooling solves
Workstations and servers are comparatively tractable, because the tool that configures them can usually enumerate them. An organization running centralized configuration management—the Unix-oriented tools or their Windows equivalents—can demonstrate that a setting is enforced across the estate and produce the list of machines it was enforced on.
The valuable output of that tool is not the list of managed machines. It is the difference between that list and reality: the laboratory system nobody enrolled, the contractor's laptop, the server stood up for a project that ended two years ago, the machine that has not checked in for months. Those gaps are findable, because the organization owns the network the machines sit on and the directory they authenticate against.
Finding that difference means holding several lists against each other, because each is built from a different vantage point. Configuration management knows what it manages. DHCP logs know what asked for an address, which includes everything the configuration tool never heard of. The vulnerability management system knows what it scanned. A network scan or switch tables know what is actually connected. And the inventory records what the organization believes it has.
In practice those lists rarely agree. That is not by itself alarming: a machine built this week may legitimately appear in some and not yet in others, and those short-term differences resolve as normal onboarding catches up. The signal worth acting on is duration. A system that has appeared in the DHCP logs and the scanner for months, and has never appeared in the inventory, is not a timing artifact. It is a system nobody is accounting for, and it has been running that way long enough for the omission to be the normal state.
Reconciling the lists periodically, and asking about anything that persists in one and not another, turns four partial pictures into something close to a complete one.
Access control at the network layer narrows the problem from the other direction. A small network can require that only known hardware addresses be permitted to connect, which is administratively simple at that scale and makes an unknown device conspicuous. Larger networks need something more robust than a list of hardware addresses, which are straightforward to observe and impersonate; the usual answer is port-based network access control to the IEEE 802.1X standard, authenticating the device or its user before the port carries traffic.
Straightforward is not the same as free. It still takes a decision about who owns enrollment and what happens when something appears unmanaged. But the mechanism exists, and the answer is knowable.
The layer below the machine
Most inventories stop at the machine and its installed applications. One level below that sits software the organization rarely counts and frequently cannot list at all: the extensions loaded into browsers, code editors, and office suites.
They deserve counting because they behave like separate systems. An extension has its own vendor, its own update channel that usually operates automatically and without review, its own permissions, and often its own network connections. A browser extension permitted to read and change data on every site can see everything the person using it sees. An editor extension can read an entire source tree, execute code, and talk to a remote service, and it is typically installed by a developer in a few seconds because it looked useful. Office add-ins sit in the same position with respect to documents, as do plugins in engineering and laboratory applications.
The practical consequence is that an inventory can be accurate about every machine and still be unable to answer what has access to the source code or the contract files. Browser extensions can be enumerated through managed browser policy. Editor extensions are harder, because they live in per-user directories rather than in the system package manager, so this usually means pointing the endpoint software inventory at those locations deliberately.
An organization that has never looked will find the answer surprising, which is the ordinary reason to look.
The half that tooling does not solve
The harder half is the systems the organization pays for and does not run.
Consider three that most organizations have. The outsourced HR platform holds employee records, and the payroll and benefits data around them. The learning management system tracks role-based training completion—which is to say, it holds the evidence for a control the organization has almost certainly committed to somewhere. The external design validation service that a handful of engineers use may hold the most sensitive technical material the company owns.
What those three have in common is more instructive than what they do. None appears in a configuration management console. Each may or may not authenticate through the corporate identity provider. And in each case the department that bought it thinks of it as a subscription rather than as a system, which is exactly why it does not appear on a list of systems.
How much IT knows varies, and the variation is the point. IT was probably consulted about the HR platform, since it had to be connected to something. It may have been consulted about the learning management system. It may know nothing at all about the service the engineers use, which was very likely bought on a card, approved by a manager who saw a reasonable business expense, and never described to anyone as a system.
That last case is shadow IT, and it is not a discipline problem. It is what happens when people who have work to do find a tool that does it faster than the procurement process moves. The organization still owns the consequences.
The design validation service is the instructive one. It is likely the smallest line item of the three, used by the fewest people, purchased with the least ceremony—and holding the material a competitor or a foreign intelligence service would most want.
Finding what was never registered
The methods that surface unregistered systems are the same ones that surface unregistered AI use: expense and corporate-card records, identity provider application lists, web proxy and DNS records, contract and renewal files, and conversations with departments about the work they are actually trying to get done.
No single source is complete. Purchasing records miss anything free. Identity provider records miss anything with its own local accounts, which tends to be the systems that matter most for authentication questions. Network records show that a service was reached, not what was sent to it.
What a record needs to carry
Organizations working to a standard do not have to invent this list. NIST SP 800-53 CM-8 requires an inventory that accurately reflects the system, includes all components within it, avoids double-counting components assigned to another system, sits at a granularity sufficient for tracking and reporting, and carries whatever information the organization defines as necessary for component accountability. The accountability information named in the guidance is concrete: the system name; software owners, version numbers, and license information; hardware inventory specifications; and for anything networked, machine names and addresses across every protocol in use. The inventory specifications are themselves enumerated—date of receipt, cost, model, serial number, manufacturer, supplier information, component type, and physical location.
NIST SP 800-171 states the same expectation more briefly, and where it states it moved between revisions. In Revision 2 the inventory is folded into 3.4.1 alongside baseline configuration, covering hardware, software, firmware, and documentation across the system life cycle. Revision 3 promotes it to its own requirement, 03.04.10, which asks the organization to develop and document the inventory, review and update it at a defined frequency, and update it as part of installations, removals, and system updates. The mapping is to CM-8 and CM-8(1).
Those requirements are written for components the organization runs, which is part of why the outsourced half falls through. Externally provided services sit under SA-9 instead, where the obligation is to require providers to meet the organization's requirements, define oversight roles, and monitor compliance on an ongoing basis. An organization that reads its inventory obligation narrowly can satisfy CM-8 completely and still have no record of the service holding its most sensitive data.
Working from that base, each entry is more useful carrying:
- the operating system and version, which drives nearly every configuration and patching question asked later;
- the installed software, or a reliable pointer to the configuration management system that holds it, which is usually the better answer since a static list is wrong within a week;
- the business owner, who is usually not in IT;
- what data the system holds, and whether that puts it in scope for a specific obligation;
- what happens if it is unavailable, and for how long that is tolerable. This is the field that turns an inventory into something a risk assessment and an incident responder can both use, and it varies enormously between entries that otherwise look alike. A virtualization host carrying thirty workloads takes all thirty with it. A replicated DNS server with a secondary already answering queries may not be missed until the second one fails. Recording the judgment once is far better than forming it under pressure;
- how people authenticate to it, and whether the provider supports the authentication the organization's policy requires;
- who has administrative access, including at the provider;
- the contract, its renewal date, and what security terms it contains;
- when the entry was last confirmed, and by whom.
The authentication column is where inventories earn their cost. A requirement for phishing-resistant multifactor authentication is a claim about a set of systems, and it can only be as accurate as that set. A provider that does not support it, or supports it only on a subscription tier the organization did not buy, is a gap worth finding during selection rather than during an assessment.
What an assessor does with it
An assessment usually opens with a request for the inventory: either a copy, or read-only access to wherever the organization maintains it. The second is better for everyone. An assessor who takes a copy is now holding customer data and has to protect it, retain it, and dispose of it; an assessor who is given a read-only account is looking at the live record and holding nothing. Read-only access is not always possible, and a copy is a normal outcome, but an organization that can offer the account has made the engagement simpler.
What happens next is the part organizations tend not to anticipate. The inventory is not checked off and set aside. It drives the rest of the assessment: which people get interviewed, which systems get sampled, and what evidence gets requested.
An example. If the inventory shows both Windows and Linux systems, an assessor asking about a configuration control cannot sample only Windows machines and call the control met. Meeting it on one platform says nothing about the other, so the sample has to cover both, and the evidence has to come from systems of each type. The same reasoning applies to any split the inventory reveals: laptops against servers, on-premises against cloud, employee accounts against contractor accounts.
This is the difference between evidence that is adequate and evidence that is sufficient. A single screenshot may adequately show that a setting exists somewhere. Whether it is sufficient depends on how much of the scope it covers, and the inventory is what determines the scope.
A thin inventory therefore costs more than it appears to. It does not reduce the assessment; it moves the work into the assessment, where the organization is paying for the time and where an incomplete answer looks like an incomplete program.
Keeping it true
An inventory is accurate on the day it is built and decays from there. Subscriptions renew automatically, staff leave holding the only knowledge of a tool, departments adopt something new between reviews, and providers change what they offer.
Tying confirmation to events that already happen helps more than scheduling yet another review: contract renewals, budget cycles, onboarding and departures, and the annual policy review. The measure of a good inventory is not that it was complete when written. It is how quickly the organization would notice that it no longer is.
Kenneth Ingham Consulting helps organizations establish scope and inventory as part of readiness work, which is usually where the surprises turn up.