Anonymization vs Pseudonymization: Which One Actually Gets You a DPDP Exemption

The DPDP Act does not define anonymisation or pseudonymisation with a specific technical threshold, and it does not certify any particular algorithm or aggregation level as sufficient. What it gives you instead is a functional test under Section 17, which exempts processing for research, archiving, or statistical purposes provided the processing is not used to take any decision specific to a Data Principal. That is the hook engineering teams actually need to design against: not 'is this anonymised enough' in the abstract, but 'could this data, as processed, ever be used to make a decision about a specific identifiable person.'

This reframes the whole exercise. A dataset can be heavily transformed and still fail the test if it is realistically re-identifiable and someone downstream could act on that re-identification. Conversely, a lighter transformation can be defensible if the processing pipeline genuinely has no path back to individual-level decisions, and that path is closed off structurally, not just by policy.

Pseudonymisation replaces a direct identifier with a token or hash, but the substitution is reversible given the mapping table or a secret key, and that reversibility is the defining feature, not a bug. Common implementations include tokenisation services that swap identifiers for random surrogate values with the mapping stored separately, and keyed hashing, where the same input consistently maps to the same output but the key is protected. Pseudonymised data still functions as personal data under the Act because it remains linkable to an individual; it reduces exposure and supports safeguards, but it does not, by itself, qualify for the Section 17 exemption.

Where pseudonymisation earns its keep is as a risk-reduction layer inside systems that still need individual-level processing: analytics pipelines that need to join events to a user without every analyst seeing raw identifiers, or environments where the mapping key can be segregated from the working dataset with strict access controls. It is a security control, and a good one, but it is not an exemption strategy.

Anonymisation, to actually support a Section 17 argument, needs to remove the realistic possibility of re-identifying an individual, not merely make it inconvenient. Aggregation to sufficiently large cohorts, generalisation of quasi-identifiers, k-anonymity style approaches that ensure any record is indistinguishable from a minimum number of others, and differential privacy techniques that add calibrated noise to query outputs are the common technical approaches, chosen based on how the data will actually be used downstream.

The re-identification risk assessment has to account for auxiliary data, because that is how most real-world anonymisation failures happen: a dataset that looks anonymous in isolation becomes identifying when cross-referenced with another dataset the same organisation, or a third party, already holds. Location traces, rare attribute combinations, and small cohort sizes are the classic failure patterns, and they are exactly what a Data Protection Board inquiry would probe if an exemption claim were challenged.

The most common overclaim is treating pseudonymisation as if it were anonymisation because the direct identifier is gone from the working table, while the reversible mapping still exists somewhere in the system. If the mapping exists and is reachable by anyone in the organisation under any circumstance, the data is pseudonymised, not anonymised, and the Section 17 argument does not hold.

The second common overclaim is anonymising the dataset correctly but then using the output to make an individual-specific decision anyway — for example, an aggregated research dataset that gets re-joined against operational data to personalise an offer to a specific person. The exemption attaches to the processing purpose and use, not just to the state of the data, so the same anonymised dataset can be inside or outside the exemption depending entirely on what it is subsequently used for.

If you are trying to work out whether a specific processing activity in your organisation genuinely qualifies for an exemption, the Applicability Checker tool on this site walks through the relevant Act provisions against your actual use case rather than a generic checklist.