Founders running a Shopify store tend to use "breach" loosely, to mean anything from a suspicious login attempt to an actual leak of customer data. Under the Digital Personal Data Protection Act, the word carries weight, and it is worth being precise about what triggers an obligation and what is simply something to keep an eye on.
Incident first, breach second
A security incident is any event that could affect the confidentiality, integrity, or availability of data you hold, a failed login attempt, a vendor outage, a misconfigured setting that is caught and fixed before anything leaves your systems. Most incidents never become anything more than a line in a log. A personal data breach, in the sense the Act cares about, is when personal data is actually accessed, disclosed, altered, or lost without authorisation, a customer database exported by someone who should not have had access, an ESP account compromised and used to export a mailing list, a misconfigured storage bucket that exposed order data publicly.
The distinction matters because it decides whether you are dealing with an internal housekeeping matter or something that starts a statutory clock. Not every unusual event in your admin panel is a breach. But when personal data genuinely moves into unauthorised hands, the Act treats that as a different category of event entirely, one with notification obligations attached.
What the Rules ask of you
A breach record under the Act requires a countdown to notify the people who need to know, both the regulator and, depending on the severity, the affected individuals. That countdown is the part a tool can usefully track: the date the breach was identified, the clock running from that point, and a clear record of what happened and when, which matters as much for your own accountability as for anyone checking later.
What a tool cannot do is act on your behalf. The actual notification, whether that is a filing with the Data Protection Board or a message to affected customers, has to happen through your own channels, because it is your business making a regulatory and reputational judgement call, not software making it for you. A tool can record the incident, start the countdown, and hold the detail you will need to notify correctly. It cannot send the notification itself, and nothing should claim otherwise.
This is also where the penalty structure under the Act is worth knowing in plain terms, stated once and without drama. Section 33 sets financial penalties for non-compliance, decided case by case by the Data Protection Board of India. Multiple independent public sources confirm that the penalty for failing to take reasonable security safeguards can reach up to Rs 250 crore, and the Board can double it for repeat or grave breaches. That is not a reason to panic over every failed login. It is a reason to have an actual breach process rather than discovering, mid-incident, that nobody on your small team knows who is meant to do what. Worth remembering too that full Section 33 exposure begins 13 May 2027, which gives stores a genuine window to get a process in place before enforcement reaches this point.
Building the muscle before you need it
The practical gap in most D2C stores is not malice or carelessness, it is the absence of a defined process. Who gets told first when something looks wrong. Where the incident gets logged. Who decides whether it has crossed from incident to reportable breach. Who actually drafts and sends the notification once that decision is made. None of that needs to be elaborate for a store your size, but it does need to exist before the day you need it, because a countdown disappears quickly once you are also trying to figure out your own process from scratch.
Consent Jet gives a store a place to record a breach incident the moment it is identified and keeps the statutory countdown visible, so the clock is never the thing nobody noticed, while the actual notification stays where it belongs, with the merchant acting in their own tools.