Privacy-Preserving Data and Synthetic Data

Removing obviously identifying fields like name and social security number from a dataset — often called anonymization — feels like it should protect privacy, but it frequently is not sufficient on its own, because remaining fields can still act as quasi-identifiers: a combination of age, ZIP code, and a rare diagnosis date can narrow a record down to one specific real person even without a name attached. The NIST Privacy Framework treats this kind of re-identification risk as a core concern for any organization handling personal data, and organizes privacy risk management around functions such as identifying what data is held and how it could create risk, and protecting data through appropriate safeguards. A worked example: a released dataset that lists patient age, five-digit ZIP code, and exact admission date, with names removed, can still be cross-referenced against public voter records or news reports to re-identify specific individuals — a risk that simply deleting the name column does nothing to address, which is why anonymization typically also requires generalizing or removing quasi-identifying fields, not just directly identifying ones.

Data minimization is a distinct but related principle: collecting only the data actually needed for a stated purpose, rather than gathering everything that might conceivably be useful someday. The GDPR's consolidated text codifies this directly, requiring that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed". A worked example: a fitness app that recommends workouts only needs a user's activity level and stated goals, not their full contact list or precise real-time location history; collecting the latter anyway — because it might be useful for some future feature — violates data minimization and creates privacy risk that provides the user no corresponding benefit for the current purpose. Consent is closely tied to this: individuals should know what data is being collected and for what purpose, and data minimization narrows what needs to be consented to in the first place, since a system that only collects what it strictly needs has less to explain and less that could be misused if a breach occurred.

The NIST Privacy Framework frames privacy risk management as an ongoing organizational practice rather than a one-time checklist, encouraging organizations to systematically govern, identify, and protect against privacy risks throughout a system's lifecycle, and to communicate clearly about their data practices. A worked example: before releasing the anonymized patient dataset in the scenario above, the hospital's privacy team would apply this kind of structured process — identifying which fields are quasi-identifiers, deciding how to generalize or suppress them (for example, replacing exact age with a five-year age band, and ZIP code with only its first three digits), and documenting the resulting re-identification risk — rather than treating "remove the name column" as a complete privacy solution on its own. This governance step also has to be revisited over time, since a dataset that seemed safely generalized when released can become newly re-identifiable years later if an unrelated public dataset is released that happens to share overlapping quasi-identifying fields.

Anonymization by generalizing or removing fields can still be broken by a sufficiently determined attacker with outside information, which motivated the development of differential privacy, a mathematically rigorous alternative. In their foundational work, Dwork, McSherry, Nissim, and Smith proposed calibrating carefully designed random noise to a query's sensitivity — how much a single individual's data could possibly change the query's result — so that the noisy output reveals almost nothing about whether any specific individual's data was included, regardless of what other information an attacker might already have. A worked example: instead of releasing the exact count of patients with a rare condition in a hospital dataset, a differentially private system releases that count plus a small amount of random noise (for instance, drawn from a Laplace distribution) calibrated so that whether any one specific patient's record was included or excluded changes the released number by only a tiny, statistically bounded amount — protecting that individual's presence in the dataset even if the exact same query is run many times.

This protection is not free: adding noise necessarily makes the released result somewhat less precise, and the parameter controlling this trade-off is often called the privacy budget, or epsilon. A smaller epsilon means more noise and stronger privacy protection but less accurate results; a larger epsilon means less noise and more accurate results but weaker privacy guarantees. A worked example: a health agency releasing daily counts of a rare disease across many small regions must choose an epsilon that keeps individual patients' presence protected in the smallest regions (where a single case could otherwise be inferred) while still keeping the released numbers useful enough for public health researchers to spot real trends — a genuine engineering trade-off, not a default that can be set once and forgotten, since the Dwork et al. work established that differential privacy's guarantees compose predictably: running multiple queries against the same protected dataset consumes more of the overall privacy budget each time.

When even a noise-protected release of real data is too risky, or when the goal is to share a dataset broadly for tool-building and testing, synthetic data offers a different approach: generating entirely artificial records that preserve the statistical patterns of the real data — such as the relationships between age, diagnosis, and outcome — without any single synthetic record corresponding to a real person. Evaluating synthetic data requires checking two things in tension: utility (does the synthetic data preserve the patterns researchers need, such as the same correlations and distributions as the original) and privacy (is it actually hard to trace a synthetic record back to a specific real individual it may have been generated from) — a risk-management framing the NIST Privacy Framework's approach to identifying and managing privacy risk throughout a system's lifecycle applies just as much to a synthetic-data pipeline as to a real-data release. A worked example: a hospital could train a generative model on real patient records and use it to produce ten thousand synthetic patient records that preserve realistic distributions of age, diagnosis, and treatment outcome for a research team to prototype an algorithm against, before that team ever gains access to any real patient's actual record.