3,897 SBI records leaked. Three clocks now run: 6 hours, 6 hours and 72 hours

01The filing lists eight things. Read what it does not list.

SBI’s sequence, as it told the BSE and NSE: alerts on 16 October from its threat-intelligence provider, the Defence Cyber Agency and CERT-In about possible exposure of customer data; a preliminary analysis of about 3.75 lakh dark-web records; 3,897 of them found to contain personal information; an independent CERT-In-empanelled agency engaged; and a Regulation 30 disclosure on 21 October, five days after the first alert.²³ Bloomberg’s report of the same filing lists the exposed fields: names, registered mobile numbers, dates of birth, email addresses, residential addresses, branch identification numbers, customer identification numbers, and details associated with loan and lead records.¹

What the filing does not list matters as much, and it must be read precisely. Account numbers, balances, passwords, OTPs, card details, PAN and Aadhaar numbers do not appear among the exposed categories.² That is “not listed in a preliminary filing”, not “confirmed safe”. The person claiming the leak also claims 2,722 PDF documents, which no outlet has verified and the filing does not address.³

02Three clocks, three start lines, one customer still waiting

The first clock is CERT-In’s. Its Directions of 28 April 2022, in force sixty days later, require every body corporate to report the incident types in Annexure I, which include “Data Breach” and “Data Leak”, to CERT-In “within 6 hours of noticing such incidents or being brought to notice about such incidents”, by email to incident@cert-in.org.in.⁵ The second is the RBI’s. Paragraph 182 of the Commercial Banks Cybersecurity, Technology Risk, Resilience and Assurance Framework Directions, 2026, issued and effective 31 July 2026, says a bank “shall report cyber incidents within six hours of detection on DAKSH platform” and shall also proactively notify CERT-In.⁶ Same incident, same six hours, two recipients, two instruments; filing one does not discharge the other.¹²

The third clock belongs to the customer, and it has not started. Rule 7 of the DPDP Rules, 2025 requires a Data Fiduciary, on becoming aware of a personal data breach, to tell each affected person “without delay” through their account or registered contact what happened, what it means for them, what the company is doing and what they can do; to tell the Data Protection Board without delay; and to file a detailed report “within seventy-two hours of becoming aware of the breach, or within such longer period as the Board may allow on a request made in writing”.⁷ Rule 7 commences on 13 May 2027, eighteen months after the Rules were notified on 13 November 2025; the Consent Manager rule arrives earlier, on 13 November 2026.⁸

Notice the start lines. CERT-In’s clock begins at “noticing or being brought to notice”; in SBI’s case CERT-In was itself one of the three parties that raised the alert on 16 October, so for that clock the question of when the bank knew is almost moot.³ The RBI’s begins at detection. The DPDP’s will begin at “becoming aware”. A bank that cannot produce a timestamp for each of those moments cannot show it met any of them. And today, as the Internet Freedom Foundation pointed out on the day of the filing, both live clocks run to regulators; nothing binding requires the 3,897 customers to be told. The RBI’s advisory of 25 March 2026 recommends notifying affected customers, and IFF notes it is a recommendation.³

03What has to happen inside six hours, and what it needs

Six hours is not long. It is one working afternoon in which a team must confirm the alert is real, decide whether the incident is one of the twenty Annexure I types, work out which systems and which customers are involved, and file two reports in two formats. The mechanism below is the same for every Indian bank; what differs is whether the inputs exist when the clock starts.

Step two is where most teams would fail today, and the fix is dull. CERT-In’s Directions already require logs of all ICT systems to be kept “securely for a rolling period of 180 days” and “within the Indian jurisdiction”, and every system clock synchronised to NIC or NPL time servers.⁵ The RBI’s Directions add a Cyber Security Operations Centre for continuous surveillance (paragraph 143), with log collection and SIEM correlation (paragraph 215) and round-the-clock Level 1 monitoring, in-house or managed (paragraphs 221 to 223).⁶ None of that is new technology; it is retention, time, and someone awake.

Where the 180 days can lawfully sit is a TechBag count: 20 of the 36 SIEM and log-management products in our guide can also run on your own premises, the other way to keep logs in India.¹¹

The Bank of Baroda episode shows the second class of incident, the one no API control catches. The bank’s own statement said an employee’s email account was compromised and gave access to “certain data”, that core banking was not accessed, and that the incident was detected and contained; it disclosed no record count, and we state none.⁴ A mailbox is a data store. If a relationship manager’s inbox holds application forms, the classification step in the flow above has to be able to say so inside the hour, which is a data-discovery and DLP question long before it is a reporting one.

04The cadence the RBI now expects, and the clauses that carry your clocks to vendors

The reporting clock is the visible edge of a framework. The same Directions fix the rhythm a commercial bank must keep between incidents: a vulnerability assessment of critical systems, and of systems in the DMZ with a customer interface, “at least once in every six months”, and a penetration test of the same “at least once in 12 months” (paragraph 151); disaster-recovery drills for critical systems at least half-yearly (paragraph 165), each one switching to the DR site and running it as primary for at least a full working day (paragraph 167); and a near-zero recovery point objective for critical systems (paragraph 171).⁶

Then the contracts. Paragraph 132 requires a bank’s agreements with service providers to carry a right to audit for the bank and a right of inspection for the RBI or its authorised persons.⁶ We would add two clauses the Directions do not spell out but the clocks demand. First, a breach-notice duty from the vendor to the bank measured in hours, not “promptly”, because TechBag’s BFSI guide notes that under the RBI’s 2025 outsourcing Directions the bank’s six hours can start at the vendor’s detection, not the bank’s.¹² Second, a data-inventory duty: the vendor states, and refreshes quarterly, which customer fields it holds and where. If the SBI dataset turns out to have come from a partner, that clause is the one that would have shortened the week between alert and filing.

For entities that expose payment or disbursement APIs to partners, CERT-In’s advisory CIAD-2026-0046 of 9 October sets out a separate control list for a separate class of attack: maker-checker on all fund movement, per-transaction and per-day ceilings enforced at the API layer, beneficiary name-matching, API keys in a secrets manager or HSM with rotation, EDR with tamper protection, centralised logging kept at least 180 days, and near-real-time reconciliation against bank statements.⁹ It names no bank, and nothing public connects it to the SBI records; we cite it because a partner API that moves money is the most consequential version of the same architecture, a copy of the bank’s trust sitting outside the bank.