A 72-Hour Breach Response Plan for a Small Indian App Under DPDP

Under India's Digital Personal Data Protection Act 2023 and the CERT-In Directions issued in April 2022, a personal data breach in a small Indian app can trigger two separate reporting tracks: CERT-In requires a report within six hours of noticing a covered incident, and the DPDP Rules require you to tell the Data Protection Board without delay, followed by a detailed report within 72 hours (once those Rules apply). These are parallel obligations, not sequential ones, and both start from the moment you become aware of the breach.

This article describes what the published legislation and the CERT-In Directions require, as we understand them from publicly available text. It is not legal advice. Your obligations depend on your specific circumstances, the nature of the data involved, and how the applicable rules apply to your organisation. Consult qualified legal counsel for advice on your situation.

Two Timers That Start at the Same Moment

The CERT-In Directions of 28 April 2022, issued under Section 70B of the Information Technology Act 2000, require any service provider, intermediary, data centre, body corporate and Government organisation to report the cyber incidents listed in their Annexure I to CERT-In within 6 hours of noticing them or being brought to notice. That annexure includes data breach and data leak. The report does not need to be complete: CERT-In's FAQ says entities may provide information to the extent available at the time, and report additional information later within a reasonable time.

Under Rule 7 of the DPDP Rules, 2025 (gazetted 13 November 2025), on becoming aware of a breach you must tell the Board without delay (nature, extent, timing, location and likely impact), and within 72 hours, or a longer period the Board allows on a written request, give updated and detailed information, the broad facts and reasons, mitigation measures, any findings on who caused it, remedial steps and a report on the notices sent to affected individuals. The same rule requires notice to each affected person without delay. Under Rule 1(4), Rule 7 comes into force eighteen months after the gazette date of 13 November 2025, which puts it at around 13 May 2027. Failing to notify the Board or affected individuals can attract penalties of up to Rs 200 crore.

The practical consequence of both obligations running in parallel: you cannot spend the first six hours investigating before you report to anyone. You file the CERT-In report with what you know at the time, continue investigating, and use the 72-hour window to prepare the detailed Board report.

Hour 0: Contain First, Then Document

The first action when a breach is discovered is containment - isolating the affected system, rotating credentials, revoking tokens. This is true regardless of the regulatory timeline. You cannot investigate or report accurately if the breach is still active and data is still being accessed.

Revoke or rotate any credentials, API keys, or service account tokens that may have been exposed.
Disable affected database users or restrict network access to the compromised service.
Isolate the affected server or container from the network if the breach is ongoing.
Preserve logs in a separate, write-protected location before any remediation steps change or delete them.
Record the exact time your team became aware of the breach. This timestamp is the start of both compliance clocks.

Hours 1 to 6: The CERT-In Initial Report

The Directions list email (incident@cert-in.org.in) and a phone line for reporting, and CERT-In also publishes an incident reporting form referenced in its FAQ. Expect to give your organisation details, the type of incident, when you first became aware, which systems are affected, and an initial description of the data involved. This first report does not require you to know the full scope. 'Breach of database containing user personal data; investigation ongoing' is an acceptable initial description while you gather more information.

Date and time of discovery (as accurate as possible).
Systems or services affected.
Nature of the incident: unauthorised access, data exfiltration, credential compromise, or other.
Initial estimate of data affected: type of personal data (name, phone, payment, health, etc.) and rough estimate of records affected if known.
Steps taken so far to contain the incident.
Contact name and details for the person handling the incident response.

Hours 6 to 72: Investigating and Preparing the Board Notification

With the CERT-In initial report filed, you have the wider window to investigate and prepare the Data Protection Board notification. The investigation aims to answer four questions: what data was affected and how many individuals, how did the breach occur (root cause), what is the likely impact on the people whose data was taken, and what steps are being taken to prevent recurrence.

If you cannot determine the full scope within 72 hours, do not wait until the picture is complete. Submit what you know within the window and note that the investigation is continuing; Rule 7 also lets you ask the Board in writing for a longer period. Rule 7 does not prescribe a portal or form for the Board intimation (Rule 20 says the Board will function as a digital office), so watch for the channel the Board publishes.

Identity and contact details of your organisation and the person responsible for data protection.
Description of the nature of the breach: categories of data, approximate number of data principals affected.
Likely consequences of the breach for affected individuals.
Measures taken or proposed to address the breach and prevent recurrence.
Whether affected data principals have been or will be notified, and by what means.

Assigning Roles Before a Breach Happens

The worst time to decide who is responsible is when the breach is already active and the six-hour clock is running. A simple three-role structure covers most small app teams.

Incident Lead: makes containment decisions and signs off on external communications to CERT-In and the Board. Usually the founder or CTO. If you are a solo founder, this is you.
Technical Lead: executes containment, preserves logs, and investigates root cause. Document every action in a time-stamped log as you go - this becomes your evidence trail.
Comms Lead: files regulatory reports, handles any required communication to affected users, and keeps internal stakeholders informed. In a small team, this overlaps with the Incident Lead.

The Gaps We See in Small App Stacks

Four preparedness gaps are common in small app stacks: no log retention policy (logs auto-delete after a few days, making it impossible to determine breach scope after the fact; the CERT-In Directions also expect ICT system logs kept for a rolling 180 days), no tested backup (backups exist but have not been verified as restorable), no incident contact list (no one knows who to call at 2am), and no prior contact with a legal adviser about data protection obligations under DPDP.

Fixing the first two is purely technical. Log retention can usually be enabled with a few configuration lines in your database or hosting provider's settings. Backup restore tests should happen at least quarterly - a backup that has not been tested is not a backup you can rely on. For a detailed walkthrough of what to do in the immediate hours after a database is found exposed, see our post on the first 24 hours after a database exposure.

For a broader compliance checklist covering what a DPDP-ready app needs beyond incident response - data minimisation, consent records, processor agreements, and the other obligations that run alongside breach notification - see the DPDP app checklist.

If your app handles personal data of Indian users and you have not worked through what a breach response would look like in practice, it is worth running that exercise before you need it. We offer a launch and rescue review that includes a look at your data architecture and your logging and backup posture against the reporting timelines (this is a technical check, not legal advice). Request a review here.

Common questions

How fast do I have to report a data breach in India?

CERT-In requires a report within six hours of noticing a covered incident, and the DPDP Rules require telling the Data Protection Board without delay, with a detailed report within 72 hours or a longer period the Board allows. Both start when you become aware. This is not legal advice.

What should I do in the first hour of a data breach?

Contain first: revoke or rotate exposed credentials, restrict access to the compromised service, isolate the affected server if the breach is ongoing, preserve logs in a write-protected location, and record the exact time your team became aware.

When should I get my breach readiness checked?

Before you need it, if your app handles personal data of Indian users and you have not worked through a breach response in practice. Zovintra offers a launch and rescue review that checks your data architecture, logging and backups against these timelines. It is a technical check, not legal advice.