IT Asset Inventory Template for Small Teams

The asset inventory checklist is the hunt — the discovery pass that finds the smart plug, the contractor's laptop, and the Raspberry Pi nobody registered. This page is what you put the finds into: one register, twelve columns, three row families — hardware, SaaS, and network gear — with worked example rows and the four fields nobody fills until the day they cost real money. The register earns its keep on bad days: the insurance claim that wants serials and costs, the stolen laptop that needs its MDM status, the disposal run that starts with a row, and the quarterly walk that finds the unpatchable NAS before it finds you.

1. What the register must answer on a bad day

• The insurance claim. "List the stolen equipment with serial numbers and purchase values." A register with a serial column and a cost column turns that from a two-day archaeology project into a filtered export. This is why serial and cost are columns, not notes.
• The stolen laptop hour. The lost-or-stolen runbook needs three facts fast: which device (model + serial), what data it touches (classification), and whether remote wipe will actually land (MDM enrollment + encryption status). Three columns, read in one row.
• The disposal run. The old hardware disposal checklist starts with "inventory row before power-off." A register without rows makes disposal a guess — and the copier or NAS that isn't on the list is exactly the one that keeps a hard drive with payroll exports on it.
• The EOL walk. Quarterly, the patch cadence needs one question answered per device: does the vendor still ship updates? That answer lives in the warranty/support-ends column. No dates, no walk — just a shrug at the old NAS until the day it matters.
• The normal day, too. Onboarding needs to know there's a spare ready (the hot spare checklist points at a status column). Procurement needs the cost column for budgeting. The register is boring on good days so it can be decisive on bad ones.

2. The twelve columns that carry the whole weight

Keep them exactly this boring. Every column must answer a named question or it becomes a column nobody fills.

• Twelve is the ceiling, not a floor. If a column doesn't get used in a bad-day runbook or a quarterly walk, delete it — every dead column makes the live ones less likely to get filled. The discovery checklist says keep the register small enough to survive contact with reality; the columns are where that principle gets enforced.
• The verification date in column 9 is not optional decoration. "MDM: yes" written at purchase decays. The honest value is "verified from the console on a date" — re-verified by the quarterly drift check below, because the console is the only place "enrolled" is a fact instead of a hope.

3. One register, three row families

• Hardware rows (most of the register). Laptops, desktops, phones, tablets, monitors, printers, the NAS. Anything with a serial number gets a row — and the things people forget are the ones with serial numbers: monitors with HDMI capture, the old phone kept as the MFA device, the copier that's quietly a computer with a hard drive.
• SaaS and license rows. The subscription that renews yearly is an asset: it has an owner, a cost, an expiry, and a way to lose it (nobody remembers the login). This row family shares five columns with hardware — ID, owner, cost, renewal date, notes — but the register to run it on is the software license register. Keep the two files linked, not merged: different rhythms, different bad days.
• Network rows (few but critical). The router, the switches, the VPN concentrator, the access points. These get the same columns plus one more habit: firmware version in Notes. The wifi security checklist and the VPN checklist both assume somebody can name the exact model on the shelf — that somebody is this register.
• Shared devices get the shared: prefix and a second column value: where they live. "shared: NAS — server closet" beats "the NAS" as an owner. The failure mode of pooled gear is that it is everyone's responsibility, which is the same as no one's; the register's job is to make the pool nameable.

4. The four columns nobody fills — and what each costs later

• Serial number. Skipped because it means flipping a laptop over. Costs later: the police report that can't identify the machine, the insurance claim that pays for "a laptop" at its lowest believable value, the warranty call that can't proceed. Rule: the serial is captured once, at the day-one row — the provisioning checklist already puts it there; the register is where it lives forever.
• Warranty / support ends. Skipped because purchase dates feel final. Costs later: the EOL NAS that stopped shipping patches a year ago, the out-of-warranty laptop whose $900 motherboard dies six weeks after the coverage did. Column 8 is the cheapest calendar reminder you will ever set.
• Encryption + MDM (with a verified date). Skipped because "we set that up when we bought them." Costs later: the stolen laptop whose disk was never encrypted, the remote wipe that fires into a device that left management last macOS update. This is the column the BYOD policy leans on for the "enroll or don't connect" line.
• Owner. Skipped because "it's whoever uses it." Costs later: the laptop that returns from a departed contractor with no owner, no wipe, and no row. Every row's owner is a name from payroll; when the name leaves, the offboarding checklist reads the register, not the org chart.

5. Example rows that show the register working

• Read the table the way an auditor would. LT-021 is the hot spare whose readiness has a date. PH-003 is honest about being weak (PIN only) so nobody pretends it's protected — the honest row triggers the fix (move TOTP to the manager's enrolled phone, safe optional). NW-002 carries its firmware version so the quarterly walk can compare it to the vendor's latest. The register's value is exactly this: every row makes a promise, and the weak ones say so.
• The — in a column is a decision, not a shrug. A SaaS row has no serial; writing "—" says "we looked, there isn't one." An empty cell says "nobody checked." Pick the convention and keep it.

6. Statuses and the exit lane

• Four statuses, no more: in service, spare, repair, exiting. Every device is in exactly one; a device that's "kind of in service but also maybe broken" is in repair until a human moves it. The spare status is what makes the loaner laptop page work — its one-per-ten rule counts rows, not memories.
• "Exiting" is the handoff to disposal. The day a device is taken out of service, its row moves to exiting — which is the disposal runbook's cue: deregister from MDM, wipe, verify, log, recycle with a receipt. The register never deletes the row; it gains the outcome in Notes ("disposed 2026-10-02, wiped + verified, recycler receipt #4411"). An inventory that forgets its exits becomes a museum of machines that left years ago.
• Repair has a return date or it becomes exiting. A laptop in repair for six months is a spare with worse PR. Any row in repair longer than 30 days gets reviewed at the monthly ops check: fix it, replace it, or retire it through the exit lane.
• Date-of-death columns stay in the register, not in a separate log. Small teams don't need two files. "Disposed + date + receipt" in Notes, status exiting (or a fifth, retired, if you'd rather never confuse it with active stock) — either is fine; having none is not.

7. Where each column gets used — the runbook map

• Serial + cost → insurance and police. The claim form wants both; the register has both in one filter. Keep a quarterly CSV export of in-service hardware rows in the same folder as the incident response plan — the export is what you open at 7 a.m., not the live sheet.
• Model + serial + encryption + data class → the stolen-device hour. The runbook needs the row read aloud to the MDM console and the insurer in one phone call.
• Model + firmware + support-ends → the patch and EOL walk. The patch cadence calendar and the EOL sweep read columns 3, 8, and the firmware note per network row.
• Owner + status → onboarding, offboarding, and audits. New laptop arrives → day-one row. Person leaves → filter owner → collect or reassign every row with their name. The user access review gets a hardware column for free.
• The 80/20 of it: if a runbook can't name what it needs from the register, the register is missing a column or the runbook is guessing. Say which, in one line, and fix it — that review is how the twelve columns stay honest.

8. Keeping it alive: the fifteen-minute quarterly drift check

• Count reality, not rows. Same drill as the discovery pass, but quarterly and fifteen minutes: scan the LAN, count the devices, compare against rows in status in service. Every delta is either a missing row (write it) or a ghost row (move to exiting).
• Spot-check five rows against the world. Five devices at random: is the owner still employed? Is the spare still on the shelf and charged? Does the 2FA phone still have its SIM? The annual security review runs the same walk with more columns; the quarterly check is its heartbeat.
• Re-verify column 9 from the console, not the sheet. Filter to managed hardware, compare the MDM console's device list against the register, and update the verification dates. Two lists that disagree are the entire finding — and the fix is one afternoon, done once, with the delta in front of you.
• One writer, one file, one habit. The register lives where the team works (shared spreadsheet beats unlaunched platform — same rule as the key inventory register). Rows are written the week the thing arrives, by whoever unboxes it; the drift check is scheduled next to the patch cadence so the two walks share a slot.

9. The starter — paste this in and fill the first five rows today

asset_id,type,make_model,serial,assigned_to,status,purchase_date,support_ends,enc_mdm_verified,data_class,cost,notes
LT-014,laptop,MacBook Air M2,C02XK9ABLT86,Dana Ortiz,in service,2024-03-11,2027-03-11,FileVault+MDM v2026-09,customer PII,1290,
LT-021,laptop,ThinkPad L14,PF3XQ21,,spare,2025-08-02,2028-08-02,BitLocker+MDM v2026-09,none (wiped),840,hot spare - charged on shelf
NW-002,router,UniFi UDM-SE,F24B9C04,shared: ops,in service,2024-01-15,2027-01-15,fw 3.2.12,network edge,599,guest+office SSID
PH-003,phone,Pixel 7a,G7721,shared: office,in service,2023-06-01,out of warranty,PIN only (no MDM),2FA codes,499,team TOTP device - lives in safe
SW-007,saas,Figma org seat,,Sam Reyes,in service,,renews 2027-01-15,SSO enforced,design files,540/yr,full row in license register

• Five rows, then stop. The five devices you'd actually miss — the owner's laptop, the spare, the NAS, the router, the 2FA phone. That's a working register in twenty minutes. The other forty rows can trickle in through onboarding, the drift check, and the discovery pass; momentum beats completeness every time this file is concerned.
• CSV or spreadsheet, but one place. The starter above is a CSV so it can be pasted into anything — Sheets, Notion, Numbers. Paste it once, keep it where the team already looks, and never let a second copy exist. The workflow automation can watch the sheet for stale verification dates; the automation ideas and the Automation Starter Pack ($19) workflows include the scheduled nudge that keeps column 9 honest.

The register is twelve boring columns and one honest habit: write the row the day the thing arrives, keep serial, support-end, encryption-status, and owner filled even when it means flipping a laptop over, mark the exits instead of forgetting them, and walk the whole sheet against reality for fifteen minutes a quarter. The Ops Starter Kit ($14) includes the fill-in-the-blank register sheet and the drift-check half-page, and the Automation Starter Pack ($19) schedules the verification nudges so column 9 stays a fact instead of a hope.