Asset Registers Should Not Feel Like Archaeology

Sometimes it is in an IT platform.
Sometimes it is in a spreadsheet.
Sometimes it is in finance.
Sometimes it is in someone’s head.
Sometimes all four exist at once, disagreeing politely like a very dull murder mystery.

This is normal.

Not ideal, but normal.

But the problem is that they are often treated as storage rather than as a living operational control.

A laptop is issued, but the record is not updated.
A server is retired, but somehow remains immortal in the spreadsheet.
A SaaS platform is adopted, but nobody adds it to the inventory.
A phone is replaced, but the old one is still marked as active.
A switch exists in a cupboard, blinking away with all the quiet menace of unresolved infrastructure.

And then one day someone asks:

“Do we know what assets we actually have?”

And suddenly everyone starts looking at the floor.

Asset management is not just counting laptops

This is where asset management gets misunderstood.

People hear “asset register” and think:

• serial numbers
• purchase dates
• warranty status
• assigned users
• finance depreciation
• that one spreadsheet nobody wants to open because it has merged cells

All of that matters, but asset management is bigger than inventory. It is the organisation’s ability to answer practical questions about the technology it depends on:

• What do we own?
• What do we use?
• Where is it?
• Who is responsible for it?
• Is it supported?
• Is it patched?
• Is it secure?
• What business service does it support?
• What happens if it fails?
• Can we retire it safely?

Those questions matter far beyond IT admin. They affect support, cyber security, incident response, procurement, compliance, resilience, and operational continuity.

In plain English:

If you do not know what you have, you cannot reliably protect it, support it, update it, recover it, or retire it.

Why asset registers drift

Asset registers rarely fail dramatically.

They drift.

A device gets issued quickly because someone needs to start on Monday.
A replacement laptop is handed over during a busy week.
A server is built for a project that was definitely temporary.
A cloud service is adopted by a department because it solves a problem.
A network device is installed during a weekend change and the documentation update is left for later.

And “later”, as we all know, is where documentation goes to develop a drinking problem.

The issue is not usually laziness, itss that asset updates are treated as separate admin rather than part of the work. If asset management depends on people remembering to update records afterwards, it will drift.

People are busy, interruptions happen, and the operational universe has a sense of humour.

The warning signs your asset register is not trusted

You probably already know if your asset data is weak.

It usually sounds like this:

• “I think that device is still in use”
• “Finance has a different list”
• “Endpoint management says 92 devices, but the spreadsheet says 84”
• “That server is probably legacy”
• “Nobody is sure who owns that system”
• “It still responds to ping, so we left it alone”
• “We cannot remove it until we know what it does”
• “There are a few old devices we need to reconcile”

A few. Always a few.

If people do not trust the register, they stop using it as a source of truth. And once that happens, the asset register becomes decorative. It may still exist, but decisions are made through memory, guesswork, or whichever tool shouted most recently.

This is archaeology with admin rights.

Why this becomes a cyber risk

Cyber security depends heavily on asset visibility.

Not in a vague “best practice” way. In a very practical way.

If you do not know what devices and systems exist, you cannot confidently answer:

• Are they patched?
• Are they protected?
• Are they running supported software?
• Are they exposed to the internet?
• Are they still needed?
• Who has access?
• Who owns remediation?
• Are they included in backup or monitoring?
• Are they part of certification scope?

This is why asset management keeps appearing in cyber conversations. It supports almost everything else.

Patching requires asset data.
Vulnerability management requires asset data.
Endpoint protection requires asset data.
Incident response requires asset data.
Access reviews require asset data.
Recovery planning requires asset data.

You cannot secure what you cannot name and you definitely cannot secure what you forgot existed.

Why this becomes an operational risk

Weak asset data causes very ordinary problems:

• users wait longer for support because device history is unclear
• replacement planning becomes reactive
• warranties and support contracts are missed
• old equipment remains in use too long
• software licensing becomes harder to manage
• migrations take longer because nobody knows what is connected
• recovery planning becomes vague
• procurement decisions are based on incomplete information

In short, weak asset management makes IT slower, more expensive, and less predictable. Which is a bold strategy for something that usually begins as “we just need to tidy the spreadsheet”.

The problem with “the spreadsheet”

There is nothing inherently wrong with a spreadsheet. A good spreadsheet is a noble beast and capable of holding a frightening amount of organisational guilt.

The problem is when the spreadsheet becomes the whole process.

A spreadsheet does not discover devices.
It does not enforce ownership.
It does not update itself when a laptop is reassigned.
It does not tell you when software becomes unsupported.
It does not know when a cloud platform has quietly become business-critical.

What good looks like

1. A clear source of truth

There should be an agreed place where asset information lives. This might be an asset management tool, endpoint platform, service management system, or a controlled register. The key point is that people know which source to trust.

2. Ownership

Every meaningful asset should have an owner, custodian, or responsible function. If nobody owns it, nobody is accountable for patching, support, replacement, access, cost, or retirement.

Unowned assets are where risk likes to nest.

3. Lifecycle status

An asset should not simply exist.

It should have a state:

• requested
• ordered
• deployed
• active
• under review
• retired
• disposed

That sounds basic because it is. Basic things are where most control failures live.

4. Connection to service

Where possible, assets should be linked to the business service or function they support.

A laptop assigned to a user is straightforward.

But servers, applications, network devices, SaaS platforms, integrations, certificates, and service accounts all need context.

“What is this?” is useful.

“What business process depends on this?” is better.

5. Regular reconciliation

Asset data must be checked against reality.

That might mean reconciling:

• endpoint management
• finance records
• procurement
• service desk data
• network discovery
• cloud admin portals
• manual audit findings

How to fix it without boiling the ocean

The classic mistake is trying to fix asset management by documenting everything at once.

Don’t do that.

That way lies spreadsheet swamp, existential fatigue, and at least one meeting where people debate whether a docking station counts as an asset.

Step 1: Identify the critical asset groups

Begin with assets that matter most:

• laptops and user devices
• servers
• network devices
• firewalls and VPNs
• key SaaS platforms
• business-critical applications
• privileged accounts and service accounts
• backup and recovery systems

You can expand later.

Step 2: Define minimum useful fields

Do not collect data nobody will use.

Start with:

• asset name or ID
• type
• owner or assigned user
• location or service context
• status
• support status
• criticality
• source of record
• last verified date

If a field does not support a decision, question whether you need it.

Step 3: Make updates part of normal work

Asset records should update when:

• a device is issued
• a device is returned
• a system is built
• a system is changed
• a service is retired
• ownership changes
• an incident reveals missing data

If asset management is separate from operational work, it will fail politely.

Step 4: Reconcile regularly

Pick a rhythm.

Monthly for high-risk items. Quarterly for broader review. Annually for physical audit if needed.

The exact rhythm matters less than having one.

Step 5: Use the data

This is the most important part.

Use the asset register to support:

• patch reporting
• device replacement
• access review
• incident response
• supplier review
• budget planning
• risk reporting

If the data is used, it improves. If it is only stored, it decays.

Final thought

Asset management is not glamourous. Nobody has ever said, “Cancel my plans, the asset register is looking spicy tonight.”

But a good asset register makes IT easier to support, easier to secure, easier to budget, easier to audit, and easier to recover.

A bad one turns every incident, migration, renewal, and cyber review into a small archaeological dig.

And while archaeology has its place, it should not be your operating model.

What asset in your environment are you afraid to switch off because nobody is completely sure what it does?