The DPDP 72-hour clock: a SOC operations checklist

The Digital Personal Data Protection Act 2023 came fully into operational force in 2025, and the Data Protection Board has been visibly active since the first quarter of this year. The headline obligation everyone quotes is the 72-hour notification window. The runbook for actually hitting that window — what the SOC does in hours 0, 6, 24, 48, and 72 — is rarely written down. This post is that runbook, written from operational experience across BFSI, healthcare and SaaS deployments.

None of this is legal advice. It is engineering advice. Your compliance counsel decides whether a notification is required; the SOC decides whether the data is ready by the time counsel asks. Those are different jobs, and most of the time-pressure problems we have watched happen because the second job is assumed to be done in real time when it isn't.

When the clock actually starts

Read the Act carefully. The clock starts when the data fiduciary "becomes aware" of a personal data breach. The legal interpretation of "becomes aware" is still settling, but the working position across most Indian counsel is: awareness occurs at the point a reasonable security function would have concluded that personal data was, or is likely to have been, compromised. Practically, that means the clock often starts before the incident is officially declared, because awareness predates declaration.

This is the operational trap. SOCs assume the clock starts at incident declaration. It does not. It starts at the first signal that, with hindsight, a reasonable analyst would have escalated. If that signal sat in a queue for nine hours before triage, you have already lost nine hours of your 72.

The runbook, broken into windows

Below is the operational checklist we hand to client SOCs after deployment. It assumes a graph-native platform where assets, identities, data classifications and access edges are all queryable in one substrate. Where it doesn't, we note the gap.

Hour 0 to Hour 6 — Establish the perimeter of the breach

The first six hours are not about telling the regulator anything. They are about not lying to the regulator later. Anything you say at hour 72 must be defensible against forensic reconstruction. So the early hours are evidence preservation, not communication.

1. Pin the timeline. Identify the first observable event tied to the incident. Capture its native timestamp, source, and ingest timestamp. Lock the analyst's note timestamps to UTC. Drift between systems is the single most common reason a forensic timeline falls apart.
2. Identify the entry point. One-hop traversal from the suspect event back to the originating node. Was it a phishing-derived authentication? A misconfigured exposed service? A third-party vendor account? The entry-point classification determines which regulator template applies.
3. Snapshot affected nodes. Identities involved, assets touched, data stores accessed, applications reached. This is the seed set for blast-radius work. The graph should let you say "every personal-data-classified asset reachable in three hops from the entry node" as a single query. If your platform requires you to manually build this list, you are already in trouble.
4. Preserve logs out-of-band. Export raw events for the affected sources to a write-once location. Yes, your platform already retains them; the regulator may still ask for a sealed copy independent of the platform's audit log.

The asset that almost no one prepares for in hour 0 is a personal-data inventory. The Act asks how many data principals were affected and what categories of personal data were involved. If your data classification lives in a spreadsheet maintained by the privacy team, you are about to spend a lot of hour 0 on phone calls instead of analysis. Classifications should be edges in the graph, attached to data-store nodes, updated as part of the DSPM cycle.

Hour 6 to Hour 24 — Quantify and qualify

By hour 24, you should be able to fill out three numbers with confidence: how many data principals are affected, what categories of personal data were involved, and what the likelihood of actual exfiltration is (as opposed to mere access).

This is also the window where you decide whether the incident is, in fact, a "personal data breach" under the Act. The Act's definition is broad — unauthorised processing, accidental disclosure, accidental loss — so the engineering default is "assume yes, prepare the package, let counsel down-grade later". It is easier to retract a draft than to assemble a notification from a cold start.

Hour 24 to Hour 48 — Draft the notification

By hour 48 you want a draft notification on counsel's desk. The standard template — derived from the Board's notification rules and the broader sector advisories — asks for nine fields. Most of these should auto-fill from the graph; the ones that don't are the ones that need human writing.

1. Time of incident                      [auto: earliest_signal_ts]
2. Time of awareness                     [auto: first_escalation_ts]
3. Time of notification                  [manual: counsel signs]
4. Nature of incident                    [manual: 2-3 sentence prose]
5. Categories of personal data involved  [auto: classifications union]
6. Approximate count of data principals  [auto: distinct subject count]
7. Likely consequences                   [manual: risk narrative]
8. Mitigation taken                      [auto: containment actions log]
9. Mitigation proposed                   [manual: remediation plan]

Fields 1, 2, 5, 6 and 8 should be machine-generated. The platform writes them; counsel reviews them. If a human is typing those fields into a Word document at hour 48, the workflow is broken — not because of the typing, but because typing implies the data was not in the system in a structured way, which means it might also not be in the system reliably.

Fields 4, 7 and 9 are prose. They are where the SOC and counsel collaborate. The SOC drafts the nature-and-consequences narrative; counsel rewrites for tone and legal exposure. We recommend keeping a "narrative skeleton" file with three short prose templates — one for credential compromise, one for misconfiguration exposure, one for malicious insider — that the SOC fills in. This shaves several hours off the drafting cycle and prevents the all-too-common "we ran out of time to write the narrative" outcome.

Hour 48 to Hour 72 — Notify, document, and start the parallel obligations

The last 24 hours are the easiest if the first 48 went well, and the hardest if they didn't. Assuming they went well:

• Counsel submits the notification through the Board's prescribed channel.
• The SOC delivers an internal incident report (separate from the regulator submission — more detail, more technical).
• Parallel notifications begin: to affected data principals (where required), to processor entities, and — if you are in a regulated sector — to the sector regulator. The DPDP notification does not displace these; it sits alongside them.
• Evidence-of-notification is logged as an edge in the graph: a "notified" relationship from the incident node to each recipient entity, with a timestamp and a copy reference. This sounds bureaucratic; it is critical for the audit trail when the Board comes back with follow-up questions weeks later.

If hours 0-48 did not go well — if the entry point is still ambiguous, if data classifications are uncertain, if exfiltration is unconfirmed — the notification still needs to go in. The Act allows for follow-up information, but the initial notification must be made within 72 hours regardless of investigative completeness. Counsel will know how to phrase the uncertainty; the SOC's job is to make sure counsel knows what they don't know.

What the graph buys you, concretely

The reason graph-native matters here is not that it makes the analyst feel productive. It is that several of the 72-hour fields are not knowable in a join-at-query-time SIEM within the window. Specifically:

1. Principal count. Requires reconciling subject_id across multiple data stores. In a graph, this is a node-merge that already happened at ingest. In a SIEM, it is a 4-hour query if you're lucky and a 4-day query if you're not.
2. Reachable scope. "What other personal data could have been touched?" is a multi-hop traversal in a graph (asset → identity → service → asset → datastore). In a SIEM, you write 6-8 separate queries and join the results in a spreadsheet.
3. Third-party data flows. Was data shared with a processor? The graph has data-sharing edges. The SIEM has logs that may or may not have captured the API call. We have seen this exact gap turn a 72-hour clock into a 96-hour overshoot.

If you operate in a fully air-gapped environment — which is increasingly common in Indian BFSI and defence-adjacent deployments — the constraints get sharper still. We've written about the architecture pattern in the air-gapped and DPDP-first whitepaper. The headline: notification preparation cannot rely on cloud lookups, threat-intel cross-references, or remote forensics support, so everything you need has to be local. The graph being a single substrate means everything is local.

The compliance edge cases

Three operational situations are worth calling out, because they routinely catch SOCs by surprise:

• Insider access without exfiltration. An employee accessed data outside their need-to-know but did not move it. Counsel will usually treat this as reportable; the SOC has to be ready to evidence the access pattern without overclaiming exfiltration. The graph distinction is access edges vs. egress edges. Be precise.
• Suspected breach that turns out to be a false positive. If counsel was notified, the SOC is on the clock. If the SOC stands the incident down at hour 30, the documentation must still exist — the Board may ask why an incident was opened and closed. Keep the audit trail clean.
• Multi-jurisdiction overlap. If your firm operates across India and another jurisdiction with a similar notification regime, you may have two clocks running in parallel with different definitions of "awareness". The SOC has one source of truth; counsel reconciles the regimes. The runbook above is the SOC's contribution.

For Indian healthcare and BFSI specifically, the sector regulators (the central bank, the sectoral cybersecurity directorate) may also have parallel notification windows that are shorter than the DPDP 72-hour clock. We've documented one such workflow in the hospital network case study — the 6-hour incident reporting window for critical infrastructure that overlaps the DPDP clock. The runbook structure is similar; only the timings compress.

Next we step back into incident response architecture: blast radius as a first-class concept, not a post-hoc whiteboard exercise.