The 60x asset inventory problem | The IT Ops Brief

Two months ago I argued your asset inventory drifts into fiction because record-keeping is separate from the work that changes it. I thought I was being provocative. Then the 2026 numbers arrived, and it turns out I was being conservative.

IT inventory accuracy is the audit you already run every offboarding — you're just not reading it. When Lumen Technologies ran proper discovery, it uncovered 60x more devices than its records showed; only 45% of organizations even consolidate their asset and exposure data into a single view; and EU regulators are now legally requiring financial-sector firms to maintain a real-time ICT registry. The gap between record and reality doesn't announce itself — it only becomes visible when you need the device back or when an auditor asks. The fastest way to size your own gap is to look at the last ten offboardings and count how many produced a recovered, certified-wiped device, then fix global IT asset management as an architecture problem, not a spreadsheet one.

The signal: 60x, 45%, and a new regulatory floor

Three data points landed recently that should reframe how seriously you take asset visibility:

Only 45% of organizations consolidate their asset and exposure data into a single view (Axonius, 2026 Actionability Report). In the same report's most striking example, Lumen Technologies uncovered 60x more devices than it knew it had once proper discovery ran. And in the EU, DORA now legally requires financial-sector firms to maintain a real-time registry of ICT assets — visibility has crossed from best practice into regulatory obligation, with audit costs already exceeding $1M over three years for nearly half of enterprises.

The market's quiet assumption — “our records are roughly right” — is failing audits, and the audits are getting less patient.

The problem: what the record-vs-reality gap looks like

From inside recovery operations — real cases from the last 30 days across our network, anonymized:

• A device recovery stalls because the ex-employee's phone number on file was disconnected — the record was confident, and wrong, about the one field that mattered.
• An offboarded employee responds about returning her laptop — from her personal Gmail, because her corporate account was closed before the device came back. The system that “owned” the relationship no longer had a way to reach her.
• A pickup fails on its third attempt because a shipping label never existed at any of them. Every dashboard involved showed the return “in progress” the entire time.
• A collection sits blocked for days because a local logistics partner needs photos that a client-side contact hasn't sent — a dependency no asset system anywhere records.

None of these are exotic failures. They're Tuesday. And each one is a place where the record and the world disagree silently — no alert fires when a phone number goes stale or a label doesn't generate. The gap only becomes visible at the worst moment: when you need the device back, or when an auditor asks you to prove where it is.

That's why discovery projects keep producing numbers like 60x. The drift doesn't announce itself. It accumulates.

The operator takeaway: retrieval is the audit

You don't need a discovery project to estimate your gap. You already run the audit — you're just not reading it.

Retrieval is the audit.

Every offboarding is a live fact-check of your record: right person, right contact info, right device, right location, device actually returns, wipe actually certified, record actually closes. Onboarding rarely exposes bad data — new devices are the easy rows. Getting devices back tests every stale field at once.

So run the ten-offboarding test: pull your last ten departures and count how many produced a recovered, certified-wiped, record-closed device. Ten for ten — your visibility is real. Six for ten — your record is ~40% fiction at the exact rows an auditor will sample, because departed-employee devices are precisely where data risk concentrates.

Then fix the structure, not the spreadsheet:

• Contact data has to be verified while the person is still an employee (offboarding day is too late).
• Returns need real logistics with escalation, not a label-and-hope email.
• The record should close only on certified wipe — not on “ticket resolved.”

One GroWrk lens

The reason we see these failure modes so clearly is that we operate at the exact point where records meet reality — the recovery. When retrieval, wipe, storage, and redeployment run through one system, every physical event updates the record as a byproduct: the pickup confirms the address, the return confirms the device, the certificate closes the loop. The record can't drift far, because the work keeps correcting it.

That's the practical answer to the 60x problem — not a better annual true-up, but making execution and record-keeping the same event. And for teams staring down DORA-style registry requirements: a record generated by the work is the only kind that's real-time by definition.

One stat

60x. The gap one company found between its device records and its actual devices.

Your gap is smaller. The question your next audit will ask is: how much smaller — and can you prove it?

When did your team last check the record against physical reality — not a report against a report, but rows against actual laptops? And what did you find?

If you want to see what a record that fact-checks itself looks like, we would like to show you.

Book a demo →