By the time an incident reaches your ticket queue, the deadline to report it may already have gone.
That is the part most teams learn during their first real filing, not before it. A data incident at a bank, an NBFC, an insurer or a broking firm in India can trigger reporting duties to both RBI and SEBI at once, plus a separate notification track under DPDP. Two of those windows are six hours long. And the six hours do not start when your analyst opens the alert. They start the moment the activity first shows up in a log.
For a CISO, this is not a process problem sitting somewhere lower in the org. It is your name on the filing, with a countdown already running.
Two of the three run on six hours. One does not
Here is the distinction that trips people up, so it is worth stating plainly.
RBI and SEBI both give you six hours. DPDP gives you seventy-two. The six-hour clocks determine whether you filed on time. The DPDP clock is the one many teams assume they are working to, right up until they realise it was never the binding deadline.
RBI sets the pace for banks. Since 2016, banks have been required to report unusual cybersecurity incidents to the Reserve Bank within two to six hours of detection. There is no size threshold. A small finance bank runs on the same clock as the largest private bank in the country, which surprises many smaller institutions the first time the requirement applies to them.
SEBI adds a second reporting obligation for participants in the securities market, including brokers, depositories, mutual funds, and market infrastructure institutions. Under CSCRF, a reportable incident must be reported within six hours of detection, followed by a root cause analysis. Serious incidents also require a forensic review.
DPDP is the outlier. When a personal data breach occurs, the Data Protection Board must be notified and provided with a detailed report within seventy-two hours. Every affected individual must also be informed. There is no minimum threshold. A breach affecting ten records carries the same reporting obligation as one affecting ten million.
Two important conclusions emerge when you line these requirements up.
They do not substitute for one another. Filing with RBI does not satisfy SEBI. A single incident at a bank that also operates a broking business may require both filings, each in its own format, alongside the DPDP notification process.
And the shortest reporting window governs the entire response. The six-hour clock sets the pace, and everything else is measured from the same starting point.
Six hours from when, exactly
This is the detail that quietly causes firms to miss the deadline, so it is worth slowing down for.
Regulators count from the moment the incident first becomes visible, not from the moment your team gets to it. If suspicious activity first appears in your logs at 1 AM, the clock starts at 1 AM, even if nobody opens the alert until the morning shift comes in.
That matters because of how an incident is reviewed. A regulator does not look at your ticketing system. They reconstruct the timeline from your logs, trace the activity back to its earliest observable sign, and treat that moment as hour zero. In effect, your own telemetry defines your reporting deadline. If five hours pass between the first log entry and the moment anyone acts on it, five of your six hours are already gone before the real work begins.
So the six hours are not investigation time. They are the time you have to know what happened well enough to report it, while the clock is already partway down. Which turns the whole thing into a single question you can test this week. How much can your team establish, with evidence behind it, within six hours of a log line written at 1 AM on a Saturday?
The four things every filing needs
Peel the forms apart, and they all ask for the same facts, just in a different order.
What data was involved? Not which server, which data. Whether those records were marketing contacts or KYC files containing PAN details and account numbers changes the severity of the incident, the wording of the filing, and whether the personal data notification requirements even apply.
How many people were affected, and what kind of data about them? The filing has to identify the categories of data involved and the number of individuals affected. A regulator reading “customer data may have been affected” without numbers behind it sees an organisation that cannot account for its own data estate, and that impression shapes everything that follows.
Where did the data go, and how far? Did it remain on a single system, or did it reach a reporting database, a third-party vendor, or another endpoint downstream?
Has the incident been contained? The filing has to explain what has been contained and what remains exposed. An open exposure at the moment you file reads very differently from one that has already been contained.
Answer all four questions with evidence, and you can file confidently within the reporting window. Fall short on the first, and the other three quickly become assumptions you may later have to defend.
Why the hours get spent on the wrong work
In practice, most of the six-hour window is spent answering one question: Was the data even sensitive?
That question is slow to answer, and not because the incident team is unprepared. It is slow because the answer was never established before the incident began. Classification that runs on a schedule, whether through quarterly scans, periodic crawls, or cataloguing tools operating on their own cadence, can only describe the data as it existed the last time they ran. By 1 AM on a Saturday, files have moved, copies have been created, and new data stores have appeared that no scan has seen yet. The map is always slightly behind the territory, and that gap is exactly where the incident unfolds.
The places where regulated data actually sits at 1 AM are also the places with the least visibility.
Endpoints come first. Laptops are where records get staged before they move, while cloud-only tools stop at the API boundary.
On-premises databases come next. Core banking systems. An aging Oracle instance. The reporting database nobody ever decommissioned.
SaaS sharing is third. A single public link in Google Drive or SharePoint can expose regulated data outside the organisation without generating a single network alert.
What has to be true before the alert fires
None of this can be assembled in the middle of an incident. The capability is either there at 1 AM or it is not.
You need a continuously updated inventory of classified data, not one refreshed on a schedule, across cloud, SaaS, on-premises environments, and endpoints, so the sensitivity question is already answered the moment an alert arrives. You need detections from all of those surfaces flowing into a single queue, because four separate consoles at 2 AM require four sets of eyes that most teams simply do not have. You need a baseline for normal behaviour, so a large data transfer means one thing for a scheduled batch job and something entirely different for a relationship manager on a weekend. You need data lineage, so determining how far information has spread becomes a lookup instead of a two-day investigation. And you need containment actions that a named individual can approve within the reporting window, with every action, approval, and timestamp recorded, because regulators will ask what you did, who approved it, and when.
This is the problem Matters.AI was built to solve. Its Data Detection & Response (DDR) engine brings together detections from AWS, GCP, and SaaS applications into a single alert queue, using UEBA to establish behavioural baselines so severity reflects who is accessing sensitive data, not just how much data moved. Database Activity Monitoring extends that visibility to self-hosted Oracle alongside PostgreSQL, MySQL, Amazon Redshift, and Amazon RDS, keeping on-premises databases in the same investigative view as cloud environments. Endpoint coverage across Windows, macOS, and Linux ensures the staging ground is visible before data ever leaves the device. For SaaS applications, security teams can revoke a public link, remove external sharing, or transfer file ownership across Google Drive, OneDrive, and SharePoint, with every action, approver, and timestamp automatically recorded in an audit trail. Every containment action remains human approved, creating a defensible record for regulatory filings and audits.
Deployment differs by environment because a single deployment model does not fit every surface. Cloud and SaaS integrate through agentless APIs. On-premises environments use a lightweight agent. Endpoints run small language models locally, allowing sensitive data to be classified and monitored without leaving the device.
Start with the timestamp
There is one number worth measuring this week, and it costs nothing to find.
Pull your last three incidents. For each one, identify the earliest log entry showing suspicious activity, then identify the moment someone on your team first acted on it. The time between those two events is your real exposure, because it counts against the six-hour reporting window every time, whether anyone was watching when it started or not.
If that gap exceeds six hours for even one of those incidents, the reporting deadline was effectively lost before your team knew there was anything to report. The answer is not a faster ticket queue. It is seeing the activity when it happens, across every surface where sensitive data lives.
The six-hour window is not won during the incident. It is won long before the first alert fires.
See what becomes visible at the data layer
Read more: RBI Data Governance Framework
