Anonymisation and Pseudonymisation Under the DPDP Act

Introduction

"It is anonymised, so the Act does not apply" is a common answer when a business plans to share data with an analytics or AI partner. Sometimes it is right: the Digital Personal Data Protection Act, 2023 (the DPDP Act) regulates only personal data. But the Act never uses the word "anonymised", sets no standard for it and does not prohibit re-identification.

This article covers when data stops being personal, why pseudonymised and hashed data does not, and which ground covers anonymising. A data fiduciary decides why and how personal data is processed; a data principal is the person it is about. Trayambic's articles on AI training and on retention are not repeated here.

The legal position

The only test is identifiability. Section 2(t) defines personal data as "any data about an individual who is identifiable by or in relation to such data". The word "identifiable" appears nowhere else in the Act, which defines neither anonymisation nor de-identification.

Parliament dropped a definition. The Personal Data Protection Bill, 2019, which did not become law, defined anonymisation as an "irreversible process" meeting "standards of irreversibility specified by the Authority". The 2023 Act keeps neither the definition nor a standard-setter.

Anonymising is processing. Section 2(x) defines processing to include "adaptation", "alignment or combination" and "erasure or destruction". Stripping or coarsening identifiers is such an operation.

Masking is a safeguard, not an exit. Rule 6(1)(a) of the DPDP Rules, 2025 lists, as security measures, securing personal data through "encryption, obfuscation, masking or the use of virtual tokens mapped to that personal data". These protect data that remains personal.

Research has its own exemption. Section 17(2)(b) disapplies the Act for processing "necessary for research, archiving or statistical purposes" if the data "is not to be used to take any decision specific to a Data Principal" and prescribed standards are followed. Rule 16 and the Second Schedule set those standards, from lawful and minimal processing to security and accountability.

Reference points outside the Act are few, and none binds private businesses generally.

Analysis

Identifiable by whom, and with what means

Section 2(t) covers a person identifiable "by" the data, through a name, face or number, or "in relation to" it, by linking it with something else. It does not say who must be able to link. Read absolutely, almost nothing is anonymous. Read purely from the holder's side, a business could launder personal data by handing it to a partner without the key.

The ABDM policy's middle course is means "reasonably likely to be used". The Court of Justice of the European Union took a similar line in EDPS v SRB (Case C-413/23 P, 4 September 2025): pseudonymised data is not personal "in all cases and for every person" (para 86), but is personal for a recipient with means reasonably allowing re-identification (para 85), though the discloser's duty to inform is judged "from the point of view of the controller" (para 111). That does not bind India, but in our view the Data Protection Board is likely to read s.2(t) the same way: assess each holder with the means realistically open to it, and treat a discloser that keeps the key as disclosing personal data.

A Trayambic test: key, crowd, context, conduct

Building on the re-linking test in our AI training article, ask four questions of every holder: you, your processors, each recipient, and anyone who would get the data through publication or a breach. Data is anonymous for a holder only if all four answers are clean.

1. 1.Key. Does the holder have, or could it obtain, a code list, source system or original data that maps records back to people?
2. 2.Crowd. Does every record share its mix of indirect identifiers, such as age, sex, pin code and visit date, with enough others that it cannot be singled out?
3. 3.Context. What other data can the holder reasonably reach, such as public registers, its own customers or other clients' datasets, and what barriers stop it?
4. 4.Conduct. Will anyone use the data to single out, contact, profile or decide about a person? If so, it is personal by design.

Record the answers, and re-run them whenever the data, the recipients or public datasets change.

Why pseudonymised and hashed data stays personal

A pseudonymised dataset always has a key somewhere: the table linking each reference number to a person. It fails the first question for whoever holds that table: the fiduciary and, in our view, any group company with access.

Hashing fails more quietly. The same input always gives the same hash, which is why advertisers use hashes to match customers. Indian mobile numbers have ten digits, so anyone can hash every possible number and reverse an unsalted hash by lookup. A keyed hash resists that only for those without the key. Trayambic's ad-tech study took the same view of hashed emails.

Masking and tokenisation reduce harm in a breach, but Rule 6 lists them as safeguards for personal data, so notice, a lawful ground, rights and breach reporting continue to apply. Trayambic's article on SDKs and trackers covers device identifiers.

Techniques that lower risk

• Aggregation publishes counts and rates, not records. Suppress small cells and watch for differencing between releases.
• Generalisation and k-anonymity coarsen indirect identifiers (age bands, districts, months) until every combination is shared by at least k records. If all k share one diagnosis, it still leaks, so check sensitive values too.
• Noise and synthetic data add randomness or artificial records. Test synthetic data for copied rare records.
• Free text, images, voice and genomes resist all of these. Treat them as identifiable unless specifically processed and tested.

Anonymising needs a ground

Because anonymising is processing, s.4 requires a ground for the step itself, chosen by why you anonymise.

Some argue that anonymisation is always erasure and never needs a ground. We do not rely on that for live data put to a new purpose, because any new use could then bypass consent. Drawing the line at the end of the purpose is our reading and untested.

Research and analytics

Section 17(2)(b) reaches further than anonymisation: a pseudonymised research dataset can be exempt if no decision about an individual follows and the Second Schedule is met. Aggregate reporting, such as turnaround times by centre or test positivity by district, fits "statistical purposes"; analytics that ranks, targets or calls back individual customers does not. Trayambic's AI training article reads the exemption as unavailable for a product built to make decisions about people, and we keep that reading. In health, the ICMR's ethical guidelines add ethics review and expect de-identified or anonymised sharing.

Practical implications

Worked example: diagnostics data for an AI vendor

All figures are illustrative. A diagnostics group with 22 imaging centres in Karnataka and Tamil Nadu holds six years of chest scans and reports. A Bengaluru AI vendor owned by a Singapore company offers a revenue share for images to train a lung-nodule product for other hospitals. It proposes "anonymised" files with names and phone numbers removed.

The four questions expose the gaps. Key: file names carry accession numbers that the group's systems map to patients. Crowd: a 91-year-old scanned at a small taluk centre on a given day is unique. Context: the vendor holds scans from other hospitals in the same cities, head CT can be rendered into a face, and report text names relatives. Conduct: the vendor wanted to send "flagged" cases back for follow-up, a decision about individuals.

The group decides:

1. 1.Validation first. The vendor's model runs on a pseudonymised sample inside the group's Indian cloud tenancy, with ethics approval, under s.17(2)(b): measuring accuracy is statistics, and no result reaches a patient.
2. 2.Training data from expired records only. Images past the group's five-year retention period, due for erasure, are anonymised instead. That goes beyond the statistics and evaluation uses our retention whitepaper accepted; in our view it is defensible only with full rigour: headers and burned-in text stripped, faces removed from head scans, reports reduced to structured findings, ages banded, pin codes cut to districts, dates turned into intervals, and combinations shared by fewer than ten patients suppressed. The mapping is destroyed, and a team outside the project tries to re-identify records before release.
3. 3.Consent for the future. From May 2027, registration offers a separate, optional consent to use de-identified images for AI development with named partners.
4. 4.Contract. Because the Act does not prohibit re-identification, the contract does: no re-identification attempts, no linkage with other datasets, notice of accidental re-identification, audit rights, and deletion if a later test fails. As an ABDM participant, the group also checks clause 29 of the ABDM policy.

Checklist

Key takeaways

Under the DPDP Act, "anonymised" is a conclusion, not a label. It holds only when no holder has a key, a small crowd, useful context or a reason to single anyone out, and it must be re-tested as data and recipients change. Pseudonymised and hashed data stays personal for anyone who can reverse it. Because anonymising is itself processing, settle the ground for that step before choosing the technique.

• The DPDP Act has no definition of anonymisation; data leaves the Act only when no one is identifiable 'by or in relation to' it under s.2(t).
• Judge identifiability holder by holder, using the means each could reasonably use; a discloser that keeps the key is still sharing personal data.
• Pseudonymised, hashed, masked and tokenised data remains personal data; Rule 6(1)(a) treats these techniques as safeguards, not exits.
• Anonymising is processing: it needs a ground, which can be erasure, security, research under s.17(2)(b) or consent, depending on why you do it.
• Standards such as ISO/IEC 20889 and 27559 are voluntary; contracts must supply the re-identification ban the Act lacks.