PART 2 OF A SERIES ON MID-MARKET IT ASSET MANAGEMENT
The conversation every mid-market IT director has had.
Let me describe a conversation I have had more times than I care to count.
“Where is the asset register?”
“It’s in the service desk.”
We opened the service desk. The assets are there. Some imported, some manually added, some discovered by an agent that ran six months ago and was never reconfigured. Some with custodians; many without. Some with purchase values; most without. Some are still assigned to people whose offboarding dates are visible in a different tab of the same system.
The data is present. The data is, in many cases, even organized. The list exists.
Then I ask the questions that matter:
- Who owns this laptop today, and can you prove it?
- When was it issued, and to whom?
- Was it recovered at offboarding?
- Is this asset still in use, or sitting somewhere we have forgotten?
- Does Finance know this asset exists?
- Does IT know that the asset on Finance’s books still physically exists?
- Can you walk me through the custody trail?
- Can you reconcile this register, line by line, to the accounting fixed asset register?
- Can you tell me, with confidence, which assets are missing?
That is where the silence begins.
The misconception is older than the tools. It has nothing to do with the specific service desk; the same scene plays out in every ITSM platform, in every spreadsheet, in every homegrown database proudly built and proudly maintained by an internal IT team. The misconception is structural and almost universal across mid-market IT organizations: They confuse a list with a system.
What is the difference between asset data and asset management?
A list records what someone decided to enter. A system records what actually happens. The distinction sounds semantic. It is operational, and it is the entire reason mid-market IT organizations end up reconstructing their asset estate whenever a consequential question is asked of them.
A list answers the question: what did we record? A system answers the question: what is true right now, and how do we know? Those are not the same questions. They are not even close.
Five questions any real asset management system must answer — instantly, without human reconstruction, without phone calls to the floor, without a half-day spent opening drawers and emailing department heads — include:
1. What do we own? Not what we paid for; not what was once delivered; not what someone manually entered three quarters ago. What exists today, on premises and off, in stores and in the field, deployed and idle.
2. Where is it? Physical location. Logical location. Custodian. Department. The chain of custody from procurement to the current state is traceable end-to-end.
3. Who has it, and since when? Custody is not assignment; assignment is intent, custody is reality. The two diverge constantly in companies that do not track movement.
4. What has changed, when, and by whom? Every reassignment, every status update, every move from active to retired to disposed — logged, timestamped, attributable to a named action.
5. What does the data surface, automatically, that I have not asked? Ghost assets nobody has touched in fourteen months. Devices issued to terminated employees. Assets approaching end-of-life with no replacement plan. Insurance coverage diverges from physical reality. The system that does not surface intelligence on its own is, by definition, a list with formatting.
If your current asset record cannot answer all five — without someone going to the floor, calling departments, opening drawers, and reconstructing the truth from fragments — you do not have an asset management system. You have a list. Possibly a beautifully formatted one; possibly maintained by someone diligent and well-meaning; but a list nonetheless, requiring a human reconstruction exercise every time the truth is needed.
That reconstruction exercise has a name in finance. It is called audit work. The whole point of having a system is that audit work should not be required to know what your company owns.
I know what that exercise costs, because I have run it with my own hands. At one of my previous employers (a tech firm), where finance and administration reported to me, the annual verification began at a printer: the fixed asset register printed page by page, scotch-taped into one enormous chart, and walked desk to desk so that every employee could sign, by hand, against every asset they held.
Then the team went remote, and the chart could no longer walk the floor; so we sent dispatch riders across the city — paper to living rooms, signatures collected like rent — a week-long logistics operation to establish, once, what a system should have known continuously.
A printer, a roll of scotch tape, and a fleet of motorbikes. That is the audit a list demands.
What is ITAM, and what is it not?
The confusion runs deeper than spreadsheets. Most mid-market IT organizations have something they call asset management. The thing they have is, almost always, one of four other systems wearing borrowed clothes.
The accounting fixed asset register
Finance has the FAR (fixed asset register). The FAR knows acquisition cost, capitalization date, depreciation method, accumulated depreciation, and net book value. It is, in financial reporting terms, complete and correct. It is also, in operational terms, irrelevant to the question of where the asset actually is.
The FAR knows that you bought a laptop. It does not know whether that laptop is currently in the hands of a senior engineer, sitting in a desk drawer, in transit to a remote contractor, or quietly idling at the home of an employee who left in February.
The FAR was never designed for any of that. It was designed to depreciate. Conflating it with asset management is like asking a thermometer for the weather forecast — same general subject, but an entirely different instrument.
I once walked that gap myself. Annual audit, a publicly listed technology company, a laptop sitting quietly in the FAR, and when I asked the IT manager to produce the machine, the answer came back that it was checked out, to a name I did not recognize. That surprised me; I had audited this client before, and the custodian was on an admin team small enough that I thought I knew every member. I did not know this one for a simple reason. He had left the company three years earlier.
The laptop had ridden the books the whole time — not through fraud, and not through negligence in any form one individual could own; the man had simply been late returning it, and the register was Excel, and Excel does not chase, does not remind, does not escalate. It carried the line forward, year after faithful year, the way a ledger carries anything nobody questions. The FAR did exactly what it was designed to do. That is the indictment.
And the same instrument misleads in the opposite direction with equal confidence. Across my audit years, and later as a finance manager, I watched perfectly good machines — laptops written down to nothing on a standard three-year schedule, still quick, still humming — fall to zero net book value and promptly attract requests from IT for allotment at no cost; because on the FAR, a machine worth nothing on paper is a machine worth nothing. More than once, I had revaluation entries passed for no purpose grander than making the books admit what the floor already knew: the economic life had outrun the depreciation schedule. A register that carries ghosts at full value and writes the living off at zero is recording your accounting policy, not your assets.
Meanwhile, the register that could not say where one laptop was would faithfully itemize every dustbin, whiteboard, and teacup the company had ever bought — row upon row of crockery and store items swelling the file — because without an inventory module, everything is an asset, and every asset is a row.
The CMDB
The Configuration Management Database is the configuration record of your IT estate. It maps relationships: which server runs which application, which application depends on which database, which database serves which business service. It is a relationship graph; an excellent one when properly maintained, which it usually is not.
The CMDB knows that a laptop is a configuration item of class ‘workstation.’ It does not know if that laptop has been recovered at offboarding, whether its purchase value has been depreciated, or whether it is sitting in stores awaiting reissue. The CMDB cares about configuration relationships; it does not care about ownership lifecycle, financial value, or physical custody.
The ITSM asset tab
Your service desk has an asset module. It probably even ingests endpoint data from your MDM. In nearly every mid-market deployment I have audited, it is a list. A long, dynamic, sometimes fairly accurate list, populated mostly by ticket-driven workflows: somebody reports an issue, the asset is logged. If somebody gets a new device, it is added.
What the ITSM asset tab is not is a lifecycle management system. It does not, in its native form, track procurement-to-disposal as a continuous flow with custody, financial reconciliation, contractual obligations, and end-of-life planning woven in. It records assets as they are brought to the service desk. It does not, by design, manage them between collisions.
The SaaS discovery tool
The newest entrant — discovery tools that scan your network, your SSO, your finance feeds, your endpoint agents, and report back what they found. Excellent at what. Weak at the who, when, and what next. Discovery is a starting point for an asset management system; it is not the system itself. Knowing a device exists is not the same as managing its lifecycle.
What ITAM actually is
Asset management — properly understood — is the operational system that lives between procurement and disposal, between finance and IT operations, between physical reality and the records that claim to reflect it. It is not a list, not a depreciation schedule, not a configuration map, not a discovery scan. It is the discipline of maintaining the truth about ownership, custody, and lifecycle in real time across the full estate.
The implication is this: not one of these systems, on its own, constitutes asset management. Each is necessary in its own domain. None is sufficient. The mid-market IT organization that has any of them is doing something correctly. The mid-market IT organization that believes any one of them is asset management is heading toward an avoidable conversation with an auditor, a customer, or an acquirer.
When does a mid-market company need ITAM?
The honest answer, arrived at through more engagements than I care to relive: when memory stops being a control.
At fifty people, someone knows. The IT lead has personally carried every laptop into the office; they remember who sits where, who got what, and who returned what at offboarding. The asset register is, in effect, the IT lead’s mental model of the company. It is informal but largely accurate, because the mental model fits inside one person’s head.
At a hundred and fifty people, someone thinks they know. The mental model has become a hybrid of memory and a spreadsheet that gets updated when somebody remembers, which is, predictably, less often than anyone admits. Cracks appear in places nobody notices until someone asks a question that, a year ago, would have had a confident answer.
At five hundred people, nobody knows. The IT lead has changed; the spreadsheet has changed hands twice; the spreadsheet itself has accumulated contradictions; some assets exist that the spreadsheet does not record, and some assets are recorded that no longer exist. Memory has stopped being a control. The system that was meant to replace memory was never built.
That is the breaking point. Not at five hundred precisely — sometimes at four hundred, sometimes at seven hundred, sometimes earlier if the company is asset-intensive or compliance-bound. But the principle is invariant: there is a headcount threshold beyond which informal tracking is no longer sufficient, and the company will move to a system at that point, either by design or in an emergency.
The five triggers that force the move
In mid-market IT organizations, the move to real ITAM is rarely driven by internal maturity. It is almost always forced by an external party that asks a question the organization cannot answer. There are five common forms this takes; familiarize yourself with them before they familiarize themselves with you.
1. The audit
The auditor asks for the fixed asset register. The company hands over a spreadsheet. The auditor asks for reconciliation to physical reality, then for the custody trail, then for documented disposals, then for the list of assets known to be missing. Somewhere between question two and question four, the company realizes it has handed over a list, not a register. What follows is usually expensive, visible, and avoidable: additional audit work, control findings, board-level questions, or, in the worst cases, a qualification or forensic review.
2. The enterprise customer security review
A large customer — frequently your most important contract — sends a security questionnaire. How do you track devices issued to your team? How do you ensure terminated employees no longer hold company equipment? Can you provide evidence that a former employee’s laptop was recovered, wiped, and disposed of in compliance with applicable regulations? The questionnaire is not optional; the customer has SOC 2 obligations of their own, and any gaps you have become their findings. This is increasingly the trigger that moves mid-market IT, because the cost of failing a customer review is not theoretical. It is the contract.
3. The offboarding that goes wrong
A senior employee leaves on bad terms, or on perfectly good terms, but the offboarding process is sloppy. HR asks for the equipment back. IT records show one set of assets. The employee insists they had a different set. Finance shows a third reality. Nobody can prove anything. The cost is not just the unrecovered assets; it is the senior team’s first encounter with the fact that the IT estate is not knowable. That encounter changes the conversation in ways that no internal memo ever could.
I have stood inside this exact standoff. An engineering employee, two laptops against his name; and on his final day, he stated, flatly and quite possibly truthfully, that he held only one — the second was a team asset, passed around the pod for months. The team-level reallocation had never been signed off; the system showed no assignment to anyone else; no acknowledgment email had ever gone out, because nothing in the chain sends one. He pinned it on IT, and IT had nothing to pin back with — no evidence, no trail, no agent, no closure. The last documented custodian was a man walking out the door, and the documentation was wrong.
4. The due diligence process
An acquirer or a major investor requests information on fixed assets, IT inventory, security posture, and lifecycle controls. The company has thirty days. The asset register, such as it is, requires reconstruction; reconstruction under deadline; reconstruction with the deal closing visible on the calendar. The cost of poor ITAM has been theoretical until this moment. It is now a discount on the valuation.
5. The security incident
A device is lost. A user account is compromised. Someone — incident response, the CISO, legal counsel — asks the questions: which device was used, who had it, was it encrypted, was it recovered, was it still active in any system? If the answer to any of these is we need to check, the company has already failed the test. The incident has merely revealed it.
These triggers are not hypothetical. They are common. They are the standard sequence by which mid-market IT organizations discover that the question they should have asked themselves three years ago is now being asked by someone with leverage.
What capabilities must your ITAM system have?
Once you have decided that a list is no longer enough, the next question — and the one most companies get wrong — is what to require of the system that replaces it. The temptation is to evaluate features. The discipline is to evaluate capabilities.
Eight capabilities separate a real ITAM system from a list with a better interface. If your evaluation does not explicitly test each of these, you will end up paying for a more sophisticated version of the same problem you are trying to solve.
1. Custody chain, end to end
The system must record every transition of every asset from procurement through deployment, reassignment, return, and disposal. Not who is currently assigned. Who has had it, in what sequence, with what handover at each step?
2. Offboarding recovery workflow
The system must enforce — not request, enforce — the recovery, return, and verification of every asset issued to a departing employee. With evidence. With a closed loop. Without the recovery depending on someone remembering.
3. Continuous finance reconciliation
The system must speak to the accounting fixed-asset register continuously, not in a heroic quarterly effort. The day the two registers disagree, you must know — and so must Finance.
4. Audit trail by user, date, and action
Every change is attributable. No silent edits. No untraceable status flips. I have kept registers where an update or a deletion left no trace at all; online spreadsheets later gave us version history, and with a dozen hands editing weekly, it told us that everything had changed and nothing about why. The trail is what separates a register from a list with version history.
5. Idle and ghost asset detection
The system must automatically surface assets that are not being used, that have not been touched for a defined period, and that are recorded but unverifiable. If the system does not volunteer this intelligence, you are still doing manual archaeology — only now with a license fee attached.
6. Lifecycle status management
Procurement, deployment, active, idle, retired, disposed. Each status is meaningful, each transition is controlled, and each stage produces the artifacts the next stage requires.
7. Integration with the systems that already own pieces of the truth
HRIS for joiners and leavers. MDM for endpoint reality. Accounting for financial reconciliation. ITSM for ticket-to-asset linkage. An ITAM system that lives in isolation reproduces the original problem at a higher cost.
8. Audit-grade evidence export
When the auditor, the customer, the acquirer, or the incident response team asks for proof, the system must produce it — formatted, complete, defensible — without a half-day reconstruction effort. If you cannot export the evidence on demand, you do not have evidence. You have raw material.
Notice what is not on this list: dashboards, mobile apps, AI-powered insights, and customizable fields. These are features. They become useful only after the eight capabilities above are present. Buy capability first. Features either follow or do not matter.
The rebuttal you will hear in the demo
One more thing before you evaluate anything, because I can tell you in advance how that conversation will go. Your incumbent vendor — the service desk, the suite, the platform you already pay for — will tell you that its asset module already does all eight. Do not argue. Test. Four requests, thirty minutes, no slideware.
Ask for one custody trail. Pick a laptop that has changed hands at least twice. From procurement to deployment to reassignment to recovery, every transition is timestamped and attributed to a named action. A system produces this in clicks; a list produces it in a follow-up meeting.
Ask for the leavers’ report. Every device and license is still assigned to employees who left in the last two quarters. If the answer involves exporting to a spreadsheet and cross-referencing HR, you have your answer.
Ask for last month’s reconciliation. The operational register, compared line by line with the accounting fixed asset register, shows variances. Not “we could build that report.” The report.
Ask what the system surfaced on its own. Idle assets, ghost entries, devices past end-of-life — in the last thirty days, unprompted. A system that only answers the questions you remember to ask is still a list, just a more expensive one.
The demo that survives all four questions is worth your afternoon. The demo that reroutes to the roadmap slide has already addressed your question.
The most expensive mistake you will never see in a single invoice
There is a class of loss that mid-market IT organizations sustain continuously, year after year, that nobody flags because it is invisible by construction. It does not show up as fraud; it does not show up as theft; it does not show up as a single dramatic event that triggers an investigation. It shows up as normal procurement.
A team needs laptops. IT cannot say, with confidence, what is currently available, where it is, what condition it is in, or whether the recently offboarded devices have been recovered and reset. Procurement, given the choice between pausing operations and ordering more equipment, chooses the latter. The order is approved through normal channels; the invoice arrives from a known vendor; the cost hits the budget on a familiar line item. Nothing about the transaction looks abnormal because nothing about it is. The transaction is the symptom; the absence of visibility is the disease.
Meanwhile, laptops sit in the homes of ex-employees. Monitors stack quietly in the storeroom. Accessories (keyboards, mice, dongles, cables) are reordered every quarter because no one keeps a count of what already exists. Devices marked as ‘assigned’ on the spreadsheet have, in practice, been physically reassigned twice, returned once, and currently sit on a shelf nobody opens. Old stock becomes obsolete before anyone has the chance to use it. Finance dutifully depreciates assets that nobody has verified for two fiscal years.
And hardware is only the visible half. When IT came under my remit, I inherited a software estate of over a hundred tools — and no instrument anywhere to tell me when any of them were no longer needed. The only signal was human: a departing employee mentioning a subscription on his way out; a line manager confessing, months later, that the team had quietly moved on to something else. At one point, we were paying for Zoom, Google Meet, and Skype simultaneously — three tools, one meeting. My audit method, in the absence of anything better, was payroll: count the heads on each team, count the seats on each invoice, and chase the gap, tool by tool, month after month. One frustrated afternoon, I asked my IT manager whether I was expected to post a watchman over every tool we used, and then, because the question had answered itself, I told him to go hire some interns.
That is the confession a list eventually extracts from you: its only control is labor. More eyes, more chasing, more humans deputized to watch what the system cannot see on its own. A register that needs a watchman is not a register. It is a liability with staff.
The technical name for this is procurement duplication. The honest name is buying around your own ignorance. I will not pretend to a precise industry rate — the loss is, by construction, distributed across hundreds of small, individually unremarkable transactions, which is exactly why nobody totals it. But in the estates I have audited, the duplication that could be reconstructed ranged from tens of thousands of dollars a year in stable environments to six figures in environments where churn was high, procurement was distributed, or the workforce had gone hybrid.
That is the silent killer. Not the dramatic loss; not the stolen laptop; not the embezzlement that finally gets investigated. The steady, untracked, normalized leakage of capital that the company never sees because it has implicitly decided not to look.
The question you are now equipped to ask
The question is no longer whether you have asset data. You almost certainly do. The question is whether your asset data can prove reality without a human reconstruction exercise.
If it cannot, you have a list. The list is not the problem; the belief that it is a system is. That belief is what allows procurement to over-buy, offboarding to under-recover, audits to find gaps, customers to find weaknesses, acquirers to find leverage, and the silent leakage of capital to continue, quarter after quarter, while nobody is held accountable because nobody can name what is being lost.
Memory is not a control. A spreadsheet is not a system. A configuration database is not a register. A service desk asset tab is not lifecycle management. An accounting fixed asset register is a financial record, not an operational one. Each of these does what it was designed to do; none of them does the job of asset management; and the gap between what they do and what your company needs is the gap your next external trigger will walk through.
You already know what you have. Now you know what it is not. The next question is the only one that matters: What are you going to do this quarter, before someone with leverage asks you for proof you cannot produce?
