DPDP Data Breach Reporting: The 72-Hour Rule and CERT-In’s Six-Hour Deadline

Imagine a hospital discovering that an unauthorized user has accessed patient records. At the same time, a financial institution identifies suspicious activity involving customer information, transaction records, and internal systems.

Both organizations must investigate the incident, contain the threat, identify potentially affected data, and coordinate their response. But there is another challenge: regulatory reporting under overlapping deadlines.

India’s Digital Personal Data Protection (DPDP) framework establishes personal data breach notification obligations under the DPDP Rules, 2025. Separately, the Indian Computer Emergency Response Team (CERT-In) requires specified cyber incidents, including data breaches and data leaks, to be reported within six hours of being noticed or brought to an organization’s notice.

Under Rule 7 of the DPDP Rules, 2025, affected individuals must be informed without delay. The Data Protection Board of India must also receive an initial breach description without delay, followed by specified detailed information within 72 hours of the Data Fiduciary becoming aware of the breach, subject to the rule’s extension provision.

These requirements raise an important question for security and compliance leaders: Can your incident response team investigate a breach, protect sensitive information, and coordinate the required notifications without losing valuable time?

For banking, financial services and insurance (BFSI) organizations and healthcare providers, the answer depends on more than having security tools. It requires a coordinated approach to threat detection, data discovery, privileged access, recovery, and regulatory reporting.

Let’s explore how organizations can strengthen their data breach readiness.

Understanding DPDP Data Breach Reporting and the Compliance Timeline

What Is the DPDP Act, and Why Does Breach Readiness Matter?

India’s Digital Personal Data Protection Act, 2023, establishes a framework for processing digital personal data. The DPDP Rules, 2025, specify operational requirements for organizations covered by the framework.

The objective extends beyond preventing cyberattacks. Organizations must also implement appropriate safeguards, understand their personal data exposure, and respond responsibly when a breach occurs.

Data protection can no longer be treated exclusively as an IT responsibility. Security, legal, compliance, risk management, operations, and executive leadership must work together to address the potential effects of a breach on customer trust, business continuity, and regulatory exposure.

Without an established response process, even an organization with strong security controls may struggle to determine what happened, identify affected individuals, and prepare accurate notifications on time.

What Does the 72-Hour DPDP Breach Reporting Requirement Mean?

Rule 7 of the DPDP Rules, 2025, addresses the intimation of personal data breaches. It establishes two distinct notification responsibilities for a Data Fiduciary that becomes aware of a personal data breach.

1. Notify affected individuals without delay

Under Rule 7(1), affected Data Principals must be informed in a concise, clear, and plain manner. The communication should explain the nature and extent of the breach, likely consequences, mitigation measures, recommended safety precautions, and contact information for addressing questions.

2. Inform the Data Protection Board of India

Under Rule 7(2), the Data Fiduciary must provide an initial description of the breach without delay. The specified detailed information must then be submitted within 72 hours of becoming aware of the breach, unless the Board allows a longer period following a written request.

The distinction is important. The 72-hour period is not a blanket extension for every notification. Both the initial description to the Board and communication to affected individuals are required without delay.

Organizations should also distinguish between publication of the Rules and their commencement. Rule 4, concerning Consent Managers, is scheduled to take effect on 13 November 2026. Rule 7’s breach-intimation obligations are scheduled to take effect on 13 May 2027, based on the Rules’ phased commencement provisions.

Organizations should verify the latest official commencement notifications before finalizing their compliance calendars.

How Does CERT-In’s Six-Hour Reporting Requirement Fit In?

CERT-In’s directions establish a separate reporting obligation for covered cyber incidents.

Under the directions issued on 28 April 2022, specified entities must report covered incidents within six hours of noticing them or being brought to their notice. The listed incident categories include data breaches and data leaks.

This creates a distinct operational requirement: a single incident may trigger separate reporting workflows, with different recipients, information requirements, and deadlines.

Reporting requirement Operational priority CERT-In: six hours Report covered cyber incidents within the applicable deadline DPDP Rule 7: without delay Provide an initial breach description to the Board and notify affected individuals DPDP Rule 7: 72 hours Submit the specified detailed information to the Board, subject to the extension provision

These obligations should be assessed independently. Meeting one does not automatically satisfy the other.

BFSI organizations should also evaluate applicable requirements from their financial regulator. Healthcare providers should assess relevant sector-specific requirements and contractual commitments.

The practical takeaway is straightforward: organizations need a coordinated incident-management process that can manage multiple reporting obligations simultaneously.

Why BFSI and Healthcare Need a Structured Data Breach Response Plan

Three Challenges That Can Delay Breach Reporting

When an incident occurs, the security team may be dealing with suspicious logins, compromised endpoints, encrypted files, unusual database activity, or unauthorized access to cloud applications.

Meanwhile, legal and compliance teams need reliable information about the incident’s scope and potential impact. Three challenges commonly slow this process.

1. Identifying which personal data was exposed

Personal data may be distributed across databases, cloud platforms, SaaS applications, employee devices, backups, and third-party systems. Banks may need to trace customer records and financial information, while hospitals must identify potentially affected patient and insurance data.

Teams need to establish what is known, what remains uncertain, and which systems require further investigation.

2. Connecting security alerts to business impact

A security alert alone does not establish that personal data was compromised. Teams must correlate endpoint, identity, network, cloud, and data-access records to determine whether unauthorized access occurred.

Disconnected evidence can delay the investigation, increase uncertainty, and complicate decisions about containment and reporting.

3. Coordinating security, legal, and leadership teams

Responses can become fragmented when responsibilities are unclear. Security teams investigate, legal and compliance teams assess obligations, and leadership coordinates business continuity and communications.

Predefined ownership, escalation paths, decision-making authority, evidence requirements, and notification templates help teams respond more consistently.

A Practical Incident Response Workflow for Overlapping Reporting Deadlines

A coordinated incident response process helps organizations investigate a breach while preparing the required notifications.

Step 1: Detect and escalate the incident. Identify suspicious activity through endpoint, network, identity, and cloud monitoring. Escalate suspected incidents according to predefined severity criteria.

Step 2: Contain the threat. Isolate affected systems, restrict compromised accounts, and block malicious activity where appropriate. Preserve relevant evidence while taking necessary containment measures.

Step 3: Determine potential data exposure. Identify affected systems, data categories, potential recipients of the information, and whether personal data may have been accessed, altered, disclosed, or lost.

Step 4: Activate the reporting process. Record when the incident was noticed or brought to the organization’s attention. Assess applicable CERT-In reporting requirements and determine whether DPDP breach-notification obligations apply.

Step 5: Coordinate notifications. Assign responsibility for CERT-In reporting, communication with the Data Protection Board, affected-individual notifications, and additional sector-specific reporting.

Step 6: Document findings and recover. Maintain an incident timeline, preserve relevant logs, validate recovery, and track corrective actions. Update reports as additional evidence becomes available.

A critical principle is to avoid delaying required reporting while waiting for a complete forensic investigation. CERT-In’s published guidance allows organizations to provide information available at the time of reporting and submit additional information later within a reasonable time.

A Healthcare Data Breach Scenario: Managing Both Reporting Clocks

Consider a hypothetical hospital where an attacker compromises an employee account and accesses a system containing patient information.

The security team detects suspicious activity and begins containment. Investigators assess whether patient records were accessed, which systems were affected, and whether the incident involves personal data.

At the same time, the hospital activates its reporting workflow. The team evaluates whether the incident falls within CERT-In’s reportable categories and coordinates reporting within the applicable six-hour deadline.

The privacy and legal teams work with technical investigators to establish the scope of the incident. Where DPDP Rule 7 applies, the organization prepares the initial breach description for the Board without delay and communicates with affected individuals without delay. It also prepares the detailed information required within the applicable 72-hour period, subject to the rule’s extension provision.

The hospital documents its findings, tracks remediation, and validates recovery measures.

This scenario demonstrates why data breach readiness must combine technology, evidence collection, decision-making, and communication.

Building DPDP Data Breach Readiness With the Right Security Controls

Technology can support incident response, but no product guarantees DPDP compliance. Effective readiness also requires integrated systems, documented procedures, clear ownership, and appropriate governance.

Palo Alto Networks: Strengthening Threat Detection and Network Visibility

Palo Alto Networks security capabilities can help organizations improve network visibility, detect suspicious activity, and investigate threats across critical environments.

Better visibility can help teams identify affected systems, correlate activity, and build a more complete incident timeline.

CrowdStrike: Detecting and Investigating Endpoint Threats

CrowdStrike Falcon provides endpoint detection and response capabilities that can support the investigation and containment of threats such as ransomware and credential theft.

Endpoint telemetry can help investigators trace attacker activity, assess affected systems, and make informed containment decisions.

CyberArk: Protecting Privileged Access

CyberArk helps organizations manage and secure privileged access to critical systems and data.

Restricting excessive permissions, protecting credentials, and monitoring privileged sessions can reduce unauthorized access risks and improve accountability during investigations.

Veeam and Cohesity: Supporting Data Resilience and Recovery

Veeam and Cohesity provide data protection and resilience capabilities that can support backup management and recovery planning.

Tested, access-controlled backups can help organizations restore critical services after ransomware or data loss. Recovery capabilities do not, however, replace breach investigation or regulatory notification.

Thales: Discovering and Protecting Sensitive Data

Thales data security capabilities can support sensitive-data discovery, classification, and protection across supported environments.

Improved visibility into customer, financial, and patient information can help incident responders prioritize investigations and assess potential exposure.

Bringing Security Solutions Together

These capabilities are most useful when they support a coordinated incident response process.

Readiness requirement Relevant solution area Network visibility and threat investigation Palo Alto Networks Endpoint detection and response CrowdStrike Privileged identity protection CyberArk Backup and recovery Veeam or Cohesity Sensitive data discovery and protection Thales

The right combination depends on the organization’s infrastructure, risk profile, existing investments, and regulatory obligations. Integration across security, identity, data protection, backup, and reporting teams is essential.

A 30-Day Starting Plan for DPDP Breach Readiness

Organizations can begin preparing well before the relevant DPDP breach-intimation obligations take effect.

Week 1: Assess personal data exposure

Identify critical systems, personal data repositories, existing incident procedures, and applicable reporting obligations. Document major gaps in visibility and evidence collection.

Week 2: Map the response process

Define incident ownership, escalation paths, reporting contacts, evidence requirements, and notification templates. Confirm who can make time-sensitive reporting decisions.

Week 3: Validate technology and recovery

Review threat detection coverage, privileged access, data visibility, logging, and backup restoration. Identify weaknesses that could delay an investigation or recovery.

Week 4: Run a tabletop exercise

Simulate a personal data breach and test the CERT-In reporting workflow alongside the planned DPDP notification process. Include the initial breach description, affected-individual communication, and detailed-reporting requirements.

Measure the time required to detect the incident, identify potentially affected data, escalate decisions, and prepare the required information. Record gaps, assign corrective actions, and schedule follow-up testing.

This exercise helps leaders move from a written compliance policy to an operationally tested incident response capability.

Conclusion: Prepare for Data Breach Reporting Before an Incident Occurs

DPDP data breach readiness is not simply about meeting a deadline. It is about knowing where personal data resides, detecting suspicious activity, understanding the impact, containing threats, and coordinating accurate communications.

For BFSI and healthcare organizations, the challenge becomes more demanding when a cyber incident triggers multiple reporting obligations. CERT-In’s six-hour reporting requirement and the DPDP Rules’ breach-notification process must be addressed through a coordinated approach, with each obligation assessed independently.

Palo Alto Networks, CrowdStrike, CyberArk, Veeam or Cohesity, and Thales can support different parts of this process. Their value depends on how effectively their capabilities are implemented, integrated, and aligned with organizational procedures.

The most important question for business and security leaders is not whether they have purchased the right tools. It is whether their teams can use available evidence to make timely decisions when a real incident occurs.

Frequently Asked Questions

1. What is the 72-hour DPDP data breach reporting requirement?

Rule 7(2) of the DPDP Rules, 2025, requires a Data Fiduciary to submit specified detailed breach information to the Data Protection Board within 72 hours of becoming aware of a personal data breach, unless the Board allows a longer period following a written request. The initial breach description must be provided without delay.

2. Does CERT-In require data breaches to be reported within six hours?

CERT-In’s directions require covered cyber incidents, including data breaches and data leaks, to be reported within six hours of being noticed or brought to the organization’s notice. Organizations should consult the official directions and FAQs to determine their specific reporting obligations.

3. Are DPDP and CERT-In reporting requirements the same?

No. They are separate obligations with different reporting processes and timelines. Organizations should assess each applicable requirement independently and coordinate the response.

4. When do the DPDP breach-notification obligations take effect?

Rule 7’s breach-intimation obligations are scheduled to take effect on 13 May 2027 under the DPDP Rules’ phased commencement provisions. Rule 4, scheduled to take effect on 13 November 2026, concerns Consent Managers rather than breach notification. Organizations should verify the latest official notifications before relying on these dates.

5. How can BFSI and healthcare organizations improve data breach readiness?

They can map personal data, strengthen threat detection, restrict privileged access, maintain reliable logs, test backup recovery, establish reporting procedures, and conduct simulated breach exercises.

6. Can cybersecurity tools guarantee DPDP compliance?

No. Security tools can support detection, investigation, access protection, and recovery. Compliance also requires appropriate governance, documented processes, and fulfilment of applicable legal obligations.

7. What should an organization do first after discovering a suspected breach?

Activate its incident response process, preserve relevant evidence, contain the threat where appropriate, assess potential personal data exposure, and promptly involve security, legal, and compliance stakeholders to determine applicable reporting requirements.