When your legal team asks if a dataset qualifies as anonymous under GDPR, you need a systematic evaluation framework, not just a gut feeling. This template provides a structured method to document your anonymisation assessment and justify your conclusions to supervisory authorities.
Purpose of the Template
This assessment template helps you determine whether a dataset meets the GDPR standard for anonymisation under Recital 26 and EDPB guidance. Use it to:
- Document the techniques applied to a dataset
- Evaluate residual re-identification risk
- Record your reasoning for supervisory authority review
- Demonstrate due diligence if your assessment is later challenged
The template addresses the three criteria the EDPB uses to evaluate anonymisation: singling out, linkability, and inference. If a dataset passes all three tests, it's no longer personal data under GDPR and falls outside the regulation's scope.
Prerequisites
Before using this template, ensure you have:
- The original dataset specification: Field names, data types, and sample records
- Documentation of transformation techniques: Aggregation levels, generalization hierarchies, noise parameters, or suppression rules applied
- Context about the dataset's intended use: Will it be published, shared with researchers, or used internally for analytics?
- Access to someone who understands the source data: You can't assess re-identification risk without knowing what auxiliary information exists publicly
Review EDPB Guidelines on anonymisation to understand current regulatory expectations.
The Template
ANONYMISATION ASSESSMENT RECORD
Dataset ID: [Internal reference number]
Assessment Date: [Date]
Assessor: [Name and role]
Review Status: [Draft / Under Review / Approved]
---
1. DATASET DESCRIPTION
Original Dataset:
- Source: [Where the data came from]
- Record Count: [Number of individuals in source]
- Time Period: [Coverage dates]
- Geographic Scope: [Countries, regions, or locations]
Intended Use:
[Describe who will access this data and for what purpose]
Anonymisation Techniques Applied:
☐ Aggregation (minimum group size: ___)
☐ Generalization (hierarchies: ___)
☐ Noise Addition (mechanism: ___)
☐ Suppression (fields removed: ___)
☐ Data Swapping (fields affected: ___)
☐ Synthetic Data Generation (method: ___)
---
2. RE-IDENTIFICATION RISK ASSESSMENT
Test 1: Singling Out
Can someone isolate records of a specific individual using this dataset alone or combined with other reasonably available data?
Quasi-identifiers present: [List fields that could narrow to small groups]
Smallest group size after aggregation: [Number]
Assessment: ☐ Pass ☐ Fail
Reasoning:
Test 2: Linkability
Can someone link two or more records concerning the same individual without knowing their identity?
Linkage keys that remain: [Any fields that could join to external datasets]
Known auxiliary datasets: [Public registries, prior releases, etc.]
Assessment: ☐ Pass ☐ Fail
Reasoning:
Test 3: Inference
Can someone deduce new information about an individual with significant probability?
Sensitive attributes in scope: [Health conditions, income, etc.]
Statistical disclosure risk: [Describe differencing attacks or other inference methods]
Assessment: ☐ Pass ☐ Fail
Reasoning:
---
3. OVERALL DETERMINATION
☐ Dataset qualifies as anonymous (all three tests passed)
☐ Dataset remains pseudonymous (one or more tests failed)
☐ Further anonymisation required
If pseudonymous: [Legal basis for processing](/glossary/legal-basis-for-processing): [Article 6(1)(___)]
---
4. DOCUMENTATION OF ASSUMPTIONS
Key assumptions underlying this assessment:
1. [e.g., "No attacker has access to the internal employee directory"]
2. [e.g., "The dataset will not be combined with future releases"]
3. [e.g., "Geolocation precision is limited to postal code level"]
Monitoring plan:
[How will you detect if assumptions become invalid?]
---
5. APPROVAL
Reviewed by: [Data Protection Officer or legal counsel]
Date: [Date]
Next Review: [Date, recommend annual or when context changes]
Customizing the Template
For high-risk datasets (health records, financial transactions, location trails): Add a section documenting your risk-utility tradeoff. Explain what precision you sacrificed to achieve anonymisation and why the remaining utility justifies the release.
For research partnerships: Add a "Data Sharing Agreement" reference field and document the recipient's contractual obligations. Even if you believe the dataset is anonymous, specify that the recipient can't attempt re-identification.
For public release: Include a "Motivating Attack Scenarios" section where you test whether a journalist, competitor, or academic could re-identify records using publicly available auxiliary data. The EDPB's discussions on anonymisation emphasize considering reasonably motivated adversaries, not just casual observers.
For cross-border transfers: If you're relying on anonymisation to avoid Chapter V transfer restrictions, add a section documenting why the receiving country's legal environment doesn't change your risk assessment. The EDPB's 2025 Annual Report highlights cross-regulatory cooperation on anonymisation standards, so assume your assessment may be reviewed by multiple authorities.
Validation Steps
Red team your quasi-identifiers: Give the anonymised dataset to a colleague who wasn't involved in the transformation. Ask them to identify three individuals they know are in the source data. If they succeed, your anonymisation failed.
Check for composition attacks: If you've released other datasets from the same population, verify that combining this release with prior ones doesn't enable re-identification. Differencing attacks are a common failure mode.
Document your rejection criteria: Before you start the assessment, write down what would cause you to conclude the dataset isn't sufficiently anonymised. This prevents motivated reasoning.
Version your assessment: Every time you update the dataset or learn about new auxiliary data sources, increment the assessment version and re-evaluate. Anonymisation isn't a one-time judgment.
Prepare for the "so what?" question: If a supervisory authority reviews your assessment, they'll ask why your chosen anonymisation level is appropriate. Your documentation should answer that before they ask.
The EDPB's comments on the European Commission's draft measures concerning Alphabet's compliance with Article 6(11) of the Digital Markets Act show that anonymisation is now a focal point in cross-regulatory enforcement. Your assessment record isn't just internal documentation; it's evidence that you applied the standard correctly.
