SBI Data Exposure October 2026: What Customers and Banks Should Know

On 21 October 2026, State Bank of India told stock exchanges that customer records had surfaced on the dark web. In a preliminary review of about 375,000 records, it found 3,897 holding personal details such as mobile numbers and dates of birth. Customers should expect convincing scam calls. Banks and fintechs should check their own data flows now.

This post sticks to SBI's filing and published reporting. The bank has not said how the data left, whether it is genuine, or where it came from, and we do not guess. The second half is for security and compliance teams at Indian banks, NBFCs and fintechs.

What happened

According to MediaNama, Storyboard18 and Cyber Security News, SBI filed a disclosure titled "Incident involving Data Loss" with the BSE and NSE on 21 October under Regulation 30 of the SEBI Listing Obligations and Disclosure Requirements (LODR) Regulations, 2015, the rule that requires listed companies to disclose material events.

The filing says SBI received communications on 16 October about suspected exposure of customer data on the dark web. MediaNama and Storyboard18 report that they came from the Defence Cyber Agency, which both outlets describe as SBI's threat intelligence service provider, and from CERT-In, India's national computer emergency response team.

A preliminary analysis covered roughly 3.75 lakh (375,000) records. Of those, SBI identified 3,897 customer records containing personally identifiable information. The bank says a detailed investigation is still needed to establish whether the data is authentic and complete, where it came from, and how far the exposure extends.

SBI says it has activated its cyber incident response and containment protocols and engaged an independent cybersecurity agency empanelled by CERT-In. It told investors there is no material impact on its core operations, financial performance or business continuity. MediaNama reports SBI said it will take "all appropriate measures in accordance with applicable regulatory requirements."

Timeline

The claim and the filing are different things

Before the filing, the Siriusim group claimed on the BreachForums dark web forum to hold more than 3.75 lakh rows of data and 2,722 PDF files related to SBI customers, according to MediaNama. Storyboard18 reports it claimed loan applications and account-opening documents.

SBI's filing does not mention the PDFs, and the bank has not confirmed the group's claims. Cyber Security News stresses that the allegations are separate from SBI's findings, and that the filing names no attacker, entry point, vulnerability, malware or compromised server. It also notes that 375,000 is a record count, not a count of people, because records can repeat.

What data was involved

No password or PIN appears in the filing. That is good news, but it does not end the risk.

Why this kind of data matters

None of these fields opens an account by itself. The risk is social engineering:

• Name, mobile number and email tell a fraudster who to contact and how.
• Date of birth and address are common answers to identity questions at call centres, telecom stores and lenders.
• Branch, CIF and loan details let a caller quote real-looking information. Cyber Security News notes that branch details and loan references could make fraudulent calls more convincing.

That is why the guidance below is about calls, messages and SIM changes rather than passwords.

What customers should watch for

This applies to SBI customers and, since leaked datasets get reused, to anyone banking in India. It draws on CERT-In, RBI and Department of Telecommunications material.

Phishing calls, SMS and WhatsApp messages

CERT-In's booklet for National Cyber Security Awareness Month (October 2025) lists fake bank calls, KYC update scams and fake SMS bank alerts as common threats. Its advice:

1. Never share an OTP, PIN, CVV or card details, including with someone who says they are from your bank.
2. Do not click unfamiliar links in messages. Banks and government bodies do not ask for sensitive information by SMS.
3. Call your bank only on the customer care number on its official website.
4. Hang up if the caller pressures you or creates panic, and report the call.

IFF's statement adds that SBI says it never asks for an OTP, user ID, password or PIN. Be extra wary of any message that quotes your loan details or address.

KYC update fraud

The usual pattern is an urgent message saying your account will be blocked unless you update KYC, a link to a fake page, then a call asking for an OTP. CERT-In's booklet tells people not to give personal information for "updating KYC" through calls or messages. Update KYC at your branch, or in the bank's official app or website opened by you.

SIM swap

RBI's BE(A)WARE booklet on fraud methods lists SIM swap among the techniques fraudsters use: someone gets a replacement SIM for your bank-linked number and starts receiving your OTPs. A date of birth and address make that impersonation easier.

• If your phone loses network for an unusually long time, call your mobile operator from another phone and ask whether a SIM change was requested.
• Do not switch your phone off just because of a flood of unknown calls; check with your operator instead.
• Use the Department of Telecommunications' Sanchar Saathi portal. "Know Mobile Connections in Your Name" shows the numbers registered to you. Chakshu takes reports of suspected fraud calls, SMS and WhatsApp messages, including fake bank KYC requests. Trusted Contact Details lists official bank numbers.

If money leaves your account

Speed matters. RBI's July 2017 circular on customer liability says that where fraud comes from a third-party breach and the customer reports it within three working days of the bank's alert, the customer has zero liability. From four to seven working days, liability is capped. The circular also requires banks to credit the disputed amount provisionally within 10 working days of notification.

1. Call your bank's official helpline and block the card or channel.
2. Call the national cyber crime helpline, 1930, or file at cybercrime.gov.in. CERT-In and Sanchar Saathi both point victims there.
3. Keep SMS alerts on. They are how you spot fraud early.

The rules that apply to an incident like this

Indian banks and fintechs work under several overlapping clocks. This is not a comment on SBI's handling; MediaNama notes the filing does not say when SBI reported to CERT-In or RBI. It is a map of what the rules require of any regulated entity.

Two details are easy to miss.

An outside tip starts the CERT-In clock. The Directions require reporting "within 6 hours of noticing such incidents or being brought to notice" of them. An alert from a threat intelligence provider or from CERT-In counts. Triage of a dark web listing has to move as fast as an internal intrusion alert.

Customer notice is coming. IFF argues today's duties run mostly to regulators and investors, and has asked RBI to make customer notification binding before the DPDP provisions start. From 13 May 2027, Rule 7 requires telling each affected person what happened, the likely consequences, what the organisation is doing, what they can do, and who to contact.

What would have helped

We do not know how the data in this case left wherever it was held. This section lists practices that lower the chance and the damage of any customer data exposure at an Indian bank, NBFC or fintech.

1. Dark web monitoring with a playbook

An alert is only useful if someone can act on it within hours. Write the playbook first:

1. Quarantine the sample in an isolated, access-controlled location. Do not pass it around by email.
2. Fingerprint the fields. Match column names, ID formats and field order against your systems. Internal identifiers such as customer or lead IDs often point to one application or export.
3. Check for canaries. Plant unique fake customer records in each system and in each dataset you hand to a partner. If one appears in a leak, you know which copy it came from.
4. Decide on reporting under the CERT-In Directions and, for banks and NBFCs, RBI's DAKSH within the six-hour window.

2. Data minimisation on lead and loan data

Lead and loan data tends to travel to CRMs, call centres, sales agents and analytics tools. Each copy is another place to leak from.

• Collect less. Does a lead tracker need a full date of birth and address, or only a mobile number and product interest?
• Mask by default. DPDP Rule 6 lists encryption, obfuscation, masking and virtual tokens as baseline safeguards.
• Erase when the purpose ends. Section 8(7) of the DPDP Act requires erasure once the purpose is served, unless a law requires retention. The Act's own illustration is a bank keeping identity records for ten years after an account closes. Unconverted leads with no legal retention duty are a liability.
• Find stale exports. Old CSV and PDF exports on shared drives and buckets are a common source of leaks.

# CSV, XLSX and PDF exports older than 90 days
find /srv/shared /data/exports -type f \( -name "*.csv" -o -name "*.xlsx" -o -name "*.pdf" \) -mtime +90 -print

# Files that look like they hold Indian mobile numbers (10 digits starting 6 to 9)
grep -rlE '(^|[^0-9])[6-9][0-9]{9}([^0-9]|$)' /data/exports --include="*.csv" | head -50

# Confirm an export bucket blocks public access
aws s3api get-public-access-block --bucket your-exports-bucket
aws s3api get-bucket-policy-status --bucket your-exports-bucket

3. Third-party and vendor data flows

Section 8(1) of the DPDP Act keeps the Data Fiduciary responsible for processing done on its behalf by a Data Processor, and section 8(2) requires a valid contract. Rule 6 adds that the contract must provide for reasonable security safeguards. RBI's NBFC directions call for vendor risk assessments covering customer data protection.

• Keep a register of every outside party that receives customer data: which fields, by what route (API, SFTP, shared drive, email), and when it is deleted.
• Give each partner the minimum fields and seed canaries in each feed.
• Ask vendors for an SBOM of the software that handles your data, and scan it.
• Test that a vendor can actually delete your data on request.

MediaNama and IFF have asked whether SBI's subsidiaries, vendors or direct selling agents were involved. No answer has been published, so treat it as a question for your own organisation, not a finding about SBI.

4. Be ready for six-hour reporting

The CERT-In Directions also require the logs and clocks that make reporting possible.

# Is the clock synced, and to which source?
chronyc tracking
chronyc sources -v

# How much local log history is kept?
journalctl --disk-usage

# CloudWatch log groups with retention under 180 days or unset
aws logs describe-log-groups \
  --query 'logGroups[?retentionInDays==`null` || retentionInDays<`180`].[logGroupName,retentionInDays]' \
  --output table

An unset CloudWatch retention means logs never expire, so check those rows by hand. Confirm your CERT-In point of contact is current and your template covers every field the CERT-In and DAKSH forms ask for.

5. Rehearse DPDP breach notices now

Rule 7 asks for notice "in a concise, clear and plain manner and without delay." Draft it now, in the languages your customers use, and test every channel they registered. The 72-hour Board report asks for causes, mitigation, findings about who caused the breach, and a report on notices sent, so keep an investigation log from hour one.

6. Reduce follow-on fraud

DSCI's brief notes RBI's commercial bank directions make DMARC mandatory. A strict policy makes it harder to spoof your domain in the emails that follow an exposure.

dig +short TXT _dmarc.yourbank.example
# Look for p=reject or p=quarantine, not p=none

Where Safeguard fits

The limits first. Safeguard does not monitor the dark web, does not find customer records in databases or file shares, cannot tell you where a leaked dataset came from, and cannot notify customers or regulators. It would not have prevented a data exposure like this one, and nothing in SBI's filing points to a software flaw.

What Safeguard covers is the software that handles customer data:

• Inventory. SBOM and dependency scanning of repos, container images and SBOM files: safeguard scan --dir ., safeguard scan --image <name> or safeguard scan --sbom <file>, with JSON results under ./output. The platform shows which projects contain a given component and version, so "which lead and loan services run this library" has an answer. See SBOM incident response.
• Vendor software. Scan the SBOM files your vendors supply with --sbom.
• Priority. Vulnerability matching against vulnerability databases, with reachability analysis showing which issues your code can reach.
• Gates. Policies and gates evaluated in the platform can hold back builds carrying components you have ruled out.
• Fixes. Autonomous remediation can open fix PRs (off by default). The Safeguard CLI assistant edits code and runs commands with your approval, with /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. safeguard exec suits CI. Desktop and phone apps can send work to a computer running the CLI and approve each command.

Zero-Day Discovery and Gold

These address software vulnerabilities, a different layer from data exposure. They matter because customer data usually sits behind web apps built from open source components.

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. It does not look for leaked data and has no link to this incident.
• Gold Open Source (gold.safeguard.sh, free, no login) offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, a free read API, and a CI gate GitHub Action.
• Gold Registry (registry.safeguard.sh, paid) offers hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3+, Sigstore-signed, with evidence pages. An artifact loses its badge on regression.

The habit worth building is pulling patched, signed components from a curated source and rebuilding fast, so the apps that handle customer data are not the easy way in.

Common mistakes

• Treating the attacker's numbers as fact. A forum claim is not a verified count. Use SBI's 3,897 figure and say it is preliminary.
• Counting records as people. Deduplicate before sizing a notification.
• Waiting for proof before starting the clock. The CERT-In window runs from when an incident is brought to notice.
• Giving password advice only. The listed data is contact and identity data. Warn about calls, KYC links and SIM changes.
• Forgetting copies. Exports, test datasets, partner feeds and analytics extracts are often less protected than production.
• Guessing at causes in public. Say what you know, what you do not, and when you will update.

FAQ

Was SBI hacked?

SBI has not said. According to Cyber Security News, the filing confirms a data loss incident but does not establish how the data was obtained or whether core banking systems were breached. A CERT-In empanelled agency is investigating.

How many customers are affected?

SBI found 3,897 customer records with personal information among about 375,000 records. The filing does not describe the rest. Records can repeat, so the number of people may differ.

Were passwords, PINs or account numbers exposed?

The filing does not list passwords, PINs, OTPs or account numbers and reports no stolen funds, according to Cyber Security News. It does list contact details, branch and CIF identifiers, and loan and lead metadata.

How do I know if my data is involved?

The filing does not say whether affected customers have been told, and no lookup service has been announced. IFF has asked SBI to notify each one and set up a helpline. Until then, follow the fraud guidance above.

Is the Siriusim claim the same incident?

The timing and the 3.75 lakh figure match, but SBI has not confirmed the group's claims, and its filing does not mention the 2,722 PDFs. Reporting treats them as separate until the investigation says more.

Does the DPDP Act require SBI to notify me?

Section 8(6) requires notice to the Data Protection Board and each affected person. IFF says that duty takes effect in May 2027, and Rule 7, which sets the form and timing, starts on 13 May 2027. RBI's Advisory No. 3/2026 recommends customer notification but is not binding.

What is the six-hour rule?

CERT-In's 2022 Directions require reporting listed incidents, including data breaches and leaks, within six hours of noticing them or being told about them. RBI's July 2026 directions separately require banks and NBFCs to report to DAKSH within six hours of detection.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

To be precise: Safeguard would not have stopped a dataset from appearing on a forum. These demos show how a bank or fintech team keeps the software that handles customer data inventoried, patched and changed under human approval. None of them shows this incident.

The first demo is a real CLI session fixing a lodash vulnerability: the assistant reads the finding and advisory, asks before each command, edits package.json, runs install and tests with approval, and pushes nothing. At a fintech, you would run the same flow on a lead-capture or loan-origination service, then approve each step of the upgrade.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code, and scans from the terminal. For a team that wants scans of customer-data applications to run from hardware it controls, you would point it at the repos and images behind your portals and partner integrations.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: work goes to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. With a six-hour reporting clock running, the engineer who can approve a fix is not always at a desk.

Click through it at your own pace, or open it full screen.

To try it, download Safeguard and follow the CLI docs. Related reading: our guide to CERT-In directives, IDCF Cloud ransomware and third-party risk, and October 2026 security incidents and what would have helped.

Quick check

Sources

• CERT-In Directions under section 70B(6) of the IT Act, 28 April 2022
• Digital Personal Data Protection Act, 2023 (Gazette of India)
• Digital Personal Data Protection Rules, 2025, G.S.R. 846(E) (MeitY)
• RBI: Limiting Liability of Customers in Unauthorised Electronic Banking Transactions (6 July 2017)
• RBI: NBFC Cybersecurity, Technology Risk, Resilience and Assurance Framework Directions, 2026
• RBI press release: BE(A)WARE booklet on modus operandi of financial frauds
• CERT-In: Cyber Security Best Practices booklet, National Cyber Security Awareness Month 2025
• Department of Telecommunications: Sanchar Saathi
• Department of Telecommunications: Chakshu fraud reporting
• MediaNama: SBI confirms 3,897 customers' data found on dark web
• Cyber Security News: SBI confirms data breach
• Storyboard18: SBI confirms data loss incident involving 3,897 customer records
• Internet Freedom Foundation: SBI told investors its data breach doesn't matter
• DSCI brief on RBI Cybersecurity Directions (Commercial Banks), 2026
• KPMG: RBI's technology-focused master directions issued on 31 July 2026

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.