SynthProof

Is synthetic data personal data under GDPR?

What GDPR and the EDPB's 2026 draft anonymisation guidelines say about synthetic data, the three criteria, and what evidence a controller needs.

Updated 18 August 2026 · Figures from metrics engine 0.8.0

Short answer: it depends, and "it's synthetic" is not the answer. Synthetic data is anonymous under GDPR when it no longer relates to an identified or identifiable natural person — and whether that is true is a question of evidence about the specific dataset, not of the technique that produced it. A synthetic dataset can be anonymous. A synthetic dataset can also be personal data, and a badly generated one frequently is.

This page sets out what the law actually asks, what the European Data Protection Board's July 2026 draft anonymisation guidelines say that bears directly on synthetic data, and what a controller needs to be able to show. It is written for privacy engineers, DPOs and data teams. It is not legal advice; it is the background you need to have the right conversation with counsel — and to know what evidence to bring.

GDPR applies to personal data. Recital 26 makes the boundary: information which does not relate to an identified or identifiable natural person is anonymous and outside the Regulation's scope. The EDPB's draft Guidelines 02/2026 on Anonymisation (adopted for public consultation on 7 July 2026, updating the Article 29 Working Party's Opinion 05/2014) frame the test as two questions:

  1. Does the information relate to a natural person — by its content, purpose or effect?
  2. If so, is that person identified or identifiable, using means reasonably likely to be used?

If the answer to either is no, the data is anonymous. Two features of the test matter enormously for synthetic data.

Identifiability is assessed per entity. Following the Court of Justice's 2025 decision in EDPS v SRB, the guidelines say the same data can be personal in one organisation's hands and anonymous in another's, depending on what each can reasonably do with it. A synthetic dataset shared with a partner is assessed from the partner's perspective — and from that of anyone the partner might reasonably pass it to.

"Reasonably likely" is a likelihood, not a certainty. The guidelines are explicit that the chance of identification need not be zero; it must be insignificant in reality, judged against all objective factors — the data's own properties (uniqueness, precision, dimensionality), the context of release, the additional information available, cost and time, and current and reasonably foreseeable technology. Two cautions the guidelines add: "lack of motivation" is not a defence, and the likelihood of re-identification typically increases over time, so anonymity should be periodically reassessed.

Why "it's synthetic" doesn't settle it

The intuition is that synthetic rows describe no real person, so the data cannot relate to anyone. The guidelines close that door in two places.

First, information can relate to a person even when the link is not readily apparent and needs processing to reveal — the guidelines say this specifically about aggregate data from which individual-level information can be extracted. Second, and directly on point, the guidelines address data "aggregated to represent correlations between elements of the original information, rather than that information itself," naming AI models and synthetic data as examples: specific inferences can be made by querying such data with additional information to elicit new information about a particular individual, and where such an inference is also meaningful, the No Inference criterion is violated.

In plain terms: a synthetic dataset is a compressed representation of the training data. If it preserved individuals rather than the population — if it memorised — then it still relates to those individuals, and the fact that no row is literally "theirs" is beside the point.

The three criteria, and how they map onto synthetic data

The guidelines' technical framework tests three criteria. All three must pass for data to be safely considered anonymous; if any fails, further analysis is needed — failing one does not automatically make the data personal, but it does mean you cannot stop there.

No Record Isolation — met if the data contains no unique combination of attribute values relating to a single individual. For synthetic data: are there synthetic records that are unique on a combination of attributes and correspond to a real, unique individual in the training data? This is what singling-out attacks and near-copy detection measure.

No Linkage — met if records cannot be linked to other data about the same individual. The guidelines note this is likely met where the information isn't recorded elsewhere and isn't correlated to similar information about the same person in other contexts. For synthetic data: does the dataset preserve joint structure precisely enough to act as a bridge between other datasets about the same real people? This is what linkability attacks measure.

No Inference — met if no specific and meaningful inference can be drawn. The guidelines' definition is worth quoting closely: an inference is specific if the inferred information relates to a single identifiable individual; it is meaningful if processing it is liable to affect that person's rights and interests, relies on the given data, and could not be obtained from general knowledge or from data about the population at large.

That last clause is the crux for synthetic data, and the guidelines spell it out. Inferring something about a new individual who was never in the training data, because they resemble people who were, is not a meaningful inference — it is generalisation about the population, and the guidelines give a bank-loan example to say exactly this. Inferring something that is actually connected to the original dataset — that depends on a real person's record having been in the training data — is meaningful, and violates the criterion. The guidelines also list membership inference — inferring that an individual's data was in the original dataset — as an inference that can itself violate anonymity.

The test the guidelines suggest is the test practitioners already run

There is a paragraph in the draft guidelines that anyone validating synthetic data should read twice. When it is unclear whether an inference relies on a specific person's data (for instance because the generating process is opaque), the guidelines propose showing it by comparing the outcome of the inference on two versions of the given data — one produced from the original dataset, and one produced from a version of the original dataset with that individual's records removed. If the inference works only on the first, it depends on the individual's data and the data relates to them. If it works the same on both, it is generalisation from the population, for which the reduced dataset is representative.

That is precisely the logic of residual risk in attack-based synthetic data validation: measure the attack's success on records the generator saw against its success on comparable records it never saw, and attribute only the difference to the generator having memorised individuals. It is why a real holdout matters (see why privacy attacks on synthetic data need a holdout) and why naive risk without one is an upper bound. The regulator's proposed method and the practitioner's method are the same idea. That is unusual, and useful.

What a controller needs to be able to show

The guidelines are direct about accountability. Anonymisation is itself processing of personal data and needs a legal basis. Controllers should not describe data as "anonymous" or "de-identified" if individuals are still identifiable. And they should keep adequate documentation of the anonymisation process — including the testing of the supposedly anonymous datasets — retained after the process completes, to demonstrate both compliance and effectiveness.

For synthetic data, that documentation is where independent validation lives. In practical terms a controller wants, for the specific dataset:

  • Evidence against each of the three criteria — measured, not asserted: record-isolation and near-copy analysis, linkability risk, inference risk, and membership inference where a holdout allows it.
  • The regime the numbers were computed under: with a control group (residual risk) or without (naive risk, an upper bound), and which metrics could not be run.
  • The dataset's risk-relevant properties: dimensionality, resolution, diversity, number of individuals — the factors the guidelines list as governing how effective re-identification techniques are likely to be.
  • Something that ties the evidence to exactly the data assessed (a fingerprint), and a version, so the assessment can be revisited as techniques evolve — which the guidelines say it should be.

None of that decides whether the dataset is anonymous. That decision applies the "means reasonably likely to be used" standard to your context, your recipients, and your risk appetite, and it is a judgement for the controller with their DPO or counsel. The evidence is what makes the judgement defensible.

Three practical points

Existing assessments stand. The guidelines say a controller that assessed a dataset as anonymous under Opinion 05/2014 before the new guidelines is not expected to redo it — though periodic reassessment is good practice. Terminology has shifted (singling-out, linkability, inference → No Record Isolation, No Linkage, No Inference); the substance is continuous.

A mixed dataset is personal data. If anonymisation is effective for most individuals but not all, the guidelines say the whole dataset should be treated as containing personal data unless the parts are handled separately. For synthetic data, that means a small tail of memorised outliers is enough — which is why per-row checks matter, not just averages.

It's a draft. Guidelines 02/2026 were adopted for public consultation, open until October 2026; details may change before final adoption. The direction of travel — relative anonymity, likelihood-based assessment, explicit attention to AI models and synthetic data — is unlikely to reverse.

How SynthProof fits

SynthProof measures the things the criteria ask about: exact and near-copy detection and singling-out risk (record isolation), linkability risk, inference and membership inference (No Inference) — with confidence intervals, and always stating whether results are residual risk (with a holdout) or naive risk (an upper bound, without one). Reports are hash-bound to the exact files assessed and stamped with the engine version so they can be revisited later. In the Compliance tier the same results are presented in the vocabulary of the three criteria, in a form designed to be attached to an anonymisation assessment or DPIA.

That is evidence for the controller's assessment. It is not a determination that a dataset is anonymous, and SynthProof does not make one.

Synthetic data in a DPIA · Singling-out, linkability and inference · Membership inference · Why privacy attacks need a holdout

Back to the guide: Synthetic data validation: the complete guide.