Loopholes in the law
The hex code that does not hide your customer
I was explaining the DPDP Act to a shopkeeper last week. He thought he had found a way out.
"I will take the customer's name and number, convert it into a code, and delete the original right away. Nothing is stored, so the Act does not apply to me."
It is a clever line of reasoning. It also does not work, and walking through why is one of the clearest lessons on the Act I have given all month.
The moment you collect, you have already processed
Processing under the Act covers collection, recording, storage, use and erasure. The instant the shopkeeper reads a phone number to build that code, processing has already happened. Deleting the input afterwards does not rewind it.
Changing the format does not make data anonymous
A common follow up is "but it is encoded, so it is anonymous." Simply changing the format of data does not make it anonymous. Reversible encoding is a different representation of the same value, not anonymisation. And then he said the part that settled it.
"When the customer comes back, I add loyalty points to that code."
To add points he has to recognise the same customer at the counter. The value is now functioning as an identifier tied to a real person, tracking behaviour over time. He did not avoid building a customer database. He built one and gave it another name.
If I write your name on paper, burn the paper, but keep the name in my head, I still know your name. Calling it a code does not change what it does.
So what can a small shop actually do?
Here are routes that are real, not theatre.
- Collect no identifying data at all. A cash sale with no name and no number, just a count of customers, involves no personal data, so the Act has nothing to attach to.
- Rely on Section 7(a), if its conditions are met. The Act's own illustration is close to a shop. A customer voluntarily gives her number and asks for the receipt to be sent. The shopkeeper may use the number for that specified purpose without a separate consent form. The condition matters: the customer must have voluntarily provided it for that specified purpose and not indicated that she objects to its use.
- Use a new purpose, get a new basis. If the number is later used for something else, such as a loyalty programme or marketing, that may need a separate legal basis. Do not assume Section 7(a) stretches to cover it.
- Minimise and erase. Take only what the purpose needs, use it only for that purpose, and erase it when the specified purpose is no longer being served and no legal retention requirement applies.
So the shopkeeper does not need a hex code. If Section 7(a)'s conditions are met, he takes the number for one purpose, uses it only for that, and then erases it. That is both lawful and free.
But here is where he has a point
The baseline obligations apply to all Data Fiduciaries, whether the business is small or large. Only Significant Data Fiduciaries, a class the Government notifies, carry the additional obligations. Even so, a kirana handling ten delivery addresses a month sits under the same baseline duties as a platform serving crores of customers. Notice, consent where required, grievance redressal, security, erasure.
So he is not wrong that compliance can feel disproportionate at his scale. He is only wrong that a code solves it.
Where should the line sit? Should the Act build in a lighter tier for small business, or does uniform protection for every citizen matter more than the burden on the smallest shops?