Data Breach notification under the DPDP Act: What Indian businesses must actually do (2026)
- Outsource 360
- 6 days ago
- 17 min read
In late July 2026, roughly a terabyte of records belonging to customers of one of India's largest state-run banks surfaced on a dark-web site. The cache reportedly held KYC documents, Aadhaar numbers, and loan files drawn from branches across the country, with some reports putting the number of exposed application forms between 100,000 and 300,000. A group calling itself TripleX claimed responsibility and made the dataset public on 24 July.
Here's the part that should make every other business in India sit up. The reported entry point wasn't an exotic zero-day or a breach of the bank's core systems. It was, per the bank's own statement, a single compromised employee email account. The lender confirmed a cyber incident, said its core banking platforms stayed secure, and opened a forensic investigation.
Sit with that for a second. A household-name institution, with a security budget most founders can only imagine, got hit through the most ordinary door there is: one inbox. And the uncomfortable question this raises isn't whether the same thing could happen to your business. It's whether, if it did, you'd know exactly what you're legally required to do next. That's precisely what data breach notification under the DPDP Act governs, and most Indian businesses can't answer it.
The gap matters more now than it did a year ago. India's Digital Personal Data Protection framework has moved from a law on paper to a live compliance regime, complete with a functioning regulator and penalties that run into hundreds of crores. A breach is no longer just an IT problem or a PR headache. It's a reporting obligation with clocks, named recipients, and financial consequences for getting the timing wrong.
And yet the businesses most exposed here aren't the big banks. They're the lean ones. A 20-person SaaS company, a bootstrapped D2C brand, a mid-market services firm with no in-house privacy team: these are the outfits collecting real personal data every day while assuming the rules are someone else's problem. They're wrong, and the cost of being wrong just went up.
So let's walk through what the law actually requires, who it applies to, and what a small team without a dedicated compliance function should do in the first 72 hours after a breach. No legalese for its own sake. Just the parts you need to act on.
Under India's DPDP Act, a business that suffers a personal data breach must notify the Data Protection Board of India and every affected individual without undue delay, with a detailed report to the Board due within 72 hours. A separate CERT-In rule requires reporting certain cyber incidents within just 6 hours. Failing to report can draw penalties up to ₹200 crore.
That's the headline. The detail is where businesses trip up, so here's how the obligation breaks down, section by section.
Table of contents
What happened in the Bank of Baroda data breach
The facts, at a glance, since they frame everything below:
What leaked: reportedly around 1 TB of data, including KYC documents, Aadhaar numbers, and loan records; some reports cite 100,000 to 300,000 customer application forms.
How: according to the bank, a compromised employee email account, not a breach of its core banking systems.
When: the dataset was published on a dark-web site on 24 July 2026 by a group calling itself TripleX.
The bank's response: it confirmed the cyber incident and said it had begun a forensic investigation.
The detail worth sitting with is the cause. A household-name bank was exposed through the most ordinary risk there is, a single inbox. What follows is what the DPDP Act expects any business to do when personal data is compromised like this.
What counts as a personal data breach under the DPDP Act
Before you can report a breach, you have to recognise one. And this is where a lot of founders quietly talk themselves out of a legal obligation.
Under the Digital Personal Data Protection Act, 2023, a personal data breach means any unauthorised processing of personal data, or accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data, that compromises its confidentiality, integrity, or availability. Read that definition again, because it's broader than most people assume. It isn't limited to hackers exfiltrating a database. Loss of access counts. Accidental disclosure counts. An internal mistake counts.
Here's what that looks like in the real world. A compromised employee email account that exposes customer files (the reported Bank of Baroda vector) is a breach. A laptop with an unencrypted client spreadsheet left in a cab is a breach. A misconfigured cloud storage bucket that anyone can browse is a breach. A phishing attack that hands an attacker your CRM login is a breach. None of these require a sophisticated attacker, and that's the point.
The mistake we see most often? The "our core systems weren't touched, so it isn't really a breach" reasoning. In the Bank of Baroda case, the bank was careful to say its core banking systems stayed secure, and that's a legitimate operational reassurance. But under the DPDP definition, the exposure of customer KYC data through a peripheral system is still a personal data breach. Where the data leaked from matters far less than whether personal data was compromised.
A common question founders raise is whether employee data counts, or only customer data. It counts. Personal data is personal data whether it belongs to a customer, an employee, a vendor contact, or a job applicant. If your HR system leaks staff PAN numbers, that's as much a reportable breach as a customer list going out the door.
The pitfall here is under-classification. When a team treats a phishing incident or a lost device as a mere security hiccup rather than a potential personal data breach, it never starts the reporting clock, and it's the missed clock, not the breach itself, that tends to attract the harshest scrutiny.
Who must report: are you a Data Fiduciary
The DPDP Act puts the reporting duty on one specific party, and naming it correctly decides who's on the hook.
That party is the Data Fiduciary: the person or entity that, alone or with others, determines the purpose and means of processing personal data. In plain terms, if you decide why and how personal data gets collected and used, you're a Data Fiduciary. Most businesses that run a website, an app, a CRM, or a payroll system are Data Fiduciaries for the data they control. The reporting obligation sits with you, not with your cloud host or your outsourced processor.
There's a second tier worth knowing. Under the Digital Personal Data Protection Rules, 2025, a Significant Data Fiduciary is a Data Fiduciary (or class of them) that the Central Government notifies as significant, based on factors like the volume and sensitivity of data processed and the risk of harm. Significant Data Fiduciaries carry heavier duties: appointing a Data Protection Officer based in India, commissioning independent audits, and running periodic Data Protection Impact Assessments. If you're a large platform or a high-volume processor of sensitive data, assume this may apply and plan accordingly.
Think of it this way. A 15-person fintech startup processing lakhs of Aadhaar-linked records is carrying a very different risk profile from a boutique design agency with a mailing list, even though both are Data Fiduciaries. The breach-notification duty applies to both. The additional governance obligations scale with how significant your processing is.
Now, the objection we hear constantly: "we're too small for this to apply to us." There's no small-business exemption in the DPDP Act. Obligations scale with the volume and sensitivity of what you process, not with your headcount or revenue. A two-founder company holding customers' financial details is squarely within scope. So is a solo operator running an e-commerce store on customer data.
The trap for lean teams is assuming the duty lives with the vendor. If you use an outsourced payroll provider and they suffer a breach of your employees' data, you as the Data Fiduciary still carry the notification obligation. The next section on the clocks makes this concrete, and the outsourcing section covers how to structure contracts so a processor's breach doesn't become your compliance failure.
The reporting clocks: 72 hours, 6 hours, and (for some) RBI
This is the section most competitor guides get half-right, and getting it half-right is how businesses miss a deadline. Because there isn't one clock. There are at least two, and for regulated sectors, three.
Under the DPDP framework, once you become aware of a personal data breach, you must intimate the Data Protection Board of India and each affected individual. The DPDP Rules set the mechanics: an initial intimation to the Board without delay describing the nature, extent, timing, and likely impact of the breach, followed by a detailed report to the Board within 72 hours (or a longer window if the Board permits). Notification to affected individuals must also happen without delay.
But the DPDP clock doesn't replace an older, tighter one. Under the CERT-In Directions of 28 April 2022, issued under the Information Technology Act, specified cybersecurity incidents must be reported to CERT-In within just 6 hours of detection. Most real-world breaches qualify as both a personal data breach and a cybersecurity incident. When that's the case, you're reporting to two authorities on two different clocks: 6 hours to CERT-In, 72 hours to the Board. These are parallel obligations, not alternatives, and that catches teams off guard.
For regulated entities, add a third. A bank or NBFC, like the one at the centre of the July 2026 leak, also reports cyber incidents to the Reserve Bank of India under its cyber-security framework. So a single breach at a regulated financial firm can trigger RBI, CERT-In, and DPDP obligations at once, each with its own format and timeline. If you operate in a regulated sector, your incident-response plan has to map all three before an incident, not during one.
Here's where timing gets genuinely tricky, and where honesty matters more than hype. Is the DPDP 72-hour rule fully enforceable against you today? Not entirely, and any guide that tells you otherwise is skipping the nuance. The DPDP Rules were notified on 14 November 2025 and are rolling out in phases. The Data Protection Board itself stood up in the first phase, but the breach-intimation mechanics sit in a later phase, with a final compliance deadline of 13 May 2027. The CERT-In 6-hour obligation, by contrast, has been in force since 2022 and applies right now.
What does that mean in practice? Treat the 72-hour DPDP process as the standard you build toward and adopt now, not a rule you can defer until 2027. The Board is live, enforcement is ramping, and the sectoral and CERT-In obligations already bite. The mistake we see forming is teams reading "phased enforcement" as "optional until 2027" and building nothing. When the deadline arrives, they'll be improvising, and improvising a breach response is exactly how the 72 hours slip away.
What your breach notifications must actually say
Knowing you have to notify is only half the job. Send a vague or incomplete notice and you've technically reported while still leaving yourself exposed. So what goes in each one?
The notice to the Data Protection Board has to give it enough to act on. Per the DPDP Rules, that means the nature, extent, timing, and likely impact of the breach up front, then a fuller report covering the broad facts and causes, the mitigation measures you've taken or plan to take, findings on who or what caused it, and the steps you're implementing to prevent a repeat. Think of the first intimation as the alarm and the 72-hour report as the incident post-mortem.
The notice to affected individuals is a different document with a different job. It has to be concise, clear, and in plain language a non-technical customer can understand. It should describe the breach, its likely consequences for that person, the mitigation you've undertaken, the safety steps the individual can take (change passwords, watch for phishing, freeze credit where relevant), and a contact point who can answer their questions. Legalese here isn't just unhelpful, it undercuts the whole purpose of the notice.
Here's a distinction that trips up businesses with cross-border exposure. Under the DPDP Act, you notify the Board and every affected individual for every personal data breach. Under the European Union's General Data Protection Regulation (Article 33), a controller notifies its supervisory authority within 72 hours only where the breach is likely to result in a risk to individuals, and notifies individuals only for high-risk breaches. India's rule is stricter on the "who gets told" question: there's no risk-threshold filter that lets you keep a minor breach quiet.
A real question founders with large user bases ask: how do you notify thousands of affected individuals "without delay"? The practical answer is that this is an operational capability you build in advance, not a task you improvise. Templated, pre-approved notice language, a mechanism to email or message every affected user, and a designated contact channel are the difference between notifying in hours and scrambling for a week. Frankly, this gets overlooked until the day it's needed.
The pitfall is treating notification as a legal formality to be minimised. A grudging, information-thin notice can read as evasive, and in a regime where the regulator weighs your conduct when setting penalties, looking evasive is expensive.
Your first 72 hours: a breach-response runbook
Theory is fine. But when a breach lands on a Friday evening and half your team is offline, what do you actually do, in order? Here's a runbook a lean team can follow without a dedicated security function.
The first window is about containment and the fastest clock. In roughly the first 6 hours after detection, your priorities are to contain the incident (revoke compromised credentials, isolate affected systems), preserve evidence rather than wiping it in a panic, and assess whether the incident is a reportable cybersecurity incident that triggers the CERT-In 6-hour obligation. Speed matters most here, because that 6-hour clock is the tightest one you face.
The second window is assessment and formal notification. Between hours 6 and 72, you scope what data was affected and whose, prepare and send the detailed report to the Data Protection Board, and prepare the notices to affected individuals. This is also when you loop in legal support and, for regulated firms, file with your sectoral regulator. The goal is to enter hour 72 with the Board report filed and the individual notices ready or already going out.
The following sequence captures the core steps for a small team:
Detect and log. Record the time you became aware. Every clock runs from awareness, so this timestamp is your most important record.
Contain. Revoke access, reset credentials, isolate the affected system. Stop the bleeding before you analyse it.
Preserve evidence. Don't reimage machines or delete logs. You'll need them for the Board report and any forensic review.
Assess CERT-In trigger (within 6 hours). If it's a specified cyber incident, report to CERT-In on the 6-hour clock.
Scope the breach. Identify what personal data was affected and which individuals.
Notify the Board. Initial intimation without delay, detailed report within 72 hours.
Notify affected individuals. Plain-language notices, without delay.
Document everything. Decisions, timings, mitigation. This record is your defence if the Board inquires.
Who owns each of these when you don't have a Data Protection Officer? This is the question that separates a plan from a wish. Assign named owners in advance: a founder or ops lead as incident commander, someone (internal or a retained provider) for technical containment, and a legal or compliance contact for the regulator filings. A common founder question is whether you need a DPO at all. Unless you're a Significant Data Fiduciary, you may not be legally required to appoint one, but you absolutely need a named human who owns breach response before a breach happens.
What if you genuinely can't determine the full scope within 72 hours? You report what you know on time and supplement it. The Board's framework anticipates an initial intimation followed by a fuller report, and it allows a longer window where the Board permits. Silence because you're still investigating is the wrong call. A timely partial report beats a late complete one.
The biggest pitfall for small teams is treating breach response as purely an IT task. It isn't. It's a cross-functional drill involving legal, communications, and leadership, and the companies that handle breaches well are the ones that ran a tabletop exercise before they ever needed the real thing.
Penalties: is it really ₹250 crore
The number that grabs headlines is ₹250 crore, and it's real. But understanding when it applies (and when a smaller or no penalty is more likely) matters more than the scary figure.
Under Section 33 and the Schedule to the DPDP Act, the Data Protection Board can impose monetary penalties following an inquiry. The Schedule sets maximums by category. The headline ₹250 crore maximum attaches to a failure to take reasonable security safeguards to prevent a personal data breach. A separate maximum of ₹200 crore attaches to a failure to notify the Board or affected individuals of a breach. So the two most expensive failures are, first, not protecting the data, and second, not reporting when it's compromised.
These are ceilings, not fixed fines, and that distinction is where businesses misread their risk. The Board weighs several factors when setting an amount: the nature, gravity, and duration of the breach, the type of personal data involved, whether the breach was repetitive, whether the responsible party gained or avoided a loss, and, crucially, what mitigation the party took. In other words, how you respond directly influences what you pay.
Does reporting on time and mitigating reduce your exposure? Based on how the factors are framed, yes, meaningfully. A firm that detects a breach, contains it, notifies promptly, and helps affected individuals presents very differently to a regulator than one that concealed the incident and got caught. The "we'll just quietly fix it" instinct is the single most expensive mistake available to you here, because non-disclosure converts a defensible incident into an aggravating one.
What's the enforcement outlook? Early signals suggest the Board will become progressively more active through 2026 and 2027 as the phased rules take full effect, and operators expect the first significant adjudications to shape how strictly the notification timelines are read. High-profile incidents like the July 2026 bank leak are exactly the cases that tend to test a new regulator's appetite. Building compliant habits now, while enforcement is still ramping, is far cheaper than retrofitting them under scrutiny later.
A question people ask after every big breach: has anyone actually been fined yet? Public, large-scale DPDP penalties are still emerging as the regime matures, which is precisely why the coming 18 months are the window to get your house in order before enforcement hardens.
When and how founders outsource this
Not every business can or should build a full privacy function in-house. So where's the line between what a lean team handles itself and where specialists genuinely help?
A small team can realistically own the basics: knowing what personal data it holds and where, maintaining a simple breach-response runbook with named owners, keeping software patched, and training staff on phishing (the very risk that reportedly opened the Bank of Baroda incident). None of that requires a large budget. It requires attention and a bit of documentation. If you've read our general DPDP compliance obligations guide, you already have the foundation this builds on.
Where outsourced support earns its keep is in the specialist, episodic work: drafting a defensible breach-response policy, running a Data Protection Impact Assessment, standing up the notification templates and channels before you need them, and providing an experienced hand during an actual incident when the clocks are running and judgment matters. This is also where cross-border founders juggling DPDP alongside other cross-border compliance deadlines benefit from a partner who maps the overlapping regimes once, properly.
There's a second-order risk here that founders miss. When you outsource data processing (payroll, analytics, customer support), the processor's breach is still your notification obligation as the Data Fiduciary. The practical reality is that your contract has to carry the weight: a clause requiring the processor to notify you of any breach fast enough for you to hit your own 6-hour and 72-hour clocks, plus defined security standards and audit rights. If your vendor learns of a breach on Monday and tells you on Thursday, your 72 hours are already gone, and the Board holds you, not them, accountable.
If handling breach-response readiness in-house is pulling your team away from the work only they can do, Outsource360's data-protection and technology-law support can help you build the policy, templates, and processor clauses that make a breach survivable. It's the kind of thing that's cheap to set up in advance and painfully expensive to assemble mid-incident.
Frequently asked questions
How many hours do you have to report a data breach under the DPDP Act?
You must give the Data Protection Board of India an initial intimation without undue delay and a detailed report within 72 hours of becoming aware of the breach. Affected individuals must also be notified without delay. Note that a separate CERT-In rule requires reporting specified cyber incidents within 6 hours.
Who do you report a personal data breach to in India?
The Data Fiduciary reports to the Data Protection Board of India and notifies each affected individual. Where the incident is also a cybersecurity incident, it's reported to CERT-In as well. Regulated entities such as banks and NBFCs additionally report to their sectoral regulator, for example the Reserve Bank of India.
What is the penalty for not reporting a data breach under the DPDP Act?
Failure to notify a breach can draw a penalty of up to ₹200 crore, and failure to take reasonable security safeguards up to ₹250 crore. These are maximums set by the Schedule to the Act, not fixed fines. The Board decides the actual amount after weighing factors including the severity of the breach and the mitigation taken.
Do I have to notify affected customers, or just the Board?
Both. Unlike some frameworks that only require individual notification for high-risk breaches, the DPDP Act requires notifying every affected individual for every personal data breach, in plain language, alongside notifying the Board.
What counts as a personal data breach under the DPDP Act?
Any unauthorised processing of personal data, or accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data, that compromises its confidentiality, integrity, or availability. That includes a compromised email account, a lost unencrypted device, a misconfigured database, or a successful phishing attack.
Is the DPDP 72-hour rule in force in 2026?
The DPDP Rules were notified in November 2025 and are being enforced in phases, with the breach-intimation mechanics carrying a final compliance deadline of 13 May 2027. The Data Protection Board is already operational, and the parallel CERT-In 6-hour obligation has been in force since 2022. The practical advice is to adopt the 72-hour process now rather than wait.
What's the difference between CERT-In 6-hour reporting and DPDP 72-hour reporting?
CERT-In reporting, under the IT Act, covers cybersecurity incidents and has a 6-hour deadline in force since 2022. DPDP reporting covers personal data breaches, goes to the Data Protection Board, and carries a 72-hour detailed-report deadline. Most breaches are both, so you report to both authorities on both clocks.
Who is a Data Fiduciary, and am I one?
A Data Fiduciary is any person or entity that decides the purpose and means of processing personal data. If your business decides why and how it collects and uses customer or employee data, you're a Data Fiduciary and you carry the breach-notification duty.
What is a Significant Data Fiduciary, and does it change my breach duties?
It's a Data Fiduciary the government notifies as significant, based on factors like the volume and sensitivity of data processed. Significant Data Fiduciaries face extra obligations such as appointing a Data Protection Officer and running periodic audits and impact assessments. The core breach-notification duty applies to all Data Fiduciaries regardless.
What's the maximum DPDP fine, and is it really ₹250 crore?
Yes. The maximum penalty for failing to take reasonable security safeguards is ₹250 crore, and for failing to notify a breach it's ₹200 crore. Both are ceilings; the Board sets the actual amount case by case.
Does DPDP breach notification apply if the data was encrypted?
The reporting duty is triggered by a compromise of the confidentiality, integrity, or availability of personal data. Strong encryption may reduce the harm and factor into how the Board views the incident, but you should not assume encryption alone removes the obligation to assess and, where required, report.
How is DPDP breach notification different from GDPR?
GDPR requires notifying the supervisory authority within 72 hours only where a breach is likely to create a risk, and notifying individuals only for high-risk breaches. The DPDP Act has no such risk threshold for who gets told: you notify the Board and every affected individual for every breach.
Can I outsource DPDP breach compliance?
You can outsource much of the preparation and specialist work: policy drafting, impact assessments, notification templates, and incident support. But the legal notification obligation stays with you as the Data Fiduciary, so outsourcing is about building capability and support, not transferring the duty.
If my outsourced vendor causes the breach, who reports it?
You do, as the Data Fiduciary. The processor's breach of data you control is still your notification obligation. That's why your processing contracts should require the vendor to alert you fast enough to meet your own reporting clocks.
Has anyone actually been fined under the DPDP Act yet?
Large, public DPDP penalties are still emerging as the regime and its Board mature through the phased rollout. That's exactly why the current window is the time to build compliant habits, before enforcement hardens over 2026 and 2027.
References
Digital Personal Data Protection Act, 2023 (No. 22 of 2023), Ministry of Electronics and Information Technology (MeitY). Section 8(6) sets the breach-intimation duty; Section 33 and the Schedule set penalties. meity.gov.in
Digital Personal Data Protection Rules, 2025, MeitY (notified 14 November 2025). Rule 7 covers intimation of a personal data breach. pib.gov.in
CERT-In Directions under Section 70B(6) of the Information Technology Act, 2000, dated 28 April 2022, on 6-hour cyber-incident reporting. cert-in.org.in
Reserve Bank of India cyber-security framework and incident reporting for banks and NBFCs. rbi.org.in
General Data Protection Regulation (EU) 2016/679, Article 33, on breach notification to the supervisory authority. gdpr-info.eu
This article is for educational and general business information purposes only and does not constitute professional legal, financial, or tax advice. For guidance specific to your situation, consult a qualified professional.
Comments