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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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.