Synthetic data — records generated by a model or algorithm rather than collected from real-world observation — is increasingly proposed as a way to make sensitive research data shareable, or to fill gaps where real data is scarce. It is also increasingly misunderstood, both as a privacy technique and as a way to satisfy a funder’s data-sharing requirement. This guide sets out what synthetic data actually is in a research context, what documentation a synthetic dataset needs to be usable and trustworthy, and what current funder and privacy-regulator guidance actually says about using it in place of real data — which, as of mid-2026, is more cautious than “generate synthetic data and you’re covered.”
What counts as synthetic data in research
CASRAI’s Dictionary defines synthetic data operationally as data generated by a model or algorithm rather than collected from real-world observations or experiments, designed to mimic the statistical structure of real data for purposes such as augmentation, privacy-preservation, or model training (see Synthetic data). Three things follow from that definition that matter for how you document and share it:
- It is generated, not collected or resampled. A GAN-generated set of chest X-rays or an LLM-generated set of patient narratives is synthetic. Bootstrap resamples of an empirical dataset are not — they reshuffle real observations rather than generating new ones, which is why the Dictionary entry lists bootstrapping as a counter-example. The same logic applies to simple noise-perturbed or masked real records: if the underlying values still trace back to specific real observations, you’re looking at a de-identification or perturbation technique, not synthetic data, and it should be documented and risk-assessed as such.
- It can be fully or partially synthetic. A fully synthetic dataset has no record-level correspondence to any real observation. A partially synthetic (or “hybrid”) dataset replaces only the disclosive fields (e.g., dates, rare diagnoses, free-text fields) in an otherwise real dataset with generated values. The two carry different privacy and validity profiles and should never be described interchangeably in a data availability statement or DMP.
- Generation method varies by field and by purpose. Common approaches include generative adversarial networks (GANs) and diffusion models for imaging data, statistical/agent-based simulation for structured tabular or epidemiological data, and large language models for synthetic text. The method matters for validation — a GAN-generated image dataset and an LLM-generated narrative dataset fail in different ways and need different fidelity checks (see below).
Related CASRAI Dictionary entries worth cross-referencing when you’re documenting a specific case: Synthetic image, Synthetic benchmark, Training data provenance, and Data leakage (training).
Why researchers generate it
Three distinct motivations show up in practice, and conflating them is a common source of confusion when a synthetic dataset gets reused for a purpose it wasn’t validated for:
Privacy-preserving sharing
Where the real dataset contains identifiable or highly sensitive information (clinical records, genomic data, free-text interview transcripts) and cannot be openly shared, a synthetic version is sometimes generated so that methods, code, and analysis pipelines can be tested and shared publicly, while the real data stays in a controlled-access environment. This is the use case with the most active current regulatory attention — see the privacy section below.
Data augmentation
Where real examples of a rare event, class, or condition are too scarce to train a robust model (a rare disease subtype, an infrequent failure mode), synthetic examples generated from the available real data can supplement — not replace — the real training set. This is the most methodologically mature use case, with the most established fidelity/utility validation practice.
Pipeline development and benchmarking
Synthetic data lets a research team build and test analysis code, CRIS/RIM integrations, or a data pipeline before controlled access to real data is granted, or as a stable, freely redistributable benchmark for comparing methods across labs. CASRAI’s Dictionary entry for Synthetic benchmark covers this use specifically.
Documentation expectations
A synthetic dataset that isn’t clearly documented as synthetic — and validated as fit for its stated purpose — is a reproducibility and integrity problem waiting to surface. At minimum, document the following, in the DMP, the data availability statement, and the dataset’s own metadata record (not just one of the three):
Disclosure that the data is synthetic
State plainly, in the methods and in the dataset’s own description, whether a dataset is fully or partially synthetic, and which fields or records are affected if partial. This should never require a reader to infer synthetic status from a methods footnote. CASRAI’s existing guidance on the data availability statement and on writing one for reproducibility applies directly here: a DAS that says data are “available” without disclosing that the shared version is synthetic is not an accurate statement.
Generation method
Name the generating model or algorithm, its version, key parameters, and (where feasible) a random seed or equivalent means of exact regeneration. If the generator was itself trained on real data, disclose what that source data was and under what authorization it was used — this connects directly to training data provenance documentation, and to code/environment disclosure via a code availability statement or a versioned container image.
Fidelity validation
Fidelity means: how closely does the synthetic data’s statistical structure match the real data it’s meant to stand in for? Common approaches compare marginal distributions field-by-field, pairwise correlations, and higher-order structure between the real and synthetic sets, or use a discriminator/detection-based test (can a classifier tell them apart). There is currently no single standardized fidelity benchmark adopted across research domains — practice varies by field, and a generic image-fidelity metric doesn’t transfer to tabular clinical data or synthetic text. Report whichever fidelity metrics you used and why they’re appropriate to the data type, rather than asserting fidelity without a stated basis.
Utility validation
Utility means: does the synthetic data actually support the analysis or model it’s meant to support? The standard check is training a model (or replicating an analysis) on the synthetic data and evaluating it against real, held-out data — sometimes called train-on-synthetic, test-on-real. Report this comparison, not just fidelity metrics, when the synthetic data is intended as a substitute for a specific downstream task; fidelity and utility can diverge (data can look statistically similar and still fail at the task it’s meant to support, or vice versa).
Privacy / re-identification risk assessment
Treat re-identification risk as a step that must be actively assessed and documented, not a property that follows automatically from “the data was generated, not collected.” See the next section for what current regulatory guidance actually requires here.
Is synthetic data automatically anonymous? What regulators currently say
No — and this is the point most often assumed rather than checked. Under GDPR, synthetic data is not automatically outside the scope of “personal data” simply because no individual record was directly collected. The European Data Protection Board’s position, most directly relevant via its Opinion 28/2024 on the processing of personal data in AI models (adopted 17 December 2024 under GDPR Article 64(2)) is that a model — and by extension data generated from it — cannot be assumed anonymous by default; anonymity has to be demonstrated case by case, considering whether identification of individuals in the source data, or extraction of their data via the generated outputs, remains genuinely insignificant given all means reasonably likely to be used. In practice, generation methods that preserve strong correlations from a small, sensitive source dataset can carry meaningful re-identification risk, particularly when combined with other public information — the standard framework for testing this looks at singling out, linkability, and inference.
The UK Information Commissioner’s Office reached the same operational conclusion in its anonymisation, pseudonymisation, and privacy-enhancing technologies guidance (published March 2025): synthetic data is treated as one privacy-enhancing technique among several (alongside differential privacy, homomorphic encryption, and secure multiparty computation), and is subject to the same effectiveness test as any other anonymisation method — it does not get an automatic exemption for being “generated.”
At EU level, the European Health Data Space Regulation (Regulation (EU) 2025/327, in force since 26 March 2025, applying in stages from 26 March 2027) explicitly names anonymised and synthetic data among the tools Health Data Access Bodies may use to support secondary use of health data through secure processing environments. It does this without yet fully settling the detailed governance provisions for synthetic data specifically — an acknowledged, active gap, not a finished framework. Treat EHDS as a live example of where this is heading, not yet as settled law you can cite as having resolved the question.
Bottom line for a DMP or data availability statement: don’t state or imply that a dataset is anonymous, or exempt from privacy review, purely because it is synthetic. Document the specific re-identification risk assessment performed, not just the generation method.
Can synthetic data satisfy a funder’s data-sharing mandate?
The honest current answer is: usually not as a substitute for the real data, without explicit disclosure and justification — and current funder policy language does not, as of this writing, name synthetic data as an accepted substitute for sharing the underlying scientific data.
The NIH Data Management and Sharing Policy (effective 25 January 2023) expects researchers to maximize sharing of scientific data itself, and its supplemental guidance on protecting participant privacy when sharing (NOT-OD-22-213) frames de-identification and controlled access as the named privacy-protective approaches — it does not establish synthetic data as a declared alternative to sharing the real dataset. Where privacy, legal, or technical constraints genuinely prevent sharing real data, the DMS Policy’s expectation is that the DMP explains and justifies that limitation, not that a synthetic proxy silently substitutes for it. If you intend to generate and share a synthetic version specifically because the real data can’t be shared, that reasoning — and the fidelity, utility, and privacy validation behind it — belongs explicitly in the DMP, not left implicit. See CASRAI’s NIH vs. NSF Data Management Plans guide for how the two agencies’ DMP requirements otherwise differ.
This is a genuinely moving area of policy, not a settled one. The EHDS framework above shows a live example of a major funder-adjacent regulatory system naming synthetic data as a candidate secondary-use tool without yet finishing the rules for how it counts. If you’re relying on synthetic data to meet a specific funder or journal data-sharing requirement, verify the current position with the funder or program officer directly, and check your funder’s DMP guidance and any relevant journal/publisher data policy for explicit language on synthetic-data substitution before assuming it will be accepted — don’t rely on a generic “synthetic data helps you comply” claim from a vendor or secondary source, including this one, without checking the primary policy text yourself.
Where synthetic data does have a legitimate, currently-accepted role in a sharing strategy is as a documented complement: a publicly shareable synthetic version released alongside real data held under controlled access, clearly labelled as synthetic, with its generation method and fidelity/utility validation reported — supporting reuse and code-testing by researchers who haven’t yet obtained (or won’t seek) controlled access to the real data. That is a genuinely useful pattern with real current adoption in health-data infrastructure (see the EHDS discussion above); presenting a synthetic dataset as an unqualified replacement for the real one is the pattern current guidance does not support.
Practical checklist
- State explicitly, in the DMP, data availability statement, and dataset metadata, whether the data is fully or partially synthetic.
- Name the generation method, model/software version, and parameters; disclose the source data if the generator was trained on real data.
- Report the fidelity metrics used and why they suit the data type — don’t assert fidelity without a stated basis.
- Report a utility validation (e.g., train-on-synthetic/test-on-real) if the synthetic data is meant to substitute for a specific downstream task.
- Document a re-identification risk assessment separately from the generation method — synthetic status is not itself a privacy guarantee.
- If synthetic data is offered in place of real data sharing to satisfy a funder mandate, state that reasoning explicitly in the DMP and confirm current acceptance with the funder — don’t assume it.
- Where feasible, offer synthetic data as a documented complement to controlled-access real data, not as its sole public substitute.
Frequently asked questions
Is synthetic data the same as anonymized or de-identified data?
No. De-identification and anonymization work on real records — removing or altering identifiers within an actual observed dataset. Synthetic data is newly generated by a model and, in the fully synthetic case, has no one-to-one correspondence to any real record at all. Partially synthetic data sits in between and should be documented as such rather than folded into either category.
Does using synthetic data mean I don’t need IRB/REC or privacy review?
Not automatically. If the generator was trained on real human-subjects data, questions about the original data’s collection, consent, and re-identification risk of the generated outputs still apply and should be part of your institution’s review, not bypassed because the shared artifact is labeled synthetic.
What’s the difference between fidelity and utility, and do I need both?
Fidelity asks whether the synthetic data statistically resembles the real data; utility asks whether it performs the same job (e.g., produces the same model or analysis conclusions). Report both where the synthetic data is meant to substitute for real data in an actual analysis — a dataset can score well on one and poorly on the other.
Can I cite or archive a synthetic dataset the same way as a real one?
Yes — deposit it in a repository, mint a DOI, and document it with standard dataset metadata as you would any dataset (see CASRAI’s guide on choosing an open data repository), with the generation method and synthetic status included in the description and any relevant metadata fields, not left to a reader’s assumption.
