--- title: "3,897 SBI records leaked. Three clocks now run: 6 hours, 6 hours and 72 hours" summary: "What SBI's 21 October 2026 filing listed, the CERT-In, RBI DAKSH and DPDP Rule 7 reporting windows an Indian bank now runs, and what an IT team must have in place before the next leak." url: https://www.thetechbag.com/blog/sbi-leak-three-clocks-six-hours-72-hours format: Analysis desk: "Data & privacy" published: 2026-10-22 facts_checked: 2026-10-22 author: TechBag (The TechBag Journal) tags: ["SBI","data breach","CERT-In","RBI","DAKSH","DPDP","incident reporting","SIEM","log retention","BFSI"] cover: https://www.thetechbag.com/blog/covers/sbi-leak-three-clocks-six-hours-72-hours.png --- # 3,897 SBI records leaked. Three clocks now run: 6 hours, 6 hours and 72 hours *What SBI's 21 October 2026 filing listed, the CERT-In, RBI DAKSH and DPDP Rule 7 reporting windows an Indian bank now runs, and what an IT team must have in place before the next leak.* Analysis · Data & privacy · By TechBag · Published 2026-10-22 · Facts checked 2026-10-22 · Canonical: https://www.thetechbag.com/blog/sbi-leak-three-clocks-six-hours-72-hours The short version - On 21 October State Bank of India told the exchanges that 3,897 of roughly 3.75 lakh records found on the dark web carried its customers’ personal data: names, mobile numbers, dates of birth, email and home addresses, branch and customer IDs, and loan and lead details. Core banking, it said, was untouched.[1][2] - An Indian bank now runs three reporting clocks on one incident: six hours to CERT-In (since 2022), six hours to the RBI’s DAKSH portal (since 31 July 2026), and from 13 May 2027 a 72-hour detailed report to the Data Protection Board plus notice to every affected customer. Only the third clock reaches the customer, and it is not running yet.[5][6][7] - Meeting them is less about a product than about four things being in place before the alert: 180 days of logs kept in India, a SOC that can classify an incident inside an hour, a customer-notice template, and vendor contracts that carry the bank’s clocks. Twice in four months a state-owned Indian bank has confirmed that customer data left the building, and twice the bank was able to say, truthfully, that core banking was not touched. Bank of Baroda in July traced its incident to one compromised employee mailbox.[4] SBI in October has not yet said how its records got out.[2] For the IT and security team at any Indian bank, NBFC or fintech, the question this raises is not “could it happen here”. It is: when the alert arrives at 4 pm on a Friday, which regulator hears from us first, by when, with what, and what must already be true of our systems for those answers to be possible. ## The 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.[2][3] 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.[1] 3,897 of roughly 3.75 lakh dark-web records carried SBI customers' personal data SBI's preliminary count to the exchanges, 21 October 2026 ReportedSBI’s words to the exchanges, 21 October 2026 The incident has “no material impact on SBI’s core business operations, financial performance or business continuity”.[1] The source and full extent of the exposure “remain under investigation”.[2] 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.[2] 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.[3] **Figure: SBI's filing names eight exposed field classes; the sensitive ones it does not name are unlisted, not cleared** *Data categories in SBI's Regulation 30 disclosure, as reported, 21 October 2026* Listed as exposed - Customer names - Registered mobile numbers - Dates of birth - Email addresses - Residential addresses - Branch identification numbers - Customer identification (CIF) numbers - Details tied to loan and lead records Not listed in the filing - Account numbers and balances - Passwords and OTPs - Card details - PAN and Aadhaar numbers - The 2,722 PDF documents the leaker claims: unverified, unaddressed Source: SBI exchange filing via Bloomberg and Inc42; Internet Freedom Foundation · as of 21 October 2026 · a preliminary filing; the investigation was still open Our viewThe question we would ask, not a claim we can make Names, mobiles, dates of birth, branch codes, CIF numbers and lead IDs is the shape of a lending-origination or lead-management dataset, the kind that sits in a CRM and with direct selling agents and partner fintechs, rather than the shape of a core-banking dump. Is that where this came from? SBI has not said, the Internet Freedom Foundation has asked the same question of the bank, and we do not know.[3] If it is, the lesson is about where customer data is copied to, not about the mainframe. ## Three 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.[5] 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.[6] Same incident, same six hours, two recipients, two instruments; filing one does not discharge the other.[12] 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”.[7] 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.[8] **Figure: Two of the three clocks give a bank six hours, and neither of them reaches the customer; the 72-hour one that does is not yet running** *Hours allowed from the start event to the report, by regime, with the in-force date* CERT-In Directions, s.70B(6) to incident@cert-in.org.in; in force since June 2022 6 hours RBI Directions 2026, para 182 (DAKSH) to the RBI's DAKSH portal; in force since 31 July 2026 6 hours DPDP Rule 7(2)(b), detailed report to the Data Protection Board; from 13 May 2027, extendable on request 72 hours | | Value (hours) | | --- | --- | | CERT-In Directions, s.70B(6) | 6 | | RBI Directions 2026, para 182 (DAKSH) | 6 | | DPDP Rule 7(2)(b), detailed report | 72 | Source: CERT-In Directions (28 Apr 2022); RBI Commercial Banks Directions 2026 para 182; DPDP Rules 2025 Rule 7(2)(b) and commencement notice · as of 22 October 2026 · start lines differ: CERT-In runs from noticing or being brought to notice, the RBI from detection, DPDP from becoming aware 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.[3] 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.[3] ## What 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. **Figure: From alert to report, the four steps every Indian bank now walks; the first two decide whether the last two are possible** *The breach-to-report mechanism under the CERT-In, RBI and DPDP instruments, as they stand and as they commence* 1. 01Detect, or be toldA SIEM alert, a threat-intelligence feed, a researcher’s post, or CERT-In itself. Whichever comes first, the clock starts; log the timestamp. 2. 02Classify in the first hourAnnexure I type, DAKSH category, systems touched, whether personal data is involved and whose. Needs 180 days of searchable logs with synchronised clocks. 3. 03Six hours: CERT-In and DAKSHEmail incident@cert-in.org.in and file on DAKSH. Two reports, two formats, same facts. A pre-filled template is the difference between six hours and sixty. 4. 0472 hours, from May 2027: the Board and the customerDetailed report to the Data Protection Board; each affected person told without delay what happened, what it means, what to do, and whom to call. Source: CERT-In Directions 2022 paras (i), (ii), (iv); RBI Directions 2026 paras 143, 182, 215; DPDP Rules 2025 Rule 7 · as of 22 October 2026 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.[5] 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).[6] 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.[11] **Figure: Fewer than half the SIEMs in TechBag's guide document an Indian region; 21 of 36 document none** *SIEM and log-management products by the India-region field on their cards, count of 36* - Document an Indian region13 36% - Have announced one2 6% - Document none21 58% | | Value | Share | | --- | --- | --- | | Document an Indian region | 13 | 36% | | Have announced one | 2 | 6% | | Document none | 21 | 58% | Source: TechBag count, SIEM & log management guide, India-region field on each product card · as of 22 October 2026 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.[4] 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. ## The 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).[6] **Figure: Four numbers set the RBI's 2026 rhythm for a commercial bank: a scan every six months, a test every twelve, a real DR day twice a year, and six hours to report** *Minimum cadence for critical and customer-facing DMZ systems under the RBI Commercial Banks Directions, 2026* 6 months Vulnerability assessment, critical and DMZ systems para 151 12 months Penetration test, the same systems para 151 6 months DR drill, run as primary for a full working day paras 165, 167 6 hours Cyber incident reported on DAKSH, from detection para 182 Source: RBI/DoS/2026-27/410, paragraphs 151, 165, 167 and 182, text on rbi.org.in · as of 31 July 2026, text as updated 1 October 2026 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.[6] 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.[12] 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.[9] 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. If you are buying this in India The penalties are already law even though the duties are not yet in force: the Schedule to the Digital Personal Data Protection Act, 2023 provides up to ₹250 crore for failing to take reasonable security safeguards and up to ₹200 crore for failing to notify the Board and affected Data Principals of a breach.[10] Against that, the retention bill is small and knowable. Retention is storage, not a capability: every SIEM in the TechBag guide retains, and what you pay is ingest multiplied by months, or disk. The guide’s worked example puts a self-hosted Wazuh estate at about ₹8 lakh to ₹11 lakh a year at 250 agents including the people to run it, and notes one cloud SIEM whose thirteen-month retention exceeds CERT-In’s 180 days on duration but fails it on location, because it has no Indian region.[11] Every figure is before GST at 18%. Dates to write into your runbook, none of them predicted: CERT-In six hours, in force since June 2022; RBI DAKSH six hours for commercial banks, in force since 31 July 2026; DPDP Consent Manager rule, 13 November 2026; DPDP Rules 3 and 5 to 16, including Rule 7, 13 May 2027.[5][6][8] TechBag sizes log retention against your real daily volume and quotes SIEM, DLP and data-discovery tools in INR; it earns a margin on several vendors named in the guides this piece cites, and none of them saw this piece. How we did this Figures as of 22 October 2026 The SBI facts are the bank’s Regulation 30 disclosure of 21 October 2026 as reported by Bloomberg (via Insurance Journal), Inc42 and the Internet Freedom Foundation; Bloomberg’s own page is paywalled and Business Standard returned an error, so neither was read directly. The 3,897 and 3.75 lakh figures are SBI’s preliminary numbers; the 2,722-document figure is the leaker’s claim and is labelled as such. Bank of Baroda’s statement is quoted via The Record; no record count was published and none is given. The CERT-In clock, log-retention and time-sync clauses are quoted from the Directions PDF itself. The RBI paragraphs are quoted from the full text of the Commercial Banks Directions on rbi.org.in, as updated 1 October 2026; the other six 2026 Directions were not re-read for this piece. Rule 7 is quoted from a reproduction of the Gazette text, not the Gazette PDF. The SIEM count is TechBag’s, from the 36 product cards in its guide. Nothing here infers how the SBI data left the bank, and CIAD-2026-0046 is not connected to SBI. Spotted an error? Write to us; corrections are published at the foot of the piece. Sources 1. [Bloomberg (Siddhi Nayak), via Insurance Journal: Cyberattack Hits India's Largest Bank, Exposes Customer Records](https://www.insurancejournal.com/news/international/2026/10/21/889809.htm) — 21 October 2026 2. [Inc42: SBI Flags Exposure Of 3,897 Customer Records On Dark Web](https://inc42.com/buzz/sbi-flags-exposure-of-3897-customer-records-on-dark-web/) — 21 October 2026 3. [Internet Freedom Foundation: SBI told investors its data breach doesn't matter. What about the 3,897 customers it affected?](https://internetfreedom.in/sbi-told-investors-its-data-breach-doesnt-matter-what-about-the-3-897-customers-it-affected/) — 21 October 2026 4. [The Record: India's Bank of Baroda reports cybersecurity incident (the bank's statement)](https://therecord.media/india-bank-of-baroda-reports-cybersecurity-incident) — 28 July 2026 5. [CERT-In, Directions under sub-section (6) of section 70B of the IT Act, 2000 (No. 20(3)/2022-CERT-In), paras (i), (ii), (iv) and Annexure I](https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf) — 28 April 2022 Effective 60 days from issue. 6. [RBI, Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, RBI/DoS/2026-27/410, paras 132, 143, 151, 165, 167, 171, 182, 215, 221–223](https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13643) — 31 July 2026 Text as updated 1 October 2026. 7. [Digital Personal Data Protection Rules, 2025, Rule 7 (intimation of personal data breach), text of G.S.R. 846(E)](https://dpdpa.com/dpdparules/rule7.html) — 13 November 2025 Reproduction of the Gazette text. 8. [DPDP Rules 2025 commencement timeline (Rules 1, 2, 17–21 on notification; Rule 4 on 13 Nov 2026; Rules 3, 5–16, 22, 23 on 13 May 2027)](https://legismith.com/dpdp-rules-2025-timeline/) — notified 13 November 2025 9. [CERT-In, CIAD-2026-0046: Threat Actors Exploiting Payment and Disbursement APIs for Unauthorized Fund Transfers in BFSI Entities](https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES02&VLCODE=CIAD-2026-0046) — 9 October 2026 10. [Digital Personal Data Protection Act, 2023, Schedule (penalties)](https://www.meity.gov.in/data-protection-framework) — 11 August 2023 11. [TechBag, SIEM & log management guide: 36 products, India-region and deployment fields, retention notes and the Wazuh cost band](https://www.thetechbag.com/browse/security/siem-log-management) — October 2026 12. [TechBag, BFSI industry guide and obligations register: the two six-hour clocks and the vendor-detection note](https://www.thetechbag.com/industries/bfsi) — verified 5 October 2026 Related on TechBag: the [BFSI obligations register](https://www.thetechbag.com/industries/bfsi/obligations) lists every dated RBI, SEBI and CERT-In duty by tier; the [SIEM & log management guide](https://www.thetechbag.com/browse/security/siem-log-management) prices 180 days of retention by meter; the [DLP & insider-risk guide](https://www.thetechbag.com/browse/data-security-privacy/dlp-insider-risk) covers the tools that find where lead and loan data has been copied to. **Disclosure.** TechBag is a software reseller: it earns a margin when a reader buys through it, including from vendors named here. The analysis is TechBag’s own; no vendor paid for or saw this piece before publication. Facts are labelled reported, TechBag count or our view. Go deeper on TechBag - [BFSI obligations: RBI, SEBI and CERT-In duties, dated](https://www.thetechbag.com/industries/bfsi/obligations) — the two six-hour clocks, by tier and instrument - [SIEM & log management guide](https://www.thetechbag.com/browse/security/siem-log-management) — 180 days of retention priced by meter; which products document an Indian region - [DLP & insider-risk guide](https://www.thetechbag.com/browse/data-security-privacy/dlp-insider-risk) — finding where lead and loan data has been copied to