Your Slack is blowing up. Someone found customer data where it shouldn’t be. Maybe it’s a security researcher. Maybe it’s a customer. Maybe it’s worse. You’re now in the first hour of a data breach, and what you do next determines whether this becomes a manageable incident or a company-ending event.
If you’re a SaaS founder in India, you have legal obligations under both the DPDP Act and CERT-In’s incident reporting rules. This is the step-by-step playbook.
Hour 0 to 1: Contain the Breach
Before you do anything else, stop the bleeding.
Isolate affected systems. If you know which server, database, or service is compromised, take it offline or restrict access. Don’t wipe anything. Don’t restart servers. Don’t “fix it real quick.” Every action you take now could destroy forensic evidence you’ll need later.
Revoke compromised credentials. If API keys, database credentials, or admin accounts were exposed, rotate them immediately. If you’re not sure which credentials are affected, rotate all privileged access.
Activate your incident response team. If you have one. If you don’t, this is the group: CTO (or most senior engineer), a founder, legal counsel, and whoever manages customer communication. Get them in one room or one call. Right now.
Hour 1 to 4: Assess the Scope
You need answers to four questions as fast as possible:
- What data was exposed? Names and emails are different from payment data or Aadhaar numbers. The type of data changes your legal obligations and the severity of the incident.
- How many users are affected? Exact numbers can come later. Right now, you need an order of magnitude. Is it 50 users or 50,000?
- How did it happen? Was it a vulnerable endpoint, leaked credentials, a misconfigured S3 bucket, a compromised employee account? Knowing the vector tells you whether the attacker still has access.
- Is it still happening? Check whether the attacker is still active in your systems. If they are, containment is your priority over everything else.
Document everything as you go. Timestamps, actions taken, who discovered what and when. This log becomes critical for regulators and for your own legal protection.
Hour 4 to 6: Notify CERT-In
This is non-negotiable. CERT-In requires reporting within 6 hours of becoming aware of a cyber incident. The clock started when you first learned about the breach, not when you confirmed it.
You do not need to have a complete investigation to report. CERT-In expects an initial notification with whatever you know so far, followed by updates as you learn more.
Report through the CERT-In incident reporting portal. Include:
- Nature of the incident
- Systems and data affected (to the extent known)
- Initial assessment of impact
- Containment actions taken
Read our full guide to the CERT-In 6-hour rule for exactly what to include and how to file.
Do not skip this because you’re still investigating. The penalty for late reporting exists regardless of your reasons. File what you know, update later.
Hour 6 to 24: Notify the Data Protection Board
Under the DPDP Act, if personal data has been breached, you must notify the Data Protection Board of India. The exact timeline for this notification is still being defined through rules, but the obligation itself is clear. The Act treats breach notification as a core responsibility of every Data Fiduciary (that’s you, the company processing personal data).
Your notification should cover:
- Nature of the breach
- Categories of personal data affected
- Approximate number of Data Principals (users) affected
- Measures taken to contain and remediate
- Contact point for further information
If you’ve already filed with CERT-In, you’ll have most of this information ready. Don’t start from scratch. Use what you’ve already documented.
Hour 24 to 72: Notify Affected Users
This is the part most founders dread. But getting this right matters more than you think. A well-handled notification can actually build trust. A delayed or dishonest one destroys it.
What to tell users:
- What happened, in plain language
- What data was affected
- What you’ve done to contain it
- What they should do (change passwords, monitor accounts, etc.)
- How to reach you with questions
What not to do:
- Don’t minimize. If personal data was exposed, say so.
- Don’t blame a third party without evidence.
- Don’t use legal language that obscures what happened. Your users are not lawyers.
- Don’t wait until you have “all the facts.” A timely, honest notification with partial information is better than a perfect notification sent two weeks late.
Throughout: Preserve Evidence
From the moment you detect the breach, everything you do should preserve the forensic trail.
- Do not delete logs. CERT-In requires you to maintain logs for 180 days. If you delete them during an active incident, you’ve created a compliance problem on top of a security problem.
- Image affected systems before making changes if possible. A disk image taken before remediation is your best evidence if this goes to legal proceedings.
- Engage a forensics team if the breach involves significant data or a sophisticated attacker. If you don’t have internal forensics capability, engage an external firm. This is something you should identify before a breach happens, not during one.
The Three Mistakes That Make Everything Worse
1. Delaying notification hoping to fix it quietly. This is the most common mistake. Founders think: “If we patch the vulnerability and nobody noticed, we don’t have to report.” That’s not how it works. If personal data was accessed by an unauthorized party, the notification obligations are triggered. Fixing the vulnerability doesn’t undo the breach. And if it comes out later that you knew and didn’t report, the penalties are far worse.
2. Not having an incident response plan. When your first breach is also the first time you think about breach response, everything takes 5x longer. Who makes decisions? Who talks to CERT-In? Who drafts the customer email? Who handles press? Without a plan, people freeze or freelance. Neither is good.
3. Not knowing what data you actually store. We regularly talk to founders who can’t answer basic questions about their own data. Where is PII stored? Which databases contain payment information? Is data encrypted at rest? If you can’t answer these questions on a normal day, you certainly can’t answer them during a breach when everything is on fire.
The Real Fix: Prepare Before It Happens
Every item in this playbook becomes dramatically easier if you’ve done the preparation work:
- Incident response plan with roles, escalation paths, and notification templates. Tested at least once a year.
- Data inventory documenting what personal data you collect, where it lives, who has access, and how it’s protected.
- Forensic readiness with proper logging, log retention (180 days minimum for CERT-In), and a relationship with an external forensics firm.
- Legal counsel who understands DPDP Act and CERT-In requirements, identified and on retainer before you need them.
- Notification templates pre-drafted for CERT-In, the Data Protection Board, and customer communication. You should not be writing these under pressure.
If you don’t have an incident response plan or aren’t sure your current setup would survive a breach, that’s exactly the kind of problem a Security on Demand session is built for. Four hours, founder-led, focused on your specific gaps.
For ongoing incident response readiness as part of a broader security program, fractional security consulting gives you dedicated security leadership without a full-time hire.
Bottom Line
A data breach is stressful. But the difference between a startup that recovers and one that doesn’t usually comes down to preparation and speed of response. The DPDP Act and CERT-In rules are not suggestions. They carry real penalties. But the notification requirements also serve a practical purpose. They force you to act quickly, communicate honestly, and take the incident seriously.
Do the preparation now. Build the plan. Know your data. When the breach happens (and for most companies, it’s when, not if), you’ll be ready to execute instead of scrambling.