TL;DR: A breach doesn’t wait for you to figure out who to call. If your business handles sensitive data across multiple countries, a single incident can trigger CERT-In’s 6-hour window, GDPR’s 72-hour window, and separate obligations under the US, Australia, and India’s DPDP Act simultaneously, on independent clocks that don’t wait for each other. Most companies that get this wrong don’t get it wrong because the law was unclear. They get it wrong because there was no plan, and the first few hours got spent figuring out who was even supposed to be in the room.
Quick overview: This guide is written specifically for SaaS, fintech, and app businesses handling sensitive user data across borders, since that’s where multi-jurisdiction breach obligations hit hardest and most often. It covers what actually triggers a notification obligation, how to build one response plan that satisfies overlapping regimes at once instead of scrambling separately for each, and India’s specific CERT-In and DPDP requirements. For the proactive, setup-stage side of this, our complete DPDP Act guide and our guide to data protection laws around the world cover compliance before an incident happens; this page is about what to do once one has.
The pattern that actually causes the damage
Ask any lawyer who has actually handled a breach response what goes wrong, and it is rarely the law itself. Data protection statutes are demanding, but they are not secret. What actually causes the damage is far more mundane: there was no plan.
A pattern we see constantly with SaaS, fintech, and app clients specifically: a breach is discovered, usually not by the company’s own monitoring but by a customer complaint, a security researcher, or in the worst cases a ransomware note. The next few hours, the hours that matter most, get spent not on notification but on internal confusion. Who needs to be told first. Whether legal or engineering owns the decision. Whether this counts as a “breach” or just an “incident.” By the time anyone actually starts the notification clock, a meaningful chunk of the tightest deadline in the entire framework, CERT-In’s 6-hour window, has often already passed without a single external notification having gone out.
This is not a knowledge problem. It is a process problem, and it is entirely preventable with a plan built before the breach happens, not during it.
What actually triggers a notification obligation
Before anything else, it matters to get the terminology right, because getting it wrong is one of the most common points of confusion in a live incident.
A cybersecurity incident is any event affecting your systems, a malware infection, a denial-of-service attack, unauthorised access, regardless of whether personal data was actually touched. A personal data breach is specifically an event that compromises personal data, whether through unauthorised access, accidental disclosure, or loss. Most real-world incidents that make the news are both at once, but they are legally distinct triggers, governed by different frameworks, and a company that only checks one box can miss an obligation that was sitting under the other.
This distinction matters practically because your reporting obligations depend on which one applies, and often both apply to the same event simultaneously, to different regulators, on different clocks.
The real challenge: multiple regimes, multiple clocks, one event
For a SaaS or fintech company with users across more than one country, and this is the normal situation for most of the businesses actually dealing with this, a single breach rarely triggers just one obligation. It triggers several, based on two separate questions asked at the same time: where are your affected users located, and where does your business itself operate.
Where your users are located determines which data protection regimes apply. If any affected individuals are in the EU, GDPR applies. If any are California residents, the CCPA applies. If any are in Australia, the Privacy Act applies. These obligations are triggered by the location of the data subject, not by where your company is headquartered or incorporated.
Where your business operates determines which additional regimes apply on top. An Indian company, or a foreign company with Indian operations or Indian users, has CERT-In and DPDP Act obligations that apply regardless of where else the company is also answering to a regulator.
The result for a genuinely global SaaS or fintech business: a single breach affecting European, American, Australian, and Indian users at once can trigger GDPR’s 72-hour clock, CCPA’s requirements, Australia’s Privacy Act obligations, CERT-In’s 6-hour clock, and DPDP Act notification, all starting from the same moment of discovery, all requiring separate filings, and none of them waiting for the others to be finished first.
Building one response that satisfies all of them at once
This is where most breach-response guidance stops short. It explains each regime separately and leaves you to figure out how they interact. The actual practical answer is to build a single incident response structure designed around the tightest deadline and the broadest disclosure requirement across every regime you’re subject to, then adapt the output for each specific regulator, rather than starting from scratch for each one.
Build around your tightest clock, not your average one. If CERT-In’s 6-hour window applies to your business, that is your internal deadline for the first action, not 72 hours, not “as soon as possible.” A response plan built around GDPR’s more generous 72-hour window will fail the moment an Indian obligation is also in play, because the shorter clock doesn’t pause to be polite to the longer one.
Maintain one core incident narrative, not five separate ones. The facts of what happened, when it was discovered, what data was affected, and what containment steps were taken should be documented once, accurately, and then adapted in format and emphasis for each regulator, rather than reconstructed independently each time. Inconsistent accounts across parallel filings are precisely what turns a difficult incident into a genuinely damaging one, since regulators compare notes, and a story that shifts between filings reads as concealment even when it’s just poor coordination.
Assign clock ownership before an incident, not during one. Decide in advance who is responsible for triggering each notification, CERT-In, the Data Protection Board, GDPR’s supervisory authority, US state attorneys general, Australia’s regulator, so that the first hour of a real incident is spent executing a decision that was already made, not making one under pressure.
Separate detection, containment, and notification as parallel workstreams, not sequential ones. A common and costly mistake is trying to fully understand and contain an incident before notifying anyone. Most regimes do not require full certainty before the clock starts, they require notification once you become aware of a breach, with the ability to supplement details later. Waiting for complete information before making any external notification is one of the most common ways a company blows through its tightest deadline entirely.
A standard data breach response action plan
The framework below is a starting structure, built around the tightest clock a genuinely global SaaS, fintech, or app business is likely to face, CERT-In’s 6-hour window. Treat every timestamp as counting from the moment your organisation first becomes aware of the incident, not from when it’s fully understood. This is a generic foundation, not a finished plan: a fintech business carries additional obligations under RBI and payment card industry rules, a healthcare-adjacent product carries its own sector-specific data rules, and a product handling children’s data carries additional consent and disclosure considerations layered on top. Adapt the structure below to your specific sector, regulator relationships, and company size before you need it, not while you’re using it.
Hour 0 to 1: Detect and activate. Confirm the incident is real and document the basic facts as you understand them, time of detection, nature of the event, systems or data types potentially affected. Activate your incident response team and name a single Incident Commander, one person with authority to make time-sensitive calls, so decisions aren’t stuck waiting for consensus. Begin evidence preservation immediately, system logs, access records, and forensic snapshots, since this obligation runs in parallel with notification, not after it. Assume, by default, that your tightest applicable clock has already started.
Hour 1 to 6: Contain and file your first notification. Work to isolate affected systems and stop the incident from spreading further, without destroying the evidence you preserved in the previous step. If CERT-In’s window applies to your business, this is the period in which that filing needs to happen, based on what you know now, not on complete findings. In parallel, work out which data subject jurisdictions are actually affected, EU, US states, Australia, India, or a combination, since this determines every notification that follows. Start drafting your core incident narrative as a single internal source of truth document that every subsequent regulatory filing will be adapted from, rather than rewritten from scratch.
Hour 6 to 72: Complete your broader regulatory notifications. File the Data Protection Board notification where a personal data breach is involved. Where EU data subjects are affected, this window is where your GDPR supervisory authority notification is due. Assess whether US state attorney general or SEC 8-K disclosure obligations apply, and prepare Australia’s OAIC notification if applicable. Each of these should be built from the same core narrative, adapted in format and emphasis, not reconstructed independently.
Day 3 to 30: Notify affected individuals and begin remediation. Notify every affected individual or Data Principal directly, in the form each applicable regime requires. Where relevant, offer practical remediation, credit monitoring, forced password resets, or equivalent steps appropriate to what was actually exposed. Continue the forensic investigation and supplement your earlier regulatory filings with additional detail as it becomes available, since most regimes expect and allow for this rather than demanding total certainty upfront.
After the incident: review and close the gaps it exposed. Run a genuine post-mortem examining not just the technical cause but where your response process itself broke down. Update your written incident response plan based specifically on what actually happened, not a generic template. And review the vendor, API, and data processing agreements that were involved, since a breach frequently exposes exactly which contracts had inadequate indemnity or liability provisions for a scenario like the one you just lived through.
What the strictest obligations actually require
GDPR requires notification to the relevant supervisory authority within 72 hours of becoming aware of a breach, and to affected individuals without undue delay where the breach poses a high risk to their rights and freedoms.
In the United States, requirements vary by state, but most require notification to affected individuals within a defined window, and increasingly states are layering separate regulator or attorney general notification on top of consumer notification, with its own independent clock. Publicly listed companies also face SEC requirements to disclose material cybersecurity incidents on Form 8-K within four business days of determining materiality.
Australia’s Privacy Act requires notification to the Office of the Australian Information Commissioner and affected individuals as soon as practicable once an organisation has reasonable grounds to believe an eligible data breach has occurred.
India: two parallel regimes, and they don’t substitute for each other
Where an Indian entity or Indian users are involved, two separate Indian frameworks apply simultaneously, and satisfying one does not satisfy the other.
CERT-In’s 6-hour reporting window applies to cybersecurity incidents generally, under the CERT-In Directions of April 2022, issued under Section 70B of the Information Technology Act, 2000. This covers a wide range of specified incident categories, ransomware, unauthorised access, data breaches, denial-of-service attacks, and more, and the 6-hour clock starts from the moment the incident is noticed, not from when it’s fully understood. Non-compliance carries real consequences under the IT Act.
The DPDP Act’s Data Protection Board notification applies specifically to personal data breaches, requiring Data Fiduciaries to notify the Board and every affected Data Principal. Guidance on the precise notification window has varied across sources following the DPDP Rules notified in November 2025, with some describing a confirmed 72-hour reporting window and others describing an “as soon as possible” standard pending further Board guidance; either way, there is currently no materiality threshold in the statutory text, meaning a breach affecting ten records triggers the same notification obligation as one affecting ten million. Confirm the current precise requirement with counsel at the time of an actual incident, since this is an area where Board guidance continues to develop.
The practical trap this creates: CERT-In and DPDP obligations are parallel, not alternative, so filing with one does not discharge the other, and because CERT-In’s window is materially tighter, it is almost always the first deadline your team will actually face in a real incident, regardless of which framework feels more relevant to the specific data involved.
What to build before you need it
A response plan is only useful if it exists before the breach, not while everyone is still figuring out who’s in charge. At minimum, this means a written incident response plan naming who owns detection, who owns the decision to activate the plan, and who owns each specific regulatory notification. It means pre-drafted, adaptable notification templates for each regime you’re realistically exposed to, so the first hours aren’t spent drafting from a blank page. It means a tested process for preserving forensic evidence from the moment of detection, since evidentiary obligations run in parallel with notification ones. And it means knowing, in advance, exactly which regimes actually apply to your specific user base and operations, not discovering it mid-incident. Our guide to what having international users actually means for your legal obligations covers how to map this out properly, and our complete guide to the SaaS legal document stack and Data Processing Agreement template cover the contractual groundwork a genuine response plan needs to sit on top of.
Contracts matter here too, not just internal process. Our indemnity clause guide and guide to why not having a limitation of liability clause can seriously damage a business cover how breach-related costs actually get allocated between you and your vendors, customers, and API providers when an incident involves data flowing through multiple parties, which is standard for most SaaS and API-driven products. Our API licensing agreement guide and Acceptable Use Policy guide cover the related platform obligations worth checking alongside this.
Frequently asked questions
What is the difference between a cybersecurity incident and a personal data breach?
A cybersecurity incident is any event affecting your systems, regardless of whether personal data was involved, malware, unauthorised access, denial-of-service. A personal data breach is specifically an event that compromises personal data. Most real-world incidents are both at once, but they are legally distinct triggers under different frameworks, and a company that treats them as interchangeable can miss an obligation sitting under the one it didn’t check.
If my company operates in India but has users in Europe, which breach notification rules apply?
Both, and they run independently. CERT-In’s 6-hour window and, where personal data is affected, the DPDP Act’s Data Protection Board notification apply because your business operates in India. GDPR’s 72-hour window applies separately because you have affected users in the EU. Neither regime substitutes for the other; you file with all of them.
How fast do I actually need to respond to a data breach?
As fast as your tightest applicable deadline, not your most familiar one. For a business with Indian operations, CERT-In’s 6-hour window is almost always the binding constraint, since it is materially shorter than GDPR’s 72 hours or Australia’s “as soon as practicable” standard. Build your internal response plan around the shortest clock you’re actually subject to, not the average.
Do I need to fully understand a breach before notifying regulators?
No, and waiting to reach full certainty is one of the most common ways companies blow through their tightest deadline. Most regimes require notification once you become aware of a breach, with the ability to supplement details as the investigation continues. Detection, containment, and notification should run as parallel workstreams, not a strict sequence.
What should a small SaaS or fintech company actually do before a breach happens?
Build a written incident response plan naming clear ownership for detection, activation, and each specific regulatory notification; prepare adaptable notification templates in advance for every regime you’re realistically exposed to; establish a forensic evidence preservation process; and map, in advance, exactly which jurisdictions’ rules actually apply to your specific user base, rather than discovering it under pressure during a live incident.
Is there a standard action plan I can actually follow during a breach?
Yes, though it needs adapting to your specific industry and structure. A workable starting framework moves through five phases: the first hour for detection and activating a named Incident Commander; hours one to six for containment and your first regulatory filing, typically CERT-In if it applies, since it’s usually the tightest deadline; hours six to seventy-two for broader notifications including GDPR and the Data Protection Board; days three to thirty for direct notification to affected individuals and remediation; and a post-incident review to close the gaps the breach actually exposed. A fintech business layers RBI and payment card obligations on top of this; a healthcare-adjacent product layers its own sector rules; adapt accordingly.
This article is for informational and educational purposes only and does not constitute legal advice. Data breach notification requirements change and vary significantly by jurisdiction, sector, and the specific facts of an incident, particularly under India’s DPDP Act, where Board guidance continues to develop. If your business is currently experiencing a suspected breach, seek qualified legal advice immediately rather than relying on this guide alone.
Authored and reviewed by Prakhar Rai, Advocate, founder of My Legal Pal, enrolled with the Bar Council of India, with the My Legal Pal legal team, drawing on patterns seen advising SaaS, fintech, and app businesses handling multi-jurisdiction data obligations. Connect on LinkedIn.
If your business needs a genuine incident response plan built before you need it, or is currently navigating a live breach across multiple jurisdictions, our team can help. Our privacy policy drafting service covers the underlying compliance documentation, and our contract review and revision and contract drafting services can help build the vendor and platform agreements a real response plan depends on. Speak to our contract lawyers in India or the USA today.
