Breach response in India: the 6-hour CERT-In and 72-hour DPDP deadlines

When personal data leaks in India, two authorities have deadlines, and both are short. CERT-In expects a report within 6 hours. Under the DPDP Rules, 2025, the Data Protection Board must be told "without delay", and get a detailed report within 72 hours. Affected users must be told without delay too.

Those deadlines are hard to meet if, at hour one, the team is still working out who is in charge, which logs exist and how to find the affected users. This article covers what each deadline requires, an hour-by-hour runbook, what to build before you need it, and how to rehearse it.

Two clocks#

The CERT-In duty already applies to most companies. The directions cover "service providers, intermediaries, data centres, body corporate and Government organisations". The DPDP duties start on 13 May 2027, when Rule 7 comes into force. A runbook built for both now will be ready in time.

What counts as a breach#

The DPDP Act's definition is broad:

That covers far more than an attacker stealing a database. Each of these can be a breach. Treat it as one until you've ruled it out:

• a storage bucket made public by mistake
• someone using a leaked API key to read your support tickets
• an employee exporting user data they shouldn't have
• a breach at one of your vendors
• ransomware
• an accidental deletion you can't restore

Section 8(6) has no size or harm threshold: "In the event of a personal data breach, the Data Fiduciary shall give the Board and each affected Data Principal, intimation of such breach…"

CERT-In's list is wider still. It includes incidents that may not involve personal data at all, such as DDoS attacks, website defacement and phishing. Those still need a 6-hour report.

What each report must contain#

To the Board, without delay (Rule 7(2)(a)): "a description of the breach, including its nature, extent, timing and location of occurrence and the likely impact".

To the Board, within 72 hours (Rule 7(2)(b)), or a longer period if the Board allows it on a written request:

1. updated and detailed information about that description
2. "the broad facts related to the events, circumstances and reasons leading to the breach"
3. measures implemented or proposed to mitigate risk
4. "any findings regarding the person who caused the breach"
5. remedial measures taken to prevent it happening again
6. a report on the notices given to affected users

To each affected user, without delay (Rule 7(1)), "in a concise, clear and plain manner":

1. what happened, including its nature, extent and timing
2. the likely consequences for them
3. what you have done, and are doing, to reduce the risk
4. what they can do to protect themselves
5. contact details of a person who can answer their questions

Write that notice in advance. Here is a skeleton that covers each element:

Subject: Important: a security incident affecting your [Product] account
 
What happened
On [date], we found that [plain description, e.g. "a file of support tickets was
accessed by someone outside our company"]. It included your [data types].
 
What this could mean for you
[Likely consequences, e.g. "You may receive phishing messages that mention your
support requests."]
 
What we have done
[Containment and fixes, e.g. "We revoked the access key, closed the gap that
allowed it, and are reviewing all access from the past 30 days."]
 
What you can do
[Concrete steps, e.g. "Be careful with messages asking for OTPs or payments.
We will never ask for your OTP."]
 
Questions
Contact [name, role] at [email / phone].

Illustrative template. Have your lawyer review the final wording.

The runbook, hour by hour#

Hour 0: declare. Whoever spots the incident declares it, even if they aren't sure. An incident lead takes over, and an incident log starts. The first entry is the time the company became aware, because both clocks run from that moment. CERT-In's directions also require system clocks to be synchronised to the NTP servers of NIC or NPL, or to servers traceable to them. That keeps your timeline defensible.

Hours 0–2: contain, and preserve evidence. Revoke the leaked key, close public access, disable the compromised account. Before anyone rebuilds or deletes anything, take snapshots of the affected resources and copies of the relevant logs. If you wipe a server first, you lose the facts the 72-hour report asks for.

Hours 0–4: scope. Answer four questions:

• Which systems were affected?
• Which data types were involved?
• Which time window does it cover?
• Which people were affected?

If you aren't sure whether personal data was involved, assume it was while you draft. It is easier to withdraw a draft than to write one at hour 5.

By hour 6: report to CERT-In. Send what you know, mark what you don't, and say when you will update. CERT-In takes reports at incident@cert-in.org.in and publishes its reporting formats on its website. The directions also require you to name a point of contact for CERT-In, so do that before an incident, not during one.

Without delay: the Board and affected users. Send the Board the initial description. Notify users as soon as you can tell them what happened and what to do. Use their account or the contact details they registered with you.

By hour 72: the detailed Board report. Cover the six items listed above. If you can't, ask the Board in writing for more time before the deadline passes.

Afterwards: fix the root cause, hold a blameless review, and update this runbook with whatever slowed you down.

Agree in advance who decides whether an incident is reportable, and keep your lawyer in that loop. Get the templates reviewed now, not during the incident.

What to build before you need it#

Access logs that answer "who read what"

Rule 6(1)(c) asks for "visibility on the accessing of such personal data, through appropriate logs, monitoring and review, for enabling detection of unauthorised access, its investigation and remediation…". Application logs alone rarely answer the 72-hour questions. You need records of access to the data itself:

• Database audit logs, such as pgaudit for PostgreSQL.
• Storage access logs. In AWS, reading an object from S3 is a CloudTrail data event, and data events aren't logged by default. If they're off for buckets that hold personal data, you can't say what was downloaded.
• Audit trails in your own tools, recording who viewed or exported which user's record in admin panels and support tools.
• Audit logs from SaaS tools that hold personal data.

How long to keep them: Rule 6(1)(e) asks for one year. CERT-In asks for logs of all ICT systems for a rolling 180 days, "maintained within the Indian jurisdiction". Keep personal data out of the logs themselves where you can, and log internal user IDs instead.

A fast way from "this was exposed" to "these people"

Given an exposed table, bucket, export or API key, can you list the affected users and how to reach them within an hour? That needs:

• a data map that says what each table, bucket and vendor holds
• prepared queries for your most sensitive stores
• each user's registered contact channel, since Rule 7(1) says to notify them through it

Alerts on the signals that matter

Start with these:

• storage made public
• bulk exports from admin tools
• unusual read volumes from one identity
• new access keys or admin accounts
• admin logins from unfamiliar locations
• secrets pushed to public repositories

In AWS, an EventBridge rule can flag the changes that could make a bucket public: bucket policies, ACLs and Block Public Access settings, at bucket and account level. It needs a CloudTrail trail that logs management events:

{
  "source": ["aws.s3"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventName": [
      "PutBucketPolicy",
      "DeleteBucketPolicy",
      "PutBucketAcl",
      "PutBucketPublicAccessBlock",
      "DeleteBucketPublicAccessBlock",
      "PutAccountPublicAccessBlock",
      "DeleteAccountPublicAccessBlock"
    ]
  }
}

Most matches will be routine changes, so route them to a channel someone reviews, and page on-call only for the riskiest, such as removing Block Public Access.

Vendor notification terms

A breach at a processor is your breach. Section 8(1) makes you responsible for processing done on your behalf, and Rule 6(1)(f) expects your contracts to require safeguards. CERT-In's 6 hours can start when you are "brought to notice" of an incident, so you need vendors to tell you quickly. Check that your contracts with your main processors say how fast they must notify you, and through which channel.

Rehearse it: a breach drill#

A runbook nobody has used fails in predictable places. A two-hour drill shows you where. Pick a realistic scenario, start a timer, and work through it with your actual on-call team, tools and logs.

Scenario: An API key for your support desk was committed to a public GitHub repository. The vendor's audit log shows someone used it two days ago to export tickets.

Track:

• the time to declare
• the time to name the affected users
• the time to a first CERT-In draft
• every question you couldn't answer

The output looks like this:

Illustrative drill results, not from a client.

Every gap in that table is something to fix this quarter. Rerun the drill after you fix them.

Sources#

• The Digital Personal Data Protection Act, 2023, sections 2(u), 8(1), 8(5) and 8(6) (MeitY)
• The Digital Personal Data Protection Rules, 2025, Rules 1, 6 and 7 (MeitY)
• CERT-In Directions under section 70B(6) of the IT Act, 28 April 2022, including Annexure I (CERT-In)