Back to the blog

DPDP Stack

Section 33 penalties explained: what triggers them, what doesn't

8 October 2026

Section 33 penalties explained: what triggers them, what doesn't

Section 33 is the part of the DPDP Act that founders hear about secondhand, usually as a rumour with a large number attached. The rumour is not wrong, but it is also not the useful part. The useful part is understanding what actually triggers a penalty and what does not, because almost nothing about running an honest D2C store puts you anywhere near one.

What Section 33 actually does

Section 33 sets out financial penalties for non-compliance with the Act. It is not a fixed fine schedule. The Data Protection Board of India decides penalties case by case, after looking at what happened, how serious it was, and what the business did or did not do about it.

One fact is worth stating plainly, once: multiple independent public sources confirm that the penalty for failing to take reasonable security safeguards under Section 8(5) can reach up to Rs 250 crore, and the Board can double that for repeat or especially grave breaches under Section 33(3). That figure describes the ceiling for the most serious category of failure. It is not a number that applies to a small store that has made a reasonable effort and had a minor lapse.

What actually draws Board attention

The Board is not running automated scans of Shopify stores looking for missing cookie banners. Based on how the Act is structured, a few patterns of behaviour are what move a matter toward serious scrutiny:

  • A data breach that affected real people, where the business had no reasonable security measures in place and no record of having tried.
  • A pattern of ignoring a shopper's request to access, correct, or delete their data, with no process and no response at all.
  • A business that was told about a problem, by a regulator, a shopper, or anyone else, and did nothing to fix it.
  • Repeat conduct after a prior warning or finding, which is specifically what lets the Board double a penalty.

In every one of these, the common thread is not a technical imperfection. It is the absence of any good-faith effort, or ignoring a known problem.

What does not trigger it

A store that has a privacy notice, even an imperfect one, that is working toward a complete processor list, that has some record of shopper consent, and that responds when a shopper asks about their data, is not the fact pattern the Board is built to go after. Having gaps while visibly working on them is a different category from having no process and no record at all.

This distinction matters because the fear many founders carry is disproportionate to the actual trigger. The number itself should never be the reason a store acts. The behaviour that number is attached to, ignoring data obligations entirely with no attempt made, is the thing worth avoiding, and avoiding it does not require perfection.

The practical takeaway

Reasonable effort, documented, is the standard that keeps a store out of Section 33's attention. That means knowing where your customer data actually goes, having a notice that reflects it, recording shopper consent, and having somewhere to log a shopper's request when one comes in. None of that is exotic. It is closer to basic bookkeeping than to a legal minefield.

This is precisely the record that Consent Jet exists to build: it maps your store's actual data flows into a notice, logs shopper consent as tamper-evident proof, and gives you a place to record access, correction, and deletion requests as they come in.

Section 33 penalties explained: what triggers them, what doesn't | Consent Jet