Classifying data you did not know you had

Data classification projects usually begin with a policy defining four levels and an instruction for staff to label documents. They usually end quietly, some months later, with a small proportion of documents labelled and no clear view of where sensitive data actually sits.

The reason is that the hard problem is not classification. It is discovery. You cannot classify what you have not found, and the copies that matter are rarely in the places the policy assumes.

Where sensitive copies actually accumulate

Non-production environments. Development, test, staging and training systems restored from a production backup because that was the fastest way to get realistic data. These environments typically have weaker access controls, more users, and less monitoring than production, which makes them one of the most common sources of exposure.

Reporting and analytics. Extracts built for an analysis, saved somewhere convenient, never deleted. Business intelligence tools that cache query results. Warehouses that aggregate across systems and therefore hold more sensitive combinations than any source did.

Spreadsheets on shared drives. Exports taken for a legitimate purpose (a reconciliation, a migration check, a board pack) and left where they were made. These are the hardest to find and among the most common.

Email and collaboration platforms. Attachments sent internally, files shared to chat, documents in personal cloud storage folders that are part of a corporate tenant.

Backups. Retained far longer than the source data, sometimes beyond the retention period the data itself is subject to, and often less protected.

Ticketing systems. Support tickets containing customer details, screenshots showing personal data, log excerpts pasted into a comment. Rarely considered a data store and frequently retained indefinitely.

Departed systems. The application replaced two years ago whose database still exists because nobody was confident it could be deleted.

Start with discovery, not policy

A useful sequence inverts the usual one.

Follow the data flows first. Where does personal or sensitive data enter the organisation, what systems process it, and where does it go afterwards. This is a conversation with people, not a scan, and it produces the map that tells you where to look.

Then scan the likely locations. Automated discovery against file shares, databases, object storage and collaboration platforms. Pattern matching for identifiers, financial data and whatever else is sensitive in your context. Expect a high false positive rate initially; tune it against your actual data formats.

Then reconcile against the asset inventory. Anything holding sensitive data that is not in your inventory is a finding in itself.

Then classify. By this point you know what exists and where, and classification becomes a decision rather than a guess.

Keep the scheme small

Elaborate classification schemes fail because people cannot apply them consistently. Three levels is usually enough, four is the practical maximum.

What matters is that each level has a clear handling consequence. A classification that does not change how data is stored, shared or retained is a label, not a control. If "Confidential" and "Internal" result in identical treatment, you have two words for one thing.

Write the handling rules alongside the levels, and keep them to a page.

Automate the labelling

Asking people to classify every document reliably does not work at scale, for the ordinary reason that it is extra effort with no immediate benefit to the person doing it.

What works better:

Classify at the source. Data from a system known to hold personal data is classified as such automatically, wherever it goes. This is far more reliable than judging each document.

Inherit by location. A folder or repository designated for sensitive data classifies its contents. Combined with restricting where such data may be stored, this covers a great deal.

Default sensibly. Rather than requiring a choice on every document, default to the appropriate internal level and require explicit action only to make something more or less restricted.

Reserve manual classification for exceptions. A small number of documents genuinely need human judgement. Asking for it on all of them means getting it on none.

What to do with what you find

Discovery reliably finds sensitive data in places it should not be. The response should be proportionate and, importantly, should address why it got there.

• Delete what is not needed. The cheapest control. Most discovered copies have no current purpose.
• Mask or synthesise in non-production. This removes a whole category of exposure permanently and is usually the single highest-value change a discovery exercise produces.
• Move what belongs elsewhere, and restrict the place it was.
• Fix the process that created the copy. If someone exported to a spreadsheet because the reporting tool could not answer their question, the spreadsheet will reappear. Solve the underlying need.

That last point is what determines whether the exercise holds. Copies are made for reasons. Removing the copy without addressing the reason produces a new copy within months.

Keeping it current

Discovery is not a one-off. Data spreads continuously, and a picture built once decays.

Run discovery on a schedule, quarterly is reasonable for most organisations, and compare against the previous run. What you are watching for is not the absolute count but the appearance of sensitive data in new locations, which tells you about a process that needs attention.

Add a discovery check to the points where data typically spreads: new integrations, new reporting tools, environment refreshes, and system decommissioning. Catching it at those moments is far cheaper than finding it a year later.