Asset Inventory

Protection only means something once you know what you are protecting. At a small company the gap never shows. Two servers and a handful of tools fit inside one person's head. Then teams multiply, each one starts paying for whatever software it needs, and nobody in the building can list everything the company now runs on.

The gap usually surfaces when someone outside asks. At Pagedeck, Grace came back from an enterprise prospect with a security questionnaire and asked where exactly customer data lived. Nobody knew, and it took three days of asking around to assemble an answer. The answer was still incomplete. A marketing survey tool, paid for on a company card, held about 4,000 customer email addresses, and two people on that team were the only ones who knew it existed.

An asset inventory answers that question with one table. It isn't a piece of security technology so much as a count, which makes it sound like the least interesting item in the field. Security governance puts it first because every other procedure takes this table as its input. An access review — pulling a list of who can reach what and revoking whatever is no longer needed — covers only the systems on the table. An incident response plan, which spells out who does what in what order when something goes wrong, gets its list of places to check from here as well. A system missing from the table drops silently out of both.

One row is one asset, and a row usually carries five columns.

1. Name and type — a recognizable name plus a category: server, database, third-party service, device.
2. Owner — one person to contact when this asset has a problem. A person's name, not a team's. Write "billing team" and nobody picks up the phone at three in the morning.
3. Data it holds — what information sits inside and how sensitive it is. A store of customer payment records and a test environment with no real data deserve different levels of care. Most teams mark this high, medium, or low, and start with the high rows.
4. Access — who can get in. Groups rather than a full roster of names, with admin accounts listed individually.
5. Location and contract — whether it runs on your servers or somebody else's, and when that contract ends if it belongs to somebody else. A $60-a-month tool with customer data inside takes that data with it when the vendor shuts down.

Filling the columns is the easy half. Deciding what deserves a row is the hard one. A table of servers and databases leaves out most of the places that actually get breached. Laptops, the repository holding the code, the company domain and the account that manages it, and the tools individual teams attach on their own all belong on it. That last group goes missing most often. A tool nobody ever approved appears on no official list, so you find it by reading payment records and login history rather than by asking people. The first time Pagedeck built the table, eleven tools surfaced that way, and four of them held customer information.

One person owns the table and many people fill it in. Whoever runs security sets the format and the refresh cycle and chases the missing rows, but the contents of each row come from the team that actually uses the asset. A security lead who researches everything alone finishes the survey with half of it already out of date.

Filling it in doesn't rely on memory. Three starting points do the work: charges on the company card, the list of third-party services signed into with company accounts, and the resource list from the cloud provider. Together they surface most of what nobody remembered, and only the remainder has to be asked about.

Three groups read it.

1. Whoever runs access reviews — picks which systems to pull permissions for this quarter out of this table.
2. Whoever handles an incident — checks what was breached and whether customer data sat inside it. Start building the table after the incident and the legally mandated notification deadline won't wait for you.
3. Whoever sits through an audit — security certification, the process of having an outside body confirm that a security program exists, asks for this table before anything else.

Refreshes happen at two moments: a scheduled sweep every quarter, and an immediate update whenever a tool is adopted or a system is retired. The second one carries more weight. With only the quarterly sweep, the table and reality drift apart for three months and then get reconciled in a rush, and rushed research is thin research.

"Is that service on the asset inventory? Register it first, then connect it."

Asking for a row before a new third-party tool goes live.

"Access review scope this quarter is the fourteen rows marked high sensitivity."

The sensitivity column narrowed the work instead of reviewing everything.

"About that customer security questionnaire — if the inventory is current, half of it is copy and paste."

Keeping the table current took time out of a sales cycle.

At Pagedeck the table gets opened in three situations: before a new tool is paid for, at the start of the quarterly access review, and when an enterprise customer sends a security questionnaire. Theo adds a row the day he creates a new repository, and Grace opens the table first when a questionnaire lands. The longest part of setting it up was not filling the columns. It was deciding who owns the table and when it gets refreshed.

The most common mistake is treating it as a document you build once. The word inventory invites that reading. In practice, at a company that attaches and drops tools every month, the table starts aging the day it's written. A table left alone for six months is worse than no table at all. Without one, you know that you don't know and you go look; with a stale one, you trust it and skip the looking.

Reading it narrowly, as a register of servers and hardware, is the other frequent error. The word asset calls up things you can see and put a price on. Most of what a company would hate to lose now sits on somebody else's servers — customer records in a payment processor and a support tool, source code in a hosted repository. Count only the physical things and the finished table holds none of the things worth protecting. A more useful test when you scan the table is to ask what stops working if this asset disappears tomorrow. That question puts a hosted repository and a survey tool on the list, and leaves the spare monitor in the supply closet off it.