IT Asset Management, and How It Differs

IT asset management is a mature discipline with standards, processes and decades of practice. Most of it transfers to SaaS and four assumptions do not.

What ITAM assumes

The asset is physical, or at least installed. You can find it, tag it and count it.

It was procured. Someone raised a request, someone approved it, someone received it.

It has a location. A desk, a room, a person.

It has a lifecycle with a clear end. Retired, disposed, wiped.

Where SaaS breaks each

Nothing to tag. An application exists as an account somewhere. Discovery is inference from several imperfect sources rather than a walk round the building with a scanner.

Frequently not procured. A free tier signed up for by one person becomes a system of record for a team. There is no purchase order to find.

No location. The data sits with a vendor, in a region you may not know, under terms nobody read.

No clean end. Cancelling a subscription does not delete the data, and the account may persist. Retirement is a process rather than an event.

What transfers unchanged

The register. The central list, with an owner, a status, a cost and a lifecycle stage. This is the foundation of both disciplines and it is the same artefact.

Ownership. Every asset has an accountable owner, or it decays.

Lifecycle stages. Request, approve, acquire, deploy, maintain, review, retire.

Reconciliation. Comparing what you think you have against what is actually there, periodically, by hand.

Cost attribution. Per asset, per team, per site.

Compliance evidence. What we hold, where, under what terms.

Why they should be run together

The same people are asked both questions. "What laptops do we have" and "what applications do we pay for" arrive at the same desk.

Offboarding touches both. A leaver needs their laptop back and their accounts closed. Two processes means one of them is forgotten, and it is usually the accounts.

The register discipline is identical. An organisation that maintains a good hardware register can maintain an application register; one that cannot maintain either has a management problem rather than a tooling problem.

Spend questions cross over. A team's total IT cost is hardware plus software plus SaaS, and reporting them separately makes that number unavailable.

Security needs both. Incident response asks which devices and which applications, immediately.

Where they stay separate

Procurement paths differ. Hardware goes through purchasing; SaaS arrives on a card.

Discovery methods differ entirely.

Disposal differs. One is physical destruction and a certificate; the other is data deletion you have to ask a vendor for and cannot verify.

Renewal is a SaaS problem. Hardware does not auto-renew at a higher price.

The practical arrangement

One register, two asset types, with the fields that differ handled per type.

One owner model.

One lifecycle, with different steps at the acquisition and disposal ends.

One offboarding process covering both.

Separate discovery pipelines, because they have nothing in common technically.

Separate spend processes, because the money moves differently.

That arrangement is more work to set up than two disconnected systems and it is the only one that answers the questions people actually ask.

The shared register, in practice

Running both disciplines from one register requires deciding which fields are common and which are type-specific.

Common to both: identifier, owner, status, cost, lifecycle stage, review date, data classification, notes.

Hardware only: serial, model, warranty expiry, physical location, assigned person, disposal record.

Application only: vendor, renewal date, notice deadline, seat count, authentication method, integration scopes.

One table with nullable columns, or two tables with a shared key. Either works; what fails is two unrelated systems maintained by different people with different conventions.

The offboarding query is the test. If you cannot produce a single list of everything a leaver holds — devices and accounts together — the registers are not joined, whatever the architecture diagram says.

Where the standards help and where they do not

There is a substantial body of formal practice in asset management, and it is worth knowing what to take from it.

Take: the lifecycle model, the register discipline, the separation of ownership from custody, and the vocabulary, which makes conversations with auditors easier.

Take: the reconciliation requirement, which formal practice states more clearly than most internal processes do.

Leave: the process weight, which assumes a dedicated function that most organisations do not have.

Leave: the assumption of physical assets and procurement paths, which is where SaaS breaks the model.

Adapt rather than adopt. An organisation of two hundred people implementing a framework designed for twenty thousand produces documentation rather than a register.