What exactly has to be reported, and when?

On becoming aware of a personal data breach you inform the Data Protection Board without delay, describing the nature, extent, timing and location of the breach and its likely impact, and you inform affected data principals without delay as well. Within seventy two hours you give the Board an updated account covering the circumstances that led to the breach, the remedial and mitigation measures you have implemented, and your findings on who caused it. The Board can allow longer for that second submission if you make a written request. The clock runs from awareness, which is why defining what constitutes becoming aware is the first thing we write down.

Is there a threshold below which we do not have to report?

The DPDP framework does not give you a volume threshold or a harm test to hide behind in the way some regimes do, so the working assumption should be that a personal data breach is notifiable. That is a materially stricter posture than many teams expect, particularly those who have worked with regimes where a risk assessment can conclude that notification is unnecessary. Whether a particular incident meets the definition is a determination for your counsel on the facts, and our job is to make sure you can produce those facts quickly enough for them to make it inside the window.

How is this different from CERT-In reporting?

They are separate obligations with separate triggers, recipients and clocks. CERT-In directions require reporting specified cyber incidents within six hours of noticing them, whether or not personal data is involved, and carry their own requirements for one hundred and eighty days of logs held within Indian jurisdiction and time synchronisation to NPL or NIC. DPDP concerns personal data breaches specifically, is reported to the Data Protection Board and to affected individuals, and expects at least a year of logs under Rule 6. A ransomware incident that encrypts a customer database plausibly triggers both, on different clocks, and the six hour one binds first. That is why we build a routing decision tree rather than a single generic notification step.

Our incident response plan already covers ransomware. Is that enough?

Almost certainly not, because it is answering a different question. An IT incident response plan optimises for restoring service and measures itself on time to recovery. A personal data breach response optimises for accurate notification within a statutory window and measures itself on whether the account you gave the regulator was complete and timely. The two even conflict at one point: the instinct to rebuild a compromised system immediately is right for recovery and destroys the forensic evidence you need to answer the Board question about causation. We usually keep the existing plan and add the personal data track alongside it, with an explicit handoff between them.

How long does it take to become ready?

The plan itself, the decision tree, the templates, the roles and the tabletop, is typically a few weeks of work. The constraint is usually the logging assessment that precedes it. If your retention is at default, commonly ninety days or less, then extending it is a quick configuration change but it only produces a year of history after a year has passed. So you can have a credible plan quickly and full investigative capability considerably later, which is an argument for starting the retention change now regardless of when you do the rest.

What does the tabletop exercise actually involve?

A realistic scenario for your estate, run in a room with the actual people who would respond, against the real clock. We inject information progressively the way it arrives in a real incident, incomplete and sometimes wrong, and the team works the process. It typically takes half a day. The recurring findings are the same across almost every organisation we run it for: uncertainty about who has authority to declare, legal not reachable at the hour the scenario starts, the data map not detailed enough to scope inside the window, and no agreed position on what to tell customers before the regulator has responded. We write those up plainly and fix the plan.

Do we have to tell affected individuals even if we contained it quickly?

The Rules require informing affected data principals without delay on becoming aware, and they do not offer a containment exemption in the way you might hope. Fast containment is highly relevant to the remedial and mitigation measures you report to the Board, and it is relevant to the likely impact you describe, but it is not by itself a reason to skip telling people. Whether a specific incident meets the definition is your counsel call. What we would caution against is a plan that quietly assumes quick containment means no notification, because that assumption tends to be made under pressure by people who are not the ones who will have to defend it.

What if we cannot complete the investigation in seventy two hours?

The Rules anticipate this: the Board may allow a longer period for the detailed submission if you make a written request. The important distinction is between requesting an extension and missing the deadline. An extension requested in good time, with an explanation of why the investigation is still open and what you have established so far, is a normal part of handling a complex incident. Silence at the seventy two hour mark is not. We build the extension request into the templates so it is a decision the team makes deliberately rather than a deadline that passes unnoticed.

Who should hold the authority to declare a breach?

Somebody senior enough that the declaration is not second-guessed, and available outside office hours, with a named deputy for when they are not. In most organisations it is whoever holds IT or information security accountability, and where a Data Protection Officer has been appointed it is usually them. What does not work is requiring a committee or an executive who is unreachable at night, because the clock runs from awareness rather than from when the right person finally saw the message. We also write down explicitly what constitutes becoming aware, so the organisation is not later reconstructing that from memory.

What if the breach happened at one of our vendors?

If they were processing personal data on your behalf, it is still your notifiable breach. You remain the data fiduciary, the obligation to inform the Data Protection Board and affected individuals sits with you, and the seventy two hour clock runs from when you became aware. That makes your dependency on the vendor acute, because you cannot describe the nature and extent of a breach in systems you do not operate without their cooperation, and cooperation under pressure is a function of what the contract says and what relationship exists. This is why we review processor contracts as part of the engagement, looking specifically for a notification obligation on them with a deadline shorter than yours, a duty to assist with your regulatory reporting, and a named contact. Contracts that say the vendor will notify you promptly are not much help at hour sixty.

Do we still have to notify if the data was encrypted?

Do not assume encryption is an exemption, because the DPDP framework does not offer the explicit safe harbour that some other regimes do. Encryption is highly relevant and it is not automatically decisive. It goes to the likely impact you describe in the notification and to the remedial measures you report, and strong encryption with keys that were not also compromised makes a materially weaker case for harm. But the determination of whether a particular incident is notifiable is one for your counsel on the facts, and the honest engineering question underneath it is usually whether the data was encrypted in a way that actually helps. Data encrypted at rest on a disk is no protection at all against an attacker who obtained valid credentials and queried the application normally, which is how most of these incidents actually happen.

Can you do this remotely? We are not in Hyderabad.

Yes. The logging assessment, the decision tree, the templates and the role definitions are all delivered remotely. The tabletop exercise works well over video and we run most of them that way, though it is somewhat better in a room if your responders are already in one place, and we will travel for it where that is the case. We are based in Gachibowli, Hyderabad and work with organisations across India. Initial enquiries get a reply within 4 business hours.

Breach response, India

Seventy two hours is not enough time to build a process. It is barely enough to run one.

Under the DPDP Rules you inform the Data Protection Board without delay on becoming aware of a personal data breach, tell affected individuals without delay, and give the Board a detailed account within seventy two hours covering how it happened, what you did about it and who caused it. Most incident response plans in Indian businesses were written with ransomware and downtime in mind and say nothing about personal data, notification or regulators. This is the plan that covers the part with a clock on it.

Book a breach readiness review See the seventy two hour sequence

Data breach response planning and notification readiness for Indian businesses

Without delayInitial Board notification
72 hoursDetailed report to the Board
6 hoursCERT-In, where it also applies
TestedTabletop before you need it

What a compliant response requires

Seven capabilities, each of which has to exist before the incident.

Breach response fails in predictable places, and none of them are the technical containment. It fails on who is allowed to declare, on how fast scope can be established, and on whether anybody knows which regulator to tell. These are the capabilities we build and test.

A declaration trigger with a named owner

Somebody has to be able to say this is a personal data breach and start the clock, and that authority has to be named in advance and available outside office hours. The common failure is that awareness is diffuse: an engineer notices something odd on a Friday, mentions it Monday, and the organisation later has to explain when it became aware. We define the trigger, name primary and deputy holders of the authority, and write down what constitutes becoming aware.

Scoping that runs in hours, not days

The Board notification requires the nature, extent, timing and location of the breach and its likely impact, which means knowing what personal data the affected system held, roughly how many individuals, whether any of it was sensitive or related to children, and which processors also received it. Without a field-level data map that is a multi-day investigation. With one it is an hour. This is the single strongest argument for doing data mapping first.

A routing decision tree for the regulators

A single incident can be a personal data breach under DPDP, a reportable cyber incident under CERT-In directions, and a sectoral reporting obligation under RBI or SEBI or IRDAI rules, on three different clocks to three different recipients. A generic plan that says notify the authorities is useless at three in the morning. We build a decision tree that takes incident characteristics and outputs who is told, by when, by whom and in what format.

Pre-drafted notifications

The Board notification, the follow-up detailed report, and the communication to affected data principals all get drafted in advance as templates with the variable parts marked. Writing regulator-facing text under time pressure produces either dangerous over-commitment or uselessly vague language. Templates reviewed by your counsel in calm conditions solve both, and cut hours off the clock.

Logs that go back far enough to investigate

Rule 6 requires logs and associated traffic data retained for at least one year to support detection, investigation and remediation. Default retention in most tenants and most appliances is considerably shorter, often ninety days. Investigating an intrusion that began outside your retention window means you cannot establish timing or extent, which are both required content in the notification. Extending retention is quick to configure and slow to bear fruit, since it only evidences a year after a year has passed.

A team that has actually done it once

The first time a group runs a breach response should not be during a breach. A tabletop exercise against the seventy two hour clock reliably exposes the same gaps: nobody knows who declares, legal is not reachable, the data map is not detailed enough to scope, and nobody has considered what to tell customers before the regulator has responded. Finding those in a room is inexpensive. Finding them live is not.

Evidence preservation that survives the response

The detailed report has to include findings on the circumstances and on who caused the breach, which requires evidence that still exists. The instinct under pressure is to rebuild the affected system immediately, which destroys the forensic record. The plan has to state explicitly what gets preserved and in what order, so containment does not eliminate the ability to answer the Board question about causation.

A path to tell affected individuals

Affected data principals are informed without delay, which means you need a way to reach them that does not depend on the compromised system. If your only channel to customers is the platform that was breached, you have a problem worth solving before it arises. This also intersects with consent, since a breach notification is not marketing and goes to everyone affected regardless of their marketing preferences.

The clock

What happens in the first seventy two hours.

This is the sequence we build and rehearse. The times are targets rather than statutory sub-deadlines, chosen so the statutory obligations are met with margin rather than exactly on the line.

01
Hour 0· On becoming aware
Declare and start the clock
The named authority declares a personal data breach. The clock starts at awareness, not at confirmation, and the time of awareness is recorded because you will need to evidence it. Response team convened, evidence preservation instruction issued before any containment work begins.
- Declaration logged with the time of awareness
- Response team convened, roles assigned
- Evidence preservation instruction issued
02
Hours 1 to 6· The tightest window
Scope, contain, and meet the shortest clock
Scope established from the data map: what personal data, roughly how many individuals, sensitivity, children involved, processors affected. Containment proceeds without destroying evidence. Where the incident is also a reportable cyber incident, the CERT-In six hour clock is the binding constraint and is met inside this window.
- Categories and approximate volume of affected personal data
- Containment actions taken and recorded
- CERT-In notification where the incident is reportable
03
Hours 6 to 24· Without delay
Notify the Board and affected individuals
Initial notification to the Data Protection Board covering the nature, extent, timing and location of the breach and its likely impact. Affected data principals informed without delay, through a channel independent of the compromised system. Sectoral regulators notified where separate obligations apply.
- Board notification submitted and acknowledged
- Data principal communication issued
- Sectoral notifications where applicable
04
Hours 24 to 72· Statutory deadline
Investigate and file the detailed report
The updated account to the Board: the circumstances that led to the breach, the remedial and mitigation measures implemented, and findings on who caused it. Where the investigation genuinely cannot conclude in time, a written request for an extension is made rather than the deadline being missed silently.
- Detailed report filed with the Board inside seventy two hours
- Remedial and mitigation measures documented
- Written extension request where genuinely required

How we build it

A plan that works at three in the morning.

We rehearse it, we do not just write it

Every engagement ends in a tabletop exercise against the clock with the actual people who would respond, including whoever holds the declaration authority and somebody from legal. A plan nobody has executed is a document. The exercise reliably surfaces gaps that reading the plan does not, and it is the part clients tell us afterwards was worth the engagement on its own.

We connect it to your data map

Scoping is the step that determines whether seventy two hours is comfortable or impossible, and scoping runs off the data map. Where you have one we wire the plan to it. Where you do not, we are direct that breach response will be slow until you do, and we scope the minimum discovery needed to make notification achievable.

We fix the logging before we write the plan

A plan that assumes investigative capability you do not have is worse than no plan. We check retention across the tenant, the network estate and the applications first, extend it where it falls short of the one year Rule 6 expects, and centralise where logs are scattered. This has a lead time, which is why it goes first rather than last.

We build it with your counsel in the room

Notification text carries legal weight and the decision to notify is not purely technical. We draft the templates and the decision tree, and we do it alongside your legal advisers rather than handing them a finished document to approve. We are engineers, not lawyers, and the boundary is explicit throughout.

Where the clock bites hardest

Sectors with compounding obligations.

BFSI and fintech

Three regimes at once: DPDP, CERT-In, and sectoral reporting to RBI, SEBI or IRDAI depending on the entity. The routing decision tree earns its keep here more than anywhere, because getting it wrong means either missing a mandatory notification or over-reporting to a regulator that did not need to know.

Healthcare and diagnostics

High-sensitivity data, so the likely impact assessment in the notification is more serious and the duty to inform individuals is more consequential. Shared counter accounts also make attribution hard, which directly undermines the findings on causation the detailed report requires.

Retail and consumer

Very large numbers of affected individuals, which turns the notification to data principals into a logistics problem. The channel question matters most here, because reaching several hundred thousand people quickly without using the breached platform requires planning.

SaaS and platforms

Frequently the processor rather than the fiduciary, so the obligation runs through your customers and your contracts define what you owe them and how fast. Customer notification clocks in enterprise contracts are often tighter than the statutory ones.

Manufacturing and logistics

Operational technology sitting outside IT monitoring, so detection is the weak link rather than notification. Biometric attendance appliances and shop-floor systems frequently produce no usable logs at all, which makes establishing timing and extent very difficult.

Education

Children data, which raises the sensitivity of the impact assessment and means notification reaches guardians rather than the data principals directly. Worth resolving in the plan rather than during the incident.

The first hour

What has to happen before anybody starts fixing anything.

The instinct in the first hour is to make the problem go away, and that instinct destroys the evidence you will need to answer the Board and skips the decisions that start the clocks correctly. This is the sequence we put on a single card that lives somewhere reachable when the primary systems are not.

Establish and record

Record the time awareness began, and who became aware
The statutory clock runs from here, and you will be asked
Declare, using the named authority or the deputy
Not a committee, and not the following morning
Open a single written log for the incident
Every decision and its time. This becomes the detailed report
Issue the evidence preservation instruction
Before containment, because rebuilding destroys the record

Scope before you notify

Identify the affected systems and pull their entries from the data map
This is why the map exists
Establish categories of personal data and approximate volume
Required content in the Board notification
Flag whether sensitive data or children data is involved
It changes the likely impact assessment
List processors that also hold the affected data
They may have their own obligations and may need telling

Route correctly

Run the decision tree, do not improvise the notification list
DPDP, CERT-In and sectoral rules are separate obligations
Check whether the CERT-In six hour clock applies
Where it does, it binds before the DPDP clock
Bring counsel in before any external communication goes out
Notification text carries legal weight
Confirm your channel to affected individuals is not the breached system
Worth knowing the answer in advance

The plan you probably have

IT incident response against personal data breach response.

Most organisations have a plan. It was written for availability incidents and it does not cover the obligations that carry deadlines. These are different documents serving different purposes, and the second one is usually missing.

Feature	Aspect	Typical IT incident response plan
Primary goal	Restore service	Meet notification obligations and limit harm to individuals
Success measure	Time to recovery	Time to accurate notification, and completeness of the account
First instinct	Rebuild the affected system immediately	Preserve evidence, then contain
Key input	System inventory and backups	Field-level data map, to establish what was exposed and whose
External parties	Vendors and support contracts	Data Protection Board, CERT-In, sectoral regulators, affected individuals
Legal involvement	Rarely, and usually after the fact	From declaration, because notifications carry legal weight
Communications	Internal status updates	Regulator-facing text and direct notice to affected individuals
Clock	Business tolerance for downtime	Statutory, and running from awareness

The routing question

DPDP and CERT-In are different obligations on different clocks.

The most common planning error we see is treating these as one requirement. An incident can trigger either, both or neither, and the plan has to route correctly under pressure rather than defaulting to telling everybody or telling nobody.

	Dimension	DPDP Rules
What triggers it	A personal data breach, meaning unauthorised processing, disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data	A cyber incident of a specified type, whether or not personal data is involved
Who you tell	The Data Protection Board, and affected data principals	CERT-In
How fast	Board and individuals without delay, detailed report inside seventy two hours	Within six hours of noticing or being notified
Log retention it assumes	At least one year under Rule 6, to support detection, investigation and remediation	One hundred and eighty days, maintained within Indian jurisdiction
Individuals notified	Yes, affected data principals without delay	Not a CERT-In requirement
Can one incident trigger both	Yes, frequently	Yes, and the six hour clock binds first

The engagement

Four stages to a tested plan.

1
Assess detection and investigative capability
Log retention across the tenant, network, endpoints and applications measured against the one year Rule 6 expects. Alerting reviewed for whether a personal data breach would actually be noticed rather than only a service outage. Gaps in evidence preservation identified. This determines whether the clock is achievable at all.
2
Build the decision tree and the notification templates
The routing logic that takes incident characteristics and produces who is notified, by when and in what form, covering DPDP, CERT-In and any sectoral obligations that apply to you. Board notification, detailed report and data principal communication drafted as templates and reviewed by your counsel.
3
Define roles, authority and escalation
Who declares, who deputises when they are unreachable, who owns scoping, who owns the regulator relationship, who owns customer communication, and how each is contacted outside working hours. Written down, distributed, and stored somewhere reachable when the primary systems are not.
4
Run the tabletop, then set a review cadence
A realistic scenario run against the clock with the real responders. Findings written up honestly, the plan corrected, and a rehearsal cadence agreed, normally annually or on significant change. Plans decay as people move roles, so the review is the part that keeps it real.

Questions we get asked

Breach response under DPDP, answered plainly.

What sits either side of this.

DPDP Act compliance

The full obligation set and the phased timeline, and where breach reporting sits among the other six duties.

Learn more

DPDP data mapping

The field-level record that turns breach scoping from a multi-day investigation into an hour, which is what makes the clock achievable.

Learn more

Microsoft Sentinel

Cloud-native SIEM and SOAR for the detection and log retention half of the problem, for estates already on the Microsoft stack.

Learn more

Next step

Find out whether seventy two hours is achievable for you.

The honest test is not whether you have a plan. It is whether you could establish what personal data was exposed, and whose, in time to tell the Board accurately. A readiness review answers that, and the tabletop proves it. Remote-first from Hyderabad, serving all of India.

Book a breach readiness review See the full DPDP obligation set

Related Services

Explore more solutions that work great with this service

Seventy two hours is not enough time to build a process. It is barely enough to run one.

Seven capabilities, each of which has to exist before the incident.

A declaration trigger with a named owner

Scoping that runs in hours, not days

A routing decision tree for the regulators

Pre-drafted notifications

Logs that go back far enough to investigate

A team that has actually done it once

Evidence preservation that survives the response

A path to tell affected individuals

What happens in the first seventy two hours.

Declare and start the clock

Scope, contain, and meet the shortest clock

Notify the Board and affected individuals

Investigate and file the detailed report

A plan that works at three in the morning.

We rehearse it, we do not just write it

We connect it to your data map

We fix the logging before we write the plan

We build it with your counsel in the room

Sectors with compounding obligations.

BFSI and fintech

Healthcare and diagnostics

Retail and consumer

SaaS and platforms

Manufacturing and logistics

Education

What has to happen before anybody starts fixing anything.

Establish and record

Scope before you notify

Route correctly

IT incident response against personal data breach response.

DPDP and CERT-In are different obligations on different clocks.

Four stages to a tested plan.

Assess detection and investigative capability

Build the decision tree and the notification templates

Define roles, authority and escalation

Run the tabletop, then set a review cadence

Breach response under DPDP, answered plainly.

What exactly has to be reported, and when?

Is there a threshold below which we do not have to report?

How is this different from CERT-In reporting?

Our incident response plan already covers ransomware. Is that enough?

How long does it take to become ready?

What does the tabletop exercise actually involve?

Do we have to tell affected individuals even if we contained it quickly?

What if we cannot complete the investigation in seventy two hours?

Who should hold the authority to declare a breach?

What if the breach happened at one of our vendors?

Do we still have to notify if the data was encrypted?

Can you do this remotely? We are not in Hyderabad.

What sits either side of this.

DPDP Act compliance

DPDP data mapping

Microsoft Sentinel

Find out whether seventy two hours is achievable for you.

Related Services

DPDP Act Compliance

DPDP Data Mapping

Consent Architecture

Microsoft Sentinel