Knowledge hub

Asset inventory

A current list of the systems, apps and data you are responsible for.

What it means

An asset inventory is a current, shared list of what you run: servers, cloud accounts, domains, applications, APIs, databases, devices, and the data they hold. Each entry says what it is, who owns it, where it lives, how it is reached from outside and how important it is to the business.

The word that matters is current. A spreadsheet made once for an audit and never updated is a historical document. A useful inventory changes when your systems change, ideally because tools feed it automatically, and people who know each system check it.

Why it matters

You cannot patch, monitor or test something you do not know exists. Many incidents start with an asset nobody listed: an old test site, a forgotten API version, a cloud account opened by one team. The attacker finds it because it is reachable, not because anyone remembered it, and by the time your team hears about it the damage may be done.

It also decides priority. A flaw in a system that holds customer payments matters more than the same flaw in an internal wiki. Without an inventory that records importance and ownership, every ranking is a guess, and every fix waits while people work out whose problem it is.

How it shows up

CIS Controls put it first for a reason: control 1 is an inventory of enterprise assets and control 2 covers software. CISA's BOD 23-01 asks US federal agencies for regular, automated asset discovery. Build yours from cloud accounts, DNS records, code repositories, the API inventory and your software bill of materials.

Gaps cluster in the same places: shadow APIs, forgotten subdomains (see subdomain takeover), test environments exposed to the internet, and software run by teams outside engineering. Compare what you list with what outside scanning finds. Any difference is a finding about the inventory itself.

Questions people ask

Asset inventory, answered

What should an inventory include?

At minimum: name, type, owner, location, environment, the data it handles, and how it is exposed. Add version and criticality when you can.

Keep the first version small and accurate rather than wide and stale.

How is it different from a CMDB?

A configuration management database is one way to hold an inventory, usually with relationships between items. An inventory can be simpler.

What matters is that it is accurate and used.

How often should it be updated?

Continuously if tools can do it, otherwise on every change and reviewed at a fixed interval. A yearly review is too slow for cloud systems that change weekly.

Discovery tools help find what manual lists miss.

Does it include data as well as systems?

It should. Knowing where personal and payment data sits is what lets you apply the right controls and answer regulators.

See data classification for how to label it.

Who owns the inventory?

Usually IT or security keeps it, but each entry needs an owner in the team that runs the asset. Central staff cannot know every service.

Owners confirm their entries on a schedule.

Sources