A data inventory is a list of the kinds of records your business holds, where each kind lives, who inside the business can reach it, and which outside company touches it. If you want to know how to build a data inventory, the method is to start from the work rather than the systems: walk through what your business actually does, note the records each step creates or uses, and only then write down where those records sit.
This article is general information about documentation and recordkeeping. It is not legal, compliance or security advice. Which obligations and frameworks apply to any given business varies by organization, industry and jurisdiction, and questions about what you must hold, disclose or delete belong with a qualified professional who knows your situation.
What a data inventory is, and what it is not
A data inventory describes categories of records, not individual files. “Client intake forms” is a row. “Smith_intake_v3.pdf” is not. Getting that distinction right at the start is the difference between a document you finish and one you abandon.
It is not a list of computers, and it is not a list of logins. Those are useful documents and they are different documents. A data inventory answers one question in several directions: what do we hold, and what else is attached to it.
It also is not a one-time exercise that produces a diagram for a wall. The useful version is a plain table that somebody edits when the business changes how it works.
How to build a data inventory from the work, not the systems
Starting from systems produces an inventory that mirrors your software bill and misses whole categories of records, because the things that cause the most trouble usually live in spreadsheets, shared mailboxes and personal drives rather than in named platforms.
Start instead with four to eight processes that describe how the business actually runs. For most small businesses that is something close to: getting inquiries, turning them into clients, delivering the work, invoicing and getting paid, hiring and paying staff, and handling questions or complaints after the fact.
For each process, ask three questions in order:
- What records does this step create? Inquiry details, signed agreements, work product, time records, invoices, payment details, resumes, payroll records.
- What records does this step need to read? Often more than it creates, and often from another team.
- Where did the person doing the work actually put it? Ask the person doing the work, not the person who designed the process. The answer is frequently a second place nobody documented.
That third question is the whole value of the exercise. Shadow copies are not an edge case; they are how businesses work, and an inventory that pretends otherwise is a tidy document about a business that does not exist.
Grouping records into categories
Aim for somewhere between fifteen and forty rows. Fewer than ten usually means you have written down departments. More than sixty usually means you have started listing files.
Group by sensitivity and by who the records are about, because those are the two distinctions you will need later. Client records, employee records, financial records, supplier records and internal operating records is a serviceable starting split. Keep sign-in credentials and payment details as their own rows wherever they appear, since they tend to need different handling from everything around them.
The columns in a data inventory
Keep the table narrow. Every column has to be filled in on every row, forever, by somebody who has other work.
| Column | What goes in it | Note |
|---|---|---|
| Record category | Plain name, in your own words | “Client intake forms”, not a system name |
| What it is about | Clients, employees, suppliers, the business itself | Drives most later questions |
| Where it lives | The primary place, named plainly | One row can list a second place |
| Also held in | Shadow copies, exports, mailboxes, local drives | The column most often left blank and most often needed |
| Who can reach it | Roles or named people | Roles for larger teams, names for small ones |
| Outside company involved | The vendor or contractor that touches it | Cross-reference to the vendor file |
| Internal owner | One person, by name | The person who confirms the row at review |
| How long we keep it | Your current practice, stated honestly | Write what happens today, not the aspiration |
| Last reviewed | A date | A row with no date is unverified |
Two of those columns do most of the work. “Also held in” is where exports, email attachments and old backups show up, and it is the column that turns the inventory from a description of your software into a description of your business. “Outside company involved” is the link between this document and your vendor records, and it is the reason the two are worth building in the same month.
Who can reach each record set
Fill this column with what is true rather than what was intended. The honest version is usually broader than the designed version, and the gap is the point of writing it down.
Work at the level of roles for anything with more than a handful of people, and at the level of names for a small team. Note where access is wider than the process needs, as a plain statement rather than a finding, and let that note become an entry in your risk register rather than a comment buried in a cell.
Three things belong in a note next to this column whenever they apply. Records that anyone in the business can open. Records held in a place where access is controlled by one person’s personal account. And records where a departing team member’s copy would not come back automatically. None of those are unusual, and all three are easier to deal with once they are visible on one page.
Which vendor touches which records
This is where the data inventory pays for itself, because it answers the question customers and suppliers ask most often and the one that is hardest to reconstruct from memory.
For each row, name the outside companies that can see or hold those records in the course of delivering their service. That includes the obvious ones and three categories people routinely miss: contractors and freelancers working inside your systems, services that hold copies rather than originals, and the companies your own vendors rely on, to the extent they tell you about them.
Keep it as a cross-reference rather than a duplicate. The inventory names the vendor; the vendor’s own folder holds the detail of what was asked and what came back. When those two documents point at each other, a question about one record category can be answered in a couple of minutes.
Where a vendor appears against a row and no vendor file exists, that pairing is the next piece of work. It is also the most common finding of a first inventory, which is a useful thing to discover from a table rather than from a customer’s question.
How to build a data inventory that stays current
An inventory goes stale in a predictable way: the business changes how it works, and nobody tells the document. Fix that with triggers rather than discipline.
Attach a review to four events: a new outside company is engaged or an existing one ends, a new line of work starts, a system or shared location is replaced, and someone whose name appears as an owner leaves or changes role. Those four cover most real changes.
Then hold one short scheduled pass, twice a year for most businesses. Each owner confirms their rows, corrects the “also held in” column, and sets a date. Record that the pass happened even when nothing changed, and keep the previous version rather than overwriting it.
Build the first version in a single sitting from the processes you already know, accept that it will be incomplete, and improve it at the triggers. A short inventory that gets edited beats a detailed one that was accurate once. For a plain list of the records that belong next to it, including the vendor files and register entries it cross-references, see the Trust Center Document Checklist page on this site.