Classifying sensitive data means identifying, categorizing, and then labeling any information falling under the GDPR's special categories (health, biometrics, political opinions, religion) or presenting high business risk. The first step is not technical-it's organizational: map your critical repositories (HR, health, finance) and apply a simple three- or four-level taxonomy. Pseudonymization comes next, as the pivotal technique for continuing to exploit that data, especially with AI, without exposing the identity of the individuals concerned.
In brief:
- Accurate classification of sensitive data must be based on organizational mapping and a clear four-level taxonomy, to avoid excessive complexity.
- Most classification errors stem from overly ambitious rollouts or insufficient review, exposing organizations to regulatory and reputational risk.
- Hybrid automation-combining content and context analysis-enables effective detection while allowing human review of critical cases.
- Real-time pseudonymization of sensitive data by Safe-doc enables secure AI exploitation while ensuring identities remain protected.
- A successful classification project depends on clear governance, business-team involvement, and regular review to keep the system relevant.
Table of contents
- What is sensitive data under the GDPR?
- Why classification determines DLP effectiveness
- How many classification levels should you define?
- How to automatically detect and label sensitive data
- What steps to follow when launching a classification project
- What technical controls to associate with each sensitivity level
- How Safe-doc facilitates pseudonymization of sensitive documents
- What mistakes to avoid in a classification project
- What field experience teaches about running a classification project
- Test Safe-doc on your most sensitive documents
- Sources
What is sensitive data under the GDPR?
The GDPR doesn't speak of "sensitive data" in the strict sense. The regulation refers to "special categories of personal data," defined in Article 9, and that 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 concerning sex life or sexual orientation. Processing such data is prohibited in principle, unless a specific exception applies.
In practice, these categories often hide where you least expect them: an HR file mentioning long-term sick leave, an access badge coupled with fingerprint authentication, a mutual-insurance form collected by payroll. These are not isolated cases. HR files are among the most documented sources of data breaches in business.
To process this data lawfully, two cumulative conditions must be met:
- A lawful basis under Article 6 (consent, legal obligation, legitimate interest, etc.).
- A specific exception under Article 9(2), such as explicit consent, performance of obligations under employment law, or public interest in health.
Health data remains the category most exposed to sanctions: it accounts for over 30% of fines linked to special categories, according to legal analysis of Article 9. The CNIL has repeatedly stressed, in decisions on medical practices and mutual insurers, that the absence of documented lawful basis is sufficient to justify a sanction, even without a proven breach.
Why classification determines DLP effectiveness
A data loss prevention (DLP) policy without prior classification is like deploying sensors without knowing what they should detect. This is what CISOs regularly observe: classification is the foundational building block of a successful DLP program, because rules applied to a poorly defined scope generate either too many false positives or dangerous blind spots.
The concrete benefits of effective classification are quickly measurable:
- Finer access rules, based on actual sensitivity level rather than assumptions.
- A measurable reduction in unnecessary DLP alerts, and thus less fatigue for security teams.
- Easier traceability in the event of CNIL audits or internal reviews.
Conversely, failing to classify carries direct costs. Sanctions related to health or HR data are never trivial, and the reputational damage to an organization implicated in a medical-data leak often takes longer to repair than the budget allocated to the fine itself.
How many classification levels should you define?
Four levels are sufficient for the vast majority of organizations, and adding more granularity tends to complicate adoption without real security gains.
Public groups information that can be distributed without restriction: press releases, commercial brochures, content already published on the corporate website.
Internal use covers documents that should not leave the company but are not strictly confidential, such as an org chart, an internal 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 encompasses everything falling under Article 9 special categories, trade secrets, or data whose leak would trigger direct regulatory sanction: health records, biometric data, individualized payroll information.
The decision criteria for placing a document in one level or another rest on three axes: financial impact of a leak, legal risk incurred, and probable reputational harm. A confidential business contract does not carry the same risk profile as a medical file, even though both deserve serious protection.
Pro tip: Don't exceed five classification levels. A taxonomy that business teams can't grasp at a glance always ends up being misapplied, no matter how sophisticated your tools.
How to automatically detect and label sensitive data
Manual classification quickly hits its limits: a document volume exceeding a few thousand files makes the exercise humanly unsustainable, and judgment errors accumulate through fatigued reviews. Automation relies on three complementary families of techniques.
Content-based analysis scans the text itself using regular expressions (RegEx) to spot patterns like a social security number, or machine-learning models capable of recognizing medical or legal context without explicit keywords. Context-based analysis relies instead on metadata: file location, the department that created it, the author's role. A document stored in an "HR/health" folder already carries a strong signal even before being read.
Most organizations combine both approaches, as highlighted in a reference guide on data classification. For unstructured files (PDF, DOCX), coupling RegEx and language models with contextual analysis avoids a label explosion that would swamp teams with unusable alerts.
The most robust workflow remains hybrid:
- Automatic detection in a first pass, across the entire identified scope.
- Targeted human review on ambiguous or high-stakes cases, never on the entire stream.
- Continuous correction loop: every reported error must retrain the model or refine the rules.
Pro tip: Automatic labeling without a manual-exclusion mechanism always ends up misclassifying a subset of legitimate documents. Plan this correction mechanism from the design stage, not after the first incident.
What steps to follow when launching a classification project
A classification project aiming for comprehensiveness in the first quarter almost always fails. The right approach is iterative and follows a fairly stable sequence across organizations.
1. Define objectives and taxonomy: set the number of levels (ideally four), decision criteria, and those responsible for 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 those repositories, via tools combining RegEx, context, and detection models.
4. Label the identified documents, with human review on edge cases.
5. Apply controls corresponding to the detected level: encryption, access restrictions, pseudonymization.
6. Monitor and audit continuously, to adjust the taxonomy and correct recurring false positives.
Starting with high-risk repositories-HR, health, finance-delivers immediate credibility with management, a point confirmed by a practical guide on key classification steps. Targeting a narrow but critical scope first lets you demonstrate tangible results before expanding the project.
Four indicators track progress: coverage rate (share of repositories inventoried), labeling accuracy, average remediation time after anomaly detection, and false-positive rate reported by business teams.
What technical controls to associate with each sensitivity level
Each classification tier must trigger a proportionate set of controls, or else the label remains mere decoration in a governance spreadsheet.
- Public: no specific technical restrictions, except version control to prevent erroneous publication.
- Internal use: access control based on organizational membership, with no strong encryption required.
- Confidential: encryption at rest, role-based access control (RBAC), logging of consultations.
- Restricted: systematic encryption, attribute-based access control (ABAC), dynamic masking, and pseudonymization before any analytical processing or transmission to third parties.
Data platforms like those described in Databricks documentation on classification illustrate this principle well: a classification tag directly links to a masking or access policy, making control application automatic rather than dependent on manual intervention for each new document.
Pseudonymization occupies a special place in this framework. It allows you to exploit sensitive data for statistical analysis or AI processing without exposing the identity of data subjects, unlike anonymization, which makes data permanently irreversible and often unusable for subsequent business needs. It's the tipping point between a rigid security policy and an organization that continues to leverage its data without disproportionate regulatory risk.
How Safe-doc facilitates pseudonymization of sensitive documents
Once classification is in place, the question becomes operational: how do you concretely process documents labeled "confidential" or "restricted" without blocking the teams that need to analyze them or submit them to a generative AI tool?
Safe-doc addresses this precise need. The platform detects more than 90 types of personal and confidential data (PII) within a document, then pseudonymizes them in real time, without durably storing the processed file, in compliance 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 data subjects stays protected until controlled restoration via an exported mapping.
Three scenarios are particularly well-suited to this use: processing legal acts containing sensitive data in client files, analyzing internal HR files, and auditing financial documents before they pass through an external analysis tool. Before large-scale deployment, a test under real conditions on a representative batch of documents remains the best way to verify detection coverage on your own file formats.
What mistakes to avoid in a classification project
Failing projects often share the same symptoms: trying to classify everything at once, unclear governance over who validates levels, and the absence of periodic reviews once the tool is deployed. A system frozen at launch 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 no one will reread.
- Keep label wording understandable for non-technical teams.
- Maintain regular human review on ambiguous cases, not just at launch.
- Audit classification results quarterly, not once a year.
Minimum checklist before and after deployment: taxonomy validated by leadership, priority repositories inventoried, detection tool tested on a real sample, operational correction loop in place, and review calendar fixed.
What field experience teaches about running a classification project
Most failures I see stem not from a bad tool choice, but from a project launched without a clear sponsor at the executive level. A perfect technical taxonomy is useless if business teams continue to store health records in a generic network share because they weren't trained or involved in the initiative.
The lever that works almost every time is building the decision case around a risk already documented in your sector, rather than a theoretical risk. Showing a CNIL sanction case comparable to your activity convinces an executive committee more effectively than an abstract compliance matrix. Clearly separating the classification policy-which stems from business decisions-from the technical rules that implement it, as recommended by data-governance guidelines, also prevents the project from stalling while awaiting legal validation on every technical detail.
- Jacques
Test Safe-doc on your most sensitive documents
Safe-doc fits directly into the logical next step of a classification project: once your "confidential" and "restricted" documents are identified, you still need to process and analyze them without exposing them. Unlike a solution that archives your files for processing, Safe-doc does not durably store the submitted document. Processing happens in real time, with exportable mapping to restore data once analysis is complete-a feature particularly suited to legal departments and DPOs subject to strict auditability requirements.
Discover how pseudonymization works in detail and run 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