Thought Leadership · 7 min read · Jun 2026

When DPDP Meets A Data Breach: Why Your 72‑Hour Response Window Is Now Business‑Critical

B2 I2.png # When DPDP Meets A Data Breach: Why Your 72‑Hour Response Window Is Now Business‑Critical

No matter how well you design your product, breaches happen. Credentials leak, misconfigured buckets expose records, an employee clicks on the wrong link. Under India's DPDP regime, what happens in the next few hours after you discover a breach can decide whether you're seen as a responsible steward of data-or face regulatory heat and multi‑crore penalties.

The DPDP Act 2023 and the DPDP Rules 2025 turn breach response from a purely technical firefight into a legal and trust‑critical process: you must communicate clearly with users, report to the Data Protection Board, and align with CERT‑In's six‑hour cyber‑incident requirement.

What Counts As A "Personal Data Breach" Under DPDP?

DPDP treats a personal data breach as any unauthorized or accidental compromise of the confidentiality, integrity, or availability of personal data. That's broader than just "data leak" headlines. It includes:

Unauthorized access to user records (for example, due to a privilege misconfiguration).
Accidental exposure or disclosure (like a public S3 bucket with customer PDFs).
Loss or destruction of personal data where security safeguards have failed.

If the breach touches personal data, DPDP expects you to treat it as reportable-there is effectively no de‑minimis threshold for hiding "small" incidents.

Rule 7: The Dual Duty To Tell Both Users And The Board

Rule 7 of the DPDP Rules 2025 lays out a structured, two‑track notification obligation: you must notify affected Data Principals and the Data Protection Board of India when you become aware of a personal data breach.

1. Talking To Your Users, Not Just Your Lawyers

Once you become aware of a breach, Rule 7 expects you to reach out to each affected Data Principal without delay, using their user account or registered communication channel. That notification must be:

Concise, clear, and in plain language-no dense legalese.
Specific about what happened: nature, extent, timing and location of the breach.
Honest about consequences: what risks they may face (fraud, identity theft, account takeover, reputational harm).
Transparent about mitigation: what you have already done and what you're doing next to contain and remediate the breach.
Practical about self‑protection: what users should do (change passwords, enable MFA, watch bank statements, contact support).
Linked to a real human contact on your side who can answer questions.

Think of this as a "fire alarm plus evacuation guide" that tells people there is a problem, what you're doing, and how they can protect themselves.

2. Reporting To The Data Protection Board With Substance, Not Spin

In parallel, you must also inform the Data Protection Board in two stages:

Initial intimation "without delay": a quick but structured description of the breach-nature, extent, timing, location, likely impact.
Detailed report within 72 hours of becoming aware, or within a longer period if the Board specifically permits:
- Updated information on the breach description.
- Broad facts about events and circumstances leading to the breach.
- Measures implemented or proposed to mitigate risk.
- Findings about who caused or contributed to the breach.
- Steps taken to prevent recurrence.
- A summary of notifications sent to affected Data Principals.

The clock starts when you become aware of the breach, not when the breach actually happened, which means detection capability and internal escalation processes are part of compliance, not just engineering hygiene.

The CERT‑In 6‑Hour Rule: Why DPDP Isn't Your Only Timer

India already has a cyber‑incident reporting obligation under the CERT‑In Directions 2022, which require service providers to report certain cybersecurity incidents within six hours of such incidents being noticed. DPDP doesn't replace that-it adds another layer:

CERT‑In focuses on technical incidents affecting computer resources (ransomware, DDoS, unauthorized access, data exfiltration).
DPDP focuses on personal data breaches and the rights and interests of individuals whose data is compromised.

When a ransomware attack or intrusion compromises personal data, you now have dual obligations:

6‑hour CERT‑In technical incident report.
72‑hour DPDP report to the Data Protection Board and notifications to affected individuals.

Legal analyses are clear on one point: these obligations are cumulative, not alternatives-failing to notify either side can be treated as a separate violation.

Penalties: Why "We'll See Later" Is Not A Strategy

Under the DPDP framework, penalties for breach‑related failures are serious:

Notification failures and poor breach communication can attract fines up to ₹200 crore.
Inadequate security safeguards more broadly can pull penalties up to ₹250 crore.

This is why breach response is now a board‑level conversation: regulators are signaling that late or opaque communication is as much a problem as the breach itself.

Building A 72‑Hour Incident Response Playbook

Here's how a DPDP‑aligned incident response playbook typically looks when you piece together Rule 7 requirements and practitioner guidance:

Detect and triage quickly
- Use logging, monitoring and alerting to spot unusual access patterns, configuration changes, or data exfiltration.
- Have a clear threshold for when an incident "becomes" a suspected personal data breach that triggers DPDP workflows.
Lock down and contain
- Isolate affected systems, revoke compromised credentials, turn off risky features temporarily.
- Start evidence preservation so forensics can proceed without destroying trails.
Assess personal data impact
- Identify which categories of personal data were involved (names, contact details, financial identifiers, health data, etc.) and how many Data Principals are affected.
- Map these against your data inventory to avoid guesswork.
Trigger dual notification tracks
- Prepare the initial CERT‑In report within the 6‑hour window with technical details.
- Prepare the DPDP intimation to the Board plus a 72‑hour detailed report outline, with clear ownership inside your team.
Craft user‑friendly breach notices
- Write templates in plain language that can be adapted to different breach scenarios, rooted in Rule 7's content requirements.
- Decide channels (email, SMS, in‑app banners) based on how users normally interact with your product.
Coordinate legal, security, product and customer teams
- Run a cross‑functional incident room: security handles containment and forensics, legal manages regulatory interaction, product/CS own user communications.
- Document decisions so you can show the Board and auditors that you acted reasonably and promptly.
Run post‑mortems and fix root causes
- Treat every breach as a learning opportunity: patch controls, update runbooks, revisit DPIAs and risk registers.

At Vishwaas.ai, a DPDP‑aligned toolchain would typically translate these steps into configurable workflows, breach communication templates, and evidence trails that help compliance and security teams move in sync instead of scrambling in silos.

Embedding Breach‑Readiness Into Your Product And Culture

From a product management lens, breach readiness is less about fear and more about design maturity:

During discovery and design, treat failure modes of features (export, sharing, integrations) as seriously as their happy paths. Map which DPDP obligations each failure could trigger.
During build and deploy, bake in least‑privilege access, strong audit logging, and frictionless ways to revoke tokens or disable features when something looks wrong.
During operations, run breach drills, keep notification templates ready, and maintain an internal "DPDP‑CERT‑In checklist" every time an incident is suspected.

This isn't about turning your company into a fear‑driven place-it's about making sure that when something goes wrong, your users experience clarity, care, and competence instead of silence and confusion.

Final Takeaway: Breach Response As A Trust Moment

DPDP's breach notification rules are designed to ensure that people are not left in the dark when their data is at risk and that regulators get a clear view of systemic vulnerabilities. For Indian SaaS and digital businesses, the 72‑hour window is less a compliance stopwatch and more a trust window:

How transparent you are.
How quickly you act.
How empathetically you speak to affected users.

Getting this right, with a well‑rehearsed playbook and DPDP‑aware tooling, can turn a difficult incident into a moment where your product and brand show what "Vishwaas" (trust) really means in practice.