Data classification and DLP: why your rules depend on it

Data classification tells the DLP what it must protect. A DLP rule only blocks what it knows how to recognise: a sensitivity label, a document fingerprint, a pattern or a keyword. If the classification is missing, incomplete or wrong, the DLP lets the data out without flagging anything, and this is often the first cause of false negatives.

This article explains how DLP relies on classification, where the usual gaps are and what this changes in the way you test your controls.

What the DLP actually “sees”

A DLP engine does not understand that a file is confidential. It applies conditions. Depending on the product, these conditions rest on four main families of signals:

Scroll the table →

The first three mechanisms are classification in the strict sense: someone, or a process, decided upstream that a piece of data was sensitive. The fourth tries to guess. A mature DLP combines both, but the rule that actually blocks almost always rests on a prior classification decision.

Labels: effective, provided they exist

Labels are the most direct lever. A rule such as “block the external sending of any document labelled Confidential” is clear, auditable and easy to explain to the board. The problem is not the rule. It is the coverage rate.

Where labels are missing

• The historical stock: network shares and document spaces that predate the classification project often remain unlabelled.
• Data generated outside office tools: CSV exports from an ERP, SQL extracts, application logs, screenshots. These formats frequently escape labels.
• Copy and paste: an extract of a labelled document pasted into a new file, a chat or a prompt loses the original label.
• Manual labelling under pressure: when the user chooses, they often choose the lowest level so as not to be hindered. A mandatory justification reduces the phenomenon without eliminating it.
• Conversions: printing to PDF, compressed archive, format change. Depending on the tool, the label follows or disappears.

Fingerprints: precise, but fragile

Document fingerprinting answers a different need: recognising a specific piece of content, for example a contract template, a technical data sheet or a patient record format. It does not depend on the user, which is a real advantage.

Its weaknesses are well known to the teams that use it:

• the reference corpus ages if nobody is in charge of updating it;
• the similarity threshold is a compromise: too strict, it misses variants; too loose, it generates useless alerts;
• some transformations of the content (partial extraction, rewording, change of structure) can push the document below the threshold.

Scenario: a “completed” classification that lets the essentials through

Take an industrial mid-sized company (ETI). The classification project is finished: four levels, default label “Internal”, automatic labelling on a few types of personal data. The DLP rule blocks the external sending of “Confidential” and “Secret” documents.

Manufacturing drawings are stored in a business application and exported as needed in PDF format or as an archive. These exports carry no label. No fingerprint has been created for these drawings, because they do not look like office documents. The result: the company’s most strategic data is the data the DLP does not recognise. Nobody notices, since no alert is triggered. The absence of an alert is read as the absence of a leak.

There is nothing exotic about this case. It illustrates the mechanism described in our article on DLP false negatives: the rule works, but it does not apply to the right data. For this type of context, see also protecting intellectual property against exfiltration.

Consequences for testing

If the DLP depends on classification, a test that ignores classification measures the DLP poorly. Three mistakes come up often.

Mistake 1: testing only with perfectly labelled data

Sending a file marked “Confidential” and observing the block proves that the rule exists. It says nothing about the real data that circulates without a label. A useful test varies the classification state of the data tested.

Mistake 2: testing with real data

To check that a customer file is recognised, the temptation is to use a real customer file. That is precisely what you must not do. Realistic synthetic data, built to trigger the same detection mechanisms (format, structure, label, decoy fingerprint), is enough and removes the risk. The topic is covered in detail in the article on synthetic data in production.

Mistake 3: testing once, at deployment

Classification moves: new applications, new export formats, cloud migration, changes to labels. A rule that is valid in January can be bypassed without any malicious intent in June.

The steps of a test that takes classification into account

1. For each category of sensitive data, identify the mechanism that is supposed to recognise it (label, fingerprint, exact match, pattern).
2. Prepare decoys in several states: correctly labelled, labelled at the lower level, unlabelled.
3. Replay the same decoys after common transformations: format conversion, archive, partial extract, copy and paste.
4. Cover the real egress channels: email, browser, cloud storage, endpoint, network.
5. Record for each case: blocked, alerted only, or passed without a trace.
6. Escalate the failures to two distinct teams: the one that configures the DLP and the one that owns the classification.

The last point is often neglected. A test failure is not always a DLP rule problem. It can reveal a classification gap, and the fix then does not belong to the same team. For the general method, see how to test your DLP and find out whether it really blocks, and the reference page on data exfiltration testing.

Should you wait for a perfect classification before testing?

No. It is even the opposite. Active testing is an excellent tool for prioritising the classification work. It shows which categories of data get out without being recognised, on which channels, and therefore where the labelling or fingerprinting effort pays off the most. Waiting for a complete classification means accepting months of blind spots on a project that, in most organisations, is never really finished.

Frequently asked questions