Data Breach Response in India 2026: CERT-In 6-Hour Reporting, DPDP Timeline, 72-Hour Board Notice & Incident Response

By Adv. Govind Bali

India’s data-breach law in 2026 is unusually easy to misstate because two regulatory timelines overlap. The CERT-In cyber-incident reporting framework is already operative and can require specified cyber incidents, including qualifying data breaches and data leaks, to be reported within six hours. At the same time, the Digital Personal Data Protection Act, 2023 (DPDP Act) and the Digital Personal Data Protection Rules, 2025 have been brought into force in phases. The core Data Fiduciary obligations in Sections 3 to 17—including the personal-data security and breach-intimation duties in Section 8—are scheduled to commence only after the notified eighteen-month transition period.

That distinction matters. A business suffering a breach on 21 August 2026 should not assume that it can wait for the future DPDP breach-notification regime. It must first determine whether the incident is reportable under the CERT-In Directions issued under Section 70B of the Information Technology Act, 2000, along with any sector-specific obligations that apply to the organisation. At the same time, organisations should build their systems now for the DPDP framework that is approaching.

For a broader overview of the privacy statute, see our existing DPDP Act business compliance guide. This article is deliberately narrower: it focuses on what to do when a cyber incident or personal-data breach actually occurs.

Quick Answer: What Should a Business Do After Discovering a Data Breach in India?

Activate the incident-response team immediately.
Contain the incident without destroying evidence.
Record the exact time the incident was noticed or brought to notice.
Determine whether it falls within CERT-In’s reportable cyber-incident categories.
If reportable, make the initial CERT-In report within six hours. Do not wait for every forensic fact to become available.
Preserve logs, images, access records, cloud audit trails, endpoint artefacts and relevant communications.
Identify the personal data, systems, users and third parties affected.
Check contractual and sectoral notification obligations.
Prepare a privilege-conscious forensic and legal investigation.
Prepare for the future DPDP breach regime now, including affected-person communication and the proposed two-stage Board intimation process.

The Most Important 2026 Distinction: CERT-In Is Current; Most DPDP Breach Duties Are Future-Dated

The DPDP Act was enacted in 2023, but commencement is phased. The Government’s notified timeline provides that the substantive processing provisions—including Sections 3 to 17—commence after the eighteen-month transition period calculated from 13 November 2025. That places the operative date for those provisions at 13 May 2027.

Section 8 is inside that future tranche. It contains two core breach obligations:

Section 8(5): reasonable security safeguards to prevent personal-data breaches; and
Section 8(6): intimation to the Data Protection Board and each affected Data Principal when a personal-data breach occurs.

Accordingly, as of 21 August 2026, businesses should not describe Section 8(6) as if its breach-notification obligation were already the operative legal trigger for today’s incident. The correct current analysis begins with CERT-In, the Information Technology Act framework, applicable contracts, and sector-specific regulation. The DPDP breach framework is nevertheless close enough that organisations should build their compliance architecture now rather than waiting until May 2027.

What Is a Data Breach?

A data breach is broader than a hacker stealing a customer database. Operationally, a breach may involve unauthorised access, disclosure, alteration, loss, destruction or compromise of information. Common incidents include:

ransomware encrypting servers and exfiltrating files;
employee credentials being phished and used to access email or cloud storage;
customer records exposed through an unsecured API;
a database backup placed in a publicly accessible bucket;
malware harvesting credentials or payment information;
an employee sending a spreadsheet containing personal data to the wrong recipient;
a vendor or cloud processor being compromised;
lost or stolen devices containing unprotected data;
insider extraction of customer, employee or business information;
unauthorised scraping or bulk download through compromised credentials;
source-code or configuration leaks exposing keys and secrets; and
unauthorised deletion or alteration that damages availability or integrity even where no public disclosure occurs.

The incident should be classified on evidence, not on the initial label used by IT staff. A ticket called a “server issue” can later prove to be ransomware. A “misdirected email” may expose financial or health information. A “vendor outage” may conceal an upstream compromise.

CERT-In’s Six-Hour Reporting Rule

The Indian Computer Emergency Response Team (CERT-In) issued binding directions under Section 70B(6) of the Information Technology Act on 28 April 2022. CERT-In’s current official directions page continues to list those directions and the associated FAQs.

CERT-In’s FAQ explains that specified cyber incidents must be reported within six hours of noticing the incident or being brought to notice about it. The FAQ expressly identifies reportable categories including severe cyber incidents, data breaches or data leaks, large-scale or frequent intrusions and cyber incidents affecting human safety.

This six-hour period is short. It is not a six-hour period to finish the entire investigation. CERT-In specifically recognises that an organisation may not have all information required by the incident-reporting form within the first six hours. The entity may provide information available at that stage and supplement it within a reasonable time.

Why the Six-Hour Clock Changes Incident Management

Many companies still operate on an incident-response model in which IT investigates for several days before legal or senior management becomes involved. That model is dangerous where a reportable CERT-In incident is possible.

The better sequence is:

Detection → triage → legal/regulatory classification → initial CERT-In report if required → continuing forensic investigation → supplemental reporting.

The six-hour window means a business should have a pre-approved escalation matrix identifying who can decide whether CERT-In reporting is required outside normal working hours. Waiting for the CEO, board meeting or overseas parent company to approve the first report may consume the statutory window.

When Does the Six-Hour Clock Start?

The practical trigger is when the incident is noticed or brought to the organisation’s notice. Organisations should therefore document:

when the first alert was generated;
when a person actually reviewed it;
when the issue was escalated;
when available information first indicated a reportable incident; and
who made the regulatory-classification decision.

These timestamps can become important if the timeliness of reporting is later questioned.

What Information Should Be Included in the Initial CERT-In Report?

CERT-In permits an initial report using information reasonably available at the time. A useful first report should ordinarily identify:

the reporting organisation and contact person;
date and time the incident was detected;
affected systems, networks or services known at that stage;
nature of the incident—such as ransomware, intrusion, data leak, credential compromise or denial of service;
known indicators of compromise;
initial containment steps;
whether personal, financial, government, critical or other sensitive information may be affected;
known third-party or vendor involvement; and
a statement that forensic investigation is continuing and supplemental information will follow.

CERT-In’s incident-reporting page identifies the current reporting channels and explains the incident verification, triage and response process.

Do Not Delay Reporting Because the Forensic Investigation Is Incomplete

A recurring compliance mistake is: “We do not yet know exactly what was taken, so there is nothing to report.” CERT-In’s own FAQ rejects that approach where a reportable incident has occurred. Information may be supplied to the extent available and updated later.

The incident team should therefore separate two questions:

Do we have enough information to determine that a reportable cyber incident has occurred?
Do we know the complete root cause and full scope?

The first question may be answered hours or days before the second.

Third-Party and Cloud Breaches: Outsourcing Does Not End the Problem

Modern data processing frequently involves SaaS vendors, payroll processors, cloud platforms, CRM providers, logistics vendors, call centres, payment intermediaries and outsourced technology teams. A compromise in a third-party environment can still create regulatory exposure for the customer organisation.

CERT-In’s FAQ states that its incident-reporting directions apply to entities in relation to cyber incidents even where the affected data is stored in a third party’s systems. Companies therefore need incident-notification clauses in vendor contracts that operate faster than the external regulatory deadline.

A vendor clause requiring notification “within seven business days” is commercially inadequate where the customer may itself face a six-hour reporting window.

Contract Clauses Every Business Should Review Before a Breach

Technology and data-processing contracts should address:

definition of security incident and personal-data breach;
immediate notification and a fixed maximum notification window;
24×7 security escalation contacts;
preservation of logs and forensic artefacts;
cooperation with CERT-In and regulators;
forensic access and investigation rights;
prohibition on unilateral public statements without coordination, subject to law;
sub-processor incident obligations;
cyber insurance notification cooperation;
allocation of remediation costs;
audit rights;
data-return and deletion controls; and
indemnity and liability allocation consistent with applicable law.

Preserve Evidence Before Remediation Destroys It

Containment is essential, but rushed remediation can erase the evidence needed to understand what happened. Before reimaging, wiping or replacing affected systems, the incident team should consider preservation of:

server and endpoint logs;
firewall, IDS/IPS, EDR and SIEM records;
cloud audit logs;
identity-provider and authentication logs;
email headers and mailbox audit data;
malware samples;
disk and memory images where appropriate;
access tokens and session information;
database-query and export logs;
API gateway logs;
VPN records;
backup logs;
screenshots of ransom notes or threat-actor communications;
relevant vendor communications; and
the incident chronology itself.

CERT-In’s directions also create log-retention expectations. The organisation should ensure that automated log rotation does not destroy evidence during the investigation.

Build a Defensible Incident Chronology

A breach chronology is one of the most valuable legal and forensic documents. It should record:

Time	Event	Source	Decision/Action
09:15	EDR alert	Security console	SOC begins triage
10:05	Unauthorised export identified	Database logs	Legal and CISO escalated
11:20	Reportability confirmed	Incident team	CERT-In report prepared

The chronology should distinguish facts from assumptions. Avoid writing unverified conclusions such as “no data was taken” merely because exfiltration has not yet been proven.

Current CERT-In Requirements vs Future DPDP Breach Requirements

Issue	CERT-In position in Aug 2026	DPDP regime scheduled for May 2027
Primary trigger	Specified cyber incidents	Personal-data breach
Regulator	CERT-In	Data Protection Board of India
Initial timing	Within 6 hours for reportable incidents	Board intimation without delay under Rule 7 framework
Detailed follow-up	Supplement information within reasonable time	Detailed Board information within 72 hours, subject to extension allowed by Board
Affected individuals	Depends on other applicable obligations and facts	Affected Data Principals to be informed without delay in prescribed manner
Security safeguards	Existing IT/cybersecurity obligations remain relevant	Section 8(5) plus Rule 6 minimum safeguards

What Will Rule 6 Require Once the Substantive DPDP Regime Commences?

The Digital Personal Data Protection Rules, 2025 prescribe minimum reasonable-security safeguards that businesses should already use as a readiness benchmark. Rule 6 identifies measures including:

encryption, obfuscation, masking or tokenisation as appropriate;
access controls;
logs, monitoring and review sufficient to detect unauthorised access and investigate it;
continuity measures and backups;
retention of relevant logs and personal data for the prescribed period where applicable;
security provisions in Data Fiduciary–Data Processor contracts; and
appropriate technical and organisational measures.

These provisions are highly relevant to 2026 implementation planning even though the core Rule 6/Section 8 obligations are in the future commencement tranche.

The Future Rule 7 Breach Notification Model

Rule 7 establishes a two-track notification model for the future substantive DPDP regime.

Notification to affected Data Principals

Once operative, the Data Fiduciary will be required to notify each affected Data Principal without delay and in clear language. The notification is to include the nature, extent and timing of the breach, likely consequences, mitigation measures, safety steps the person can take and a business contact for queries.

Notification to the Data Protection Board

The Data Fiduciary is to provide the Board an initial description of the breach without delay. Updated and detailed information is then due within 72 hours of becoming aware of the breach, unless the Board permits a longer period on written request.

The detailed follow-up includes the events and circumstances leading to the breach, mitigation measures, findings regarding the person responsible where known, steps to prevent recurrence and a report about notifications sent to affected individuals.

Do Not Confuse the Future 72-Hour DPDP Detail Report with CERT-In’s Current Six-Hour Rule

These timelines have different legal sources, regulators and purposes. When the DPDP breach provisions become operative, some incidents may trigger both regimes. A company should not assume that satisfying one automatically satisfies the other.

That is why incident-response procedures should use a regulatory matrix rather than a single generic “72-hour breach notice” rule copied from overseas privacy frameworks.

The DPDP Penalty Exposure Is Material

The statutory Schedule to the DPDP Act provides for significant monetary exposure once the relevant provisions are operational. The maximum penalty for breach of the obligation to take reasonable security safeguards may extend to ₹250 crore. Failure to meet the statutory breach-intimation obligation may attract a penalty extending to ₹200 crore.

These are maximum statutory figures, not automatic penalties for every incident. The adjudicatory process and statutory factors matter. Nevertheless, the scale makes breach preparedness a board-level governance issue rather than merely an IT support function.

The Data Protection Board Exists, but the Core Breach Enforcement Regime Is Still Transitioning

The Central Government established the Data Protection Board of India under Section 18. MeitY’s May 2026 recruitment notice describes the Board as an independent adjudicatory authority under the DPDP Act. This institutional development should not be confused with commencement of every substantive obligation under the Act. The enforcement architecture is being built in phases.

Incident Response: The First 60 Minutes

During the first hour, the objective is to prevent uncontrolled spread while preserving evidence.

Open a formal incident ticket and assign an incident commander.
Record discovery time and source.
Identify affected systems and isolate where necessary.
Do not indiscriminately wipe or restart systems.
Preserve volatile and non-volatile forensic evidence where appropriate.
Disable compromised credentials and revoke active sessions.
Engage legal, CISO/security, IT operations and senior management.
Contact relevant vendors or cloud providers through the emergency channel.
Start a regulator and contractual-notification matrix.
Assess whether emergency law-enforcement involvement is needed.

The First Six Hours

The organisation should aim to establish:

what is known and what remains unknown;
whether a CERT-In reportable incident exists;
the likely attack vector;
the systems and data categories potentially affected;
whether the attacker retains persistence;
whether data exfiltration has been observed;
whether business continuity is affected;
whether payment or financial systems are involved;
whether employees or customers require immediate protective action; and
whether contractual notices are already due.

If CERT-In reporting is required, the initial report should go within the prescribed window even if the forensic investigation remains incomplete.

The First 24 Hours

By the end of the first day, the response should ordinarily include:

forensic scoping;
malware and indicator analysis;
account and privileged-access review;
vendor and sub-processor escalation;
initial legal assessment of affected data;
customer/employee harm assessment;
preservation notices;
board or senior-management briefing proportionate to severity;
cyber-insurance notification where required;
public-relations holding statement if external disclosure risk exists; and
supplemental CERT-In information where available.

The First 72 Hours

By 72 hours, an organisation should have a substantially better evidence base. Even before the DPDP Rule 7 timeline becomes legally operative, using a 72-hour internal discipline helps prepare for the future regime. The business should seek to document:

confirmed affected systems;
categories and approximate volume of data affected;
number and class of individuals potentially impacted;
root cause or leading hypothesis;
attack timeline;
containment and remediation completed;
remaining risk;
regulatory reports made;
contractual notices made;
individual-protection steps;
law-enforcement engagement; and
next-stage remediation plan.

When Should Affected People Be Told in 2026?

There is no single universal answer for every organisation and every incident in August 2026. The future DPDP Rule 7 affected-person notification obligation is not yet in its substantive commencement phase. However, another applicable law, regulator, contractual obligation, employment duty or fact-specific risk may require or justify communication earlier.

Even where not automatically mandated by the future DPDP rule, organisations should assess whether individuals need urgent information to protect themselves—for example by changing passwords, freezing cards, monitoring accounts, replacing credentials or responding to identity theft.

What Should an Affected-Person Notice Avoid?

A breach notice should not speculate. Avoid statements such as:

“No data was accessed” before forensic confirmation;
“The incident is fully contained” while persistence remains under investigation;
“There is no risk” without analysing the data involved; or
“The vendor was solely responsible” before contractual and forensic review.

A useful notice should clearly distinguish confirmed facts, reasonable precautionary steps and information still under investigation.

Ransomware and Extortion Incidents

Ransomware often combines encryption with data theft. The absence of visible publication does not prove that data was not exfiltrated. Organisations should analyse outbound traffic, cloud logs, threat-actor statements and artefacts rather than relying on the ransom note.

Payment of a ransom raises separate legal, sanctions, insurance, ethical and operational questions. A decision should not be made merely because a threat actor sets a short deadline. Preserve communications and involve legal, forensic, senior management, insurance and law-enforcement stakeholders as appropriate.

Insider Data Theft

Not every breach is caused by an external hacker. Employees, contractors or vendors may misuse legitimate access to export customer lists, pricing, source code, employee records or confidential business information.

Where insider activity is suspected:

preserve email, endpoint and access logs before confronting the individual;
avoid tipping off the suspect prematurely;
review USB, cloud sync, printing and bulk-download events;
preserve employment and confidentiality documents;
coordinate HR, legal and cybersecurity actions;
consider whether credentials and devices must be secured; and
separately analyse regulatory reporting and potential civil/criminal remedies.

Business Email Compromise and Credential Theft

Business email compromise may create both a cybersecurity incident and financial fraud. If money has been transferred fraudulently, the organisation should immediately contact the bank and use the Government’s financial-cyber-fraud reporting ecosystem. Our Cyber Financial Fraud Recovery in India 2026 guide explains 1930, NCRP and CFCFRMS recovery workflow.

Where a criminal complaint or FIR becomes necessary, see our Cybercrime Complaint vs FIR in India 2026 guide.

Cyber Insurance: Notify Early

Cyber-insurance policies frequently contain notification, panel-vendor and consent conditions. Engaging forensic or crisis-response vendors before checking the policy may affect coverage. The incident team should identify:

policy and insurer;
broker and emergency hotline;
notification deadline;
approved forensic counsel/vendors;
ransomware conditions;
business interruption coverage;
privacy liability coverage;
regulatory defence coverage; and
documentation needed to support the claim.

Board and Management Responsibilities

A serious data breach is not merely a technical event. Management should be able to show that the organisation had:

an approved incident-response plan;
clear roles and escalation thresholds;
tested backups;
access-control governance;
vendor security oversight;
logging and monitoring;
employee awareness;
cyber drills;
regulatory reporting procedures; and
post-incident remediation tracking.

CERT-In’s 2026 cyber-resilience guidance continues to emphasise incident-response exercises, backup restoration validation, simulations and timely reporting.

A Practical Data Breach Decision Matrix

Question	Why it matters
Is this a CERT-In reportable incident?	Determines current 6-hour reporting exposure
What systems and data are affected?	Defines scope and harm
Is personal data involved?	Relevant to future DPDP duties and present contractual/sectoral obligations
Is financial fraud involved?	Triggers urgent bank/1930/NCRP action
Is a regulated sector involved?	May add regulator-specific duties
Did a vendor cause or host the incident?	Triggers contract and processor obligations
Do individuals need immediate protective information?	Reduces harm and future liability
Are logs and evidence preserved?	Critical for investigation and proof

Documents a Business Should Have Ready Before Any Incident

Cyber Incident Response Plan.
24×7 escalation matrix.
CERT-In reporting checklist and incident form.
Data inventory and system map.
Vendor and sub-processor register.
Regulatory-notification matrix.
Cyber-insurance details.
Forensic vendor/counsel contact list.
Media and stakeholder communication protocol.
Evidence-preservation procedure.
Backup and restoration procedure.
Credentials and privileged-access emergency protocol.
Template customer/employee notices.
Board escalation thresholds.
Post-incident corrective-action register.

Common Data Breach Compliance Mistakes

1. Waiting for complete forensic certainty before reporting

CERT-In permits supplementary information. Delay can create a separate compliance problem.

2. Treating every cyber event as an IT helpdesk ticket

Potentially reportable incidents require legal and regulatory triage.

3. Assuming a cloud provider will make every required report

Each entity must assess its own obligations.

4. Destroying evidence during remediation

Reimaging compromised systems without preserving forensic evidence can prevent root-cause analysis.

5. Using an outdated DPDP timeline

The final 2025 Rules and commencement notifications must be read, not draft rules or older articles.

6. Confusing the future 72-hour DPDP detailed report with the present CERT-In six-hour rule

They are separate regimes.

7. Failing to test vendor incident escalation

A contractual right is of little value if no one knows which vendor contact answers at 2 a.m.

8. Making premature public statements

Inaccurate statements can worsen legal and reputational exposure.

Frequently Asked Questions

Is every data breach reportable to CERT-In within six hours?

CERT-In’s directions and FAQs identify specified reportable cyber incidents. Data breaches/data leaks are expressly included in the FAQ’s reportable categories. The organisation should classify the actual incident against the current CERT-In directions rather than applying a blanket assumption to every minor event.

What if all facts are not available within six hours?

CERT-In’s FAQ states that entities may report information available at that time and provide additional information later within reasonable time.

Is the DPDP Act fully in force in August 2026?

No. It has a phased commencement. The core substantive provisions in Sections 3 to 17, including Section 8’s breach-related obligations, are in the eighteen-month tranche scheduled for 13 May 2027.

Is the Data Protection Board already established?

Yes. The Government established the Data Protection Board of India under Section 18, but establishment of the institution does not mean every substantive DPDP duty has already commenced.

Will the DPDP Rules require affected-person notification?

Once the relevant provisions commence, Rule 7 requires affected Data Principals to be informed without delay, with specified information about the breach and protective measures.

What is the future 72-hour DPDP deadline?

Rule 7 provides for initial Board intimation without delay and detailed information within 72 hours of awareness, subject to a longer period if permitted by the Board on written request.

What are the maximum DPDP penalties for security and breach-notification failures?

The statutory Schedule provides maximum penalties extending to ₹250 crore for failure to take reasonable security safeguards and ₹200 crore for failure to comply with the breach-intimation obligation, once the relevant enforcement provisions apply.

Does a vendor breach remove the company’s responsibility?

No. A company should assess CERT-In, contractual, sectoral and future DPDP obligations even where the incident originates with a processor, SaaS provider, cloud service or other vendor.

Should the company inform police?

That depends on the incident. Fraud, unauthorised access, extortion, ransomware, identity theft, insider theft and other criminal conduct may justify or require law-enforcement engagement. CERT-In reporting and criminal reporting are different processes.

2026 Compliance Roadmap for Businesses

Between now and the May 2027 substantive DPDP commencement, organisations should use the transition period to:

map all personal-data systems and vendors;
review current CERT-In reporting compliance;
build a six-hour cyber-incident escalation process;
align security controls to DPDP Rule 6;
build affected-person breach-notification templates;
create a future Data Protection Board reporting workflow;
rewrite processor/vendor incident clauses;
establish breach evidence and log-retention controls;
conduct tabletop exercises;
test backups and disaster recovery;
train senior management and HR/procurement teams;
review cyber insurance;
prepare a regulatory-notification matrix; and
document remediation and board oversight.

Key Takeaways

The most important data-breach rule for an Indian organisation in August 2026 is not a generic “72-hour DPDP rule.” The immediate current requirement is to assess the incident against CERT-In’s operative reporting directions, which can require reporting within six hours.

The DPDP Act is being implemented in phases. The core Data Fiduciary duties—including Section 8 security safeguards and personal-data breach intimation—are scheduled to become operative on 13 May 2027. The 2025 Rules then provide a more detailed future framework: minimum security safeguards, notice to affected individuals without delay, initial Board intimation without delay and a detailed Board update within 72 hours.

Businesses should therefore run two tracks simultaneously: comply with today’s CERT-In and applicable sectoral/contractual requirements, while building the DPDP breach-response architecture before the transition period expires.

Authoritative Sources

Disclaimer

This article is for general legal information and compliance awareness only. It does not constitute legal advice, advertisement or solicitation. Cyber-incident and data-breach obligations depend on the incident, entity, sector, contracts, regulatory status and the law in force on the relevant date.

Fastrack Legal Solutions