Pseudonymisation
Replacing direct identifiers with codes, while the data can still be linked back to a person with extra information.
Pseudonymisation replaces names and other direct identifiers with codes, while a separate key lets you link the codes back to the people. It lowers risk but the data is still personal data.
Meaning of Pseudonymisation
Pseudonymised data is still personal data, because the link can be restored. It lowers risk but does not take the data outside the Act. This is different from anonymisation.
Pseudonymisation separates the content of a record from the identity of the person it concerns. A hospital study file might list "Patient P-0482" and a diagnosis, while a different, restricted table links P-0482 to a name and phone number. Whoever sees only the study file cannot tell who the patient is, but the organisation holding both can.
The DPDP Act does not use the word pseudonymisation or give it a special status. Section 2 defines personal data as data about an individual who is identifiable by or in relation to such data, and a pseudonymised record meets that test as long as the link exists or the person can be singled out by other information. All obligations, including notice, consent, security under Section 8(5) and breach notification, therefore continue to apply.
That makes the Act different from the GDPR, which names pseudonymisation expressly and encourages it, without taking it outside the regulation. In India, it is best viewed as a good practice that supports the safeguards in Rule 6, rather than a legal shortcut. It also differs from tokenisation and encryption in purpose and method, although the three are often combined.
Compare it with anonymisation, which must be irreversible. Pseudonymisation is deliberately reversible so the organisation can correct records, follow up with participants, or erase one person's data on request. Where the research and statistical exemption in Section 17(2)(b) is in view, a fiduciary must be careful, since it applies only if the data is not used for decisions specific to a Data Principal and prescribed standards are followed. Not to be confused with: pseudonymised data is personal data; properly anonymised data is not.
Examples of Pseudonymisation
A research team replaces patient names with ID numbers, and keeps a separate key table that links them back.
A research team replaces trial participants' names with codes and keeps the link file with the clinical coordinator only. When a participant withdraws consent, the coordinator finds the code and removes the data.
A platform gives its data scientists learner records with student IDs replaced by random codes. A scientist notices that one code belongs to the only learner from a small town, and the team generalises location to district level.
An insurer shares coded claim data with an actuarial vendor. The contract bars the vendor from attempting re-identification, and the insurer keeps the key table inside its own network.
Why Pseudonymisation matters
Pseudonymisation is a practical way to keep working with data while exposing fewer people to identities. If a pseudonymised dataset leaks, but the key table does not, the harm to individuals may be much lower and the organisation can show it took thoughtful safeguards.
The danger is the false belief that coded data is outside the law. A fiduciary that treats pseudonymised data as free of obligations may skip consent, ignore erasure requests or fail to report a breach, each of which can attract penalties up to ₹50 crore, or up to ₹250 crore where it is a failure of security safeguards.
How it works in practice
- 1Decide which fields are direct identifiers, such as name, phone number, e-mail and ID number, and which indirect ones, such as PIN code and birth date, could single someone out.
- 2Replace the identifiers with random codes, store the mapping table in a separate, access-controlled system, and encrypt it.
- 3Limit the pseudonymised dataset to teams that need it, and forbid attempts to re-identify people without approval.
- 4Handle rights requests through the key table: when a Data Principal asks for correction or erasure, locate the code and update or delete both sides.
- 5Review the risk that unusual combinations, such as a rare job in a small town, can reveal someone, and generalise those fields.
Where it appears in the DPDP Act and Rules
Common mistakes to avoid
Treating pseudonymised data as anonymous: while a key or other information can link it to a person, it is still personal data.
Storing the key table in the same database or folder as the coded data: this defeats the separation.
Choosing codes that follow a pattern, such as running numbers by sign-up date, which can be guessed or inferred.
Forgetting that rights requests still apply: you must be able to find and act on one person's data in the coded set.
Compliance tips
Keep a written record of which datasets are pseudonymised, who holds each key, and the purpose of use.
Rotate or regenerate codes between projects so datasets cannot be joined without approval.
Combine pseudonymisation with access control and logging, so every use of the key is traceable.
Common questions about Pseudonymisation
Is pseudonymised data personal data under the DPDP Act?
Yes, in general. If the data can be linked to an individual through a key or other information, it is data about an identifiable person and the Act applies to it.
What is the difference between pseudonymisation and anonymisation?
Pseudonymisation can be reversed using a separate key, so the person remains identifiable. Anonymisation is meant to be irreversible, so nobody can reasonably identify the person, and the data then falls outside the Act.
Does the DPDP Act encourage pseudonymisation?
The Act does not mention it by name. It can, however, support the [reasonable security safeguards](term/reasonable-security-safeguards) required by Section 8(5) and Rule 6, and reduce the harm if a dataset is exposed.