Every insurance claim after a break-in asks the same two questions: what was taken, and what was it worth? Every stolen-laptop hour asks three more: which device, what data was on it, can we wipe it remotely? And every patch walk asks the quiet one: does the vendor still ship updates for this thing?
An IT asset inventory answers all of them — if its columns were built for the bad days, not the audit. Here is the register I'd ship for a small team: one file, twelve columns, three row families.
The twelve columns. Asset ID (a convention, never re-used); type; make + model; serial number; assigned-to (one name, or shared: + where it lives); status (in service / spare / repair / exiting); purchase date; warranty / support ends; encryption + MDM — with the date it was verified from the console, not when you set it up; data classification (what's on it if it walks away); cost; notes.
Three row families, one file. Hardware rows for anything with a serial — including the copier, the NAS, and the old phone that holds everyone's 2FA codes. SaaS rows for anything that renews — but those run on the software license register, linked not merged. Network rows for the router, switches, and VPN concentrator, with the firmware version written in notes so the quarterly walk can compare it to the vendor's latest.
The four columns nobody fills, and what each costs later:
- Serial — skipped because it means flipping a laptop over. Costs: the police report that can't identify the machine, the insurance claim that pays "a laptop" at its lowest believable value.
- Support ends — skipped because purchase dates feel final. Costs: the EOL NAS that stopped shipping patches a year ago.
- Encryption + MDM (verified date) — skipped because "we set that up at purchase." Costs: the wipe that fires into a device that left management in March.
- Owner — skipped because "it's whoever uses it." Costs: the laptop a departed contractor left behind, with no row and no wipe.
Statuses are the exit lane. Four states only: in service, spare, repair (with a 30-day review), exiting. A row moving to exiting is the disposal runbook's cue: deregister from MDM, wipe, verify, recycle with a receipt — then write "disposed 2026-10-02, receipt #4411" in notes. The register never deletes rows; that's the difference between an inventory and a museum.
Keeping it alive: the fifteen-minute quarterly drift check. Scan the LAN, count the devices, compare against in-service rows — every delta is a missing row or a ghost row. Spot-check five rows against the world (is the owner still employed? is the spare still charged?). And re-verify column nine from the MDM console, not the sheet — two lists that disagree are the entire finding, and the fix is one afternoon.
Start with five rows today: the owner's laptop, the spare, the NAS, the router, the 2FA phone. Twenty minutes, paste-in CSV, and you have a working register that momentum keeps alive.
The full template — the column table, worked example rows, the runbook map, and the starter CSV — is on the site:
👉 IT Asset Inventory Template for Small Teams — part of the free HIVE80lab ops notes library.
If you want the surrounding system: the Ops Starter Kit ($14) includes the fill-in-the-blank register sheet, the First 30 Minutes checklist is free, and the Automation Starter Pack ($19) schedules the verification nudges so the register stays a fact instead of a hope.
💬 Discuss: What are your first 3 steps in an incident?
