When are hashed, aggregated, synthetic or pseudonymous data truly anonymous?

Short answer

Data are anonymous under EU data-protection law only if they do not relate to an identified or identifiable person, or have been altered so that the person is not or is no longer identifiable by means reasonably likely to be used. The assessment is practical and contextual. It considers the data, available linkage material, recipients, legal access routes, cost, time, technology and likely future developments—not the name of a technique.

Hashing or replacing names normally leaves pseudonymous personal data where someone can test inputs, reconnect source records or obtain the key. Aggregates can be anonymous, but small cells, repeated queries and external data may enable inference. Synthetic data have no automatic exemption. Pseudonymisation can make data non-personal for a recipient that genuinely cannot identify anyone, while they remain personal for the controller holding the key. The conclusion needs evidence and periodic review as recipients, auxiliary data, attack methods and available technology change.

Anonymity is an identifiability test, not a format

The General Data Protection Regulation (GDPR), Regulation (EU) 2016/679, has applied since 25 May 2018. Article 4(1) defines personal data broadly as any information relating to an identified or identifiable natural person. Recital 26 then supplies the test for indirect identification: consider singling out by the controller or another person and all means reasonably likely to be used.

“To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments.” —

Absolute mathematical impossibility is not the test, but deleting a name is insufficient. Assess realistic recipients, auxiliary data they can obtain, and whether technical, contractual and legal barriers prevent identification. The answer can change after wider release, new linkage data or technical progress.

The Court of Justice illustrated the boundary in Case C-582/14, Breyer. A website operator's dynamic IP address could be personal data even though the subscriber information was held by an internet-service provider, because legal channels could allow the operator to obtain identification through competent authorities. The Court also explained the opposite limit:

“that would not be the case if the identification of the data subject was prohibited by law or practically impossible on account of the fact that it requires a disproportionate effort in terms of time, cost and man-power, so that the risk of identification appears in reality to be insignificant.” —

The judgment interpreted the GDPR's predecessor, but later Court judgments use the same reasoning for GDPR Article 4(1) and Recital 26.

Pseudonymisation usually keeps the GDPR in play

Pseudonymisation is expressly defined as processing personal data:

“‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person;” —

Separating a code key, restricting access and logging re-linking reduce risk. Recitals 28–29 encourage those safeguards. A controller retaining the key or source table can still identify people, so the data remain personal. Pseudonymisation supports security and data protection by design; it is not itself anonymisation.

The Court refined the recipient question in Case C-413/23 P, EDPS v Single Resolution Board, a 4 September 2025 judgment under the parallel data-protection regulation for EU institutions. The Court said its personal-data definition must be interpreted homogeneously with GDPR Article 4(1). It then held:

“It follows that, contrary to what the EDPS maintains, pseudonymised data must not be regarded as constituting, in all cases and for every person, personal data for the purposes of the application of Regulation 2018/1725, in so far as pseudonymisation may, depending on the circumstances of the case, effectively prevent persons other than the controller from identifying the data subject in such a way that, for them, the data subject is not or is no longer identifiable.” —

This is not a blanket “recipient has no key” exemption. The recipient must be unable to defeat the separation or identify by cross-checking other factors, and further recipients' reasonable means matter. The original controller's obligations can also be fixed earlier: in that case, the duty to identify potential recipients was assessed from the controller's perspective when data were collected, regardless of whether a later recipient could identify them. The Court set aside the General Court judgment in T-557/20 and referred the case back, so that set-aside judgment should not be treated as the final word.

What each technique does—and does not prove

Technique	Main identification route	Likely legal position
Hashing or tokenisation	Guessing likely inputs, matching repeated values, source tables or retained keys	Usually pseudonymous while reasonable linkage remains
Aggregation	Small cells, rare attributes, differencing between releases, repeated queries	Anonymous only after realistic singling-out, linkage and inference testing
Synthetic records	Memorisation, one-to-one “twins”, rare combinations, membership or attribute inference	Depends on whether outputs or generators still relate to identifiable real people
Pseudonymisation	Separately held additional information or other cross-linking data	A GDPR safeguard; status may differ by actor and processing context

Hashed identifiers

A cryptographically one-way hash is not necessarily anonymous. Predictable emails or telephone numbers can often be hashed again and compared, while a deterministic hash links datasets. A secret salt or keyed hash raises attack cost, but data remain personal for an actor holding the key, original values or another reasonable route back.

Case C-604/22, IAB Europe, concerned an encoded consent string rather than a hash. Its principle is directly useful: the string remained personal where it could reasonably be associated with an IP address, even though the organisation did not itself hold every linking item. An actor's entitlement to require linkage information from participating organisations mattered. A controller cannot assess a code in isolation from the system around it.

Aggregated data

An average or count may be anonymous where broad groups and disclosure controls prevent reconstruction. A one-person cell, rare attributes, or the difference between near-identical queries may reveal an individual. Multiple “safe” releases may also become linkable.

Useful tests ask whether anyone can single out a person, link records about the same person, or infer an attribute with meaningful confidence. Thresholds such as minimum cell sizes can help, but no universal number guarantees anonymity; the surrounding population and auxiliary data determine the risk.

Synthetic data and trained models

“Synthetic” is not a GDPR category. Creating synthetic records from personal data is itself processing and needs the ordinary GDPR basis, safeguards and purpose controls. The result may be anonymous if it does not relate to real identifiable people and realistic tests show no reasonable extraction, membership inference or re-linking. A record-by-record synthetic twin, a copied outlier or a generator that reproduces training examples can remain personal.

The European Data Protection Board's non-binding asks whether both direct or probabilistic extraction and intentional or accidental obtaining of training subjects' personal data through queries are insignificant. That model-specific test should not be applied mechanically to every synthetic table. It does show why “the model stores weights, not rows” is insufficient: inference, intended users, unintended access and the release environment matter.

A defensible anonymity assessment

Before treating information as anonymous:

Map every controller, processor, recipient and plausible unintended holder.
Inventory source data, code keys, salts, lookup tables, public sources and contractual or legal routes to additional information.
Test singling out, linkage, inference, guessing, differencing and extraction against the actual release conditions.
Record attacker capability, cost, time, available technology and why each route is or is not reasonably likely.
Separate the controller's position from each recipient's position, while preserving duties that arose before disclosure.
Reassess after new releases, recipients, auxiliary datasets or technical developments.

GDPR Article 11 does not change that test. It can relieve a controller from collecting extra identifying information solely to answer rights requests when its purposes no longer require identification. It does not declare the data anonymous or switch off every other GDPR duty.

Conclusion

EU law treats anonymity as a proven absence of reasonably likely identification, not as a label attached to hashing, aggregation, synthetic data or pseudonymisation. The same protected dataset may remain personal for a controller holding the key yet be non-personal for a genuinely separated recipient, provided other reasonable identification routes are also blocked. The sound approach is therefore to test the complete data environment, each actor and foreseeable technology—and to revisit the conclusion as that environment changes.

Sources

This article provides general legal information, not advice for a specific matter. Laws, facts and procedural deadlines may change the result. Follow the linked primary sources and obtain local advice before acting.