How to carry out a DPIA for a document anonymisation project
Anonymising documents sounds like a privacy safeguard rather than a privacy risk. Yet anonymisation is itself processing of personal data: someone, or something, has to read complete court judgments, medical records, case files or payslips to decide what to remove, often with an AI tool and at scale. If the output is going to be published or shared, a mistake exposes data permanently. That is why many anonymisation projects need a data protection impact assessment (DPIA). This article explains when one is required and how to carry it out, step by step.
Does your project need a DPIA?
Article 35 of the UK GDPR, mirroring the EU GDPR, requires a DPIA where processing is likely to result in a high risk to individuals' rights and freedoms, in particular when new technologies are used. The WP248 rev.01 guidelines, endorsed by the European Data Protection Board and still widely used as a reference in the UK, set out nine criteria; meeting two or more usually means a DPIA is needed. Anonymisation projects tend to tick several boxes at once:
- Sensitive or highly personal data: health, criminal offence data, children, victims, financial circumstances.
- Large-scale processing: whole archives, thousands of judgments, a historic records collection.
- Innovative technology: automated detection of personal data using AI.
- Vulnerable data subjects: patients, children, parties to legal proceedings, employees.
- Matching or combining datasets: where the anonymised document is published and could be linked with other sources.
The ICO's DPIA guidance includes its own list of processing that always requires a DPIA and a sample template. Even if you conclude that a DPIA is not mandatory, record the screening: accountability means you must be able to justify the decision. For a quick definition, see our glossary entry on impact assessments. In the US there is no general DPIA duty, although HIPAA's Expert Determination method for de-identifying health data also rests on a documented analysis of re-identification risk.
Step 1: describe the processing and its scope
Article 35(7) sets the minimum content: a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of risks, and the measures envisaged. For an anonymisation project the description should answer these questions precisely:
- Which documents: types (judgments, clinical letters, contracts), formats (native PDF, scans, Word, emails with attachments) and estimated volume.
- Why: publication, sharing with researchers, disclosure to a third party, reuse for model training, long-term retention.
- What output: irreversible anonymisation or reversible pseudonymisation. They are not the same: pseudonymised data remains personal data.
- Who is involved: the review team, the tool provider (a processor), the recipients of the output.
- Where and for how long: server location, retention of originals, anonymised versions and pseudonymisation keys.
Under necessity and proportionality, explain why publishing or sharing less is not enough and why the chosen level of anonymisation fits the purpose. Seek the advice of your data protection officer, which Article 35(2) makes mandatory where you have one, and consider seeking the views of the people affected or their representatives where appropriate.
Step 2: identify the risks specific to anonymisation
Generic risks such as unauthorised access or breaches still apply, but an anonymisation project has its own risks that the DPIA should name. The table below is illustrative; likelihood and severity depend on your context:
| Risk | How it happens | Common measures |
|---|---|---|
| Missed identifiers | The tool or the reviewer overlooks a name, NI number or address | Combined detection (AI plus patterns), human review, quality sampling |
| Indirect re-identification | Job title, date and town reveal who the document is about | Treat indirect identifiers, generalise, motivated intruder test |
| Reversible redaction | Black boxes over a PDF leave the text selectable | A tool that removes the underlying text; copy and search test |
| Metadata and hidden layers | Author, comments, revisions or an OCR layer retain data | Metadata removal and checks on the final file |
| OCR errors on scans | Misread text escapes detection | Stronger review of scanned pages, manual zones |
| Supplier and transfers | Text sent to language-model APIs abroad or reused by third parties | Processing in a defined jurisdiction, Article 28 contract, no external APIs |
| Key compromise | Whoever obtains the pseudonym map reverses it | Encryption, separate custody, access control |
Do not forget the opposite risk: over-redaction can make a published judgment or a research dataset useless. That is not a privacy harm, but it undermines the purpose, and the DPIA should justify the balance. Be concrete about re-identification: which public sources the output could be linked with, and who might be motivated to try. The ICO's anonymisation guidance frames this as the ‘motivated intruder’ test.
Step 3: measures and residual risk
For each risk, describe the technical and organisational measures and assess the risk that remains afterwards. Measures that usually make a real difference:
Measures worth documenting in the DPIA
- A written procedure: what is anonymised per document type, and on what criteria.
- Mandatory human review before publication or sharing, with a record of who signed off.
- Quality sampling and a re-identification test on the output.
- Technical checks on the final file: text not recoverable, no metadata.
- Processing location defined by contract, and a processor agreement with the supplier.
- Encrypted pseudonymisation keys and separation of duties.
- An audit log of access and operations.
- Staff training and periodic review of the DPIA itself (Article 35(11)).
Our GDPR anonymisation checklist can help make sure no control is left out. If the residual risk is acceptable, the DPIA ends with sign-off by the controller and a monitoring plan.
Step 4: do you need to consult the ICO?
Article 36 requires prior consultation with the supervisory authority before processing starts if the DPIA shows a high risk that you cannot mitigate. The ICO then has up to eight weeks to respond, extendable by six weeks for complex processing. In practice, a well-designed anonymisation project should rarely get there: a high residual risk usually signals that measures must be strengthened (more review, less data released, more generalisation) before you continue. If consultation is still needed, submit the full DPIA and the information listed in Article 36(3).
How Anonimatum supports your DPIA
Choosing the tool is part of the DPIA. Anonimatum makes several of the measures above easier to evidence: its own AI runs on servers in the European Union without sending text to external language-model APIs; it combines AI and pattern-based detection; it requires a preview and human review before anything is applied; redaction removes the underlying content and metadata can be stripped; pseudonymisation maps are stored encrypted; and the group dashboard includes an audit log. Politeia Soft holds Spain's ENS certification at medium level, with Anonimatum in scope; more on our security page. Compare the plans and get started online.
Frequently asked questions
Is anonymising documents a form of processing personal data?
Yes. You have to process the original data in order to anonymise it, so the process is covered by data protection law even if the final output, once truly anonymous, falls outside it.
Do we need a DPIA if we only pseudonymise?
It depends on the risk, not the technique. Pseudonymised data is still personal data, so if high-risk criteria apply (health data, large scale, AI), a DPIA is likely to be needed.
Who is responsible for the DPIA?
The controller, who must seek the DPO's advice where one is designated. The tool provider, as processor, supplies information about its own measures.