How to Run a Company Data Inventory Before You Sell

To run a company data inventory, list every system that stores records, describe what each holds, name an owner, flag personal and confidential content, note the contracts that govern it, and rank each dataset by demand and risk. Aim for a short ranked list of candidates, not a perfect map of everything.

Most companies cannot say, with confidence, what data they hold, where copies live and what they are allowed to do with it. That is normal. For a seller it is also a problem, because a buyer's due diligence will ask exactly these questions. This guide is built around a worksheet you can copy into a spreadsheet and fill in over a couple of working sessions.

Why do you need an inventory before selling data?

You need an inventory because selling data depends on facts you cannot guess: what exists, who created it, what it contains and what governs it. Without those facts, every other step is built on assumption.

An inventory protects you in three ways. It prevents you from selling something you had no right to sell. It shows you which datasets are valuable enough to justify preparation. And it gives you answers when a buyer asks about provenance, because the record already exists.

It also has uses beyond selling. The same document helps with security reviews, privacy requests, vendor changes and internal planning. If your company is considering selling data at all, build the inventory first, even before you check what the data might be worth.

Who should be involved, and how long should it take?

Involve one coordinator and a short list of system owners, and keep the first pass to a few focused sessions. A broad committee tends to stall, and a single person working alone tends to miss things.

A workable group looks like this:

• A coordinator who owns the worksheet and chases answers.
• Owners of the main systems: customer support, product, finance, operations and engineering.
• Someone who knows contracts, such as a legal or operations lead.
• Someone responsible for privacy and security, even if that is a part-time role.

For a small company, the first pass may take a handful of sessions. For a larger company, scope it by department and treat each as a separate pass. Timing varies widely with company size and how scattered the systems are, so set the scope first and the schedule second.

What should the inventory capture?

The inventory should capture enough to answer four buyer questions: what is it, where did it come from, what is in it and what may we do with it. Anything beyond that can wait.

The core worksheet columns:

1. Dataset name: a plain description, such as "resolved support tickets, product A".
2. System and location: the application, database or storage where it lives, plus known copies and exports.
3. Record type and format: tickets, transactions, documents, logs; structured or free text.
4. Time span and approximate volume: from when to when, and roughly how many records.
5. Origin: created by staff, submitted by customers, supplied by a vendor or imported from a third party.
6. Internal owner: a named person who can answer questions.
7. Personal data: none, some, or substantial; which fields; any special categories.
8. Confidential content: client names, deal terms, trade secrets, secrets and credentials.
9. Governing terms: customer contracts, privacy notice, vendor terms and any restrictions found.
10. Quality notes: consistency, gaps, duplicates, and whether outcomes or labels exist.
11. Preliminary rating: green, amber or red for sellability, with a one-line reason.

You can add columns later. A worksheet people abandon because it is too long is worse than a short one they finish.

How do you find all the data in the first place?

Start the hunt with a one-page questionnaire sent to each team, because asking is faster than auditing every system yourself.

Find it by following people, systems and money, not by trusting the official architecture diagram. Real data lives in the places people actually work.

• Ask each team: what systems do you log into, what do you export, and what lives in spreadsheets?
• Review the software subscription list from finance. Every tool is a potential store.
• Check cloud storage, shared drives and data warehouses for large or old folders.
• Look at backups, archives and legacy systems no one uses any more.
• Ask engineering about logs, event streams and analytics pipelines.
• Ask about data from acquisitions, former vendors and old projects.

Do not rely on memory alone, because the person who set up a system two years ago may have left, and the data may still be running. Shadow copies deserve special attention. Exports that someone took for a report in an old chat thread often outlive the official system, and they may carry the same obligations.

How do you rate each dataset for sellability?

Rate each dataset on three questions, and write the reason for the rating in a single sentence: do buyers want it, do we have the right to license it, and can we prepare it at a reasonable cost? Two yeses and a maybe is amber. Any hard no on rights is red.

Use a simple scheme:

• Green: you created it, it contains little or no personal or confidential content, the contracts do not forbid it, and the structure is usable. Move to preparation.
• Amber: valuable, but it needs consent, contract review, de-identification or legal advice. Park it until those are resolved.
• Red: contractual or legal barriers, or content that cannot be separated from sensitive material. Do not sell.

This is general information and not legal advice. Where the rating turns on a legal reading of a contract or privacy law, ask a qualified lawyer. A clear picture of ownership helps, and who owns company data works through the common cases.

What does a filled-in row look like?

A filled-in row is short, specific and honest about unknowns. The following is a hypothetical example to show the level of detail, not a real dataset.

• Dataset name: resolved support tickets for a single product line.
• System and location: helpdesk platform, with a quarterly export saved in cloud storage.
• Record type and format: conversations in free text, with category and resolution fields.
• Time span and volume: a stated start and end date, with an approximate record count.
• Origin: written by customers and by support staff.
• Internal owner: head of customer support.
• Personal data: yes, names, emails and order numbers in the text; attachments present.
• Confidential content: some enterprise customer names; passwords occasionally pasted by customers.
• Governing terms: public terms of service, privacy notice, two enterprise contracts that must be read.
• Quality notes: resolution field filled in consistently only after a certain date.
• Rating: amber, pending contract review and redaction pilot.

Notice that the rating has a reason attached and a next step implied. That is what turns the worksheet into a plan. An amber with no reason is just a shrug.

Who reviews the worksheet before decisions are made?

Have a second person read it with a sceptical eye. Ask them to pick three rows at random and trace each claim back to a source, such as a contract clause or a system screen. If claims cannot be traced, mark them as unconfirmed. Buyers will do the same, and it is cheaper to find the gaps first.

What do you do with the finished inventory?

Use it to pick one or two candidate datasets, prepare them and create a listing. Resist the urge to prepare everything at once.

A sensible sequence is to take your best green candidate, run the checks in how to sell your company data step by step, and cut a representative sample. Then write a data card using the inventory fields as your starting point. Listing is free on LogitAtlas, and the platform commission is 10%, deducted only when an order completes. The sell page explains how to start.

Amber datasets can follow when the open questions are answered. Keep the inventory alive by assigning an owner and reviewing it on a schedule, say once or twice a year, and whenever a major system or contract changes.

How do you keep the inventory honest over time?

Attach the inventory to events that already happen. When a new system is bought, a contract is signed or a team is reorganised, update the relevant row. When a customer asks about their data, check whether the answer matches the worksheet. A small habit of correction is worth more than an annual clean-up that nobody has time to do.

It also helps to record the date each row was last checked and by whom. A row that has not been checked for a long time should be treated as a hint, not a fact, and re-confirmed before anyone relies on it for a sale.

What mistakes make inventories useless?

Inventories fail when they are too ambitious, too stale or too disconnected from decisions. The remedy is to keep the scope narrow and tie each entry to an action.

• Trying to catalogue every table in every system in the first pass.
• Leaving out contracts, so the inventory describes data but not rights.
• Writing vague descriptions like "customer data" instead of specifics.
• No named owner, so no one can answer follow-up questions.
• Treating the inventory as a one-off project instead of a living document.
• Rating everything green because the data feels harmless.

The last one is the most expensive. If your first pass produces no amber or red datasets, you have probably not looked hard enough at the contracts and the free-text fields.

Frequently asked questions

What is a data inventory?

A data inventory is a structured list of the data a company holds: what it is, where it lives, who owns it, what it contains and what rules apply. For a seller, it is the factual base for deciding what can be licensed and for answering a buyer's due diligence questions.

How detailed does the inventory need to be?

Detailed enough to answer what the data is, where it came from, what it contains and what governs it. You do not need field-level maps for everything. Go deep only for the two or three datasets you may sell, and keep the rest at summary level.

Do I need special software to run an inventory?

No. A shared spreadsheet is enough for a first pass. Specialist tools can help in large organisations with many systems, but they do not replace conversations with the people who know the data. Start simple and add tooling only if the spreadsheet becomes unmanageable.

Who is responsible for the inventory in a small company?

Usually a founder, an operations lead or a technical lead takes it on, with input from whoever manages contracts and privacy. What matters is that one named person owns the worksheet and that each dataset has an owner who can answer questions about it.

What if the inventory shows we cannot sell anything?

That is a useful result. It means you avoided a costly mistake, and you now know what to change. You can adjust future contracts and notices so that later data is licensable, or create new data deliberately.