Pseudonymisation vs anonymisation GDPR: what counts

Pseudonymisation vs anonymisation under GDPR: which one takes data out of scope?

A data team or product owner who wants to reduce GDPR scope needs one fact settled first: pseudonymised data remains personal data, and only properly anonymised data falls outside the regulation. Article 4(5) defines pseudonymisation as replacing identifiers so that data can no longer be attributed to a person without additional information, and Recital 26 is explicit that such data stay personal data where that information exists. Replacing names with aliases or sequence numbers reduces risk and may help under Article 32, but it does not remove the data from the GDPR.

Whether data is anonymous depends on the means reasonably likely to be used to identify someone, judged by reference to cost, time and available technology. That makes the answer specific to each organization and each dataset. A table that is anonymous for one holder may remain personal for another that holds a linkage key, other datasets or the skills to combine them. Before relying on anonymisation, confirm who could re-identify the records, what other data they can access, how much effort re-identification would take with current tools, and whether the outcome would change if those circumstances changed.

The classification decision belongs to the controller. It must be documented, reviewed when the data, recipients or tools change, and defensible to a supervisory authority. An implementation partner can prepare the technical measures, such as separating and protecting any additional information, restricting access to re-identification keys, and testing whether records can be linked. Those results are evidence for the controller's assessment, but they do not decide scope. Only the controller's own assessment carries legal weight, and an independent auditor's review adds assurance without making the classification for the organization.

What decides whether a dataset is still personal data

Whether a dataset is still personal data depends less on its labels than on what a party could realistically do with it. The cards below cover the factors that change that answer, and each one names a check you can run against your own data and environment.

Key and mapping table custody

Pseudonymised data stays personal data while the key or mapping table that links aliases to people exists and can be used by someone. Recital 26 and Article 4(5) both turn on additional information kept separately. Check whether a mapping table exists, where it is stored, which roles can read it, and whether systems that hold the aliases can also reach the key. Record the answer, because a regulator will ask the same question.

Singling out, linkability and inference

Removing names does not remove identifiability. A record can still be singled out by a unique combination of fields, linked to another dataset through shared attributes, or have sensitive facts inferred from patterns. The EDPB's guidance on pseudonymisation and anonymisation treats these as separate risks. Test each one by asking whether a single record can be isolated, whether two datasets can be joined, and whether a value can be guessed from others.

Means reasonably likely to be used

Identifiability is judged against all means reasonably likely to be used, including cost, time and available technology. The test is about a realistic party, not the most capable attacker imaginable. Document who could plausibly attempt re-identification, what data and tools they could access, and how long and how much effort it would take. Anything that becomes cheap later, such as new matching techniques or public datasets, changes the answer.

Sharing with third parties

A dataset that is anonymous for one holder can remain personal data for another. If you pass records to a vendor, research partner or processor that also holds raw or linkable data, the recipient's means count. Map every recipient, the other data they already hold, and any contractual access to source systems. Where a recipient can combine the data with information it already has, treat the dataset as personal data for that flow.

Re-identification testing over time

Anonymity is not a one-time state. Data released today can be re-identified later as new datasets appear or analytical methods improve. Schedule re-identification tests, repeat them when the data, recipients or public context change, and keep the results with the assessment. The EDPB's 2025 coordinated enforcement action on erasure identified ineffective anonymisation used in place of deletion as a recurring problem, so untested anonymisation is a visible failure point.

Backups, logs and model outputs

Copies of a dataset often outlive the purpose that justified them. Backups, logs, exports, analytics warehouses and model training sets can each hold identifiable records even when the production system does not. Inventory every copy, decide whether each one is pseudonymised or anonymised, and confirm that the anonymised copies were produced by a documented process. Ask the same question for AI models trained on the data, since EDPB Opinion 28/2024 requires case-by-case assessment.

How common techniques are treated under the GDPR

Pseudonymisation replaces direct identifiers with an alias, token or sequence number so that the data can no longer be attributed to a person without additional information. Article 4(5) requires that this additional information be kept separately and protected by technical and organisational measures. Recital 26 is explicit that pseudonymised data remain personal data, so the GDPR continues to apply in full. The EDPB's small business guide gives the standard example: a data set where names and phone numbers are replaced by aliases or sequence numbers is still personal data.

Tokenisation: a random token replaces the identifier and a separate mapping table links them. Whoever controls the table can re-identify every record, so the table needs its own access controls and storage.
Hashing with a retained key: an HMAC or similar keyed hash of an identifier is stable across records. Anyone who holds the key can recompute the hash for a known value and match it, so the key is the additional information.
Aliases and sequence numbers: a customer ID replaces a name in an analytics extract. The mapping stays in the source system, which keeps the extract personal data.
Separation of duties: the organisation should document who can reach the additional information and how that access is logged and reviewed.

Before relying on pseudonymisation as a security measure, confirm where the key or mapping lives, who can reach it, and whether the pseudonymised set can be joined with other data the organisation holds.

Where anonymisation fails in enforcement

The clearest enforcement signal on this topic is the EDPB's 2025 coordinated enforcement action on the right to erasure, which covered 32 data protection authorities and 764 controllers and was announced on 18 February 2026. Among the seven recurring challenges the EDPB identified was ineffective anonymisation used in place of deletion. In practice, a controller that cannot or does not want to erase a record copies it, strips a few direct identifiers, and treats the result as anonymous. If the remaining fields, identifiers or linkable keys still allow a person to be singled out, the copy is still personal data and the erasure request is still open.

The same test applies to the copies most organizations forget: analytics extracts, data science sandboxes, reporting warehouses and exports sent to vendors. Ask each owner which fields remain, whether a join key or hashed identifier survives, and who can re-link the records to a person using other data they hold. Pseudonymised copies that keep a path back to the individual, such as a mapping table in the same environment, are personal data and must be covered by the same deletion or retention rules as the source. Confirm this with your data protection lead before declaring a dataset anonymous.

Backups carry the hardest version of this problem. The EDPB's erasure action also listed the deletion of personal data in backups as a recurring challenge, so a restore could bring back records a person has successfully asked to have erased. Organizations should document how backup sets are expired or overwritten, how restored data is re-checked against erasure records, and whether anonymising a backup is a credible alternative. Treat that last option with caution: it only holds if the anonymisation would survive the test described in Recital 26, and the outcome of the backup design should be confirmed with counsel and the relevant supervisory authority guidance before it is relied on.

How to reach and document an anonymisation decision

This sequence takes a team from a stated purpose to a documented decision on whether a dataset is still personal data or has been anonymised. Each step produces an artefact that an internal reviewer, a customer or a supervisory authority can check.

Define the purpose and map the data flows
The data protection lead and the system owner write down why the dataset exists, who needs it, and every place it travels, including backups, logs, analytics exports and sub-processors. Purpose matters because identifiability is judged against what the controller reasonably needs and can reach. The output is a data flow diagram and a one-page purpose statement that the decision will reference. The step is complete when every recipient and storage location is named.
Inventory identifiers and linkable keys
Engineers list every field that could single out a person, including direct identifiers such as names and account numbers, quasi-identifiers such as dates, postcodes and device identifiers, and any pseudonym or token that links records across systems. Each field is tagged with the way it could be linked to other data. The output is a field-level register that marks which values remain as keys. The step is complete when no field is unclassified.
Assess re-identification means and recipients
The controller considers all means reasonably likely to be used to identify a person, weighing cost, time and the technology available, and considers who receives the data and what else they hold. Where a recipient holds a key, a linkable dataset or the ability to query a model, the risk rises. The output is a written re-identification analysis covering each recipient and each realistic attack path. The step is complete when every recipient has a stated assumption about what it can combine with the data.
Apply the technique and test the result
The team applies the chosen technique, such as generalisation, suppression, aggregation or noise addition, and then runs tests against the output. Tests include attempts to single out records, link them to an external dataset that the recipients could hold, and check for rare combinations. Where the output is pseudonymised rather than anonymised, the test confirms that it is still treated as personal data. The output is a test report with the results and any residual risk. The step is complete when the report shows the tested attacks failed or the dataset is reworked.
Document the decision and its review trigger
The data protection lead records whether the dataset is personal data or anonymous, the reasoning, the technique, the tests and the accountable owner. The record names triggers for review, such as a new recipient, a new data source, a new release of a model trained on the data, or a change in available external datasets. The output is a signed decision record linked to the processing records. The step is complete when the record can be produced to an auditor or regulator without further explanation.
Keep key separation controls in place
Where pseudonymisation is the chosen measure, the team stores the additional information, such as the mapping table or key, separately from the pseudonymised data and restricts access to it. Access to the key is logged and reviewed under the same access control rules as other personal data. The output is an access list for the key store, its configuration evidence and the log extract showing who has used it. The step is complete when someone who can read the pseudonymised dataset cannot also read the key.
Keep deletion and backup evidence
Anonymisation is only useful if the source data is handled correctly. The team records how the original identifiable data is deleted or retained, how copies in backups and logs are handled, and when deletion occurs. Enforcement work by the EDPB has found anonymisation used in place of deletion, so the file should show that the decision did not replace an erasure obligation. The output is a deletion log, backup handling notes and a sign-off that the original data is no longer held for the anonymised purpose. The step is complete when the evidence can be matched to the decision record.

What to have in place before you claim anonymity

An organization that calls a data set anonymous takes the data outside the GDPR, so the claim has to be supported by documents an assessor can check. The cards below cover the records and tests that make that claim defensible, and each one asks a question an assessor is likely to put to you.

Written classification with reasons

Record whether each data set is personal, pseudonymised or anonymised, and the reasons for that call. Name the data subjects, the fields that could single someone out and the means reasonably likely to be used to identify them. An assessor will ask who made the decision, when it was last reviewed and whether the reasons would still hold if a new data set were joined to this one.

Register of pseudonymisation keys

Any key or mapping table that can reverse the alias keeps the data personal. List every location where the lookup key, salt or token vault is held, who can read it, and how it is stored apart from the working data. Confirm that access to the key is logged and approved. Assessors ask for this register first, because a copy of the key in an analytics environment undoes the claim.

Re-identification risk assessment

Test whether the data can still single out individuals once combined with public records, other internal data sets or outside datasets. Document the attacker you assumed, the cost and time they would need and the techniques considered, such as singling out, linkage and inference. Ask whether the assessment was done by someone who did not build the data set, and whether it covers free-text and rare-value fields.

Testing evidence for the anonymised output

Keep the test results that support the claim, including the attack scenarios run, the records flagged and the fixes applied before release. Record the parameters used, such as the grouping thresholds or noise levels, and rerun the tests after any change to the source data. Expect an assessor to ask whether a release was tested against the same data it will be combined with later.

Retention and deletion covering copies and backups

Map every place the source data, pseudonymised copy or anonymised output is stored, including exports, test environments, logs and backups. Define a deletion schedule for each copy and for the key, since deleting the key can end the link to individuals while the source remains. The EDPB's 2025 erasure enforcement action identified deletion of personal data in backups as a recurring problem, so check how backup copies are handled.

Periodic review and change control

Set a review date for each classification and re-run the re-identification assessment when the data, the recipients or the available outside data change. Keep a change log that shows who approved each review and what changed. Ask your team to confirm the trigger events in writing, so the review does not depend on memory. An assessor will check whether the claim still matches the data as it stands today.

Pseudonymise, anonymise or delete: which option fits

This table compares the three ways to handle personal data you no longer need in identifiable form: keep it pseudonymised, anonymise it, or delete it. Read each row for its GDPR status, the situations where it fits, and the evidence you should be able to produce if a regulator asks. The main takeaway is that only properly anonymised data leaves the GDPR, so the anonymisation test must be documented and must hold up against all means reasonably likely to be used.

Option	GDPR status	When it fits	Main evidence needed
Keep as pseudonymised data	Still personal data, with full GDPR duties applying	Analytics or testing where records must stay linkable to individuals through a separately held key	Documented separation of the additional information, access controls on the key, and a lawful basis for continued processing
Anonymise	Outside the GDPR only if no person is identifiable by any means reasonably likely to be used	Statistical or aggregate outputs, or datasets shared where re-identification risk is very low	A written anonymisation test covering re-identification risks, the techniques used, and periodic review of residual risk
Delete	No longer personal data once erased from all systems, including backups where the erasure process reaches them	Data with no remaining purpose, or where a valid erasure request applies and no exemption covers retention	Deletion logs, retention schedule entries, and evidence that backups and copies are handled under the erasure process
Anonymised by weak technique	Still personal data if re-identification is reasonably likely, so the GDPR continues to apply	Often chosen as a shortcut to avoid erasure work, which the EDPB flagged as a recurring problem	Re-identification testing that a reviewer could repeat, showing the technique is not reversible in practice
Pseudonymised data shared with a third party	Still personal data for the recipient if it holds or can obtain the key	Sharing with a processor or partner that does not hold the additional information	Contractual and technical proof that the recipient cannot access the key, plus a transfer assessment where relevant
Anonymised AI training data	Depends on a case-by-case test of the model and its outputs under EDPB Opinion 28/2024	Training or fine-tuning datasets where individuals could be identified or extracted from the model	Documented assessment of identification and extraction risk, confirmed with your data protection officer or adviser

Who owns the anonymisation decision and the evidence

The controller's data protection and engineering team owns the classification of every data set as personal, pseudonymised or anonymous. The GDPR places this responsibility on the controller, so no outside party can make the call on its behalf. The team decides what additional information exists, who can reach it, and whether the controller or a recipient could realistically re-identify a person using means reasonably likely to be used, including cost, time and available technology, as Recital 26 describes.

Classification register: A written record of each data set, its status and the reasoning behind that status.
Re-identification review: A documented assessment of linkage risks, outside datasets and attacker capability, repeated when the data or context changes.
Key and mapping ownership: A named owner for any pseudonymisation table or key, with access rules set by the controller.
Retention and erasure decisions: Choices on whether anonymised copies, backups and logs still fall under erasure duties.
Model and sharing reviews: Assessments before data trains an AI model or leaves the organization.

Check that the register names an accountable owner and that each anonymity claim points to a dated, reviewable reasoning file.

Questions buyers ask about pseudonymisation and anonymisation

Is pseudonymised data outside the scope of GDPR?

No. Pseudonymised data stays personal data under GDPR. Article 4(5) defines pseudonymisation as replacing identifiers so that data can no longer be attributed to a person without additional information, and that additional information must be kept separately and protected. Recital 26 is explicit that data which can be attributed to a person using that additional information remain personal data. The EDPB's small business guide gives the example of names and phone numbers replaced by aliases or sequence numbers, which remains personal data. Your organization still needs a lawful basis, must honor data subject rights, and must apply Article 32 security to the data and to the key or mapping table that links it back.

Does a certificate prove that our data is anonymous?

No. The GDPR requires no audit, attestation or certificate, and certification under Article 42 is voluntary, issued for at most three years, and does not reduce the controller's or processor's responsibility for compliance. Anonymity is a conclusion your organization must be able to justify with its own documented test, covering whether anyone could identify a person by means reasonably likely to be used, taking cost, time and available technology into account. An independent assessor may review that reasoning, but only an independent auditor or certification body issues any report or certificate. DeployOpen prepares the systems, documentation and evidence for that review; it does not issue attestations.

How long does a rigorous anonymisation test take, and what drives the effort?

The GDPR does not set a duration, and no supplied source gives one, so confirm timing against your own scope. Effort is driven mainly by the number of data sets, how many fields are quasi-identifiers such as dates, postcodes or job titles, how many other data sources could be combined with the output, and whether the data will be released publicly or shared with a limited group. Recipients with access to auxiliary data raise the bar. Ask any provider for a written scope listing data sets, fields, release model, and re-identification scenarios, then for the deliverables and timeline that follow from it. DeployOpen works on fixed scopes agreed in writing before work starts.

Can our own team run the anonymisation test in-house?

Often yes, for simple cases, provided the team has the skills and independence to run the test properly. Your data protection officer or privacy lead should own the conclusion, because the organization is responsible for it. Engineers can handle the technical work: inventorying fields, testing for singling out, linkability and inference, and documenting the additional information kept separately. External help is most useful when data sets are large, when the output is public, when data is shared with third parties, or when no one in-house has tested re-identification before. Some organizations use an outsourced DPO or an external audit for independent review, which is a separate service from the technical work.

What does the work need from our organization?

It needs named owners and access to the right people and systems. In practice that means a data inventory showing where personal data sits, the purpose for which each data set is kept, the people who hold the mapping or key tables, the recipients and any data they already hold, and the retention rules that apply. Engineering must be able to run queries and exports in a test environment, and legal or privacy staff must sign off on the outcome. Plan for backups and logs too, because copies outside the production data can keep the original identifiers. Ask your provider to list these inputs in the written scope so that delays do not surface mid-project.

Does the AI model test apply to models we buy from a vendor?

Yes, the test applies to the model itself, and you should check it even when a vendor built the model. EDPB Opinion 28/2024 says anonymity of an AI model is assessed case by case. The model is anonymous only if it is very unlikely that people whose data trained it can be identified, and very unlikely that such data can be extracted from it through queries. Ask the vendor for its training data sources, its testing for memorisation and extraction, and its documented assessment. If you fine-tune a model or feed it personal data at inference, your own processing is in scope regardless of the vendor's claim. Your own assessment and the vendor's evidence should be read together.

Does anonymisation remove our duty to delete data?

Only when the data is truly anonymous. The EDPB's 2025 coordinated enforcement action on the right to erasure, covering 32 DPAs and 764 controllers, identified recurring problems, including ineffective anonymisation used in place of deletion and deletion gaps in backups. Anonymising a data set that remains linked to identifiers does not satisfy an erasure request. Article 11 also means that where you can show you cannot identify a data subject, Articles 15 to 20 may not apply, but that argument must be demonstrated and documented, not assumed.

How DeployOpen prepares anonymisation and pseudonymisation evidence

DeployOpen prepares the technical side of pseudonymisation and anonymisation evidence inside your own infrastructure, under a fixed written scope agreed before work starts. Your organization decides which datasets are pseudonymised, which are treated as anonymised, and why. That classification, the purpose it serves and the retention decisions behind it remain your responsibility. DeployOpen does not decide whether a dataset is anonymous, does not issue audit reports, attestations or certificates, and does not guarantee a regulatory outcome. Independent assessors and supervisory authorities make those judgments.

On the technical side, the work usually covers separating the additional information that allows re-identification from the pseudonymised data, so that the key or mapping table sits in a different system with its own access control, logging and key custody. It can include a pseudonymisation pipeline that assigns aliases consistently, documented configuration for tokenization services, and test records showing which fields were replaced and whether the mapping can be reversed by the people who should not hold it. For anonymisation claims, the work can include re-identification testing against the released dataset, with the results written up for your assessor. Confirm with your team which systems hold the mapping, who administers them, and how that access is reviewed.

Deletion and backup handling deserve equal attention, because an anonymisation claim fails quickly if the original records survive in replicas, exports, snapshots or logs. DeployOpen can document the deletion routines, backup retention settings and restore procedures that determine how erased or re-identifiable data is treated over time, and test them in your environment. Ask for a written list of deliverables, the test method for each claim, the systems in scope and the evidence format before you sign. Your legal and privacy team should confirm the legal position with counsel, since the legal tests in Recital 26 and the EDPB guidance apply to your specific data and purposes.

Pseudonymisation vs anonymisation under GDPR