Anonymized and Pseudonymized Data: Are They Subject to Data Subject Requests?

Privacy laws like the GDPR and CCPA/CPRA grant data subjects several rights over their personal data, but what happens when that data is anonymized or pseudonymized? Do data subject rights still apply, and if so, to what extent?

The legal implications of these two de-identification methods differ fundamentally. Truly anonymized data (i.e., processed to a point where it can never be linked back to a person by any reasonably likely means) falls entirely outside the scope of most privacy laws.

Pseudonymized data, however, remains fully subject to data subject rights because it still counts as personal data. That said, the extent to which these rights apply may depend on whether key-linking information is available.

Below, we clarify how these concepts affect your legal obligations when responding to data subject requests, as well as what constitutes sufficient de-identification under privacy laws.

Legal Definitions of Anonymization and Pseudonymization Under Privacy Laws

First things first, let's clarify the legal definitions of anonymization and pseudonymization.

Anonymized Data Under The GDPR

According to Recital 26 of the EU's General Data Protection Regulation (GDPR), anonymous data is:

"information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable"

Here's how the legal text presents it:

By using the phrase "all the means reasonably likely to be used… by the controller or by any other person…" the GDPR creates a dual threshold:

1. You can never again reasonably identify individuals from the data
2. No third party with reasonably available means can do so either

In other words, personal data becomes anonymized only when it is irreversibly stripped of all identifiers so that a data subject cannot be re-identified by any means reasonably likely to be used by your business or any other party.

What's more, the GDPR states that your test of "reasonably likely means" for re-identification should consider all objective factors, including:

• The cost of identification
• The time required for identification
• The level of technological development at the time of processing
• Future technological advancements

Once personal data becomes truly anonymous (by the standards above), the GDPR no longer applies to that data. If, however, re-identification remains reasonably possible, the data is not anonymous, and the GDPR still applies.

To clarify just how high a bar of anonymous data is under the GDPR, the UK Information Commissioner's Office (ICO) encourages applicable organizations to conduct a "motivated intruder" test.

This test takes things up a notch by having you consider the chances of success in a scenario where someone is truly motivated (to the level of a personal vendetta) to reverse your anonymization techniques.

The ICO's updated anonymisation and privacy-enhancing technologies (PETs) guidance (2023–2024) expands on this test, offering practical steps and sector-specific examples for ensuring data remains outside the scope of personal data.

Pseudonymized Data Under The GDPR

Article 4(5) of the GDPR defines pseudonymization as a method of processing personal data in a way that the data can no longer be attributed to a specific individual without using additional information.

This "additional information" (i.e., the key to re-identification) must be kept separately and be subject to strong technical and organizational security measures to prevent re-linkage.

According to the European Data Protection Board (EDPB) Guidelines on Pseudonymization, additional information typically includes cryptographic keys for encryption or look-up tables for matching pseudonyms to personal data.

Pseudonymization essentially means replacing direct identifiers in personal data with artificial identifiers (like codes or tokens), while keeping additional information (like encryption keys) separately, which allows you to later re-identify the data.

Because the data subject can still be identified with the help of additional information, pseudonymized data is considered personal data as defined under Article 4(1) of the GDPR:

The key implication is that all GDPR requirements will apply to pseudonymized data just as with personal data.

Latest EDPB Perspective from 2025: In January 2025, the European Data Protection Board (EDPB) issued Guidelines 01/2025 on Pseudonymisation for public consultation, providing the most up-to-date regulatory interpretation.

The guidelines introduce the concept of a "pseudonymisation domain" - the environment in which pseudonymisation secrets (e.g., encryption keys, lookup tables) are held - and require that these secrets be protected by strong technical and organisational measures.

Effectiveness must be assessed against reasonably available capabilities, including those outside the controller's immediate systems. The EDPB also clarifies that pseudonymisation is a security measure, not a means of removing GDPR obligations, and its adequacy must be tested over time as new re-identification methods emerge.

Deidentified and Pseudonymized Information Under the CCPA/CPRA

Like the GDPR, the California Consumer Privacy Act (CCPA) and its amendment, the California Privacy Rights Act (CPRA), discuss the concepts of anonymization and pseudonymization.

The CCPA/CPRA uses the term "deidentified" to refer to anonymization. Section 1798.140(m) of the law defines deidentified data as information "that cannot reasonably be used to infer information about, or otherwise be linked to, a particular consumer…"

The CCPA/CPRA then goes on to add strict operational safeguards that must be in place for personal information to be truly deidentified. In essence, a business that holds deidentified data must:

• Take reasonable measures to make sure the data cannot be associated with a consumer or household.
• Publicly commit to maintain the data in deidentified form and not attempt to re-identify it, except for limited testing to confirm that deidentification measures are effective.
• Contractually require any downstream recipients of the data to comply with these same deidentification commitments.

If these conditions are met, the data is treated as outside the scope of "personal information" under the CCPA/CPRA. That means all legal obligations, including CCPA/CPRA consumer rights (access, deletion, correction, etc.), do not apply to that data, similar to the GDPR's treatment of truly anonymized data.

On the other hand, pseudonymization under the CCPA/CPRA retains the same definition and implications as it does under the GDPR:

The CCPA/CPRA also excludes "aggregate consumer information" derived from deidentified data under Section 1798.140(b), which creates an additional category outside the scope of personal information.

Several other US state privacy laws, such as those in Colorado, Virginia, and Connecticut, also exclude "deidentified" data from scope and treat pseudonymous data as personal information, using definitions broadly consistent with the CPRA.

Do Data Subject Requests Apply to Anonymized Data?

No, they don't. If data is truly anonymized under GDPR Recital 26, it is no longer "personal data." Similarly, data that meets the deidentified standard under section 1798.140 of the CCPA/CPRA is no longer "personal information."

In both cases, all data subject rights, including access, deletion, correction, restriction, objection, and others, do not apply. And businesses are not obligated to respond to users' requests to exercise these rights.

But the standard of anonymization/deidentification under privacy laws is higher than most businesses realize. The Article 29 Working Party established in its Opinion 05/2014 that all anonymization techniques must prevent three types of attacks:

1. Singling out: Isolating records about an individual
2. Linkability: Linking records about the same person across datasets
3. Inference: Deducing information about an individual from dataset patterns

As shown below:

The UK ICO backs this up, stating that simply removing names, addresses, ID numbers, or other obvious identifiers from a dataset isn't sufficient to ensure anonymization.

One high-profile example of anonymization failure is the Netflix Prize dataset case. Netflix removed subscriber names and replaced them with random numbers, believing this achieved anonymization.

However, researchers at the University of Texas were able to identify specific Netflix subscribers by cross-referencing viewing patterns with public IMDb ratings. Re-identification was possible because Netflix underestimated auxiliary information availability and the uniqueness of viewing patterns.

That said, regulators like the UK ICO acknowledge that whether information is personal can depend on who holds it and what they can access. So, your test should be based on what's reasonably likely, not every theoretical possibility of identification.

The takeaway is that you must implement ongoing technical and organizational measures to ensure that data remains anonymous. You must also periodically re-evaluate the risk of re-identification as new technologies and external data sources become available. A dataset that is anonymous today may become re-identifiable tomorrow.

Do Data Subject Requests Apply to Pseudonymized Data?

Yes, they do. Under Article 4(5) of the GDPR, pseudonymized data is still personal data because it can be linked back to an individual using additional information kept separately. The same principle applies under the CCPA/CPRA.

Recital 28 of the GDPR clarifies that pseudonymization was introduced to reduce the risk to data subjects and support controllers and processors in their duties, but does not exempt them from data protection obligations.

Pseudonymization is essentially a strong security measure, but it does not remove or lessen your legal obligations. All data subject rights, including the rights to access, deletion, correction, objection, and others, still apply as usual.

Following the CJEU's Breyer judgment (C-582/14), European courts have considered whether pseudonymised data in one party's hands may be anonymous to another party who lacks the re-identification key.

This "recipient-perspective" issue featured in the Single Resolution Board (SRB) v EDPS litigation. In February 2025, the Advocate General advised setting aside the General Court's restrictive view and re-examining whether the SRB could identify individuals without additional data it did not possess. This evolving case law underlines the importance of assessing identifiability per actor and in light of the specific technical and legal means available to them.

Narrow Exception Under Article 11 of the GDPR

Under Article 11, the GDPR provides a narrow exception that may let data controllers deny a data subject request when they hold pseudonymized data.

This provision states that if you cannot identify a data subject and have no reason to do so, you're not obligated to acquire or maintain additional information just to fulfill their data subject rights. Note that you must inform the data subject of this situation accordingly.

This provision is reinforced by Recital 57 of the GDPR, which clarifies that if you cannot identify the data subject, you're not required to acquire or maintain additional information solely to fulfill their data subject request.

If, however, the data subject provides the necessary additional information to enable identification, you cannot refuse to collect the information. You must fulfill their data subject request accordingly.

Long story short, if data is pseudonymized, start from the assumption that all data subject rights apply. You should only depart from that position if you can clearly justify a relevant exemption under the applicable law.

Here's a practical workflow for Article 11 situations:

1. Verify the request. Ensure it is valid and within scope.
2. Check identifiability. Determine if you can identify the data subject with reasonably available means.
3. If not identifiable, inform the requester under Art. 11(2) that you cannot fulfil the request without additional data and that you are not obliged to collect such data.
4. Invite further information. Under Art. 12(6), invite the requester to provide additional details to confirm identity. If they do, process the request normally.

Best Practices for Handling Data Subject Requests on Anonymized and Pseudonymized Data

Below, we briefly outline a few best practices for properly handling data subject requests based on the nature of the data involved.

• Classify Your Data Correctly: Upon receiving a request, your first action should be to determine if the data in question is anonymized, pseudonymized, or directly identifiable. This classification determines your legal obligations. Mislabeling data as anonymized when it's only pseudonymized is a common and costly mistake.
• Handle Anonymization Appropriately: If you have verified that the data is truly anonymized according to the GDPR's standards or the CCPA/CPRA's "deidentified" provisions, then data subject rights do not apply. You should explain this to the data subject, cite the relevant legal provisions, and then document your analysis to close the request.
• Handle Pseudonymization Appropriately: By default, you must treat pseudonymized data as personal data and fulfill all applicable data subject requests, unless you genuinely cannot identify the individual. In such cases, you may rely on the GDPR's Article 11 exception. That said, regulators like the EDPB recommend asking the data subject to provide additional information before denying the request.
• Continuously Assess Re-identification Risk: True anonymization is rare. Technologies and auxiliary datasets evolve, which makes re-identification more feasible over time. So, reassess your data regularly, especially after combining or sharing it.
• Maintain Robust Governance for "Keys" and Mappings: If you hold the additional information that links pseudonyms to identities, treat the data as personal. Secure these mappings with strong access controls and document who has access, when, and why.
• Handle Edge Cases with Care: Real-world data is often complex. You must consider scenarios with mixed records, joint data that would reveal others, or data held by third-party services. In these cases, a careful legal assessment is always required to determine what can and cannot be disclosed.
• Document Every Decision: Keep an audit trail of your identifiability assessments, the safeguards applied, the legal basis for any denial, and the exact wording of communications sent to data subjects. This record is vital for demonstrating compliance to regulators and defending your business against complaints.

Remember: don't mistake hashing for anonymisation. Unsalted hashes are typically pseudonymisation, not anonymisation, because the original values can often be recovered or matched using common techniques. The EDPB and former WP29 have repeatedly stressed that only irreversible transformation beyond reasonably likely reversal qualifies as anonymisation.

Summary

Anonymized data sits entirely outside the scope of privacy laws like the GDPR and CCPA/CPRA, but truly meeting the standard is rare. Most "de-identified" data still carries some re-identification risk, meaning they must be handled with caution and regularly reassessed.

In contrast, pseudonymized data is still a form of personal data because pseudonymization is only a security measure. All data subject rights apply to this data unless the narrow conditions of the GDPR's Article 11 (or equivalent provisions under other laws) are met.

For every decision you make regarding a data subject request, particularly a denial, meticulous documentation is your best defense.

When in doubt, it's best to treat any data in question as subject to full consumer rights until proven otherwise. This approach protects you against legal issues while ensuring data subjects receive the privacy protections modern laws intend to provide.