YORIX
Digital Partners
Distributing Possibilities, delivering progress digitally
YORIX
Digital Partners
Distributing Possibilities, delivering progress digitally
The vocabulary maps. The obligations do not. Here is the translation, and here is exactly where relying on it starts to cost you.
If your organisation already runs a GDPR programme, or your parent company does, the first instinct is to map it across. That instinct is sound as far as it goes. The vocabulary really does correspond, and a team fluent in one law will not be starting from nothing in the other.
It stops going far quite quickly. This page is the mapping, and then the places where the mapping stops being safe.
These are conceptual comparisons only. DPDP and GDPR are different laws and do not have identical requirements.
| GDPR term | Rough DPDP equivalent |
|---|---|
| Data Subject | Data Principal |
| Controller | Data Fiduciary |
| Processor | Data Processor |
| Supervisory Authority | Data Protection Board of India |
| Legitimate Interests | No direct equivalent; DPDP uses specified Legitimate Uses |
| Data Portability | No equivalent standalone right under DPDP |
| Right to Object | No equivalent standalone right under DPDP |
Read down the first column and the second reads as a translation. That is genuinely useful for a first conversation: it means a GDPR-trained colleague can follow a DPDP discussion without a glossary. Each of these terms is defined properly in the DPDP glossary.
Three of the rows above do not resolve to a term at all, and those three are the ones that matter, because each represents work a GDPR programme has done that DPDP does not ask for, or a decision it has made that DPDP does not support.
DPDP has no direct equivalent. It provides instead for certain specified legitimate uses, set out in the Act, in which personal data may be processed without consent. The difference is not cosmetic: a legitimate-interests assessment is a judgement an organisation makes and documents, whereas a specified legitimate use either applies to the processing in front of you or does not. A GDPR programme that leans on legitimate interests as its main basis has, in DPDP terms, not yet established a basis at all.
There is no equivalent standalone right under DPDP. Machinery built to satisfy portability is not wasted — the same data mapping underpins access requests — but it is not answering a DPDP obligation, and it should not be presented as though it were.
Again, no equivalent standalone right under DPDP. Where consent is the basis for processing, the Data Principal may withdraw it, and withdrawal must be as easy as giving consent. That is a different mechanism with a different trigger, and processes written around objection handling do not simply carry over to it.
The reverse direction has its own trap. DPDP obligations with no GDPR counterpart — the Significant Data Fiduciary regime, the treatment of anyone under eighteen as a child, the detail the Rules require to reach the Data Protection Board within 72 hours of a breach — are the ones a mapped-across programme is most likely to be silent about, precisely because nothing in the source programme prompted them.
A mapping is a starting point, not a finished answer. Used well, it tells you which parts of an existing programme are likely to transfer, which is genuine and useful economy. Used badly, it produces a programme that is thorough about things the Act does not ask for and silent about things it does — and that is harder to spot than starting from nothing, because the documentation looks complete.
The practical test is the same one that applies to any inherited work: for each control you are carrying across, can you name the DPDP obligation it satisfies? Where the answer is a GDPR article rather than a DPDP one, the control may still be worth keeping, but it is not yet evidence of anything under this Act. Establishing which is which, across an actual estate rather than on paper, is what a structured gap assessment is for.