Synthetic data in a DPIA: what to document and why

Synthetic data appears in Data Protection Impact Assessments in two very different roles, and DPIAs go wrong when they blur them. Sometimes synthetic data is a safeguard — a measure that reduces the risk of a processing activity by replacing personal data with something less risky. Sometimes generating and using synthetic data is itself the processing being assessed. This page covers both, describes what evidence a DPIA needs about the synthetic data either way, and shows how to phrase the claims so they hold up.

It is written for the people who write and sign DPIAs — DPOs, privacy engineers, data governance leads — and for the data teams who have to supply them with evidence. It is not legal advice.

Where synthetic data enters a DPIA

Article 35 GDPR requires a DPIA where processing is likely to result in high risk to individuals; the assessment must describe the processing, evaluate its necessity and proportionality, assess the risks, and set out the measures envisaged to address them. Synthetic data shows up in three of those four parts.

As a measure addressing risk. "We will train the model on synthetic data rather than production records" is a mitigation. A DPIA that lists it must say how effective it is — which means saying whether the synthetic data still relates to identifiable individuals, and to what degree. A mitigation whose effectiveness is asserted rather than shown is a weak spot a supervisory authority will notice.

As processing in its own right. Generating synthetic data from personal data is processing of that personal data. The EDPB's draft anonymisation guidelines are explicit that anonymisation is processing and needs a legal basis, and that a controller producing supposedly anonymous data must keep documentation of the process, including the testing of the resulting datasets. If the generation is part of a high-risk activity — large-scale special-category data, for instance — the DPIA covers the generation step, and the quality of the anonymisation is a central question in it.

In the description of the processing. Once synthetic data is in use, "what data is processed" has to be honest about it: is the synthetic dataset personal data or not, from whose perspective, and on what basis do you say so? See Is synthetic data personal data under GDPR?.

What the DPIA needs to say about the synthetic data

Whichever role it plays, the DPIA needs three things about the synthetic dataset — and it needs them about the specific dataset, not about synthetic data as a technique.

1. Whether, and how far, it still relates to identifiable individuals

This is the anonymisation question, and the draft guidelines give it a shape: the three criteria of No Record Isolation, No Linkage and No Inference, assessed against means reasonably likely to be used by each relevant entity. The DPIA should record, for the dataset:

• Evidence against each criterion, measured — near-copy and singling-out analysis, linkability risk, inference risk, and membership inference where it could be run.
• The regime the measurements were made under. Attack-based metrics computed with a real control group (records the generator never saw) yield residual risk — the guidelines' own logic for distinguishing inference that relies on an individual's data from generalisation about the population. Without a control group they yield naive risk, an upper bound, and membership inference cannot be run at all. A DPIA that records "membership inference: passed" for a dataset where it was never tested is recording something false. Record "not tested — no holdout available" and say what that means.
• The dataset's risk-relevant properties: record-level or aggregate; dimensionality; resolution; diversity; number of individuals represented. The guidelines list these as the factors that govern how effective re-identification techniques are likely to be, and they belong in the assessment as context for the numbers.
• The conclusion, and whose judgement it is: whether, given all of that, the controller considers the dataset anonymous for the relevant recipients — under the simplified approach (treating all entities as maximally capable) or the contextual one — and the residual risk accepted if not.

2. Whether it is fit for the purpose that justifies the processing

Necessity and proportionality cut both ways. If synthetic data is the mitigation that makes a processing activity acceptable, the DPIA is implicitly claiming the synthetic data is good enough for the purpose — otherwise the mitigation is illusory and someone will quietly go back to the real data. Fidelity and utility evidence belongs here: does the synthetic dataset preserve the statistical structure the purpose depends on, and does a model trained on it perform on real data? A DPIA rarely needs the detail; it needs a statement that this was measured, the headline result, and where the full report is.

3. What happens to the source data, and where

Two facts that reviewers ask about and that are easy to state if true: whether the real data used to generate or validate the synthetic data is retained anywhere it wasn't before, and in which jurisdiction any processing happened. If a third-party validation service was used, the DPIA should record what that service received, where it processed it, how long it held it, and how deletion is evidenced. Data residency is a DPIA question independent of anonymisation.

Phrasing that holds up

The single most common failure in DPIAs about synthetic data is overclaiming. Some rules of thumb:

• "Anonymous" is a conclusion, not a description. The guidelines caution controllers against calling data anonymous or de-identified when individuals remain identifiable. Write "assessed as anonymous for the following recipients on the following basis," and attach the basis.
• Untested is not passed. If a metric could not run, say so and why. It reads as rigour, not weakness — and a reviewer who finds an untested metric recorded as passed will distrust everything else.
• Evidence and determination are different things. A validation report is evidence. "The dataset is GDPR-compliant" is a determination nobody can make about a dataset in the abstract, and no report should say it. Phrase it as: "Independent validation (report ref., engine version, dataset fingerprint) measured … ; on that basis the controller assesses …"
• Date and version everything. The guidelines say the likelihood of re-identification typically increases over time and anonymity should be periodically reassessed. A DPIA that records the engine version, the date, and the dataset fingerprint can be re-run and compared; one that records "validated: yes" cannot.
• Don't let one pillar carry another. Excellent fidelity is not privacy evidence; a memorising generator has perfect fidelity. If the DPIA quotes a single overall score, it should say whether a privacy failure would have capped it.

A template section

For a DPIA that treats synthetic data as a mitigation, the following block is enough for most reviewers, with the full report referenced:

Synthetic data used as a risk-reduction measure. The [purpose] will be carried out on a synthetic dataset generated from [source, categories of data] using [generator, version]. The synthetic dataset was independently validated on [date] (report ref. [id], engine v[x.y.z], dataset fingerprint [SHA-256]). Against the anonymisation criteria: record isolation — [result]; linkage — [result]; inference — [result]; membership inference — [result / not tested, reason]. Measurements were made [with a holdout: residual risk / without: naive risk, upper bound]. Dataset properties: [record-level, n rows, n columns, resolution, diversity]. Fidelity and utility for the stated purpose: [headline]. Source data used for validation was processed in [region] and deleted on completion ([timestamp]). On the basis of this evidence, and applying the [simplified / contextual] approach for recipients [list], the controller assesses the synthetic dataset as [anonymous / personal data with residual risk accepted as follows]. Reassessment scheduled [date / trigger].

Every bracket is a fact the controller either has or knows they lack. That is the point.

When synthetic data is the processing being assessed

If the DPIA is about the generation itself — for example, producing a synthetic copy of a large special-category dataset for wider internal use — the structure above still applies, with two additions. The legal basis for the generation (the guidelines say it should generally coincide with the basis for the preceding processing if it is part of the same activity and purpose) needs to be stated. And the necessity of processing the full source data to produce the synthetic dataset — versus a sample, or versus not producing it — should be argued, because generation is a processing step in its own right that a reviewer will weigh.

How SynthProof fits

A SynthProof report is built to be the evidence a DPIA references: measured results against the anonymisation criteria with confidence intervals; the regime stated (residual or naive, holdout or not); "not tested" wherever a metric could not run; fidelity and utility alongside privacy with a critical privacy failure capping the overall grade; dataset shape properties; a SHA-256 fingerprint binding the report to the exact files; engine and benchmark versions; the processing region; and the source-data deletion timestamp. The Compliance tier presents the same results in the criteria's vocabulary in a form intended to be attached to a DPIA.

It is evidence for the controller's assessment. It is not the assessment, and it is not a determination of compliance.

Related

Is synthetic data personal data under GDPR? · Singling-out, linkability and inference · Why privacy attacks need a holdout

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