Data discovery is the process of finding where an organization's data is stored and moves, then labeling what is sensitive. It scans databases, file shares, cloud storage and SaaS apps, classifies what it finds, and feeds an inventory. You cannot apply controls, retention rules or breach notices to data you do not know you have.
Why does an inventory come first?
The NIST Cybersecurity Framework 2.0 groups inventories of hardware, software, services and data under its asset management outcomes in the Identify function. Every later outcome, from access control to incident response, assumes you know what you are protecting.
NIST's FIPS 199 gives the classic approach to the next step: categorize information by the impact of losing confidentiality, integrity or availability, using low, moderate or high levels. Discovery supplies the "what and where". Classification supplies the "how much does it matter".
How does discovery actually find things?
Most tools combine a few techniques.
- Metadata and schema crawling. Read table and column names. A column called
ssnordobis a strong hint. - Pattern matching. Look for formats such as card numbers, national IDs or email addresses in sampled content.
- Validation checks. A 16 digit number is not necessarily a card. A Luhn checksum test cuts false hits sharply.
- Context rules. A column of names next to dates and diagnosis codes suggests health data even when no single field matches a pattern.
- Access and lineage data. Who reads this store, and where does it get copied to? Copies often matter more than originals.
None of these is perfect. Pattern matching misses data in free text, images and compressed files, and flags test data as real. Expect to review samples by hand.
Where does sensitive data hide?
A constructed example: a support team exports a customer list to spreadsheet "just for a one-off analysis". The file lands in a chat channel, then in a personal download folder, then in a backup. The production database is well controlled. The copies are not.
Typical places that surface in a first scan:
- Logs and debug output containing tokens, emails or request bodies.
- Analytics and data warehouse copies with no retention limit.
- Shared drives with old exports and "final_v3" files.
- Test and staging databases restored from production.
- SaaS applications adopted by one team, with no central owner.
- Source repositories holding keys or sample data files.
How do you run it without drowning?
Pick a scope you can finish. Start with the systems named in your last risk assessment or regulatory scope, not the whole company. For each data store, record an owner, the data types found, the classification, and the retention period. Then act on the gap list: delete what has no purpose, restrict what is too open, and encrypt what is sensitive.
Repeat on a schedule. Data stores are created and copied constantly, so a one-time scan ages quickly.
What should you do with the results?
A finding is only useful when it leads to a decision. For each sensitive store, pick one of four outcomes: delete it because there is no purpose, shrink it by removing columns or old records, protect it with encryption and tighter access, or accept it with a named owner and a review date. Keep a short record of the choice. When an auditor, a customer or a breach investigator later asks where a type of data lives and why, you can answer from the inventory instead of reconstructing it from memory.
How to check or apply this
- List your data stores and name an owner for each. Include SaaS applications.
- Define three or four classification labels with plain examples.
- Scan or sample each store with pattern and context rules, and review a sample by hand.
- Record findings in the inventory: location, type, label, owner, retention.
- Fix the worst gaps first: open access, no encryption, no deletion date.
- Rescan quarterly and after major migrations.
Quick check
Is data discovery the same as data loss prevention?
No. Discovery finds and labels data at rest and in motion across your estate. Loss prevention enforces rules to stop specific transfers. Discovery results often feed those rules.
Do we need a tool, or can we do this by hand?
For a handful of systems, a spreadsheet and manual sampling work. At scale, tooling helps, but you still need owners and decisions.
Sources
- NIST Cybersecurity Framework
- NIST FIPS 199, Standards for Security Categorization
- NIST SP 800-53 Rev. 5, Security and Privacy Controls
Last reviewed: 18 October 2026.
