How to Track RBI, CERT-In, and DPDP Deadlines With Regulatory Clocks

Report a cyber incident in India and you may owe two separate six-hour reports to two separate regulators, off the same incident, on two different portals. Regulatory Clocks tracks every statutory deadline your organization is actually subject to, RBI, CERT-In, and DPDP included, as a live countdown linked to real evidence, not a spreadsheet someone has to remember to update.

The deadlines this tracks

Why one incident can start two clocks

RBI's Cybersecurity, Technology Risk, Resilience and Assurance Framework Directions, 2026 (effective 31 July 2026) require NBFCs the directions apply to report a cyber incident to RBI through the DAKSH portal within six hours of detecting it. CERT-In's own directions, in force since 2022 under the IT Act, require reporting the same category of incident within six hours of noticing it, to a completely different portal, under a completely different law.

Detection and noticing aren't always the same instant. Regulatory Clocks always creates two separate clocks rather than one, and when you log the incident you can optionally record the RBI detection time if it genuinely differs from when it was noticed. Leave that field blank and both clocks share the noticed-at instant, stated plainly on the RBI clock itself, so you always know exactly which instant each deadline is actually counting from.

How it works

1. Confirm which regimes apply to you. Regulatory Clocks proposes regimes based on your organization's actual data, for example flagging RBI's NBFC directions if your organization is registered as an NBFC, never based on an AI guess. Nothing starts tracking until you confirm it applies.
2. Log a compliance event. When an incident happens, record when it occurred and when your organization actually noticed it. These get stored separately, because they're often not the same moment.
3. Clocks spawn automatically. Every applicable obligation for that event, CERT-In's six hours, RBI's six hours, or both at once, starts counting down immediately, each with its own deadline and the specific rule it's based on.
4. Satisfy the clock with real evidence. A clock can't be marked done by clicking a checkbox. Closing one out requires citing the actual evidence, a DAKSH submission reference or a CERT-In acknowledgment, that proves you reported it. That evidence gets logged as a permanent decision record, the same accountability discipline behind every other claim KlaritiQ makes.

What it won't do

SEBI's Cybersecurity and Cyber Resilience Framework and DPDP's Third Schedule erasure rules are both defined in Regulatory Clocks' rule set, but not yet available to enroll: their exact due dates depend on details the product doesn't capture yet, your specific audit band for SEBI, or the completed 48-hour pre-erasure notice for DPDP's Third Schedule, and enrollment opens once that's built. Rather than show a guessed date on a record your organization might rely on during an audit, we'd rather ship the honest gap first and the computed date second. If either of these applies to you today, tell your KlaritiQ contact and it'll help prioritize the work.

This article explains how KlaritiQ tracks these deadlines. It isn't legal advice. Confirm exact applicability and obligations with your own compliance or legal team.

Was this article helpful?

Community Questions (0)

Still have questions?