Building the Data Inventory

Everyone agrees an inventory is necessary. Most attempts become enterprise-wide discovery projects that produce a spreadsheet nobody maintains.

There is a smaller version that works.

Start from consequence, not from systems

The instinct is to enumerate every system and catalogue its contents. This takes a year and produces a list dominated by things that do not matter.

Start instead from the question: what information, if it left this organisation, would cause real harm?

Most organisations name between six and fifteen categories. Customer personal data. Payment details. Employee records. Financial results before release. Product designs or source code. Deal documents and pricing. Security configuration. Legal matters under privilege.

That list is the inventory's spine, and it takes a morning with the right five people.

Then find where each lives

For each category, three questions:

Which systems hold it? The systems of record, and — more importantly — the places copies accumulate. Reporting databases, exports, shared drives, someone's inbox.

Who has access? Not who should. Who does. This is where most of the surprises are.

How does it leave? Export functions, APIs, integrations, reports, sync.

The copies are the problem. A customer database with tight controls is not the exposure; the quarterly extract someone saved to a shared folder in 2019 is.

Discovery tooling helps and does not decide

Automated discovery scans repositories for patterns and reports where they occur. Useful for finding the copies you did not know about, particularly structured data with recognisable formats.

Its limits: it finds what it has patterns for, it does not know what matters to you, and it will return an enormous number of results requiring triage.

Use it after you have the category list, to find instances. Using it before produces a report of every file containing something that looks like a phone number.

Keep it small enough to maintain

An inventory that is not maintained is worse than none, because decisions get made on it after it stops being true.

One page per category, not per system. What it is, why it matters, where it lives, who has access, how it leaves, what controls apply.

Named owner per category. Someone in the business, not in security.

Review annually, and on any significant system change.

Version and date it visibly. A reader needs to know how much to trust it.

What the inventory is for

Not compliance paperwork. Four practical uses:

Targeting controls. Policies point at locations and channels. Without the inventory you are guessing.

Triage. When an alert fires, knowing whether the file came from a category that matters determines the response.

Access review. The list of who has access, compared against who needs it, is usually the highest-value output of the whole exercise.

Breach assessment. When something does happen, the first question is what was exposed. Answering it in hours rather than weeks depends on having done this beforehand.

The realistic timeline

Category list: one workshop. Locating the top three categories: two to four weeks. The rest: incrementally, as you go.

An inventory covering the three things that matter most, accurate and maintained, beats a comprehensive one that was true last year.