Re-identification Attacks: Why Anonymized Personal Data May Not Be Anonymous

In an increasingly data-driven economy, organizations routinely collect, process, and share vast quantities of information. To reduce privacy risks, many businesses attempt to anonymize personal data before using it for analytics, artificial intelligence, research, benchmarking, or commercial purposes.

Anonymization is often treated as a technical solution that transforms personal data into information that can no longer be linked to an identifiable individual. However, this assumption can be dangerously misleading.

Data that appears anonymous may still contain enough information to identify individuals when combined with other datasets, publicly available information, or advanced analytical techniques. This process is known as re-identification.

Re-identification attacks represent a significant cybersecurity and data protection challenge. They can undermine privacy safeguards, expose sensitive personal information, create regulatory liability, and damage an organization's reputation.

For cybersecurity professionals the central question is not simply whether direct identifiers have been removed. It is whether a person can still be identified, directly or indirectly, using reasonably likely means.

This article examines how re-identification attacks work, why traditional anonymization techniques can fail, the regulatory implications, and the controls organizations should implement to reduce the risk.

1. What Is a Re-identification Attack?

A re-identification attack is an attempt to associate supposedly anonymized or de-identified data with a specific individual.

Organizations may remove obvious identifiers such as:

Full names
Email addresses
Telephone numbers
National identification numbers
Customer IDs
Postal addresses

The resulting dataset may no longer contain immediately recognizable personal information. Nevertheless, other attributes can make individuals distinguishable.

For example, consider a dataset containing:

Even without names, a person may be identifiable if an attacker knows that a particular 42-year-old woman living in postcode AB12 was hospitalized on 14 March.

The attacker could combine the dataset with other sources, such as:

Public electoral registers
Social media profiles
News reports
Public records
Data broker information
Location data
Other breached datasets
Publicly available professional information

The attack succeeds when the attacker can reliably associate a record with a real individual.

Re-identification versus data breach

A re-identification attack is not necessarily the same as a conventional cybersecurity breach.

A data breach generally involves unauthorized access to, disclosure of, alteration of, or loss of personal data. Re-identification may occur even when the dataset was intentionally and lawfully published or shared.

For example, an organization might publish a dataset believing it contains only anonymous statistics. A researcher or malicious actor could subsequently combine those records with external information and identify individuals.

In that situation, the privacy failure may arise not from unauthorized access to the original system, but from the inadequacy of the anonymization process.

2. Anonymization, Pseudonymization, and De-identification: Critical Differences

One of the most common privacy governance failures is treating these concepts as interchangeable.

2.1 Anonymization

Anonymization is the processing of data so that individuals are no longer identifiable, taking into account all means reasonably likely to be used to identify them.

TUnder the European Union's General Data Protection Regulation (GDPR), genuinely anonymized information falls outside the definition of personal data.

However, anonymization is a demanding standard. Simply deleting names or replacing them with codes is not sufficient.

A dataset may be considered anonymous only if identification is no longer reasonably possible, considering factors such as:

The cost of identification
The time required
Available technology
Available data sources
The likelihood of an attack
The nature and sensitivity of the information

Anonymization should therefore be assessed as a risk-based outcome, not as a checkbox exercise.

2.2 Pseudonymization

Pseudonymization replaces direct identifiers with artificial identifiers, such as tokens, reference numbers, or cryptographic values. For example:

Pseudonymization can substantially reduce exposure and improve security. However, the data may still be linked to individuals, especially where additional information or a re-identification key exists.

Under GDPR Article 4(5), pseudonymization is a security and privacy-enhancing technique, but pseudonymized information remains personal data when an individual can be identified using additional information. A pseudonym is not an anonymous identity.

2.3 De-identification

De-identification is a broad term used in privacy engineering and data governance to describe techniques intended to remove or reduce identifying information.

Depending on the jurisdiction and context, de-identified data may still be legally classified as personal data if re-identification remains reasonably possible.

Organizations must therefore avoid assuming that a dataset is outside data protection law merely because it has been labeled "de-identified."

3. Why Anonymization Techniques Can Fail

Traditional anonymization techniques often focus on removing direct identifiers. Re-identification attacks exploit the information that remains.

3.1 Quasi-identifiers

A quasi-identifier is an attribute that may not uniquely identify a person on its own but can do so when combined with other attributes. Common examples include:

Date of birth
Age
Gender
Postal code
Occupation
Education level
Employment status
Hospital admission date
Geographic coordinates
Household size
Rare medical conditions

Each attribute may appear harmless in isolation. Together, they can create a highly distinctive profile.

For instance, a dataset containing age, postcode, gender, and date of hospital admission may allow an attacker to identify an individual using publicly accessible information.

3.2 Uniqueness of human behavior

People generate highly distinctive behavioral patterns. Even if names and account numbers are removed, individuals may remain identifiable through:

Shopping habits
Transport journeys
Mobile phone locations
Website browsing patterns
Fitness activity
Search queries
Transaction sequences
Energy consumption
Communication patterns

A person who visits a particular sequence of locations at predictable times may be distinguishable from millions of other people.

In some datasets, a surprisingly small number of location or behavioral observations can be sufficient to single out an individual.

3.3 Sparse and rare attributes

Rare characteristics are particularly dangerous. Consider a dataset containing information about individuals with an unusual occupation, a rare medical diagnosis, or a unique combination of demographic characteristics.

Even after removing direct identifiers, these records may be easy to connect to public information. The more unusual a person's attributes are, the greater the likelihood that they can be distinguished from other records.

3.4 External data sources

Re-identification becomes more likely as data ecosystems expand. An attacker may combine an anonymized dataset with: a publicly available dataset, a commercial data broker's records, information obtained from a previous security incident, social media content, public government records, data leaked through an unsecured API, information shared by the individual themselves.

The attacker does not need access to the original identity database. They only need sufficient information to establish a credible connection.

4. Notable Re-identification Incidents

Several real-world incidents demonstrate that removing obvious identifiers does not necessarily protect privacy.

4.1 The Netflix Prize dataset

In 2006, Netflix released a dataset containing anonymized movie ratings as part of the Netflix Prize competition

The dataset did not include customer names. However, researchers demonstrated that some users could potentially be identified by correlating their ratings with publicly available movie ratings, including information from IMDb.

The incident became a landmark example of how seemingly innocuous behavioral data can be linked to real individuals.

Lesson: Removing names does not prevent identification when behavioral patterns are distinctive.

4.2 AOL search data disclosure

In 2006, AOL released a large collection of search queries intended for research purposes. Although user identifiers were replaced with numerical values, researchers and journalists were able to associate search histories with individuals.

Search queries can reveal highly sensitive information, including: health concerns, personal relationships, political views, financial difficulties, geographic location.

Lesson: Search histories can act as digital fingerprints and may reveal identity through context alone.

4.3 Location data re-identification

Research involving mobility datasets has shown that human movement patterns can be highly unique. A sequence of location observations may reveal where someone lives, works, socializes, or receives medical treatment. Even if GPS identifiers are removed, repeated patterns may be matched against other location sources.

Lesson: Location data should be treated as potentially identifying, particularly when collected at high frequency or high precision.

5. Common Re-identification Attack Techniques

Re-identification attacks can be conducted using simple data correlation or sophisticated analytical methods.

5.1 Linkage attacks

A linkage attack occurs when an attacker connects records in an anonymized dataset to records in another dataset. For example:

Dataset A: anonymized medical records containing age, postcode, and admission date.
Dataset B: publicly available information about hospital admissions or local events

If the attributes match, the attacker may infer the identity of the person associated with a record.

Linkage attacks are among the most important threats to data releases involving multiple datasets.

5.2 Singling-out attacks

A singling-out attack occurs when an individual can be distinguished from others, even if the attacker cannot determine their name.

For example, a record may describe the only individual in a dataset who: is 91 years old, lives in a particular small locality, has a rare disease, was admitted to hospital on a specific date. The attacker may be able to isolate that person using publicly available information.

Singling out is a significant privacy concern because identification risk can exist before the individual's name is discovered.

5.3 Inference attacks

An inference attack attempts to deduce sensitive information about an individual from apparently non-sensitive data.

Examples include inferring: a person's medical condition from purchasing patterns, their income from transaction behavior, their political preferences from browsing activity, their employment status from location changes, their health status from fitness data.

Inference attacks can cause harm even when the attacker cannot fully identify the individual.

5.4 Membership inference attacks

A membership inference attack attempts to determine whether a particular individual's data was included in a dataset or used to train a machine learning model.

For example, an attacker may seek to determine whether a person participated in: a medical research study, a genetic database, a financial dataset, a disease prediction model, a confidential customer program. The revelation that an individual belongs to a sensitive dataset may itself constitute a serious privacy risk.

5.5 Model inversion and AI-assisted attacks

Machine learning systems can sometimes reveal information about their training data.

Depending on the model, its outputs, and the attacker's access, an attacker may attempt to infer characteristics of individuals or reconstruct aspects of sensitive training data.

Generative AI and advanced analytics can increase the speed at which attackers: correlate disparate datasets, extract patterns from unstructured information, discover rare combinations of attributes, identify relationships between pseudonymous records, automate large-scale investigative analysis.

AI does not make re-identification inevitable, but it can increase the practical capability of attackers.

6. Why "Removing Names" Is Not Enoug

A common misconception is that removing names, addresses, and identification numbers automatically creates anonymous information. In reality, identity can be revealed through the combination of attributes. Consider the following example.

Before anonymization

After basic de-identification

The second table no longer contains a name or exact address. However, if only one 42-year-old pilot in Exampleville is known to have the rare condition, the individual may still be identifiable.

This is why privacy risk must be evaluated using the entire combination of information, not merely the presence or absence of direct identifiers.

7. Measuring and Reducing Re-identification Risk

Organizations should apply privacy engineering methods to reduce the likelihood of successful re-identification.

7.1 K-anonymity

K-anonymity aims to ensure that each record is indistinguishable from at least k − 1 other records with respect to selected quasi-identifiers.

For example, a dataset satisfying 5-anonymity should contain at least five records sharing the same quasi-identifier combination. If the attributes are age, gender, and postcode, each combination should occur at least five times.

Limitations

K-anonymity does not guarantee privacy. It can fail when:

Sensitive values are identical within an anonymity group.
Attackers possess background knowledge.
Quasi-identifiers are incorrectly selected.
The dataset is combined with another dataset.
Rare attributes remain visible.

7.2 L-diversity

L-diversity extends k-anonymity by requiring diversity in sensitive attributes within each anonymity group.

For example, a group of records should not all have the same medical diagnosis if the goal is to protect health information.

Limitations

L-diversity can still be vulnerable to:

Similarity attacks
Skewed distributions
Background knowledge
High correlation between sensitive attributes

7.3 T-closeness

T-closeness attempts to ensure that the distribution of sensitive attributes within an anonymity group does not differ excessively from the overall distribution. This can reduce the risk that membership in a group reveals sensitive information. However, it remains dependent on appropriate parameter selection and a correct understanding of the attack model.

7.4 Differential privacy

Differential privacy provides a mathematically defined privacy guarantee concerning the influence of any one individual's data on the output of a computation.

A differentially private mechanism introduces carefully calibrated randomness so that the presence or absence of one person's data has a limited effect on the result.

A common formal definition requires that, for neighboring datasets differing in one individual's record, the probability of any output event differs by at most a multiplicative factor related to the privacy parameter ε.

Smaller ε generally corresponds to stronger privacy protection, although it may reduce analytical utility.

Differential privacy is particularly relevant for: statistical releases, public dashboards, population-level analytics, machine learning, research data access systems, repeated queries against sensitive datasets, etc.

Important limitations

Differential privacy is not a universal solution. Organizations must consider:

Privacy budget management
Repeated data releases
Composition across multiple analyses
Utility and accuracy requirements
Model architecture
Auxiliary information
Implementation errors

It is a formal privacy mechanism, not a guarantee that every individual is impossible to identify under every circumstance.

8. Cybersecurity Controls Against Re-identification

Re-identification risk is not solely a data protection issue. It is also a cybersecurity concern because it involves unauthorized disclosure, misuse, correlation, and exploitation of information. A robust control framework should include the following measures.

8.1 Data minimization

Collect and retain only the information necessary for a defined purpose. Organizations should question whether they genuinely need: exact dates of birth, precise geographic coordinates, high-resolution timestamps, detailed behavioral histories, rare demographic attributes, full transaction sequences, etc.

Reducing the volume and granularity of data reduces the potential attack surface.

8.2 Generalization and aggregation

Generalization replaces precise values with broader categories. Examples:

Exact age → Age range
Full postcode → Regional area
Exact location → Geographic grid
Precise timestamp → Day or month
Exact salary → Salary band

Aggregation can also prevent individuals from being distinguished within small groups. However, excessive generalization may reduce analytical value. Privacy and utility must therefore be balanced deliberately.

8.3 Suppression of rare records

Records with highly unusual combinations of attributes may require:

Removal
Further generalization
Aggregation
Restricted access
Additional privacy protection

Rare records should be treated as high-risk data assets.

8.4 Access controls

Organizations should apply strong access management, including:

Role-based access control
Attribute-based access control
Least privilege
Multi-factor authentication
Segregation of duties
Privileged access management
Access reviews
Monitoring of unusual queries

Anonymized or pseudonymized data should not automatically be treated as low-risk.

8.5 Encryption and key management

Encryption protects data in transit and at rest. It is particularly important for pseudonymized datasets and identity-mapping tables. Organizations should separately protect:

Identity keys
Tokenization systems
Re-identification lookup tables
Data linkage services
Decryption credentials

If a re-identification key is compromised, a pseudonymized dataset may become directly identifying.

8.6 Monitoring and anomaly detection

Security teams should monitor for suspicious data access, such as:

Large-scale exports
Repeated queries targeting rare individuals
Unusual combinations of filters
Attempts to access identity-mapping systems
Cross-dataset correlation activity
Unusual access to sensitive attributes

Data loss prevention tools and security information and event management systems can support detection.

8.7 Secure data environments

For highly sensitive datasets, organizations should consider controlled research or analytics environments with:

Restricted downloads
Audited queries
Output checking
Data export approval
Network segmentation
Strong authentication
Controlled computation
Privacy review of published results

A secure environment can reduce the likelihood that a user will extract identifying information from a dataset.

For organizations operating under the GDPR, re-identification risk has several important consequences.

9.1 The definition of personal data

Under Article 4(1) GDPR, personal data includes information relating to an identified or identifiable natural person.

Identifiability may arise directly or indirectly, including through identifiers or factors relating to physical, economic, cultural, or social identity.

Consequently, a dataset may remain personal data even if names have been removed.

9.2 Recital 26 and reasonably likely means

GDPR Recital 26 requires organizations to consider whether a person is identifiable by means reasonably likely to be used, including objective factors such as: costs, time, available technology, technological developments, etc.

The assessment must account for the means available to both the controller and other parties.

This is a critical point: anonymization is not assessed solely from the perspective of the organization that released the data.

9.3 Pseudonymized data remains protected

Pseudonymized data is generally still subject to GDPR requirements where an individual can be identified using additional information. Relevant obligations may include:

Lawful processing
Purpose limitation
Data minimization
Storage limitation
Integrity and confidentiality
Data subject rights
Appropriate technical and organizational measures

9.4 Article 25: Data protection by design and by default

Organizations should integrate privacy protections into the design of data systems, datasets, analytics processes, and AI applications. Anonymization and pseudonymization should be considered during system architecture and data lifecycle planning, rather than added as an afterthought.

9.5 Article 32: Security of processing

Article 32 requires appropriate technical and organizational measures to ensure a level of security appropriate to risk. These measures may include: pseudonymization, encryption, confidentiality controls, resilience, testing, evaluation and regular review of security measures. Re-identification threats should be incorporated into security risk assessments.

9.6 Data Protection Impact Assessments

A DPIA may be required where processing is likely to result in a high risk to individuals, particularly when involving: health data, genetic data, biometric information, location data, large-scale profiling, systematic monitoring, artificial intelligence, vulnerable individuals, etc. The DPIA should evaluate whether anonymization is effective and whether the residual risk is acceptable.

9.7 Breach notification and accountability

If a re-identification incident results in unauthorized disclosure of personal data, the organization may need to assess its obligations under GDPR Articles 33 and 34. The specific obligations depend on whether a personal data breach has occurred, the likelihood and severity of risk, and the organization's role in the processing. Organizations should document their analysis and be able to demonstrate accountability under Article 5(2).

10. A Practical Re-identification Risk Assessment Framework

We should not simply ask, "Have we removed all names?" Instead, the following structured assessment should be performed.

Step 1: Identify the data elements

Create a complete inventory of the attributes contained in the dataset. Include:

Direct identifiers
Quasi-identifiers
Sensitive attributes
Metadata
Timestamps
Location data
Free-text fields
Unique identifiers
Derived attributes

Free-text fields are especially important because they may contain names, addresses, or contextual clues.

Step 2: Define the attacker model

Identify who might attempt re-identification. Potential attackers include:

Members of the public
Data recipients
Competitors
Malicious insiders
Data brokers
Researchers
Criminal groups
State-sponsored actors

Assess what information, skills, technology, and resources each attacker may possess.

Step 3: Identify auxiliary data sources

Consider the datasets that could be used for linkage. These may include:

Public registers
Social media
Commercial databases
Previous breaches
Public websites
Internal systems
Third-party data services

Step 4: Evaluate uniqueness

Determine whether records can be distinguished using combinations of attributes. The assessment should consider:

Record uniqueness
Population size
Geographic scope
Data granularity
Rare conditions
Temporal precision
Behavioral patterns

Step 5: Test realistic attack scenarios

Conduct controlled re-identification exercises. Possible techniques include:

Record linkage
Attribute correlation
Query-based attacks
Background knowledge testing
Synthetic attacker simulations
Membership inference testing
Review of machine learning outputs

Testing should be conducted lawfully and under appropriate authorization.

Step 6: Assess harm

Identification alone is not the only concern. Assess what could happen if a person were identified. Potential consequences include:

Discrimination
Financial fraud
Identity theft
Stalking
Extortion
Reputational damage
Employment consequences
Insurance discrimination
Exposure of medical information

Step 7: Apply mitigation measures

Based on the results, consider:

Removing attributes
Generalizing values
Aggregating records
Suppressing rare cases
Applying differential privacy
Restricting access
Improving monitoring
Reducing retention periods
Strengthening contractual controls

Step 8: Reassess periodically

Re-identification risk changes over time. New datasets, improved analytical methods, data breaches, and technological developments may make previously safe information more identifiable. Anonymization should therefore be reviewed periodically, especially before new disclosures or secondary uses.

11. Special Risks in Artificial Intelligence and Big Data

The rise of AI increases the importance of re-identification governance. Organizations increasingly use large datasets to train, evaluate, and operate machine learning systems. These datasets may contain information that is individually identifying or becomes identifying when combined with other sources.

11.1 Training data memorization

Some models may memorize portions of their training data, particularly when trained on duplicated, rare, or sensitive information. If a model reproduces identifiable training examples, privacy risks may arise even when the underlying dataset was described as anonymized.

11.2 Data aggregation across systems

AI systems may combine: customer data, public records, transaction information, web content, location histories, device telemetry and external data feeds. The combination may create a much more detailed profile than any individual source contains.

11.3 Inference of sensitive characteristics

Models may infer sensitive information from seemingly neutral features. For example, purchasing patterns, location histories, or language use may reveal information about health, religion, political views, or socioeconomic status. Organizations should assess not only whether direct identifiers are present, but also whether the system enables sensitive inferences.

11.4 Governance implications

AI governance frameworks should include:

Training data provenance
Privacy risk assessment
Data minimization
Access restrictions
Output monitoring
Memorization testing
Model privacy evaluations
Secure model deployment
Incident response procedures

The use of anonymized data does not eliminate the need for privacy governance.

12. Common Mistakes Organizations Should Avoid

Mistake 1: Assuming that deleted names mean anonymity

Removing direct identifiers is only one step. Quasi-identifiers and contextual information may remain identifying.

Mistake 2: Treating pseudonymization as anonymization

Pseudonymized data can often be linked back to individuals. It should be protected as personal data where applicable.

Mistake 3: Ignoring external datasets

Anonymization assessments must consider information outside the organization's immediate control.

Mistake 4: Failing to protect rare records

Unique or unusual records are more vulnerable to singling out and linkage.

Mistake 5: Publishing overly detailed data

High-resolution timestamps, precise locations, and detailed behavioral histories increase identification risk.

Mistake 6: Neglecting free-text fields

Free-text data may contain direct identifiers, personal narratives, or clues that make individuals identifiable.

Mistake 7: Relying solely on compliance labels

Calling a dataset "anonymous," "safe," or "de-identified" does not make it legally anonymous.

Mistake 8: Conducting no adversarial testing

Anonymization should be tested against realistic attack scenarios, not merely reviewed by the team that designed it.

Mistake 9: Ignoring data combinations

Several low-risk datasets may become high-risk when combined.

Mistake 10: Assuming risk remains constant

Future technology and newly available data can increase re-identification risk.

13. Recommendations

Organizations should adopt a coordinated privacy, security, and data-governance strategy to manage the risks associated with anonymization and de-identification. Effective protection requires collaboration between privacy professionals, cybersecurity teams, technical specialists, and senior management.

13.1 Privacy and Data Protection

Organizations should:

Ensure that claims of anonymization are properly documented and supported by evidence.
Clearly distinguish between anonymous and pseudonymous data when assessing privacy risks and regulatory obligations.
Consider realistic re-identification scenarios as part of Data Protection Impact Assessments (DPIAs) and broader privacy risk assessments.
Challenge unsupported assumptions that datasets are permanently or irreversibly anonymous.
Review data-sharing arrangements and secondary uses to determine whether additional privacy risks may arise.
Account for the availability of external or auxiliary information that could facilitate data linkage or re-identification.
Establish clear governance procedures for anonymization, de-identification, and the subsequent use of transformed datasets.
Periodically reassess anonymization measures in light of changes in technology, available datasets, and regulatory expectations.

13.2 Cybersecurity

Sensitive de-identified datasets should continue to be treated as valuable information assets, particularly where re-identification remains technically possible. Organizations should:

Apply least-privilege principles and strong access controls.
Monitor unusual patterns of data access, copying, aggregation, or extraction.
Protect identity-mapping keys and other information that could enable re-identification.
Conduct security testing to identify data-linkage and re-identification vulnerabilities.
Incorporate re-identification threats into organizational threat models and risk assessments.
Apply appropriate data-loss-prevention measures to sensitive datasets.
Secure analytics, research, and machine-learning environments in which de-identified data are processed.
Include potential re-identification scenarios in incident-response planning and testing.

13.3 Data Engineering and Privacy Engineering

Technical teams should incorporate privacy considerations throughout the data lifecycle rather than treating anonymization as a final processing step. Recommended measures include:

Minimize the granularity and volume of data collected and retained.
Systematically identify direct identifiers and quasi-identifiers.
Select privacy-preserving techniques according to the intended use, risk level, and characteristics of the dataset.
Evaluate attribute uniqueness and the extent to which individual records can be distinguished.
Remove, generalize, aggregate, or otherwise transform rare and highly identifying attributes where appropriate.
Apply formal privacy mechanisms when they provide an appropriate level of protection for the intended application.
Test transformed datasets and analytical outputs for potential disclosure and re-identification risks.
Maintain clear documentation of the techniques used, assumptions made, known limitations, and residual risks.
Reassess technical safeguards periodically as datasets, analytical methods, and available auxiliary information change.

13.4 Senior Management and Organizational Governance

Senior management should recognize that anonymization is not merely a technical implementation decision. It is a broader governance issue with implications for:

Regulatory compliance
Cybersecurity
Ethical data use
Organizational reputation
Customer and stakeholder trust
Research integrity
Commercial and operational risk

Organizations should therefore allocate appropriate resources to privacy engineering, independent testing, cybersecurity controls, governance processes, and continuous risk assessment. Management oversight should ensure that decisions concerning anonymization are proportionate to the sensitivity of the data, the intended use, and the potential consequences of re-identification.

Ultimately, effective anonymization governance should be viewed as an ongoing process rather than a one-time technical exercise. Organizations should continuously evaluate whether their privacy and security measures remain appropriate as technology, datasets, threats, and regulatory expectations evolve.

Conclusion

Re-identification attacks demonstrate that personal data can remain identifiable even after names, email addresses, and other direct identifiers have been removed.

The real privacy risk lies in the combination of information: quasi-identifiers, behavioral patterns, rare attributes, metadata, location histories, and external datasets can create pathways back to individuals.

For cybersecurity professionals, anonymization should be treated as a rigorous, evidence-based privacy engineering process not as a simple data-cleaning exercise.

Effective protection requires:

Understanding the difference between anonymization and pseudonymization.
Identifying quasi-identifiers and rare records.
Evaluating realistic attacker capabilities.
Considering external and auxiliary datasets.
Applying appropriate privacy-preserving techniques.
Combining privacy controls with cybersecurity safeguards.
Testing and reassessing re-identification risk over time.

Ultimately, the objective is not merely to remove names. It is to ensure that individuals cannot reasonably be identified through the information that remains.

Anonymization is successful only when the risk of identification has been meaningfully reduced not when the data merely looks anonymous.

Contents