Cyber Law • Data Protection & Incident Response

Personal Data Breach Reporting in India: DPDP 72-Hour Rule, CERT-In 6-Hour Rule, Notices, Evidence and Penalties

How Indian organisations should coordinate immediate containment, CERT-In reporting, future Data Protection Board notifications, affected-person communications and defensible evidence preservation.

A personal-data breach in India can trigger several legal and regulatory tracks at the same time. The Information Technology Act, 2000 and the binding CERT-In Directions of 28 April 2022 already require specified cyber incidents—including data breaches and data leaks—to be reported to CERT-In within six hours. Separately, Section 8(6) of the Digital Personal Data Protection Act, 2023 and Rule 7 of the Digital Personal Data Protection Rules, 2025 create notification duties to the Data Protection Board of India and affected Data Principals.

This distinction is critical. A company should not treat the future DPDP deadline as permission to delay an existing CERT-In report. Conversely, a report to CERT-In will not automatically satisfy the separate DPDP notices once Section 8(6) and Rule 7 commence.

1. Law at a glance: two distinct reporting regimes

Issue	CERT-In Directions	DPDP Act and Rule 7
Present status	Operative	Section 8(6) and Rule 7 scheduled from 13 May 2027
Trigger	Specified cyber incidents in Annexure I, including data breach and data leak	A “personal data breach” within Section 2(u)
Recipient	CERT-In	Data Protection Board and each affected Data Principal
Timeline	Within six hours of noticing or being brought to notice	Affected persons and initial Board intimation without delay; detailed Board update within 72 hours of awareness
Primary purpose	National cyber-incident response and coordination	Personal-data protection, transparency and accountability

Regulated entities may also have to notify the Reserve Bank of India, Securities and Exchange Board of India, Insurance Regulatory and Development Authority of India, Department of Telecommunications, sectoral Computer Security Incident Response Teams, stock exchanges, customers, insurers or contractual counterparties. The applicable matrix depends on the entity, licence, incident and affected system.

2. What is a “personal data breach” under the DPDP Act?

Section 2(u) defines a personal data breach broadly. It includes unauthorised processing of personal data as well as accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access that compromises the confidentiality, integrity or availability of personal data.

The definition therefore covers more than public disclosure. Examples include:

• a ransomware incident that makes employee or customer data unavailable;
• an email containing personal data sent to the wrong recipient;
• stolen credentials used to access a customer database;
• unauthorised alteration of payroll or health records;
• a publicly exposed cloud-storage bucket;
• loss of an unencrypted laptop or portable drive;
• malicious extraction by an employee, contractor or vendor;
• accidental deletion without a usable backup;
• misconfigured application programming interfaces exposing user records; and
• unauthorised sharing by a Data Processor or subprocessor.

A security event is not automatically a personal-data breach. The incident team must identify whether digital personal data was involved and whether confidentiality, integrity or availability was compromised. However, that assessment cannot be used to postpone the separate six-hour CERT-In analysis where the event falls within Annexure I.

3. CERT-In’s six-hour reporting rule

Direction (ii) of the CERT-In Directions dated 28 April 2022 requires service providers, intermediaries, data centres, bodies corporate and Government organisations to report the cyber incidents listed in Annexure I within six hours of noticing the incident or being brought to notice of it.

Annexure I includes, among other matters:

• unauthorised access to IT systems or data;
• ransomware, malicious-code and bot attacks;
• identity theft, spoofing and phishing;
• denial-of-service attacks;
• attacks on e-commerce and other applications;
• data breaches and data leaks;
• incidents affecting digital-payment systems;
• unauthorised access to social-media accounts; and
• attacks affecting cloud, artificial-intelligence, blockchain and virtual-asset systems.

The six-hour period is short by design. The organisation should not wait for a completed forensic investigation. CERT-In’s FAQ explains that information available at the time may be supplied first, with additional information furnished later. The initial report should be accurate, carefully qualified and promptly supplemented.

CERT-In lists incident@cert-in.org.in and its official reporting channels for incident reporting. The current reporting method and form should always be checked on the CERT-In website at the time of the incident.

4. Who must report to CERT-In?

The Directions apply broadly to service providers, intermediaries, data centres, bodies corporate and Government organisations. Specific requirements also apply to cloud-service providers, virtual private server providers, virtual private network service providers and virtual-asset businesses.

“Body corporate” under the Information Technology Act is wider than a listed company. Depending on the facts, it can include a company, LLP, firm, sole proprietorship or other association engaged in commercial or professional activity. A startup or professional firm should not assume that reporting applies only to large technology platforms.

Each covered organisation should designate a Point of Contact for CERT-In and keep the submitted contact particulars current. The incident playbook should state who is authorised to communicate with CERT-In outside business hours.

5. Section 8(6) DPDP notification duty

Once the substantive provision commences, Section 8(6) will require the Data Fiduciary to intimate a personal data breach to the Data Protection Board and each affected Data Principal in the prescribed form and manner.

The legal responsibility remains with the Data Fiduciary even where the breach occurs in the systems of a Data Processor. Section 8(1) makes the Data Fiduciary responsible for processing undertaken by it or on its behalf. Processor contracts and subprocessor arrangements must therefore require immediate escalation, preservation of evidence and assistance with notifications.

The broader phased-commencement position, including obligations beginning in November 2026 and May 2027, is explained in our DPDP Act compliance and commencement guide.

6. Notice to affected Data Principals under Rule 7

Rule 7 requires each affected Data Principal to be informed without delay through her user account or any registered mode of communication. The communication must be concise, clear and in plain language.

The notice must address:

• the nature, extent and timing of the breach;
• the consequences likely to arise for the Data Principal;
• the measures implemented and being implemented to mitigate risk;
• safety measures the person may take to protect her interests; and
• business contact information of a person able to answer queries on behalf of the Data Fiduciary.

A compliant notice is incident-specific. Generic language such as “we value your privacy” is insufficient if it does not explain what happened, what data was affected, the likely consequences and the practical protective steps available.

Protective steps may include resetting passwords, enabling multi-factor authentication, revoking active sessions, blocking compromised cards or accounts, monitoring financial statements, avoiding impersonation messages and preserving suspicious communications. The steps should match the actual data and threat; they should not create unnecessary panic.

7. Initial notification to the Data Protection Board

On becoming aware of a personal data breach, the Data Fiduciary must intimate the Board without delay. The initial intimation should describe:

• the nature of the breach;
• its extent;
• timing;
• location of occurrence; and
• likely impact.

This is not the 72-hour detailed report. Rule 7 creates an immediate preliminary intimation followed by an updated submission. An internal workflow that begins legal review only on the third day would therefore be defective.

8. Detailed Board report within 72 hours

Within 72 hours of becoming aware of the breach—or within a longer period allowed by the Board on a written request—the Data Fiduciary must provide:

• updated and detailed information regarding the breach description;
• the broad facts concerning events, circumstances and reasons leading to the breach;
• measures implemented or proposed to mitigate risk;
• findings regarding the person who caused the breach, where available;
• remedial measures taken to prevent recurrence; and
• a report regarding notices given to affected Data Principals.

An extension is not automatic. The request must be in writing and should identify the unavailable information, explain why it cannot reasonably be supplied within 72 hours, state the investigative steps already taken and propose a firm supplementation date.

The 72-hour clock should be recorded in the incident chronology. The organisation should preserve the first alert, validation steps, internal escalation, processor notice and management decisions so that the asserted awareness time can be demonstrated.

9. Does Rule 7 contain a risk threshold?

On its text, Rule 7 does not create a separate “high-risk” or “materiality” threshold for notification of a personal data breach. Once an event satisfies the statutory definition, the notification duties are framed mandatorily.

This differs from some foreign data-protection regimes and from sectoral rules that use materiality or impact thresholds. Organisations should not import a foreign threshold into the Indian rule without a legal basis. The incident classification should document why the event is or is not a personal data breach under Section 2(u).

10. When does “awareness” begin?

The Act and final Rules do not provide a detailed evidentiary test for awareness. The safer governance approach is to treat awareness as a fact-sensitive question based on when responsible personnel had sufficient information to conclude that a personal-data breach had occurred.

Internal delay, poor monitoring or a processor’s failure to escalate should not be treated as a reliable way to postpone the clock. The incident policy should:

• define suspected and confirmed incidents;
• identify decision-makers authorised to determine breach status;
• require immediate processor escalation;
• record the basis and time of classification;
• prohibit intentional delay in validation; and
• permit an initial qualified report while investigation continues.

11. CERT-In logs and DPDP evidence requirements

The CERT-In Directions require covered entities to enable logs of ICT systems, maintain them securely for a rolling period of 180 days within Indian jurisdiction, and provide them with the incident report or when directed.

Rule 6 of the DPDP Rules separately requires reasonable security safeguards, including appropriate access controls, monitoring, logs, backups, processor-contract protections and retention of specified logs and relevant data for at least one year, subject to longer periods under other law.

These are not interchangeable retention rules. The longer or more specific applicable requirement should be mapped system-by-system. A litigation hold, investigation, insurance condition, contractual obligation or sectoral rule may require preservation beyond the ordinary schedule.

12. Evidence preservation and forensic defensibility

Incident response must contain the breach without destroying proof. The response team should preserve:

• original alerts, tickets and time stamps;
• authentication, access, firewall, endpoint, application and database logs;
• cloud audit trails and configuration histories;
• email headers, malicious files and phishing artefacts;
• forensic images or snapshots where appropriate;
• processor and subprocessor notices;
• affected-data inventories and extraction queries;
• remediation commands and change records;
• communications with regulators, insurers and affected persons;
• minutes recording material decisions; and
• a chain-of-custody record for collected evidence.

Live systems may require urgent action. Where possible, the team should record the pre-change state, person authorising the change, exact action, time, tool used and result. Unstructured deletion, overwriting logs or rebuilding a server without preservation can compromise regulatory explanations, criminal investigation, insurance recovery and civil proceedings.

For the criminal-law and electronic-evidence aspects of cyber incidents, see our guide to cybercrime reporting and electronic evidence in India.

13. Legal privilege and investigation governance

A serious breach commonly involves technical forensics, employee interviews, contractual analysis, notification decisions and potential proceedings. The company should determine at the outset which work is operational response and which work is undertaken for obtaining legal advice or preparing for anticipated litigation.

Merely copying a lawyer does not automatically create privilege. Investigation instructions, reporting lines, engagement letters and distribution controls should reflect the actual legal purpose. Factual evidence and regulatory reporting obligations cannot be concealed by labelling everything privileged.

The final regulator or customer communication must remain accurate and consistent with preserved technical evidence. Premature attribution, unsupported assurances and speculative numbers should be avoided.

14. Data Processor and vendor contracts

A Data Fiduciary cannot meet a six-hour or 72-hour external deadline if its processor is allowed several days to report internally. Contracts should require:

• immediate notice of an actual or suspected security incident;
• a short outside escalation period measured in hours;
• 24-hour incident contacts;
• preservation of logs and evidence;
• continuous factual updates;
• access to relevant forensic findings;
• assistance in identifying affected Data Principals and records;
• cooperation with CERT-In, the Board and sectoral regulators;
• approval controls for public statements without obstructing statutory reporting;
• subprocessor flow-down obligations;
• audit and remediation rights;
• allocation of investigation, notice and credit-monitoring costs; and
• indemnity and insurance provisions proportionate to risk.

The contract should not permit a processor to delay notification until it has conclusively established root cause. It should distinguish a suspected incident, confirmed cyber incident and confirmed personal-data breach while requiring prompt escalation at each stage.

15. First six hours: operational checklist

1. Activate the response team: technical, legal, privacy, management, communications, HR and vendor owners as applicable.
2. Record the time: first detection, first notice, validation and material developments.
3. Contain safely: isolate compromised systems or accounts while preserving evidence.
4. Classify the event: check Annexure I to the CERT-In Directions and whether personal data is implicated.
5. Notify the insurer: comply with policy conditions before appointing vendors where necessary.
6. Contact critical processors: preserve logs and obtain immediate facts.
7. Prepare the CERT-In report: report available facts within six hours and identify information under investigation.
8. Check parallel duties: police, NCRP/1930, sectoral regulator, stock exchange, contract and overseas regulator.
9. Control communications: use one verified incident chronology and approved factual statements.
10. Plan supplementation: name owners and deadlines for additional facts.

16. First 72 hours: DPDP-ready checklist

• confirm the affected systems, time period and locations;
• identify categories and approximate volume of personal data;
• identify affected Data Principals and registered communication channels;
• assess confidentiality, integrity and availability impact;
• document containment and mitigation;
• prepare affected-person notices in clear language;
• prepare the initial Board intimation without delay;
• build the detailed 72-hour report and incident chronology;
• record whether an extension request is necessary and why;
• preserve evidence of all notices sent;
• start root-cause and recurrence-prevention actions; and
• brief management on legal, operational and reputational exposure.

17. Coordination with police and financial-fraud reporting

A data breach may also involve unauthorised access, identity theft, cheating by personation, criminal breach of trust, extortion, theft of trade secrets or other offences. CERT-In notification is not a substitute for a criminal complaint or financial-fraud report.

Where funds are being transferred or credentials are actively being abused, immediate reporting through the national cybercrime helpline 1930 and the National Cyber Crime Reporting Portal may assist rapid financial intervention. The organisation should preserve transaction references, beneficiary details, device information, IP logs, messages and communications with banks.

For compromised credentials used to impersonate individuals or create fake accounts, our article on identity theft and fake-profile remedies explains the evidence and takedown pathway.

18. Penalties and exposure

Under the DPDP Act’s Schedule, breach of the duty to take reasonable security safeguards may attract a monetary penalty up to ₹250 crore. Breach of the obligation to intimate the Board or affected Data Principals under Section 8(6) may attract a penalty up to ₹200 crore. These substantive provisions are scheduled to commence on 13 May 2027.

Section 70B(7) of the Information Technology Act provides that failure to provide information called for or to comply with a CERT-In direction may be punishable with imprisonment up to one year, fine up to ₹1 lakh, or both.

Exposure may also arise under contract, consumer law, employment law, confidentiality obligations, sectoral regulations, insurance conditions and criminal law. A single incident can therefore produce regulatory, civil, contractual and criminal consequences.

19. Common drafting errors in breach notices

• describing the incident as “minor” before the investigation supports that conclusion;
• failing to identify the affected data categories;
• confusing suspected compromise with confirmed exfiltration;
• promising that there is “no risk” without a defensible basis;
• using inconsistent dates across regulator, customer and insurance notices;
• omitting practical protective measures for affected persons;
• identifying an attacker without sufficient evidence;
• claiming the incident is fully contained while access paths remain open;
• allowing public-relations language to obscure statutory information; and
• failing to preserve proof of delivery and the exact notice version.

20. Board and management preparedness before May 2027

Management should not wait for a live breach to decide authority, reporting lines and communication channels. A documented readiness programme should include:

• an approved incident-response policy;
• a 24-hour escalation tree;
• CERT-In Point of Contact details;
• Data Protection Board reporting ownership;
• a data and systems inventory;
• processor incident clauses and contacts;
• pre-approved notice templates;
• forensic and legal-response retainers;
• cyber-insurance mapping;
• log-retention and evidence-preservation standards;
• tabletop exercises testing six-hour and 72-hour deadlines; and
• documented closure and lessons-learned review.

Common Client Questions

Is every data breach currently reportable to the Data Protection Board?

Not yet under Section 8(6) and Rule 7. Those provisions are scheduled to commence on 13 May 2027. The Data Protection Board exists, but the substantive breach-notification duty must be distinguished from already operative provisions.

Is CERT-In reporting already mandatory?

Yes. Covered organisations must report the specified incidents in Annexure I within six hours of noticing the incident or being brought to notice of it.

Does reporting to CERT-In satisfy the DPDP requirement?

No. They are separate regimes with different recipients, purposes and contents. Once Rule 7 commences, both may apply to the same incident.

Must affected individuals be notified within 72 hours?

Rule 7 states that affected Data Principals must be informed without delay. The 72-hour period applies to the detailed report to the Board, not as a waiting period for affected-person notices.

Can a company wait for the forensic report before notifying CERT-In?

No. The six-hour requirement generally necessitates an initial report based on available facts, followed by supplementation as the investigation develops.

What if the breach occurs at a cloud or payroll vendor?

The Data Fiduciary remains responsible for DPDP compliance for processing undertaken on its behalf. The vendor contract should require immediate escalation and cooperation so statutory deadlines can be met.

What records should be preserved?

Preserve the incident chronology, logs, alerts, cloud audit trails, affected-data analysis, forensic artefacts, processor communications, notification decisions, notice versions and proof of delivery.

Authoritative legal sources

• Digital Personal Data Protection Act, 2023 — India Code
• Section 8 DPDP Act — general obligations and breach notification
• Digital Personal Data Protection Rules, 2025 — MeitY
• DPDP Act enforcement timeline — India Code
• CERT-In Cyber Security Directions dated 28 April 2022
• CERT-In FAQs on the 2022 Directions
• Current CERT-In directions and reporting resources

Legally reviewed: 20 August 2026. Disclaimer: This article provides general legal and compliance information. The incident facts, entity status, current Government notifications, regulator-specific directions and contractual duties must be verified before any reporting decision.