The First 72 Hours After a Data Breach Could Decide Your DPDPA Exposure

A breach used to trigger one clock: contain it, fix it, recover. Under India’s Digital Personal Data Protection (DPDP) Act 2023, and the DPDP Rules, 2025 (notified on 13 November 2025), it now triggers at least two more clocks: a regulatory reporting deadline and, in most cases, a parallel CERT-In deadline. Miss either one, and the organization is exposed, no matter how well the technical response went.

This is no longer a hypothetical timeline. The Rules are final. Enforcement of the breach and penalty provisions is expected around May 2027, roughly 18 months after notification. That means the response plan needs to be ready well before then, not written after the first incident.

Why This Is a Governance Problem, Not Just a SOC Problem

Under the DPDP Act, any organization that processes personal data (a “Data Fiduciary”) must maintain reasonable security safeguards. When a breach happens, the Data Protection Board of India (DPBI) looks at two separate things:

• Were the safeguards good enough before the breach? This covers logging, encryption, access controls, and vendor contracts.
• Did the response after the breach follow the Rules? This covers timing, completeness, and documentation.

A breach that was handled well on the technical side can still lead to a big penalty if the notification was late, vague, or poorly documented. That makes this a board-level risk, not just a line in the SOC’s incident report.

What the DPDP Rules Actually Require?

Rule 7 sets out a two-stage notification process to the Board, plus a separate duty to notify affected individuals.

To the Data Protection Board of India:

1. Initial notice, sent “without delay.” As soon as your incident response team confirms a personal data breach, notify the Board. This is a short alert, not a full report. You don’t need to have finished the investigation yet.
2. Detailed report, within 72 hours of becoming aware of the breach. This should cover: the nature, scope, timing, and location of the breach; the categories and rough number of people and data affected; the root cause and circumstances; the steps taken or planned to fix it; findings on who caused it, if known; and a summary of what was told to affected individuals. The Board can grant more time, but only if you ask in writing with a reason. It’s not automatic.

To affected individuals: Notify them “without delay,” in plain language. Explain what happened, what it means for them, what you’re doing about it, what they should do to stay safe, and who to contact with questions. There’s no minimum size for this duty. A breach affecting ten people carries the same notification requirement as one affecting ten million.

The parallel clock most security teams already track: if the incident also falls under the CERT-In Directions (April 2022), you have a separate 6-hour reporting duty to CERT-In. A single ransomware attack can trigger both clocks at once, and the CERT-In clock keeps running through nights, weekends, and holidays.

The key point: the clock starts the moment you become aware of the breach, not once you’ve confirmed the root cause. Waiting for a full picture before you notify is itself a compliance failure.

What the Penalty Exposure Actually Looks Like

The DPDP Act sets maximum penalties for each type of failure. The Board also weighs things like the scale of the breach, the harm caused, and the organization’s track record when deciding the actual fine:

• Up to ₹250 crore for failing to keep reasonable security safeguards in place (Section 8(5)). This penalty is about your posture before the breach.
• Up to ₹200 crore for failing to notify the Board or affected individuals (Section 8(6)). This is a separate penalty, on top of the one above.
• Up to ₹200 crore for breaking the special rules that protect children’s data (Section 9).

The main thing to understand: weak security and a poor breach response are treated as two separate failures. A strong incident response doesn’t make up for weak controls, and strong controls don’t excuse a late or incomplete notification.

Regulatory Review: What the Board Will Actually Ask For

Once you notify the Board, it may ask for incident timelines, security logs, forensic reports, risk assessments, proof of the safeguards you had in place, and records showing how decisions were made. In practice, being able to show a clean, timestamped log of who knew what, and when, and what they did about it, matters just as much as your technical controls do.

Most organizations are underprepared here, not on detection, but on having the evidence ready.

Building a 72-Hour-Ready Incident Response Capability

1. Define “awareness” ahead of time. Confusion about when the clock started is a problem you create for yourself. Your incident response plan should spell out exactly what counts as confirmed awareness of a personal data breach (as opposed to a suspected security event), and who has the authority to make that call.
2. Set decision rights before an incident, not during one. Build a standing breach response team that includes security, legal, your DPO or compliance lead, communications, and engineering leadership, with backups named for when the main people are unavailable. The 72-hour window doesn’t pause for anyone’s vacation.
3. Close the data visibility gap. You can’t scope a breach, or write an accurate Board report, if you don’t know where sensitive personal data lives in your environment. Data Security Posture Management (DSPM) tools that map where data sits, flag excessive access, and cut unnecessary exposure will shorten the time it takes to get from detection to an accurate 72-hour report.
4. Build for evidence, not just detection. Endpoint security and identity and access telemetry help with containment, but they also need to produce the timestamped, exportable evidence trail the Board will ask for. If your logging wasn’t built with a regulatory audit in mind, fix that now.
5. Put notification duties into vendor contracts. Handing data processing to a vendor doesn’t transfer your accountability under the DPDP Act. Your organization is still on the hook if a processor is breached. Contracts should require vendors to notify you fast (well inside 72 hours, so you have time to report), give you audit rights, and commit to helping with forensics and regulatory filings.
6. Draft your templates in advance. Prepare Board notice, detailed report, and individual notification templates ahead of time, reviewed by legal, so you only need to fill in the specifics when something happens. Writing these from scratch during a live incident is where deadlines get missed.
7. Rehearse both clocks together. Run tabletop exercises that simulate the 72-hour DPBI deadline and the 6-hour CERT-In deadline at the same time, not as separate drills. Track how long it takes from detection to notification as a metric, and report it to leadership the way you’d report MTTD or MTTR.
8. Keep your DLP and identity posture strong. Stolen credentials are still one of the most common causes of breaches. Least-privilege access, strong authentication, and DLP coverage across endpoints, email, and collaboration tools reduce both the odds and the size of an incident, which also lowers your Section 8(5) risk.
9. Keep consent and processing records up to date. Organizations should also maintain accurate records of user consent and data processing During a regulatory investigation, being able to demonstrate how personal data was collected, used, and managed strengthens overall compliance and governance.

The Board-Level Framing

For most security teams, the technical side of breach response is already well practiced. What the DPDP Rules add is a hard, outside-verified deadline on the communication and documentation side, with its own separate penalty if that part fails, even if containment went well.

In practice, this means incident response readiness should now be reported and reviewed the same way business continuity and disaster recovery are: as a governance capability with a tested response time, not a document that exists but has never been tested under real pressure.

How Know All Edge Helps?

We help organizations build the technical foundation this readiness depends on, including identity and access management, DSPM, DLP, and backup and disaster recovery, set up so the evidence and containment capability are in place before the clock starts, not after. If your incident response plan hasn’t been tested against a 72-hour DPBI deadline and a 6-hour CERT-In deadline running at the same time, that’s the gap worth closing next. Let’s connect for more information.

Frequently Asked Question

What should an organization do immediately after a data breach under DPDPA 2023?

Once a personal data breach is identified, organizations should act without delay. The immediate priorities include:

• Containing the incident to prevent further exposure.
• Preserving logs and forensic evidence.
• Determining whether personal data has been compromised.
• Activating the incident response plan.
• Coordinating with IT, legal, compliance, and leadership teams.

It is equally important to document every significant action and decision. Clear documentation helps demonstrate accountability if the incident is later reviewed by regulators.

What are the consequences of a data breach under DPDPA 2023?

A data breach can have both regulatory and business consequences. Depending on the circumstances, organizations may face:

• Financial penalties for non-compliance.
• Regulatory investigations and additional scrutiny.
• Corrective actions or compliance audits.
• Loss of customer trust and reputational damage.
• Business disruption and contractual implications.

The overall impact often depends not only on the breach itself but also on how effectively the organization responds.

Is our organization still liable if a vendor or cloud provider causes the breach?

Yes. Outsourcing data processing does not transfer accountability under the DPDPA. Your organization remains responsible for notifying the Board and affected individuals, even if a third-party processor caused the breach. This is why vendor contracts should require fast notification to you and cooperation during regulatory reporting.