Does the 72-hour deadline also apply to telling affected customers?

No. Rule 7(1) requires you to inform each affected Data Principal “without delay”, and Rule 7(2)(a) uses the same words for the first alert to the Board. The 72-hour limit in Rule 7(2)(b) applies to the detailed follow-up report to the Board. “Without delay” is not defined, so treat it as a duty to act as soon as you have reliable basic facts, not as permission to wait three days.

Do small breaches, like one misdirected email, need to be reported?

On the plain text, yes. Section 8(6) of the DPDP Act applies “in the event of a personal data breach”, and neither the Act nor Rule 7 sets a size or harm threshold. A single email carrying someone’s personal data to the wrong recipient can meet the section 2(u) definition. Record your assessment of each incident, and take legal advice if you believe a particular case falls outside the definition.

Does the DPDP 72-hour rule replace CERT-In’s six-hour reporting?

No. Section 38 of the DPDP Act says it applies in addition to other laws. CERT-In’s Directions of 28 April 2022 still require listed cyber incidents, including data breaches and data leaks, to be reported within six hours of noticing them. Sector regulators such as SEBI and RBI have their own reporting rules too. One incident can need several reports, so keep a single incident log that feeds all of them.

When does Rule 7 become enforceable?

Rule 1 of the DPDP Rules, 2025 brings Rules 3 and 5 to 16, including Rule 7, into force eighteen months after the Rules were published in November 2025, which means May 2027. A January 2026 media report said MeitY had proposed shortening some timelines, but as of 24 October 2026 we have not found a notification changing the dates. CERT-In’s six-hour rule already applies.

What if we cannot finish the detailed report within 72 hours?

Rule 7(2)(b) allows a longer period if the Board permits it on a written request. Send the request before the 72 hours run out, explaining why you need more time and what you have found so far. As of October 2026 the Board’s online channels had not been announced, so check MeitY’s website for the current process when the Rules take effect.

DPDP breach reporting: the 72-hour rule

Under India’s DPDP framework, you must tell the Data Protection Board of India and every affected person about a personal data breach without delay, and then send the Board a detailed report within 72 hours of becoming aware of it, unless the Board allows more time on a written request. These duties come from section 8(6) of the Digital Personal Data Protection Act, 2023 and Rule 7 of the DPDP Rules, 2025, and they take effect in May 2027. CERT-In’s separate six-hour rule for reporting cyber incidents, which expressly lists data breaches and data leaks, already applies today.

This guide covers each clock and gives a checklist for IT, HR and front-line teams. It is general information, not legal advice.

What counts as a personal data breach under the DPDP Act?

Section 2(u) of the Act defines a personal data breach as:

“any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data, that compromises the confidentiality, integrity or availability of personal data.”

Four practical points follow from that wording:

It is not only about hackers. Accidental disclosure and accidental sharing are included, so a mis-sent email or a message to the wrong WhatsApp group can qualify.
Availability counts. Ransomware that locks you out of customer records is a breach even if nothing is copied.
There is no size or harm threshold. Section 8(6) applies “in the event of a personal data breach”, and neither the Act nor Rule 7 limits it to serious incidents.
Your vendor’s breach is your breach. Under sections 8(1) and 8(5), the Data Fiduciary stays responsible for processing done on its behalf by a Data Processor, such as a payroll provider or cloud host.

The Act covers digital personal data, including paper records that are digitised later (section 3).

What exactly does Rule 7 require?

Rule 7 sets two parallel duties. Both start “on becoming aware” of a breach.

Telling each affected person

The Data Fiduciary must, to the best of its knowledge, inform each affected Data Principal “in a concise, clear and plain manner and without delay”, through their user account or any mode of communication they have registered with you. The message must cover:

a description of the breach, including its nature, extent and when it happened;
the consequences likely to arise for that person;
what you have done, and are doing, to reduce the risk;
safety steps the person can take to protect their interests; and
business contact details of someone who can answer their questions on your behalf.

Telling the Board, in two stages

Stage one, without delay: a description of the breach, including its nature, extent, timing and location of occurrence, and its likely impact.

Stage two, within 72 hours of becoming aware of the breach, or a longer period the Board allows on a written request:

updated and detailed information on that description;
the broad facts about the events, circumstances and reasons that led to the breach;
measures implemented or proposed to reduce the risk;
any findings about the person who caused the breach;
remedial measures taken to prevent it happening again; and
a report on the intimations given to affected Data Principals.

Note that the 72 hours apply only to the detailed report to the Board. The first alert to the Board and the messages to affected people are both “without delay”, a phrase that is not defined and should not be read as “within 72 hours”.

What is the penalty for not reporting a breach?

The Schedule to the Act sets a maximum penalty of ₹200 crore for failing to give the Board or affected Data Principals notice of a personal data breach under section 8(6). Failing to take reasonable security safeguards to prevent a breach carries up to ₹250 crore. These are ceilings, not fixed amounts: under section 33(2) the Board must weigh factors such as the nature, gravity and duration of the breach, the type of data affected, and whether you acted to mitigate it, and how quickly and effectively.

When does the clock start, and is Rule 7 in force yet?

The clock runs from when the Data Fiduciary becomes aware of the breach, a phrase the Rules do not define. A cautious assumption is that awareness can begin when anyone in your organisation knows, not only when the DPO or legal team hears of it.

Rule 1 brings Rule 7, with Rules 3 and 5 to 16, into force eighteen months after publication in November 2025, that is, in May 2027. In a Lok Sabha reply on 12 August 2026, MeitY listed breach notification among the Data Fiduciary obligations in this eighteen-month phase. Business Standard reported in January 2026 that MeitY had proposed shortening some timelines, mainly for Significant Data Fiduciaries, but as of 24 October 2026 we have not found a gazette notification changing the dates.

The Board was established in November 2025, and Rule 20 says it will function as a digital office. The same Lok Sabha reply said the advertisement for its Chairperson and four Members appeared in Employment News on 6 June 2026. As of 24 October 2026 we could not find an official notice of those appointments, or a live online facility for breach intimations. Build your process now and add the Board’s channel once announced.

How does the 72-hour rule fit with CERT-In’s six hours and sector regulators?

Section 38 says the DPDP Act applies in addition to other laws, not in place of them. One incident can therefore trigger several reports, each with its own clock.

CERT-In, six hours. CERT-In’s Directions of 28 April 2022, issued under section 70B(6) of the IT Act, require service providers, intermediaries, data centres, body corporate and government organisations to report listed cyber incidents within 6 hours of noticing them or being told about them. “Data Breach” and “Data Leak” both appear in Annexure I. Reports go to incident@cert-in.org.in; CERT-In’s FAQs say you may report what you know and add details later. Non-compliance can invite action under section 70B(7).
SEBI-regulated entities. SEBI’s Cybersecurity and Cyber Resilience Framework of August 2024 requires incidents covered by the CERT-In Directions to be reported to SEBI and CERT-In within 6 hours, with details on SEBI’s incident reporting portal within 24 hours.
RBI-regulated entities. RBI’s directions carry their own clocks. For example, its November 2025 outsourcing directions for NBFCs require a cyber incident at a service provider to reach RBI within six hours of the provider detecting it. Banks and other entities should check the directions that apply to them.

What should the first 72 hours look like?

The table combines the legal deadlines with suggested internal targets. Rows marked “legal requirement” come from the texts; the rest are our suggestions for a workable rhythm.

When	What happens	Basis
Hour 0	Someone notices the incident (a “wrong person” reply, a missing laptop, an alert) and reports it internally at once.	Rule 7 runs from becoming aware; CERT-In from noticing
First hour	Contain the incident, preserve logs and evidence, record the time of awareness, appoint an incident lead and open the incident log.	Suggested internal target
By hour 6	Report to CERT-In if the incident is listed in Annexure I. Report to SEBI or RBI if they regulate you.	Legal requirement: CERT-In Directions 2022 and sector rules
Once basic facts are known (we suggest within 24 hours)	First intimation to the Board: nature, extent, timing, location and likely impact.	Legal requirement: Rule 7(2)(a), “without delay”
Once affected people are identified	Plain-language message to each affected Data Principal covering the five required points.	Legal requirement: Rule 7(1), “without delay”
Hours 24 to 60	Investigate the cause, confirm scope, record who caused the breach and log every intimation sent.	Suggested internal target; feeds Rule 7(2)(b)
By hour 72	Detailed report to the Board, or a written request for more time sent before the deadline.	Legal requirement: Rule 7(2)(b)
After 72 hours	Complete remediation, update affected people if the facts change, and review controls and training.	Good practice; section 8(5) and Rule 6 safeguards

What do everyday breaches look like?

These scenarios are illustrative, not real cases. They show how ordinary mistakes meet the section 2(u) definition.

The misdirected email

An HR executive means to send the monthly salary sheet to the finance head, but autocomplete picks a vendor contact with a similar name. Employees’ names, bank details and salaries have gone to an outsider: an accidental disclosure. First hour: tell the incident lead, try to recall the message, ask the recipient in writing to delete it, and record exactly what was sent.

The lost laptop

A sales manager leaves a laptop holding customer names, phone numbers and addresses in a cab. First hour: report it, trigger a remote lock or wipe, and reset the user’s passwords and sessions. Encryption reduces the risk, but the Act has no express exemption for encrypted devices, so record the facts and your reasoning.

The WhatsApp forward

A clinic receptionist forwards the day’s patient appointment list to a family group instead of the staff group. First hour: delete the message for everyone if the app still allows it, ask members not to forward it, and escalate. Health information raises the likely harm, which shapes what you tell patients.

The public cloud bucket

A developer makes a storage bucket public to share a test file, forgetting it also holds a backup with customer KYC records. First hour: make it private, rotate exposed keys and check access logs for downloads. This is likely CERT-In reportable too, so the six-hour clock is running.

Why does the first hour depend on front-line staff?

Most incidents like these are spotted first by an ordinary employee, not the security team. If that person waits a day out of embarrassment or fear of blame, the organisation has already missed CERT-In’s six hours and lost a third of its 72.

First-hour awareness comes down to a few habits:

Recognise a breach. Wrong recipient, lost device, unexpected access, data in the wrong place, ransomware.
Know the one place to report. A single helpdesk number, email address or ticket category, staffed outside office hours too.
Report first, explain later. Make it clear that prompt reporting is welcome and that hiding a mistake is the real problem.
Keep the evidence. Do not wipe the machine, delete logs or tidy up before the incident lead says so.
Do not go public. No posts, no forwards and no direct contact with affected customers until the response team has agreed the message.

Helpdesk teams need particular attention: they often take the first call and decide whether it is “just a password reset” or the start of an incident.

What should your breach response checklist include?

Adapt this to your own systems, vendors and regulators.

Report internally at once through the agreed channel, noting the date and time.
Appoint an incident lead with authority to decide, plus a deputy for nights and holidays.
Contain the incident: recall messages, revoke links, lock or wipe devices, close public access and rotate credentials.
Preserve evidence: keep logs, screenshots and affected systems. Rule 6 requires logs to be retained for one year, and the CERT-In Directions require ICT logs for 180 days.
Keep one incident log of every fact, decision and message, with timestamps. Every filing should draw on it.
Triage the data: what personal data is involved, whose, how many people, how sensitive, and whether it is digital.
Check CERT-In and sector duties and file within six hours where they apply.
Send the first intimation to the Board without delay, covering nature, extent, timing, location and likely impact.
Inform each affected Data Principal in plain language, with the five points Rule 7(1) requires, through their account or registered contact details.
Bring in your Data Processors: ask for their facts and logs under the contract, and confirm they have contained their side.
File the detailed report within 72 hours, or send a written request for more time before the deadline passes.
Fix the root cause and review: close the gap, update procedures and hold a short lessons-learned session with the teams involved.

Three things are worth preparing in advance: template messages for affected people in the languages your customers use, a Board report template that follows the Rule 7(2) headings, and contract clauses that oblige vendors to tell you about incidents within hours, not days.

How can you prepare before May 2027?

A written procedure helps, but teams learn the timings by practising them. A tabletop drill based on one of the scenarios above, with IT, HR and the helpdesk in the room, quickly shows who knows the reporting channel, how long triage takes and whether your templates work.

AuditDPDP runs DPDP awareness sessions and breach-response drills for Indian organisations, including role-based sessions for helpdesk and call centre teams and cloud and development teams. If that would help, you can get in touch. We are an independent training provider, not affiliated with MeitY or the Data Protection Board. This article is not legal advice; consult a qualified lawyer about your obligations.

This article explains the DPDP Act, 2023 and the DPDP Rules, 2025 in plain language for training purposes. It is not legal advice. AuditDPDP is an independent training provider and is not affiliated with MeitY or the Data Protection Board of India.

DPDP data breach reporting: the 72-hour rule explained, with a response checklist