A legacy system inventory record should hold the owner, what the system does, its software and versions, support status and end date, every connection in and out, the data it handles, the controls compensating for gaps, and a review date. Without those fields, exceptions cannot be managed.
Start from the control language
NIST's system component inventory control asks for an inventory that accurately reflects the system, includes all components, avoids duplicate accounting, is at a useful level of granularity, and records information needed for accountability. Its guidance mentions items such as system name, software owners, software version numbers and hardware specifications. It also asks that the inventory be reviewed and updated.
For legacy systems, a few more fields earn their place because they drive decisions.
The fields
| Field | Why it matters |
|---|---|
| System name and purpose | Lets non-technical reviewers understand the stakes |
| Business owner and technical owner | Someone must answer when a review date arrives |
| Operating system, runtime and key libraries with versions | Matches the system to advisories |
| Vendor support status and end date | Starts the clock for replacement or isolation |
| Network location and segment | Shows whether isolation exists |
| Inbound and outbound connections | The attack surface and the blast radius |
| Administrative access path | Jump host, console, vendor access |
| Data handled and its sensitivity | Sets how urgent everything else is |
| Known vulnerabilities and exception reference | Links the record to the decisions made |
| Compensating controls and evidence date | Shows what is protecting it now |
| Last review and next review | Keeps the record honest |
| Retirement plan reference | Points to the exit |
Where the data comes from
- Network scans and traffic logs find systems that nobody remembered to list.
- Software bills of materials list libraries for systems that were built from code you can analyse.
- Vendor notices give support dates.
- Interviews with the owner give purpose, data and connections. Do not skip this, since tools cannot see why a system exists.
Keep the record alive
An inventory that was right at creation drifts. Tie updates to events: a firewall change request, a new vendor access request, an incident, and the scheduled review. Remove entries when systems are retired, and record the date.
Common mistakes
- Listing the server but not the integrations. Most attacks travel along connections.
- Recording "owner: IT". A team is not an owner.
- Storing the inventory in a spreadsheet no one else can find.
- Treating support end as a footnote instead of a trigger.
Try it yourself
Click through it at your own pace, or open it full screen. Step through it to see how a dependency inventory is built from a project.
Where Safeguard fits
Safeguard's asset discovery helps find systems missing from the list, and SBOM and dependency scanning can fill in the software components for those you build. Run a free scan at gold.safeguard.sh/scan.
Quick check
How often should the inventory be reviewed?
Set it by risk. A legacy system holding sensitive data deserves a shorter cycle than a retired lab box. The NIST control asks for review at a defined frequency, which you choose.
Do devices without software, like sensors, belong in it?
Yes if they connect to your network. Record firmware version, owner and connections.
Sources
- NIST SP 800-53 Rev 5 control catalog (OSCAL JSON, NIST oscal-content repository) (CM-8 System Component Inventory)
Last reviewed: 19 October 2026.
