Certifying the Synthetic: A Six-Point Release File for UK Generated Datasets

Synthetic data has moved from research curiosity to routine operational input. UK organisations now use generated datasets to test migrations, train models, populate analytics sandboxes and demonstrate functionality to clients. The attraction is obvious: a dataset that resembles production without carrying production's personal data. The governance difficulty is equally obvious. A generated dataset is not self-explanatory. Unless the release file shows what it was modelled on, how it was produced and what testing it survived, the recipient is being asked to trust an assertion.

For data governance professionals, the release decision is the control point. The lab can describe its method; the releasing organisation must be able to evidence that the method was applied and that the resulting dataset is fit for the stated purpose. The six tests below form a release file — a provenance record that travels with the dataset. The term passport is useful only if it implies inspection at the border. A document completed after the dataset has been shared is a retrospective narrative, not a control.

1. Source lineage: what the generated record stands in for

Begin with the source, not the output. The file should identify the personal data categories used in the generation process, the source systems or datasets, the approximate population represented and the lawful basis for the original processing. If the synthetic data was modelled on a sample rather than a full population, say so. If the source data was itself derived from another dataset, record that chain.

Lineage should also capture transformations: filtering, pseudonymisation, aggregation, feature engineering and any exclusion of special category data. Version identifiers matter. A synthetic dataset produced from a March extract is not the same artefact as one produced from a September extract, even if the generation code is unchanged. The release file should allow a reader to reconstruct which source snapshot underpinned which output.

2. Generation method: enough detail to reproduce the reasoning

The second test concerns method. The file need not disclose a commercial model's weights, but it should describe the class of technique used — for example, statistical synthesis, generative modelling or rule-based simulation — and the principal parameters that affect fidelity and privacy. Record the tooling and version, the random seeds where applicable, the training regime and the extent of human review.

The purpose is not to publish a recipe. It is to make the release decision reviewable. A recipient or regulator should be able to understand whether the method was appropriate to the data categories involved and whether later changes to the model would require a fresh assessment. Where a third-party generator is used, the file should identify the provider and the contractual basis on which generation was performed.

3. Re-identification testing: evidence, not reassurance

The most common weakness in synthetic data governance is a statement that the output has been tested for re-identification without saying what was tested, against which baseline and with what result. The release file should record the tests performed: direct identifier checks, nearest-neighbour or similarity testing, membership inference testing where relevant, and any attack simulations. It should state the thresholds applied and who validated the results.

Equally important is the limitation. No test proves that re-identification is impossible. The file should record residual risk, the population against which the test was run and the conditions under which the conclusion might no longer hold — for example, if the recipient combines the synthetic data with another dataset. A test result without its scope is an invitation to overconfidence.

4. Purpose limits: what the dataset may and may not support

Synthetic data can be technically shareable and still be inappropriate for the recipient's intended use. The release file should state the permitted purposes, the prohibited uses and any conditions attached. If the dataset is intended for software testing, say so; if it is not suitable for model training, say so. If the generation method preserves some statistical relationships but not others, the recipient needs to know which conclusions the data can support.

Purpose limits should be reflected in the release terms, not only in an internal note. For UK organisations, this also connects to the original lawful basis and the reasonable expectations of the individuals whose data informed the model. A synthetic dataset does not automatically fall outside UK GDPR, particularly where it is derived from personal data and remains linked to identifiable individuals in the source. The file should record the governance view on that point.

5. Recipient controls: the dataset after it leaves

The fifth test looks outward. Record who receives the dataset, in what form, under what licence or contract, and with what restrictions on onward sharing. If the recipient is permitted to combine the synthetic data with other data, the file should say so and record the re-identification risk that combination creates. If onward transfer is prohibited, the mechanism for enforcing that prohibition should be identified.

For external recipients, the release file should also capture the assurance obtained: due diligence, contractual clauses, audit rights or certification. For internal recipients, the equivalent controls are access management, environment restrictions and logging. The record is not complete if it stops at the organisational boundary; synthetic data can be re-identified after release through linkage, and the controls should follow the dataset.

6. Retention and disposal: closing the loop

Finally, the file should state how long the synthetic dataset will be retained, where it will be stored and how it will be disposed of. This includes the generated dataset itself, any intermediate artefacts and the model or configuration used to produce it. If the source data is deleted from the production estate, the synthetic dataset may still retain a statistical relationship to it; the file should record the organisation's position on that residual linkage.

Retention should also include re-testing triggers. A synthetic dataset released in 2026 may become less defensible if the source population changes materially or if new re-identification techniques emerge. The file should identify who owns the review and when it will next be assessed.

The release decision

These six tests do not guarantee that a synthetic dataset is safe. They do something more practical: they make the release decision auditable. A governance team that can produce the file can show that lineage, method, testing, purpose, recipient and retention were considered before the dataset left the lab. A team that cannot produce it is relying on the generator's reputation.

The release file should be signed off by a named owner and stored with the dataset's metadata. It should be updated when material changes occur, not reconstructed after an incident. In the UK context, where ICO scrutiny and contractual assurance both depend on records, the synthetic dataset without a provenance record is simply a new form of undocumented processing. The six checks are the minimum evidence for treating it as anything else.