SBI Data-Exposure Report: A Cyber-Cover Design Test

For banks, NBFCs and fintechs, cyber insurance for banks in India should support the work that begins when a suspected exposure is identified: containment, evidence preservation, reporting, specialist support and customer communication. It does not replace incident management, but a well-designed programme can provide a clearer route for approving eligible response costs and assembling a claim while the facts are still developing.

The SBI case is a useful operating test. The Indian Express reported on 21 October 2026 that SBI disclosed an incident involving loss of certain data after alerts about suspected customer-data exposure on the dark web. SBI’s preliminary analysis of about 3.75 lakh records identified 3,897 customer records containing personally identifiable information, while the bank said a detailed assessment was needed to establish the authenticity, completeness, source and extent of the exposure. SBI also said it had activated incident-response and containment protocols and engaged an independent CERT-In-empanelled cybersecurity agency. The Indian Express’s report on SBI’s stock-exchange disclosure sets out the reported facts and the limits of what had been established at that point.

That distinction matters for cyber-cover design. A reported data-exposure event is not a basis for assuming its cause, the complete affected population or legal liability. The response team needs a disciplined process that records what is known, what remains under investigation, who can authorise action and when insurers, regulators, customers and service providers need to be involved.

What the reported SBI data exposure means for cyber insurance for banks in India

SBI’s disclosure illustrates why a bank’s response plan should separate confirmed facts from working assumptions. In the reported incident, the bank identified records containing personal information but said it still needed to determine the authenticity and completeness of the data, the potential source and the extent of the exposure. That is the point at which technical, legal, compliance, operations, communications and insurance stakeholders need to work from one controlled incident record. The reported SBI disclosure is a practical reminder not to turn preliminary findings into conclusions.

The CERT-In Directions issued on 28 April 2022 list unauthorised access to IT systems or data, data breaches, data leaks and incidents affecting digital payment systems among reportable cyber incidents. Covered entities must report listed incidents to CERT-In within six hours of noticing them or being brought to notice.

The first decision is operational rather than insurance-led: stabilise the affected environment while preserving evidence. Establish an incident-command group with a named decision owner. Its incident ledger should record when the alert arrived, the systems and vendors under review, containment measures, approvals, external engagements and the basis for each important decision.

The same CERT-In Directions require covered entities to enable ICT-system logs and maintain them securely for a rolling 180 days in India. Readiness planning should therefore include log retention, controlled access, a tested evidence-preservation process and a named CERT-In point of contact.

The Digital Personal Data Protection Rules, 2025 were published in the Gazette on 13 November 2025. Rules 3 and 5 to 16 take effect on 13 May 2027. From that date, Rule 7 requires a Data Fiduciary to notify affected Data Principals without delay after becoming aware of a personal data breach, and to give the Data Protection Board specified initial and follow-up information.

Does cyber insurance cover a customer-data exposure?

It may, but the answer comes from the policy wording rather than the label on the schedule. A bank data breach insurance India review should identify which first-party response costs, third-party liabilities and specialist services are included, as well as which expenses require insurer consent. Cover remains subject to the policy’s definitions, limits, sub-limits, deductibles, exclusions and notification conditions.

Before purchasing or renewing cover, the bank or fintech should ask:

1. Who is insured? Confirm whether the parent, relevant subsidiaries and other group entities are included.
2. What activates the policy? Check whether the wording responds to a suspected incident, security failure, unauthorised access, privacy event or only a confirmed breach.
3. Which response costs may be covered? Review forensic, legal, communications, notification, customer-support, restoration and business-interruption provisions.
4. What needs approval? Identify emergency-spend allowances, insurer-consent rules and any required or preferred vendor panel.
5. What sits outside the policy? Do not assume that payment fraud, theft of funds, contractual penalties or a third-party technology outage are addressed by the same cover.
6. What evidence is required? Agree claim-notice ownership, reporting deadlines and the documents needed to support costs and losses.

Organisational cyber cover and customer protection should remain separate. An institution’s policy addresses its own defined costs and liabilities. A customer programme may provide defined benefits for eligible events, but it does not replace the institution’s cyber-risk programme. BharatSure’s cyber-cover options for digital customers can be configured around a partner’s customer journey and product design, subject to policy terms.

The first 72 hours: an incident-to-claim operating workflow

The following workflow is a readiness model. It should operate alongside legal advice, applicable regulatory obligations and the organisation’s policy conditions.

Hour 0-6: Stabilise, preserve and notify

• Convene the incident-command group and assign a single decision owner.
• Preserve relevant logs, access records, endpoint artefacts, cloud audit trails and the original alert before ordinary retention cycles or system changes affect them.
• Record the systems, vendors, data sets and customer journeys that may be affected, while clearly distinguishing confirmed facts from assumptions.
• Take proportionate containment measures, such as restricting access, rotating credentials or isolating systems, without losing evidence needed for forensic work.
• Assess CERT-In and sector-specific reporting obligations immediately. The CERT-In Directions set a six-hour reporting requirement for listed incidents.
• Notify the broker and insurer in accordance with the policy. A factual notice of a potential incident or circumstances that could give rise to a claim is preferable to an untested conclusion.

Hour 6-24: Establish facts and activate services

• Engage forensic specialists under a written scope covering triage, preservation, analysis and reporting.
• Build a data map covering affected fields, likely population, systems of record, processors, cloud services, APIs and payment or authentication dependencies.
• Assess whether the information involved could increase the risk of phishing, impersonation, account takeover or targeted social engineering.
• Activate legal, communications and customer-support workstreams using pre-approved templates and authority levels.
• Open a dedicated incident cost code. Each vendor instruction, purchase order, invoice and payment should be traceable to the event.

Hour 24-72: Support customers and prepare the claim file

• Give the insurer a factual status update and seek required consent before committing to material costs where the policy requires it.
• Decide on customer outreach, credential resets, fraud monitoring or public messaging using validated facts and applicable advice.
• Give support teams a clear script, escalation route and process for reports of suspicious activity.
• Begin the claims pack while the investigation continues. Waiting for a final forensic report can make later reconstruction of decisions and costs more difficult.
• Give senior management and the board concise updates that distinguish facts, uncertainties, decisions, expected spend and next steps.

For an affinity programme, AffinityOS API infrastructure can support structured eligibility, status and communication flows. A connected claims infrastructure for incident workflows can support a consistent handoff after an eligible customer claim is notified.

Which breach-response services should a bank arrange before an incident

A policy is more useful when the organisation can mobilise appropriate services quickly. Pre-arrange roles, commercial terms and access paths for:

• Digital forensics and incident response: Triage, investigation, containment guidance and evidence preservation.
• Breach counsel: Advice on notification analysis, regulator engagement and communication review.
• Crisis communications: Customer messages, media holding lines, executive Q&A and monitoring.
• Customer support: Trained call-centre capacity, multilingual scripts and a route for fraud escalation.
• Notification operations: Contact-data controls, message approval, dispatch records and delivery tracking.
• Claims coordination: A named owner for insurer notifications, consent requests, loss schedules and settlement queries.

The vendor roster should record availability expectations, rate cards, data-handling obligations, engagement authority and whether a provider is required or preferred under an insurer panel. This reduces avoidable disagreement during the first day of an incident.

Designing customer communications without assuming liability or cover

Customer communication should help people protect themselves without speculating about cause, fault or claim outcomes. The planned message should include:

1. What is known: A concise account of the event under investigation.
2. What remains uncertain: The source, scope, affected systems or customer impact, where these are still being assessed.
3. What customers can do now: Use official channels, avoid sharing OTPs or credentials, verify unexpected calls or links, and report suspicious transactions promptly.
4. What the institution is doing: Only actions that have actually started, such as an investigation, enhanced monitoring or dedicated support.
5. Where help is available: A verified in-app route, phone number, branch path or support channel.

Avoid promising reimbursement or stating that a policy will pay before eligibility and policy conditions are assessed. When Rule 7 takes effect on 13 May 2027, it will require personal-data-breach intimation to affected Data Principals to cover the breach’s nature, extent and timing, likely consequences, mitigation measures, protective steps and a business contact. Rule 7 of the Digital Personal Data Protection Rules, 2025 offers a useful framework for communication planning.

What evidence insurers and claims teams need to assess a cyber claim

The cyber insurance claims process India is easier to manage when evidence is assembled as the incident progresses. Maintain an access-controlled incident file containing:

• a timeline of discovery, containment, reporting, notification and recovery decisions;
• incident tickets, approvals and decision logs;
• an affected-system, data-field and customer-population assessment;
• preserved logs and forensic engagement letters, scope documents, interim findings and final reports;
• regulatory, law-enforcement, insurer and broker correspondence where applicable;
• customer-message versions, delivery records and support volumes;
• vendor contracts, work orders, invoices and proof of payment;
• downtime records and the methodology for any business-interruption calculation; and
• remediation actions and post-incident control improvements.

From 13 May 2027, Rule 6 of the Digital Personal Data Protection Rules, 2025 will require reasonable security safeguards, including access controls, visibility through logs, monitoring and review for detecting, investigating and remediating unauthorised access. It also requires retention of relevant logs and personal data for one year for those purposes, unless another applicable law requires otherwise. Rule 6 and the commencement provision in the Gazette notification set out these safeguards and their effective date.

FAQ: Can a bank embed cyber protection for customers?

Can a bank embed cyber protection for customers?

Yes. An embedded cyber insurance India programme should be issued by an insurer and structured with an appropriate distribution arrangement, clear customer disclosures and a defined servicing model. A bank, NBFC or fintech should obtain legal and regulatory advice before assigning distribution activities or approving customer communications.

The customer journey should identify the insurer, insured person, benefit limits, exclusions, coverage start date, documents required for a claim and the support route.

Should customer cyber cover be combined with the bank’s own cyber policy?

The two programmes should be coordinated but kept distinct. The institution’s policy addresses the organisation’s defined risks. Customer protection addresses defined customer benefits. Each needs its own eligibility rules, policy wording, disclosures, servicing process and claims assessment.

What should a partner capture at enrolment?

Collect only the information needed for eligibility, policy issuance, servicing and claims. Retain a retrievable record of relevant customer consent, policy delivery, coverage start date and customer communications. This creates a clearer servicing trail if a customer later needs support.

A cyber-cover readiness checklist for bank and fintech partners

Use this checklist before a tabletop exercise, renewal or embedded-product launch:

• [ ] Keep the current policy schedule, wording, endorsements and insurer contact matrix in one controlled location.
• [ ] Map critical data stores, APIs, SaaS services, processors and outsourced operations.
• [ ] Maintain a reportable-incident decision tree, including the CERT-In six-hour escalation path.
• [ ] Pre-appoint forensic, legal, communications and customer-support providers.
• [ ] Test insurer notification and emergency-consent procedures during tabletop exercises.
• [ ] Use a single incident ledger for decisions, evidence, vendors and costs.
• [ ] Prepare customer communication templates for suspected, confirmed and contained scenarios.
• [ ] Keep organisational cyber cover separate from customer protection benefits.
• [ ] Define the insurer, distribution arrangement, eligibility, disclosures, policy delivery and claim handoff for each customer programme.
• [ ] Review the programme after every incident, near miss or exercise.

Cyber resilience is an operating-design discipline across security, product, legal, compliance, communications and claims. SBI’s reported incident underlines the value of a response process that can act quickly without overstating preliminary findings. A disciplined approach gives a bank or fintech a stronger basis for protecting customers, meeting reporting obligations and presenting eligible costs under its policy. Book a demo to map a white-label cyber-protection journey and the claims workflow behind it for your bank or fintech customers.