The eleventh day: when your processor's logs move the awareness date

01 · What the rule actually measures from

Rule 7 of the DPDP Rules 2025 gives a Data Fiduciary two duties on a personal data breach: intimate the Data Protection Board and the affected data principals without delay, then file a detailed report within 72h. If the incident is also a reportable cyber incident, the CERT-In Directions of 2022 want a report within 6h of noticing it.

Every one of those clocks starts at the same place. Not at the intrusion, not at containment, not at the point your forensic partner delivers a report. They start when the organisation became aware that a breach involving personal data had occurred.

Which means the single most consequential number in your entire response is a date you choose, under pressure, on incomplete information — and that someone else may later reconstruct from your own systems.

02 · What happened, in order

The pattern below is composited from engagements we have run and is the scenario we model in Fortis Drill #01. A mid-size consumer lender, a KYC document store operated by a processor, and a timeline that looks clean until day fourteen.

1. 02 JUN · 21:14

   The processor misconfigures a storage bucket during a routine migration. No alert fires on either side.

2. 11 JUN · 07:02

   A support agent receives a customer email attaching a stranger's Aadhaar image. She logs a ticket, tags it document-mismatch, and moves on. Nobody escalates it.

3. 13 JUN · 06:40 · AWARENESS AS FILED

   A journalist emails the CISO with a working link to the bucket. Incident declared within the hour. Every clock is set from this timestamp.

4. 13 JUN · 11:20 · 04h 40m ELAPSED

   CERT-In initial report filed, inside the 6h window, on ranges rather than exact figures. Board intimation follows at 15:10, principal notification begins that evening.

5. 14 JUN · 18:30 · THE PROBLEM ARRIVES

   Processor access logs land. First unauthorised access is dated 02 Jun. In the same review, someone finds the 11 June ticket.

The 02 June date is uncomfortable but not fatal — an intrusion nobody detected is not awareness. The 11 June ticket is the actual problem, because on that date an employee of the organisation held evidence that personal data had been disclosed to the wrong person.

03 · Two dates, and the argument between them

If awareness was 13 June, every filing was inside its window. If awareness was 11 June, the CERT-In report was roughly 48h late and the Board intimation was late too — and lateness on notification carries its own penalty entry, separate from whatever the security failure attracts.

The honest position is usually somewhere the organisation does not enjoy. A single mismatched document in a support queue is a data point, not a determination that a breach has occurred. But a competent investigator will ask what a reasonable organisation should have done with it, and the answer to that is not “close it in twelve minutes and tag it document-mismatch”.

What turns a defensible judgement into an indefensible one is almost never the date itself. It is the absence of a record showing that the date was considered, or worse, a revision made after the fact with no basis stated.

We have seen organisations quietly restate awareness in the detailed report to match their filings. That converts a possible late-notification finding into an argument about candour, in front of the same Board.

04 · What to file when the dates disagree

The Rule 7(2) detailed report is the right place to deal with this, and it is due within 72h of awareness. Four things belong in it.

1. The earlier signal, disclosed by you. Describe the 11 June ticket, what it contained, and how it was handled. Finding it yourself is worth a great deal; having it found for you is worth nothing.
2. Your awareness determination and its basis. State the date you have used, in one paragraph, with the reason. If your position is that a single ticket did not constitute organisational awareness, say so plainly rather than leaving it implied.
3. The intrusion timeline separately. First unauthorised access on 02 June is a fact about the incident, not about your knowledge. Keep the two timelines visually distinct in the report so they cannot be conflated.
4. The control change, already made. Not planned — made. A triage rule that escalates any wrong-customer-document report to the privacy function within one hour, with the date it went live.

05 · The work that has to happen before any of this

Every choice above is easier if three things already exist, and all three are cheap compared with the argument they prevent.

First, a triage rule that names the signals which escalate on sight — wrong-customer documents, credentials in a public repository, a data subject reporting someone else's information. Second, a processor contract that obliges notification to you inside a window shorter than your own, because your clock does not pause while they investigate. Third, a written awareness determination step in the response plan itself, with a named owner, so that the date is recorded at the moment it is chosen rather than reconstructed later.

None of that is expensive. It is simply the difference between a breach response that reads as competent and one that reads as improvised — and that distinction is exactly what the Board is assessing under s.33(2) when it decides what the failure is worth.