The 72-hour breach clock — what it actually demands of you

There is a moment, in almost every conversation I have with an Indian privacy team, when someone says "well, we have an incident response process — that should cover it." It usually comes up about ninety seconds into a discussion about Section 8(6). And it is usually wrong.

A general incident response process — the kind built by a security team for handling outages and intrusions — is not a breach-notification process. They share vocabulary, they share some inputs, and they share a control room. But the timelines are different, the legal triggers are different, the artefacts produced are different, and most importantly, the decision rationale a privacy operation has to produce is something a security operation almost never produces.

This post is about what the 72-hour clock actually demands, why most teams will miss it on their first real incident, and what to build in advance so they don't.

Reading the clock literally

Section 8(6) of the Act requires the Data Fiduciary to notify the Data Protection Board and the affected Data Principals of a personal-data breach. The 2025 Rules pin the Board notification at 72 hours from the moment the Fiduciary becomes aware of the breach.

Three words in that sentence do a lot of work.

Personal-data breach. Not every security incident is a notifiable breach. A failed login from an unknown IP that was correctly blocked is an incident; it is not a breach. A ransomware encryption of an HR database that contains personal data of every employee is a breach. The decision boundary between the two is something the privacy team has to make — and evidence — within the window. The Board, on a later inspection, will ask for the decision rationale. "We didn't think it was notifiable" is not a rationale; it is a guess. You need a documented impact analysis that distinguishes a security incident from a notifiable breach, with the criteria, the facts considered, and the named decision-maker.

Aware. The clock starts at awareness, not at confirmation or containment. Awareness is, in practice, the moment any one of: the SOC analyst, the on-call engineer, the third-party SIEM, the vendor's notification, or a customer complaint, brings the relevant facts to a privacy-team-aware channel. If the SOC notices something at 11 pm Saturday and forwards the alert to the privacy lead on Monday morning, the clock did not start Monday morning. It started Saturday night.

This is the part most teams get badly wrong. A 72-hour clock that starts on detection of an anomaly leaves you 72 hours. A 72-hour clock that started 36 hours ago at the alert that nobody escalated leaves you 36. Knowing which kind of clock you're on is itself a competency that has to be built.

72 hours. This is 4,320 minutes, of which a meaningful number are weekend hours, sleep hours, and travel hours. The actual usable working time inside the window — if you start counting from a real incident timeline — is much less than people imagine.

What "ready for the clock" requires in practice

When I trace what an incident actually goes through inside a Fiduciary that's prepared, the steps look like this. Almost every step is a handoff between teams, and almost every step is where most organisations fail.

Step 1 — Awareness capture. The moment an indicator that could be a personal-data breach reaches anyone in the organisation — SOC, on-call, customer support, a vendor, an automated SIEM rule, a DLP alert — that fact gets logged into a breach intake, with the time of awareness as a non-editable field. This is the artefact the clock is measured against later. If awareness isn't captured cleanly, nothing downstream is defensible.

Step 2 — Triage and scoping. Inside the first six to twelve hours, the privacy team works with the security team to scope the incident. What systems are involved? What categories of personal data are in those systems? How many Data Principals are potentially affected? What was the cause? Is the situation contained? This is the part that looks most like classic IR — but the questions are different. A security team asks "are we still bleeding?" A privacy team asks "how many Data Principals are within the impact set?"

Step 3 — Notifiability decision. Inside the first 24 hours, the privacy team makes a documented decision: is this a notifiable personal-data breach under Section 8(6)? The decision has to be evidenced. The criteria — the categories of data, the likelihood of harm, the scale, the containment status — have to be written down, and named decision-maker has to own it. The Board, on a later inspection, will read this document. It needs to make sense.

Step 4 — Notification drafting. The notification to the Board has to contain at least: the nature of the breach, the categories and approximate number of Data Principals affected, the likely consequences, the measures taken or proposed, and the name and contact of the DPO. The notification to affected Data Principals has to be in language they can understand, in their language, and offer them practical steps to mitigate harm. Drafting all of this in 48 hours, while the incident is still unfolding, is not something you can improvise. You need pre-built templates with the mandatory elements already in place, in the languages your customer base speaks, with the legal team having pre-approved the structure. The first incident is not the time to discover that translation takes two days.

Step 5 — Channel preparation. The 2025 Rules specify the channels for Board notification. Affected-Principal notification can be by email, SMS, app push, post, or a combination, depending on the data you hold. The mechanics of mass-notification — verifying you have a current contact channel for every affected person, throttling so you don't get marked as spam by every major mailbox provider, capturing delivery receipts as evidence — is engineering work that has to be done in advance.

Step 6 — Send and evidence. The notifications go out. Every notification — to the Board, to every Data Principal — has to be captured with the timestamp, the channel, the content, and the delivery status. This becomes part of the breach incident file that the Board may later ask to inspect.

Step 7 — Post-incident remediation. The Act requires the Fiduciary to take remedial steps. These have to be tracked as named actions with owners and deadlines, and the closure of each one has to be evidenced. The Board's interest in a breach does not end at notification; it continues into how the Fiduciary responded.

This is seven discrete steps with six handoffs. Each handoff is a place where an organisation that "has an incident response process" can lose a day.

The seven handoffs where teams almost always fail

If you walk through real breach drills inside Indian organisations, the same handoffs go wrong every time. Each of these is worth pre-rehearsing.

Handoff 1 — SOC to privacy team. SOC sees an indicator, classifies it as a security ticket, routes it through the security queue. Privacy team finds out a day later. Solution: every alert that touches a database, file store, or pipeline containing personal data has an automatic privacy-team copy from the SIEM/DLP layer, not a manual one.

Handoff 2 — Privacy team to legal. Privacy team makes the notifiability decision but doesn't loop legal in until the decision is made. Legal then re-litigates the decision and costs you 12 hours. Solution: the notifiability decision is made jointly, with named legal counsel as a co-signer, from the start.

Handoff 3 — Privacy team to communications. Privacy team drafts the Board notification but doesn't share the drafted Principal-facing notification with comms until it's nearly done. Comms then needs to translate, vet for tone, and clear it with brand and exec — and that takes another day. Solution: pre-approved templates with comms as a standing pre-clearance.

Handoff 4 — Comms to engineering. Comms hands a Principal-facing notification to engineering and asks them to "send it to all affected users." Engineering then discovers that the affected-user list takes hours to compile from three different systems and that they don't have a verified contact channel for 18% of them. Solution: pre-built audience-extraction queries and pre-tested mass-notification infrastructure.

Handoff 5 — Engineering to operations. The notification is sent, but no one captures the delivery evidence — the timestamps, the bounce rates, the read receipts where available. When the Board asks "show me you actually notified the Principals," the operations team has no audit trail. Solution: notification infrastructure that captures evidence automatically as a first-class artefact.

Handoff 6 — Operations back to privacy. Post-incident, the privacy team is supposed to track remediation and report progress. Operations starts the work, doesn't update privacy, and three weeks later the privacy team has to chase status updates manually. Solution: a closed-loop tracker where remediation actions, owners, and statuses live in the same artefact as the breach incident itself.

Handoff 7 — Privacy team to board (the company's board, not the DPB). The CEO finds out about the breach from a customer complaint or from the press. The internal-board update arrives a day later. The breach is real, the privacy team handled it well, but the optics are catastrophic and the board now distrusts the privacy team. Solution: an exec-notification chain that fires at the same time as the privacy intake, with confidentiality controls built in.

A test for whether you're ready

There is a single drill that, in my experience, separates organisations that are actually ready from organisations that believe they're ready.

Pick a date. Tell the privacy team, the security team, and the legal team that at 11:47 pm on that date, a SOC analyst will surface a synthetic incident — a credible scenario, no actual data involved — and the clock starts. Run the full process: scoping, notifiability decision, drafting, channel preparation, send, evidence capture, remediation. At hour 72, the executive sponsor asks for the full breach incident file as it would be presented to the Board.

Organisations that pass this drill are organisations that have done the work to be ready. Organisations that don't pass it discover the gaps in exactly the places I described above. Either way, the drill is the single most useful investment you can make in the next six months. It costs almost nothing. The first time you do it is humbling. The third time, you have an operation.

The 72-hour clock is enforceable. The 2025 Rules have made it specific. The Board's first major enforcement actions are very likely to be drawn from breaches that were either notified late or not notified at all. The Fiduciaries that aren't ready will explain that "we have an incident response process" and "we didn't realise it was notifiable" and "the SOC didn't escalate it in time." Those are not defences. Those are the precise failure modes the Act was written to penalise.

The runway is short. Use it.