Data breach under DPDP: the 72-hour Board report and CERT-In's six hours

From 13 May 2027, a Data Fiduciary that becomes aware of a personal data breach must tell each affected person without delay, tell the Data Protection Board without delay, and send the Board a detailed report within 72 hours of becoming aware, unless the Board allows longer on a written request (Rule 7). The duty falls on every Data Fiduciary, subject to the exemptions in section 17. Any unauthorised processing or accidental loss that compromises confidentiality, integrity or availability is a breach (s. 2(u)); there is no minimum size and no harm threshold. CERT-In's Directions of 28 April 2022 apply today: service providers, intermediaries, data centres, body corporates and government organisations must report listed cyber incidents, including data breaches and data leaks, within six hours of noticing them (CERT-In Directions). One incident can start both clocks, so run them from one playbook and one fact sheet.

Like the Act (s. 2(y)), we use "she" and "her" for every person.

Jump to what you need.

• CISOs and IT heads: CERT-In vs DPDP, The hour-by-hour playbook, The drill.
• DPOs and lawyers: What Rule 7 asks, Illustrative notices and reports, Where the law is unclear.
• SaaS and other processors: Processors and multi-tenant platforms.
• NGO and programme heads: Is this a breach?, The one-page card.

The first six hours.

1. Log T0: the time a credible report reached you, who reported it, what they said.
2. Contain and preserve: cut access, pull public links, rotate credentials; copy logs before anything is wiped.
3. Does CERT-In apply? Only for an Annexure I incident type (data breach, data leak, unauthorised access, ransomware, phishing and others). Yes if you are a company (including a section 8 company), LLP, government organisation, service provider, intermediary or data centre. In our view, a firm or sole proprietorship is covered through the s. 43A definition until 13 May 2027; after that, and for trusts and societies, it is unsettled; we recommend reporting anyway.
4. Report within six hours of noticing: incident@cert-in.org.in, phone 1800-11-4949, fax 1800-11-6969, using the current format on cert-in.org.in (direction (ii)).
5. Send (our suggested minimum; CERT-In's format governs): incident type, when it happened and when you noticed, systems and data affected, what you have done, your Point of Contact, and logs if asked (direction (iv)).
6. From 13 May 2027 also: draft the Board's initial intimation and the notices to affected people.

CERT-In vs DPDP, side by side

Sector regulators, such as RBI, SEBI and IRDAI, set their own incident-reporting rules for the entities they regulate. We have not set out their timelines here; take the current directions from your regulator's website into the playbook and check them each year. Contracts with clients, processors and funders add their own windows. Until 13 May 2027, body corporates also remain bound by the SPDI Rules, 2011 under IT Act s. 43A, which section 44(2) deletes on that date. The DPDP Act adds to these laws rather than replacing them (s. 38(1)).

What counts as a personal data breach

Section 2(u) defines it 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". Processing runs from collection and storage to use, sharing and erasure (s. 2(x)), so a staff member opening records without a work reason is unauthorised processing. Malice is not needed. Availability counts: ransomware that encrypts a beneficiary database is a breach even if nothing leaves the network. The Act covers digital data, or paper data later digitised (s. 3(a)); a lost paper file never digitised is outside it.

Is this a breach?

The judgements in the right-hand columns marked "arguably" or "report" are our view.

What Rule 7 asks

Everything runs from the fiduciary "becoming aware", which the Rules do not define.

To each affected person (Rule 7(1)). "To the best of its knowledge", "in a concise, clear and plain manner and without delay", through her user account or a mode of communication she registered: what happened, including nature, extent and timing; the likely consequences for her; what you have done and are doing to reduce the risk; what she can do; and a contact who can answer her. "To the best of its knowledge" lets you notify on what you know and update later. For a child, notify her parent, who is part of the Data Principal (s. 2(j)). The tagged SMS below shows each element.

To the Board without delay (Rule 7(2)(a)). The nature, extent, timing and location of the breach, and its likely impact.

To the Board within 72 hours (Rule 7(2)(b)). Updated detail, the circumstances and reasons, mitigation, findings on who caused it, measures against recurrence, and a report on the notices to affected people; or a written request for more time. The last item means that by hour 72 you must be able to say how many people you notified, by which channel, when, and how many you could not reach.

The Act guide sets out our reading of "without delay" (hours, within the working day) and of processor timing, which we apply here without repeating.

The Board is meant to work as a digital office (s. 28(1), Rule 20). MeitY sought nominations for the Chairperson and Members on 6 May 2026 and issued a further notification in June; reports through August 2026 say no appointments were made (LiveLaw), and we have found none announced since. We have not found a published form or channel for breach intimations. Check before 13 May 2027 and write it into the playbook. On an intimation the Board may direct urgent remedial measures and inquire (s. 27(1)(a)).

Before 13 May 2027. Rule 7 does not apply yet. Our position: where a breach creates real risk for people, such as fraud, targeted phishing, or exposure of health or children's data, tell them anyway, using the Rule 7(1) content as the template. It reduces harm, and it rehearses the process you will need from May. Sector regulators or contracts may already require customer notice.

CERT-In's six hours: who is covered and what else applies

Who. The Directions name service providers, intermediaries, data centres, body corporates and government organisations (direction (ii)); a company, including a section 8 company, is covered. For firms, trusts and societies, see the card above and Where the law is unclear.

What else the Directions require:

• synchronise ICT clocks to NIC or NPL NTP servers, or sources traceable to them (direction (i));
• designate a Point of Contact and send her details to info@cert-in.org.in in the Annexure II format (direction (iii));
• act on CERT-In orders and supply information in the format and time it sets (direction (iii));
• keep logs of all ICT systems for a rolling 180 days within India, and provide them with an incident report or on direction (direction (iv)).

One retention setting for logs. We recommend keeping one year of security and processing logs, with the associated personal data and traffic data, stored in India and time-synchronised to NIC or NPL. That meets CERT-In's 180 days and both DPDP one-year rules (Rule 6(1)(e), 8(3)), and a synchronised clock makes your incident timeline credible.

Illustrative CERT-In report cover sheet

Illustrative only. CERT-In's current format on its website governs; the fields below are those the Directions themselves name plus facts any report will need.

• Incident type (Annexure I): [for example, (xi) Data Breach; (iii) Unauthorised access of IT systems/data]
• Date and time noticed or brought to notice: [IST, from the incident log]
• Date and time of occurrence, as known: [start and end]
• Systems affected: [application, host or service, hosting location, provider]
• What happened: [two or three plain sentences]
• Actions taken: [containment, credential resets, isolation, time of each]
• Logs: [which logs are preserved; available on request (direction (iv))]
• Point of Contact (Annexure II): name, designation, organisation, office address, email, mobile, office phone

When the incident is at a processor or a multi-tenant platform

The fiduciary remains responsible for processing done on its behalf, "irrespective of any agreement to the contrary" (s. 8(1)); its security duty covers its processors (s. 8(5)); its contracts must provide for safeguards (s. 8(2), Rule 6(1)(f)). Rule 7 puts the notices on the fiduciary. In practice the processor's call starts your clock, so we recommend contracts that require:

• notice to you within a few hours, early enough for your CERT-In six hours, through named 24-hour contacts;
• the facts and logs you need for Rule 7: what data, whose, when, how, what is contained, with updates at fixed intervals;
• no notice to your users or public statement without your agreement, and the same terms flowed down to sub-processors.

The processor contracts guide has the full clause set.

If you are the processor. You may have your own CERT-In duty, on your own six hours. Report, and tell each affected customer at once. Do not notify your customers' users unless the contract says so. For processing whose purpose you decide, such as your own analytics, you are the fiduciary and Rule 7 is yours.

Multi-tenant SaaS. One incident can touch hundreds of customer-fiduciaries, each with its own clock. Prepare for it:

• Scope by tenant. Your logs should let you say, per customer, which records and fields were exposed.
• Produce a per-tenant export of affected users with the fields the customer needs for Rule 7(1): her identifier, registered contact, and data categories involved.
• Send one first-wave notice to every affected customer at the same time, then per-tenant detail. Do not let the largest customer's questions delay the rest.
• Keep a register of each customer's contractual notice window and plan to the shortest.
• Offer each customer an adaptable Rule 7(1) text and your fact sheet, so their notices and reports agree with yours.

Joint fiduciaries and funders. Where a foundation and an implementing NGO both decide purpose and means, each is a fiduciary (s. 2(i)). Our view: agree in advance who sends people the notice and who files with the Board; send one coordinated notice to each person; both file, each describing its role. A CSR funder that only funds and received no personal data needs a short factual note on the same day if the grant agreement requires it, with no personal data attached. One that received or specified the data is likely a fiduciary and needs the fact sheet at once. The CSR foundations guide covers roles.

One incident, every clock: the hour-by-hour playbook

T0 is the moment your incident desk records a credible report of a possible breach. We recommend starting every clock at T0 and explaining later, if needed, why confirmation came after it.

Decide these before the incident

Keep one fact sheet: what happened, when, where, what data, how many people, what has been done, what is unknown. Every report draws on it, so CERT-In, the Board and your public statement carry the same numbers.

Put the approval chain for 2 am in writing. We recommend that the incident lead can file with CERT-In and send the Board's initial intimation without further approval; that the DPO, or the person named under section 8(9) and Rule 9, approves notices to people together with one executive on call; and that the chief executive approves the 72-hour report. Use the same named contact in people notices, since Rule 7(1)(e) requires one.

Agree what the board or trustees hear. Within 24 hours, a half-page: what happened, how many people, which clocks were met, decisions needed. At day 30, the review: root cause, fixes, cost of remediation and what changes in the playbook.

Brief field staff on their first ten minutes using the one-page card.

Our view: privilege over forensic reports is unsettled in India (Bharatiya Sakshya Adhiniyam, 2023, ss. 132–134 protect communications with an advocate); if you want to argue it, have counsel commission the work. Where the incident involves a crime, such as extortion, fraud or impersonation, report it to the police or through the National Cyber Crime Reporting Portal (cybercrime.gov.in), or call 1930, in addition to CERT-In.

Illustrative notices and reports

These texts are illustrative. Adapt them to the facts; Rule 7 prescribes content, not wording. Send people notices in the language you use with them; where that is English or an Eighth Schedule language, keep that version on file.

SMS or WhatsApp to an affected person (Rule 7(1))

[Organisation]: On 2 June 2027 we found that a file with your name, mobile number and loan application status was sent by mistake to an outside email address on 1 June (7(1)(a)). It did not contain bank details or ID numbers. You may receive calls or messages pretending to be from us (7(1)(b)). We have asked the recipient to delete it and stopped email sharing of such files (7(1)(c)). We will never ask for your OTP or PIN; do not share them (7(1)(d)). Questions: call 1800-XXX-XXXX, 9am–6pm, or write to privacy@example.org (7(1)(e)). Details: example.org/notice-0602

Remove the rule references before sending, and check how a long SMS renders on a basic phone.

Email or in-app notice (Rule 7(1))

Subject: A security incident affecting your account with [Organisation]

What happened. On [date and time] we found that [plain description]. It took place between [date] and [date] and affected [number] people, including you.

What information was involved. Your [itemised list]. It did not include [what was not involved, if known with confidence].

What this could mean for you. [Specific, likely consequences.]

What we have done and are doing. [Containment, resets, reports to CERT-In and the Data Protection Board, monitoring.]

What you can do. [Specific steps.]

Questions. [Name or role], [phone], [email], [hours]. Updates at [link].

Initial intimation to the Board (Rule 7(2)(a))

Personal data breach: initial intimation under Rule 7(2)(a)

• Data Fiduciary: [legal name, address, contact person, phone, email]
• Became aware: [date, time IST]
• Nature: [for example, unauthorised access to a support database through stolen staff credentials]
• Extent: [systems and data categories; estimated number of people; children's data involved or not]
• Timing: [start and end, as far as known]
• Location: [system, hosting location, office or vendor]
• Likely impact: [for example, risk of targeted phishing]
• Status: contained at [time]; detailed report within 72 hours of awareness

Detailed report to the Board within 72 hours (Rule 7(2)(b))

Use these headings, in this order:

1. Updated and detailed description of the breach (7(2)(b)(i))
2. Events, circumstances and reasons, with a timeline (7(2)(b)(ii))
3. Measures taken and proposed to mitigate risk (7(2)(b)(iii))
4. Findings on the person who caused it, if any (7(2)(b)(iv))
5. Remedial measures to prevent recurrence, with owners and dates (7(2)(b)(v))
6. Report on notices to affected people: number, channels, dates, undelivered and follow-up, copy of the notice (7(2)(b)(vi))
7. Annexes: fact sheet; other reports filed; contact person

Request for more time (Rule 7(2)(b))

We became aware of the breach at [time, date] and filed the initial intimation on [date]. Forensic analysis of [systems] is expected to establish the full scope by [date]. We request that the period for the detailed report be extended to [date]. We will file the information available at the end of 72 hours and update the Board every [interval].

We recommend asking before hour 72, giving a specific date, and filing what you have anyway.

A breach and near-miss register

Record every incident, including the ones you decide are not breaches. The register is your evidence of judgement and speed under section 33(2)(e).

A one-page incident card for small organisations

Print it, fill the blanks, and pin it where the people who will need it at 10 pm on a Friday can see it.

If you think personal data has been lost, sent to the wrong person, or accessed by someone who should not see it:

1. Call the incident lead now: [name, mobile]. Backup: [name, mobile].
2. Write down the time, what happened and what data was involved.
3. Stop it spreading: ask the recipient to delete it; lock or report the device; change the password.
4. Do not discuss it in WhatsApp groups or on social media.

The incident lead:

• Within 6 hours, if we are covered: report to CERT-In at incident@cert-in.org.in or 1800-11-4949.
• From 13 May 2027, the same day: tell the Data Protection Board through [channel], and send each affected person the notice template in [folder].
• Within 72 hours: send the Board the detailed report, or ask for more time in writing.
• Tell [funder or partner contact] if the data came from or went to them.

A 90-minute drill script

Run this tabletop before 13 May 2027 and once a year after. Each ten minutes of drill stands for several hours.

Roles. Incident lead; security or IT lead; DPO or legal; communications; helpline; a processor's representative if possible; a timekeeper who writes the log; an observer who scores.

Scenario. This illustration is a composite, not a client story. Your learning-app vendor emails at 9:40 pm on a Friday: a storage bucket of student progress reports was publicly readable for an unknown period.

Score it. Was T0 recorded? Was containment done before discussion? Did the team know whether CERT-In applies? Did the people notice carry all five Rule 7(1) elements? Could anyone find the processor's 24-hour contact? Was there one fact sheet?

What the Board will weigh

Failing to keep reasonable safeguards can draw up to ₹250 crore, and failing to notify the Board or affected people up to ₹200 crore (Schedule items 1 and 2), after an inquiry finds a significant breach, and after a hearing (s. 33(1)). In setting the amount the Board must consider whether you mitigated, "and the timeliness and effectiveness of such action" (s. 33(2)(e)), which is what your timestamped log, register and 72-hour report prove; the penalties guide covers the rest.

Where the law is unclear

When does a fiduciary "become aware"? When a responsible person, such as your incident desk, has a credible report that a breach may have occurred. Why: the duty runs "on becoming aware", and CERT-In's clock runs from "noticing" or "being brought to notice". Would change if: the Board issues guidance or decides a case. Confidence: medium.

Must trivial breaches be notified? Yes, on the text. Why: section 2(u) and Rule 7 set no threshold. We notify, keep the notice proportionate, and record the decision in the register. Would change if: the Rules add a threshold or the Board signals otherwise. Confidence: medium.

What if an affected person has no registered channel? Use the best available route, such as a field visit or a notice at the service point, and record why. Why: Rule 7(1) names only her user account or a registered mode and is silent on people with neither. Would change if: guidance addresses it. Confidence: low.

Does Rule 7 apply to a breach that happened before 13 May 2027 but is found after? We assume yes. Why: the duty is triggered "on becoming aware", and section 8(6) applies "in the event of" a breach without a date limit; the opposite reading is arguable. Would change if: the Board or a court reads it otherwise. Confidence: low.

Are firms, trusts and societies within the CERT-In Directions? Firms and sole proprietorships, yes until 13 May 2027; after that, and for trusts and societies, unsettled. Why: section 70B(6) lets CERT-In direct "any other person", but the 2022 Directions name only five categories and do not define "body corporate". They borrow IT Act meanings, and the IT Act defines it, for the purposes of section 43A, as "any company and includes a firm, sole proprietorship or other association of individuals engaged in commercial or professional activities". Section 44(2) deletes section 43A and that definition from 13 May 2027, leaving the ordinary meaning, under which in our view a trust or registered society is generally not a body corporate. We advise all of them to report Annexure I incidents anyway. Would change if: CERT-In clarifies or issues directions naming them. Confidence: low.

A plan for the next six months

For the wider programme, see the Act guide and the compliance checklist.

How we wrote this guide. We worked from the text of the Digital Personal Data Protection Act, 2023 (No. 22 of 2023), the Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E), as corrected by G.S.R. 892(E)), the commencement notification G.S.R. 843(E), CERT-In's Directions No. 20(3)/2022-CERT-In of 28 April 2022 read from the official PDF, and IT Act sections 43A, 70B and 85 as amended by the Jan Vishwas (Amendment of Provisions) Act, 2023. Events after 13 November 2025 come from the linked public reports, last checked 25 October 2026. Statements marked "our view", "our position" or "we recommend" are our judgement, not the law. This guide explains the law; it is not legal advice.