The asset register nobody maintains, and what to do instead
Almost every organization has an asset register. Most are a spreadsheet built during an audit, accurate on the day it was finished, and progressively less so afterwards. The problem is not effort or discipline — it is that a manual register requires every change to be recorded by hand, and nothing enforces that.
Discovery first, manual second
Anything that can be detected should be detected. Network scanning, agents, cloud provider APIs, virtualization platforms, the directory service — between them they can produce most of a register automatically and keep it current without anyone typing.
What discovery cannot give you is the part that matters most: who owns this, what business service it supports, what happens if it stops, when the support contract ends. Those are facts about the organization, not about the machine, and they have to be recorded by a person.
So the shape is: discovery maintains existence and technical detail; humans maintain ownership and purpose; and the register shows clearly which fields are which, so nobody trusts a hand-entered field that has not been touched in three years.
What is worth recording
Registers fail in both directions — too thin to be useful, or so detailed that nothing stays current. A workable middle:
- IdentityName, addresses, serial or instance identifier.
- LocationSite, rack, cloud region or account.
- OwnerA named person or team accountable for it, not a department.
- PurposeWhich business service it supports. This is the field that makes an incident triageable.
- CriticalityWhat happens if it stops.
- Lifecycle datesIn service, warranty end, support end, planned retirement.
- DependenciesWhat it needs and what needs it, at least at the service level.
Dependencies are the hardest to maintain and the most valuable during a change or an incident. Even a coarse service-level map beats nothing.
The register has to be in the workflow
A register updated in a separate system, after the fact, by someone who remembers, will drift. The fix is to make it the thing people already use:
- Provisioning writes the record, rather than a person doing it afterwards.
- The change process reads from it, so a wrong entry causes friction now instead of silently persisting.
- Monitoring and ticketing reference the same identifiers, so an alert names something the register knows.
- Decommissioning includes removal, as a step that is checked.
The last one is the most commonly skipped, and it produces the classic register full of machines that no longer exist — which is worse than a missing entry, because it makes the whole register untrustworthy.
Reconcile, then act on the gaps
Monthly, compare what discovery found against what is recorded, and treat each difference as a finding:
- Discovered but not registeredSomething was built outside the process. Worth understanding, not just recording.
- Registered but not discoveredEither decommissioned without removal, or something has stopped reporting, which is itself worth knowing.
- No ownerThe most dangerous state. An unowned system is patched by nobody and shut down by nobody.
What an accurate register is actually for
It is not a compliance artefact, although it satisfies one. Its value is in the ordinary questions that are otherwise expensive:
- Which systems are affected by this vulnerability, and who do we tell?
- What is dependent on this thing we want to change?
- What is out of support, and when does the next batch fall out?
- What is this machine for, and can we turn it off?
- What did we lose, exactly, when that site went down?
Every one of those takes days without a register and minutes with one. That is the argument for maintaining it, and it is more persuasive than the audit.
Our infrastructure managed services begin with discovery and an ownership pass, because taking responsibility for an estate that has not been inventoried means taking responsibility for an unknown quantity — and the unowned systems found in that first pass are usually the ones that later cause incidents.