A Bank's Vendor Platform Leak: Is Your CRM Software Holding Too Much?

Originally published at ictcrm.com

An Indian bank says its own systems are fine after a possible leak from a vendor-hosted platform that held vehicle loan onboarding data for about 2.85 million customers. That's the lesson for anyone running CRM software: a breach of the hosted platform still exposes your customers. Before the next headline, list what sensitive data sits in your CRM, who holds its keys, and whether it needs to be there.

AU Small Finance Bank said it became aware of the possible leak on 29 October 2026. In a statement reported by PTI on 30 October, it said it was "investigating a potential data leak involving a software-as-a-service (SaaS) platform managed and hosted by Salesforce, which holds limited data relating to our vehicle loan customers". It added that its own systems were unaffected and banking services were running normally.

What we know so far

On 2 November the bank filed a clarification with the stock exchanges. According to reports of that filing, the platform is hosted and managed by a third-party vendor and was used to onboard about 28.5 lakh, or 2.85 million, vehicle loan customers. The filing doesn't name the vendor. Only the earlier media statement named Salesforce. The bank has told the Reserve Bank of India and CERT-In, India's cyber emergency team, and a forensic investigation is under way.

A group calling itself ScarlettGroup has claimed responsibility and threatened to publish data. It says it has KYC documents, PAN and Aadhaar details, credit reports, bank statements, loan applications, signed agreements, CRM data and login histories. None of that has been confirmed.

Two things haven't been disclosed, and it's worth being careful about them:

• How many records were exposed. 2.85 million is the number of customers onboarded through the platform, not a count of stolen records.

• How the attackers got in. There's no public report that Salesforce itself was breached or had a flaw. Many SaaS incidents come down to a customer's own accounts, connected apps or integration tokens, but nobody has said what happened here.

"Our systems are unaffected" isn't the reassurance it sounds like

The bank's core banking may well be untouched. But the data the attackers say they have, if real, is the most sensitive data a lender holds about a borrower. It didn't need to be in the core system to be exposed. It sat on a platform the bank rented, and that platform was where customers were onboarded.

That pattern is common. Sales and onboarding teams move fast, and the CRM becomes the easiest place to keep everything about a customer, including the documents. Over a few years, a tool meant for tracking contacts and deals ends up holding ID scans, credit reports and signed contracts. The security review that covered the core system never looked at it.

There's also the question of who's responsible. With a hosted CRM, the vendor runs the platform, but you still decide what goes into it, who can sign in, which apps are connected and how long data is kept. A regulator will ask you about those choices, not your vendor.

What to check in your own CRM software

You don't need to wait for the forensic report to act on this. Here's the review we'd run this week.

Sort the data into three bins

Go through your CRM's objects, custom fields and file attachments and put each one in a bin. The first bin is what you need to sell and serve: names, numbers, deal stages, call history, opt-outs. The second is sensitive and rarely needed: ID numbers, ID scans, credit reports, bank statements, signed agreements. The third is the keys to everything else: API keys, OAuth tokens, admin accounts and export rights.

Move the middle bin out, or lock it down

Most sales and service work never needs the ID scan or the credit report. Store those in a document system you control, and keep only a reference in the CRM. If they must stay, limit them to the few roles that actually use them, and turn off bulk export for those fields.

List every connected app and token

Every integration that syncs with your CRM, whether that's a dialer, a marketing tool, a document signer or a reporting app, holds a token that can read data. Make a list. Revoke anything nobody can explain, rotate the rest, and check which ones can read everything when they only need a few fields.

Review admins and exports

Count the admin accounts. Check that each one belongs to a current person, uses strong sign-in, and is still needed. Then look at who can run reports or exports across all records. A leak doesn't always need an attacker inside the platform. A single over-privileged account will do.

Set retention for onboarding data

Onboarding documents are needed during onboarding. Ask how long they need to stay in the CRM after that. Data you've already deleted can't leak.

Where ICTCRM fits

ICTCRM is open source CRM software built on ICTContact, so the CRM, the dialer and the campaign tools are one platform. You can run it on your own server or start on our cloud. Self-hosting doesn't make a system secure by itself, but it does put the data, the backups and the logs on infrastructure you choose, and it means one less vendor platform holding your customer records.

A few specifics that map to the checks above:

• Logins and tenants are separate. Each user login gets a role, and a client login sees its own campaigns, contacts and reports, but not Administration. The client management guide explains how clients and users differ.

• Connector credentials are visible in one place. CRM connectors for tools such as Zoho, Salesforce, Pipedrive and Agile CRM store either an OAuth refresh token or an API key, and each connector only appears to users with the matching permission. That makes the token list in step three quick to build. The CRM integrations guide lists the fields for each connector.

• The contact record stays lean. ICTCRM is built around contacts, calls, messages and campaigns, so it has no reason to hold ID scans or credit reports. Keep those in the system made for them.

We've written before about how CRM data privacy and the 2026 state laws affect self-hosted setups, and about a CRM outage that took a vendor's support portal down with it. This case is the security side of the same question: who controls the platform your customer data lives on.

Whatever CRM you use, start with the three-bin list. If the middle bin is bigger than you expected, that's the first thing to fix.

Frequently asked questions

Was Salesforce hacked?

Nothing published says so. AU Small Finance Bank said the affected platform was managed and hosted by Salesforce, but how the data was accessed hasn't been disclosed, and the bank's stock exchange filing doesn't name the vendor.

How many customers were affected?

The bank says about 2.85 million vehicle loan customers were onboarded through the platform. It hasn't said how many records were actually exposed.

What data did the attackers take?

ScarlettGroup claims it has KYC documents, ID numbers, credit reports, loan documents and CRM data. Those claims haven't been verified by the bank or by regulators.

Is self-hosted CRM software safer than SaaS?

Not automatically. A self-hosted CRM can be breached too. What changes is control: you decide where the data, backups and logs live, who can reach the server and which apps connect to it.

What's the first thing to check in our CRM?

Look for sensitive documents and ID numbers stored in contact records or attachments, then list every connected app and token. Those two checks cover most of the exposure in cases like this one.