Synthetic data in test and ML pipelines: a privacy checklist

Before swapping production data for synthetic data in test or training pipelines, check the source of the generator, test the output for leakage, limit who gets it and record the decision. NIST's de-identification and differential privacy guidance both stress measured risk over assumptions.

Why a checklist?

Synthetic data feels safe because no row is a real person's row. NIST SP 800-188 warns that tools which merely mask personal information may not provide enough for de-identification, and it recommends re-identification studies and a standard with measurable performance. NIST SP 800-226 describes privacy hazards, common pitfalls that appear when differential privacy is implemented. Engineers need steps they can run.

The checklist

Constructed example: a payments team wants realistic transaction data for a staging environment and for training a fraud model. Walk it through the list.

Purpose and source

1. What is the use: UI testing, load testing, model training or sharing outside the company? Each has a different bar.
2. Do you need real distributions at all? For UI and load tests, rules and random values from a schema are enough, and no real records are involved.
3. If you train a generator on production data, who approved using it for that purpose?
4. Is the training data itself stored and accessed under production controls?

Generation

5. Which technique: rule based, statistical model, deep generative model, or differentially private mechanism?
6. If differential privacy is claimed, is the privacy budget written down, and was the implementation reviewed against the hazards in NIST's guidance?
7. Are direct identifiers removed before training, and quasi identifiers reviewed?
8. Are rare categories and outliers handled, for example suppressed or clipped, before generation?

Leakage tests

9. For each synthetic row, what is the distance to the nearest real row? Flag anything suspiciously close.
10. Do exact copies of real rows appear? The expected count is zero.
11. Do rare value combinations in the output match real rare combinations?
12. Has someone tried a membership inference test against the generator?
13. Have you recorded the test results with the dataset version?

In the payments example, a check finds 14 synthetic transactions that match real ones on amount, merchant and timestamp. They are removed, the generator is retrained with outlier clipping, and the test is rerun and stored.

Access and handling

14. Who can use the synthetic set, and is it treated as sensitive until the review finishes?
15. Do test environments hold it under their own access controls, not wide open?
16. Is it excluded from logs, tickets and screenshots that are widely shared?
17. Does the model trained on it get evaluated for memorization if the training set was derived from real data?

Governance

18. Is there a named owner or review group, as NIST suggests with a disclosure review board?
19. Did legal assess whether the data counts as personal data in your jurisdictions?
20. Is there a refresh and retirement date, so stale sets do not linger?

What about the software around it?

Generators and pipelines are software with dependencies. Keeping an inventory of the libraries used to generate and test data helps when one is found vulnerable. Safeguard can generate SBOMs and scan dependencies, and the browser scan at gold.safeguard.sh/scan covers up to 100 dependencies for free.

What to do

1. Choose the cheapest technique that meets the purpose, starting with rule based data.
2. Write down the source, the method and any privacy budget.
3. Run nearest record, exact match and rare value tests, and save the results.
4. Restrict access until review is complete.
5. Name an approver and record legal's view.
6. Set an expiry and rerun tests whenever the generator or source changes.

Quick check

Sources

• NIST SP 800-188, De-Identifying Government Datasets
• NIST SP 800-226, Guidelines for Evaluating Differential Privacy Guarantees

Last reviewed: 18 October 2026.