You can't protect what you never counted

Every security conversation eventually lands on the same question: “what do we even have?” The breach post-mortem, the insurance questionnaire, the offboarding of the employee who left eight months ago — all of them need a list of devices, accounts, and services that actually exists, not the list someone wrote in a spreadsheet in 2023 and never opened again. An asset inventory is not an enterprise compliance artifact; it is the smallest possible map of what matters, and the annual security review is only as good as it is.

1. Keep the register small enough to survive contact with reality

• One row per thing that could hurt you if it vanished or leaked. Laptops, phones, servers, routers, SaaS accounts with data in them, API tokens that can move money or mail, the printer with a stored scan-to-email credential. If a row would never change a decision, cut it — an inventory that lists the coffee machine's MAC address is a museum, not a control.
• Eight fields, no more, to start. Name, owner (a person, not “IT”), serial or identifier, purchase or contract date, data class (customer data, credentials, nothing), access level (admin/user), where it lives (office/cloud/staff homes), and status (active/retired). Everything else is an enterprise hallucination — you can add fields the day you actually use them.
• The owner field is the whole point. An asset without a named owner is an orphan, and orphans are where stale credentials and unpatched firmware live. The owner is the person who gets the phone call when the thing is found doing something strange — the same naming discipline as the key inventory register, where every physical key has a hand attached to it.
• Pick the dullest tool that three people can edit. A shared spreadsheet beats an asset-management platform the team won't log into. What matters is that the file has one copy (not six), version history, and a rule that changes get written the week they happen — the same “one source of truth” rule as the on-call schedule.

2. The discovery pass: find what nobody wrote down

• Count the network first. Log into the router or run a scan from a laptop on the LAN and list every device that responds. Compare that count to the register — the gap is the inventory. The smart plug, the contractor's laptop, the spare phone in a drawer: they're all on the network whether or not the spreadsheet knows it.
• Then count the SaaS. Every email inbox is a list of vendors nobody remembers signing up for. Sort by sender and by auto-renewal charge: the invoice feed is an asset feed. Pair this with the shadow IT audit — the discovery pass and the audit are the same walk with different questions.
• Ask each person for their list. One message per employee: “what company devices, accounts, and logins do you personally hold?” The answers won't match the spreadsheet, and that mismatch is the most valuable output of the exercise. Personal devices used for work go on a second list with a policy attached — that's the remote work security conversation, not a shaming exercise.
• Chase the shared and the forgotten. The NAS in the closet, the laptop that “sometimes runs the dashboard,” the old phone used as the 2FA device, the Raspberry Pi someone's Raspberry-Pi'ing with prod data on it. The forgotten devices are the ones that skip every patch cycle; write them down before the patch management checklist tries and fails to find them.

3. Assign a lifecycle state to every row — and make onboarding write the first one

• Every asset is exactly one of: onboarding, active, at-risk, retired. Four states, no more. “At-risk” means unpatched, unknown-owner, or holding data it shouldn't — it's the state that generates work, which is exactly what makes the inventory a tool instead of a filing cabinet.
• Onboarding is the moment the row is born. The day a laptop is handed over, the row exists with its owner, serial, and data class filled in — bake it into the onboarding checklist as a step, because inventories built “later” are never built. Account-based assets (email, SaaS seats, tokens) get the same treatment in the access request checklist.
• Offboarding is the moment the row closes. Device returned and wiped, accounts disabled, tokens revoked, the row flips to retired with a date and the name of who verified it. The offboarding checklist should point at the register row, not the other way around.
• Retire, don't delete. A retired row is history you will want: “that laptop held customer data until March, was wiped on the 14th, verified by ___.” Deleting rows destroys the audit trail the next incident (or the cyber-insurance renewal) will ask for.

4. Tag the data, not just the device

• Data class beats device class for risk. A laptop holding the customer database and a laptop holding PDF manuals are the same hardware and different emergencies. Tag every row with what it can reach: customer data, credentials, production systems, money movement, nothing sensitive. This single field decides backup priority, encryption requirements, and breach panic level.
• Credentials are assets too. The admin passwords, API tokens, and shared logins belong in a credential manager with their own inventory rows — what they open, who holds them, when they last rotated. The secrets rotation checklist needs this list to exist before it can schedule anything.
• Mark the money-paths explicitly. Anything that can move money — banking tokens, payment dashboards, payroll access — gets its own tag, its own MFA requirement, and its own review line in the user access review. If a breach ever happens, this tag is the difference between a bad day and a very bad quarter.

5. Keep it alive with one calendar and one honest audit

• Quarterly, 30 minutes, honest counting. Re-run the network count, diff it against the register, and walk the retired-and-purchased rows for the quarter. The audit is not the problem — skipping it is. Drift of more than a few devices between audits means the register has stopped being a map and started being a decoration.
• Renewals and warranties feed the register. Every auto-renewal email is a prompt to update a row: still in use? owner still right? data class still true? Cancel the ones that aren't — an inventory that quietly saves money pays for its own upkeep, which is the only budget argument that ever wins.
• Tie the register to the checks you already run. Patch cycles read the “active” list. The access review reads the account rows. The annual review reads everything. If a checklist references the register and the register is stale, the check fails visibly — that feedback loop is what keeps it honest.
• Write the “found something” drill down while it's fresh. The first discovery pass always finds devices and accounts nobody knew about. Record what they were, how they were found, and what happened to them — that one-page story is what convinces the next holdout that the register matters.

6. The 10-minute version for teams with no time

• Today: one shared spreadsheet, eight columns, the five most dangerous things you can name off the top of your head. That's a register — incomplete, but real.
• This week: network scan + SaaS inbox sort, add everything found, assign owners to the top 20 rows.
• This month: quarterly audit on the calendar with a named owner; onboarding and offboarding checklists updated to write to the register.

Related: new admin first week runbook