The classification of sensitive data consists of identifying, categorizing and then labeling any information falling under the particular categories of the GDPR (health, biometrics, political opinions, religion) or presenting a high business risk. The first action to take is not technical, it is organizational: map your critical deposits (HR, health, finance) then apply a simple taxonomy to them with 3 or 4 levels. Pseudonymization comes next, as a pivotal technique to continue to exploit this data, particularly with AI, without exposing the identity of the people concerned.
In brief:
>
- Accurate classification of sensitive data must be based on organizational mapping and a clear four-level taxonomy, to avoid excessive complexity.
- The majority of classification errors come from overly ambitious implementation or insufficient review, which exposes you to regulatory and reputational risks.
- Hybrid automation, combining content and context analysis, enables effective detection while facilitating human review of critical cases.
- The pseudonymization of sensitive data, carried out in real time by Safe-doc, allows secure AI exploitation while ensuring the non-exposure of identities.
- The success of a classification project depends on clear governance, the involvement of business teams, and a regular review to maintain the relevance of the system.
Table of contents
- What is sensitive data according to the GDPR?
- Why classification determines the effectiveness of DLP
- How many classification levels should be defined?
- How to automatically detect and label sensitive data?
- What steps should I follow to launch a classification project?
- What technical controls should be associated with each sensitivity level?
- How Safe-doc facilitates the pseudonymization of sensitive documents
- What errors should you avoid in a classification project?
- What the field is learning about conducting a classification project
- Test Safe-doc on your most sensitive documents
- Sources
What is sensitive data according to the GDPR?
The GDPR does not speak of “sensitive data” in the strict sense. The text mentions “special categories of data”, defined by article 9 of the GDPR, and this list is closed. It covers racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data, health data and data relating to sex life or sexual orientation. Their processing is prohibited in principle, unless a specific exception applies.
Concretely, in a company, these categories are often hidden where you don't expect them: an HR file mentioning long-term sick leave, an access badge coupled with a fingerprint, a mutual insurance form collected by the payroll department. These are not isolated cases. HR files are also among the most documented sources of data breaches in companies.
To legally process this data, two cumulative conditions are required:
- A legal basis under Article 6 (consent, legal obligation, legitimate interest, etc.).
- A specific exception provided for in Article 9(2), such as explicit consent, the execution of obligations in terms of labor law or the public interest in health.
Health data remains the category most exposed to sanctions: it accounts for more than 30% of fines linked to specific categories according to legal analysis of article 9. The CNIL has regularly reminded, in its deliberations on medical practices or mutual insurance companies, that the absence of a documented legal basis is sufficient to justify a sanction, even without a proven leak.
Why classification determines the effectiveness of DLP
A data leak prevention (DLP) policy without prior classification amounts to installing sensors without knowing what they should detect. This is the observation that CISOs regularly make: classification is the fundamental building block of a successful DLP program, because rules applied to a poorly defined perimeter generate either too many false positives or dangerous blind spots.
The concrete benefits of a well-conducted classification are quickly measured:
- Finer access rules, based on the actual level of sensitivity rather than on hypotheses.
- A measurable reduction in unnecessary DLP alerts, therefore less fatigue for security teams.
- Facilitated traceability in the event of CNIL control or internal audit.
Conversely, not classifying has a direct cost. Sanctions linked to health or HR data are never anecdotal, and the reputation of a company implicated for a medical data leak often takes longer to rebuild than the budget devoted to the fine itself.
How many classification levels should be defined?
Four levels are enough in the vast majority of organizations, and adding more granularity tends to complicate adoption without any real gain in security.
Public includes information that can be distributed without restriction: press releases, commercial brochures, content already published on the institutional site.
Internal use covers documents that should not leave the company without being confidential in the strict sense, such as an organization chart, a memo or a team meeting report.
Confidential corresponds to information whose disclosure would harm the company or a third party: commercial contracts, unpublished financial data, standard customer files.
Restricted brings together everything that falls under the special categories of Article 9, industrial secrets or data whose leak would result in a direct regulatory sanction: health records, biometric data, individualized payroll information.
The decision criterion for placing a document in one or the other level is based on three axes: the financial impact of a leak, the legal risk incurred and the probable reputational damage. A confidential business contract does not have the same risk profile as a medical record, although both deserve serious protection.
Pro tip: do not exceed five classification levels. A taxonomy that business teams don't understand at a glance always ends up being misapplied, no matter how sophisticated your tools are.
How to automatically detect and label sensitive data?
Manual classification quickly reaches its limits: a volume of documents which exceeds a few thousand files makes the exercise humanly untenable, and errors of judgment accumulate over the course of tired rereading. Automation is based on three families of complementary techniques.
Content-based analysis scans the text itself using regular expressions (RegEx) for patterns like a social security number, or machine learning models that can recognize medical or legal context without an explicit keyword. Context-based analysis relies instead on metadata: the location of the file, the service that created it, the role of the author. A document stored in an “HR/health” folder already carries a strong signal even before being read.
Most organizations combine the two approaches, as one data classification reference guide points out. For unstructured files (PDF, DOCX), coupling RegEx and language models with contextual analysis avoids an inflation of labels which would end up swamping teams with unusable alerts.
The most robust workflow remains hybrid:
- Automatic detection in first pass, over the entire identified perimeter.
- Human review targeted on ambiguous or high-stakes cases, never on the entire flow.
- Permanent correction loop: each error reported must retrain the model or refine the rules.
Pro tip: automatic labeling without the possibility of manual exclusion always ends up misclassifying a subset of legitimate documents. Plan this correction mechanism from the design stage, not after the first incident.
What steps should I follow to launch a classification project?
A classification project that aims for completeness from the first quarter almost always fails. The right approach is iterative and follows a fairly stable sequence from one organization to another.
1. Define the objectives and the taxonomy: set the number of levels (ideally four), the decision criteria and those responsible for the final validation.
2. Inventory repositories: list storage locations, from file servers to data rooms, including often forgotten shared mailboxes.
3. Automatically discover sensitive content in these repositories, via tools combining RegEx, context and detection models.
4. Label the identified documents, with human review on borderline cases.
5. Apply the controls corresponding to the level detected: encryption, access restrictions, pseudonymization.
6. Monitor and audit continuously, to adjust the taxonomy and correct recurring false positives.
Starting with high-risk deposits, HR, health, finance, gives an immediate credibility effect with management, a point confirmed by practical guide on the key classification steps. Targeting a small but critical area first allows you to demonstrate a tangible result before expanding the project.
Four indicators make it possible to monitor progress: the coverage rate (share of deposits inventoried), the precision of the labeling, the average remediation time after detection of an anomaly, and the rate of false positives reported by the business teams.
What technical controls should be associated with each sensitivity level?
Each classification level must trigger a proportionate set of controls, otherwise the label remains a simple decorative mention in a governance table.
- Public: no particular technical restrictions, excluding version control to avoid erroneous publications.
- Internal use: access control based on organizational membership, with no strong encryption required.
- Confidential: encryption at rest, access control by role (RBAC), logging of consultations.
- Restricted: systematic encryption, access control by attributes (ABAC), dynamic masking and pseudonymization before any analytical processing or transmission to a third party.
Data platforms like those described in Databricks documentation on classification illustrate this principle well: a classification tag is directly linked to a masking or access policy, which makes the application of controls automatic rather than dependent on manual intervention for each new document.
Pseudonymization occupies a special place in this system. It makes it possible to use sensitive data for statistical analyzes or AI processing without exposing the identity of the people concerned, unlike anonymization which makes the data permanently irreversible and therefore often unusable for subsequent business needs. It is the tipping point between a rigid security policy and an organization that continues to exploit its data without taking on disproportionate regulatory risk.
How Safe-doc facilitates the pseudonymization of sensitive documents
Once the classification is posed, the question becomes operational: how to concretely process documents labeled “confidential” or “restricted” without blocking the teams who must analyze them or submit them to a generative AI tool?
Safe-doc meets this specific need. The platform detects more than 90 types of personal and confidential data (PII) within a document, then pseudonymizes it in real time, without ever storing the processed file, in accordance with the definition of pseudonymization set out in Article 4(5) of the GDPR. The document remains usable, including by ChatGPT or Claude, while the identity of the people concerned remains protected until controlled restoration via an exported mapping.
Three scenarios lend themselves particularly well to this use: the processing of legal acts including sensitive data in customer files, the analysis of internal HR files, and the accounting audit of financial documents before their passage into an external analysis tool. Before large-scale deployment, a test in real conditions on a batch of representative documents remains the best way to verify detection coverage on your own formats.
What errors to avoid in a classification project?
Projects that fail often share the same symptoms: wanting to classify everything at once, unclear governance over who validates the levels, and the absence of periodic reviews once the tool has been deployed. A system frozen in the first quarter becomes obsolete as soon as the organization changes structure or tools.
Best practices that make the difference on the ground:
- Adopt a simple policy, formulated in one page, rather than a fifty-page legal document that no one will reread.
- Keep label wordings understandable for non-technical teams.
- Maintain regular human review on ambiguous cases, not just at launch.
- Audit classification results quarterly, not once a year.
A minimum checklist before and after deployment: taxonomy validated by management, priority deposits inventoried, detection tool tested on a real sample, operational correction loop, and fixed review schedule.
What the field is learning about conducting a classification project
Most of the failures I see come not from a bad choice of tool, but from a project launched without a clear sponsor at the management level. A perfect technical taxonomy is of no use if business teams continue to store health records in a generic network share, because they have not been trained or involved in the process.
The lever that works almost systematically is to build the decision file around a risk already documented in your sector rather than a theoretical risk. Showing a CNIL sanction case comparable to your activity convinces a management committee more than an abstract compliance table. Clearly separating the classification policy, which is a matter of business decisions, from the technical rules that implement it, as recommended by the data governance guidelines, also prevents the project from remaining stuck awaiting legal validation on each technical detail.
- Jacques
Test Safe-doc on your most sensitive documents
Safe-doc is a direct continuation of a classification project: once your “confidential” and “restricted” documents have been identified, you still need to be able to process and analyze them without exposing them. Unlike a solution that archives your files for processing, Safe-doc never stores the submitted document. Processing is done in real time, with exportable mapping to restore data once analysis is complete, which is particularly suitable for legal departments and DPOs subject to strict auditability requirements.
Discover detailed operation of pseudonymization and launch a first test on your most sensitive files this week.
Sources
- GDPR sensitive data - Art. 9
- Guide to data classification: types, levels and best practices
- What is data classification? Types