Imagine discovering that your customer's personal information has been exposed.

Your security team is investigating. Your IT team is trying to contain the incident. Your legal team wants to understand the reporting obligations.

And someone asks the question that changes everything:

"We have 72 hours to report this, right?"

Not exactly.

Under India's Digital Personal Data Protection (DPDP) framework, the 72-hour rule is often misunderstood.

Once the relevant provisions become applicable, businesses must notify affected individuals and the Data Protection Board of India without delay. The 72-hour window applies to submitting detailed information to the Board following the initial notification.

That distinction matters. Because when a data breach happens, misunderstanding the reporting timeline can create additional compliance risks.

With the breach-notification provisions scheduled to take effect on 13 May 2027, businesses have an opportunity to prepare their incident response processes before these obligations become enforceable.

Let's understand what the rules require, where businesses may face challenges, and how to prepare.

1. What Counts as a Personal Data Breach Under the DPDP Act?

When businesses hear the term "data breach," they often imagine hackers stealing customer databases.

But a personal data breach is not limited to cyberattacks.

The DPDP Act covers incidents involving unauthorised processing or accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data that compromises its confidentiality, integrity, or availability.

Consider a few everyday situations.

Scenario 1: The wrong email recipient

An employee accidentally emails a spreadsheet containing customer information to someone outside the organisation.

There was no hacking involved. Yet personal data has potentially been disclosed to an unauthorised individual.

Scenario 2: A compromised database

An attacker gains unauthorised access to a database containing employee or customer information.

Even if the investigation has not established whether information was downloaded, the organisation needs to assess whether personal data was compromised.

Scenario 3: Ransomware disrupts access

Ransomware encrypts employee records, making them temporarily unavailable.

The incident may qualify as a personal data breach because the availability of personal data has been compromised.

The important question is not simply whether someone stole information.

It is whether personal data was accessed, disclosed, altered, destroyed, or made unavailable in circumstances covered by the Act.

For businesses, this means breach detection must go beyond monitoring external cyberattacks. Internal mistakes, access control failures, system disruptions, and vendor incidents also require attention.

2. Understanding the DPDP 72-Hour Breach Notification Rule

Here's where businesses need to be particularly careful.

The DPDP breach notification process involves different reporting requirements and timelines.

The Board may permit a longer period for the detailed submission following a written request. However, businesses should not assume an extension has been approved simply because they requested one.

What does "without delay" mean?

It means businesses should not treat the 72-hour deadline as permission to postpone their initial notification.

Imagine an organisation discovers a breach on Monday morning.

Its investigation team is still determining how many records were affected, whether the attacker extracted information, and which systems were compromised.

Waiting until Thursday to make the first notification simply because the investigation is incomplete would misunderstand the reporting framework.

Instead, the organisation should communicate the information available at the initial reporting stage and continue investigating.

The distinction is straightforward:

• Initial notification: Without delay.

• Detailed Board submission: Within 72 hours of breach awareness.

The 72-hour period is a reporting deadline, not a waiting period.

3. What Should Businesses Tell Affected Individuals?

A data breach notification should do more than inform someone that an incident occurred.

It should help them understand what happened, how they may be affected, and what action they can take.

Under the DPDP Rules, notifications to affected Data Principals should communicate relevant information in a concise, clear, and understandable manner.

This includes:

• A description of the breach, including its nature, extent, and timing.

• The consequences that may affect the individual.

• Measures taken or being taken to reduce the risk.

• Steps the individual can take to protect themselves.

• Contact information for further assistance.

Consider a practical example

A business discovers that login credentials associated with some customer accounts may have been exposed.

A vague message saying "We experienced a security incident" offers little practical value.

A more useful notification would explain the potential exposure and advise affected customers to reset their passwords, avoid reusing compromised credentials, and monitor their accounts for suspicious activity.

The objective is to answer three questions from the customer's perspective:

What happened to my data? What could happen next? What should I do now?

Clear communication is not only a compliance requirement. It is also an important part of maintaining customer trust during a security incident.

4. What Must Be Reported to the Data Protection Board?

The DPDP Rules establish a two-stage reporting process.

Stage 1: Initial notification without delay

The initial notification should provide information about the breach, including its nature, extent, timing, location, and likely impact.

At this stage, the organisation may still be investigating.

The key is to communicate the information available without unnecessarily delaying the initial report.

Stage 2: Detailed submission within 72 hours

The subsequent submission provides a more comprehensive account of the incident.

This includes:

• Updated information about the nature and extent of the breach.

• Events and circumstances surrounding the incident.

• Reasons or causes identified during the investigation.

• Risk mitigation measures implemented or proposed.

• Available findings about the person responsible.

• Measures taken to prevent similar incidents.

• Information about notifications sent to affected individuals.

One important point deserves attention.

Businesses are not expected to complete every aspect of a forensic investigation within 72 hours.

However, they must provide the required information available at the time of reporting, subject to any extension permitted by the Board.

This makes incident documentation especially important.

If an organisation cannot establish when it became aware of the breach, which systems were affected, or what corrective actions were taken, preparing an accurate report becomes significantly more difficult.

5. What Should a DPDP Breach Response Process Look Like?

When a breach occurs, different teams may need to work simultaneously.

Security teams investigate the technical incident. Legal and compliance teams assess reporting obligations. Business teams coordinate communications. Vendors may need to provide supporting evidence.

Without a defined process, these activities can become disconnected.

A practical breach response workflow could follow these stages.

Step 1: Detect and record the incident

Identify the potential breach and record when the organisation became aware of it.

Step 2: Assess and contain the impact

Determine which systems and personal data may be affected. Take appropriate steps to prevent further exposure or disruption.

Step 3: Initiate notifications

Assess the applicable reporting obligations and notify affected Data Principals and the Board without delay.

Step 4: Investigate and collect evidence

Gather relevant logs, incident details, technical findings, and mitigation records.

Step 5: Submit detailed information

Provide the required detailed information to the Board within the applicable 72-hour period, unless a longer period has been permitted.

Step 6: Remediate and prevent recurrence

Complete recovery activities, document corrective actions, and strengthen controls where weaknesses have been identified.

These stages are a practical operating model, not a rigid sequence prescribed by law.

In reality, containment, investigation, communication, and reporting may need to happen at the same time.

6. What Happens When the Data Breach Comes From a Vendor?

Your organisation may have strong internal security controls.

But what happens when a cloud provider, SaaS application, or outsourced service provider experiences a breach involving your customers' personal data?

Under the DPDP framework, engaging a Data Processor does not remove the Data Fiduciary's applicable responsibilities.

That creates an important operational challenge.

Your reporting obligations may depend on how quickly your vendor communicates the incident.

Imagine a SaaS provider detects unauthorised access to a system containing your customer information.

The provider begins investigating internally but informs your organisation two days later.

By that point, your team may have limited time to assess the impact, collect evidence, and coordinate the required notifications.

This is why vendor incident response arrangements matter.

Businesses should establish clear contractual and operational expectations for vendors to communicate:

• When an incident occurred and when it was detected.

• Which systems and personal data were affected.

• How many individuals may be impacted.

• What containment measures have been taken.

• What logs and investigation findings are available.

Vendor risk management should therefore extend beyond onboarding assessments and annual security reviews.

It should include the vendor's ability to support your organisation during an actual incident.

7. DPDP's 72-Hour Rule vs CERT-In's 6-Hour Rule

Another common source of confusion is the difference between DPDP breach notification and CERT-In incident reporting.

These are separate regulatory requirements.

Under CERT-In's directions, specified reportable cybersecurity incidents must generally be reported within six hours of noticing the incident or being informed of it.

The DPDP framework introduces its own notification requirements for personal data breaches.

Consider a ransomware incident affecting a system containing personal data.

Depending on the circumstances, it may trigger obligations under both frameworks.

Submitting a report to CERT-In does not automatically satisfy DPDP notification requirements, and vice versa.

Businesses may also need to consider contractual commitments and sector-specific reporting requirements.

The practical solution is to build one coordinated incident response process that accounts for all applicable reporting obligations.

Separate regulatory deadlines should not mean disconnected internal response teams.

8. How Can Businesses Prepare Before May 2027?

The DPDP breach-notification provisions are scheduled to become applicable from 13 May 2027.

For organisations that have not yet formalised their privacy incident response processes, this preparation period matters.

The challenge is not simply creating a notification template.

It is making sure the organisation can detect an incident, determine its impact, collect reliable information, coordinate stakeholders, and meet reporting requirements under pressure.

A useful exercise is to simulate a breach and ask the incident response team to prepare the initial notification using only the information available during the first few hours.

This can reveal missing responsibilities, communication delays, and evidence gaps before a real incident occurs.

9. What Are the Penalties for Non-Compliance?

The DPDP Act provides for significant monetary penalties for certain contraventions.

Two provisions are particularly relevant to data breach readiness.

These figures represent statutory maximums, not automatic penalties imposed for every breach.

Nevertheless, they highlight why organisations should treat breach readiness as a governance priority.

It is not enough to have security policies documented.

Businesses need operational processes, responsible teams, appropriate safeguards, and records that demonstrate how incidents were handled.

10. How WhizzC Helps Businesses Strengthen DPDP Breach Readiness

Preparing for DPDP compliance requires more than understanding the law.

Businesses also need visibility into their security controls, privacy responsibilities, vendor risks, and compliance activities.

This is where WhizzC can help organisations build a more structured approach to compliance readiness.

With WhizzC, businesses can strengthen the governance activities that support incident preparedness through:

Centralised compliance management

Organise compliance requirements, supporting documentation, policies, and evidence in one place, reducing dependence on scattered spreadsheets and manual follow-ups.

Risk assessment and tracking

Identify security and privacy risks, assign responsibilities, and monitor mitigation activities before weaknesses develop into larger issues.

Policy and control management

Maintain relevant security and privacy policies, track control implementation, and support periodic reviews.

Third-party risk management

Assess vendor-related risks, maintain oversight of third-party security practices, and track gaps requiring remediation.

Audit readiness and evidence management

Maintain organised compliance evidence and improve visibility into control gaps, ownership, and corrective actions.

These capabilities can support a more coordinated compliance programme. They do not replace the organisation's incident response procedures, legal assessment, or required regulatory notifications.

The goal is to help teams stay prepared before an incident puts their processes to the test.

Don't wait for a data breach to discover gaps in your compliance readiness.

Explore WhizzC and see how your organisation can build a more structured approach to security, privacy, and DPDP compliance.

Final Thoughts: The First 72 Hours Shouldn't Be Spent Figuring Out What to Do

A data breach is already a difficult situation for any business.

Unclear responsibilities, delayed vendor communications, missing evidence, and uncertainty about reporting deadlines can make it even harder.

The DPDP framework makes one thing clear: organisations need to be ready to respond before an incident occurs.

The real preparation happens long before the first breach notification is written.

It happens when teams define responsibilities, test their processes, strengthen security controls, and establish reliable reporting procedures.

Because when a breach happens, the question should not be, "Who is responsible for reporting this?"

It should be, "Is our response process already in motion?"