AU Small Finance Bank Data Leak Probe: Third Party Risk Management Lessons

On 30 October 2026, AU Small Finance Bank said it is probing a possible data leak on a software-as-a-service (SaaS) platform. Salesforce manages and hosts the platform, which holds limited data on the bank's vehicle loan customers. The bank says its own systems are not affected. It has not said whether that platform is the source of the data a hacking group claims to hold. For anyone who runs third-party risk management, the lesson is already in that short statement.

A group calling itself ScarlettGroup claims to hold customer and internal data from AU Small Finance Bank. The claimed data includes Aadhaar and PAN details, KYC documents, and financial and loan information. A ransomware tracker logged the claim on 29 October. The claims have not been independently verified.

Look at where that data was held: on a vendor's platform, outside the bank's own systems. Whatever the investigation finds about the AU Small Finance Bank data leak, the customers on that platform are the bank's customers. Their questions go to the bank, not the vendor. You can hand a vendor your data. You cannot hand over your responsibility for it.

The AU Small Finance Bank Data Leak and a Busy October for Indian Data

On 21 October, India's largest public sector bank told the stock exchanges about an incident involving the loss of certain data. Alerts reached it on 16 October. The Hacker News reported that the records found on the dark web include names, mobile numbers, dates of birth, addresses, and loan-linked details. The source is still under investigation.

In the same month, a hacking group said it had taken mailboxes and identity records from a state police department. That claim is unverified. The Free Press Journal reported that the police cyber team is investigating and that officers were told to change their official email passwords.

In all three cases, the first public word came from outside the organisation: threat alerts, forum posts, and claims by the people offering the data. The first word on a breach is not always yours to give.

ScarlettGroup: Two Claims in Ten Days

ScarlettGroup appeared on a ransomware tracker against the police department on 21 October and against AU Small Finance Bank on 29 October. The tracker lists it as a new group, and the group has threatened to publish the data it claims to hold.

Data theft that encrypts nothing breaks nothing, so there is often no outage to notice. The first sign of trouble is the claim itself. Claims are made loudly to create pressure, which is why a claim deserves verification before it deserves repetition.

Data Security Is a Shared Responsibility

The first of the third-party risk management lessons is about who secures what. Salesforce has denied any vulnerability in its platform. What happened in the AU Small Finance Bank Salesforce case is for the investigation to establish, and nothing here suggests an answer. The denial is still a useful reminder of how data security works on any vendor's platform: it is shared.

Think of a bank locker. The bank secures the vault, the guards, and the cameras, while you decide who holds a key to your locker. If someone steals a key you handed out, the vault was never broken, and your locker is emptied all the same. A SaaS platform works the same way. The vendor secures the platform itself. Each customer decides which people and which connected apps can get into its account, and what they can see once inside.

A public case from August 2025 shows how this plays out. Salesloft, a sales software company, owns Drift, a chat tool that many companies connect to their Salesforce accounts. Attackers stole the digital keys that let Drift into those accounts and used them to pull data from hundreds of companies. Salesforce itself was not broken into. The way in was an app the customers had trusted with a key.

Forrester noted that companies which allowed access only from approved network addresses kept their data, even though they were targeted. That setting was in the customer's hands. A platform's security is the vendor's job. Who you let in is yours. That second half is third-party risk management.

Under DPDP, Your Vendor's Breach Is Your Breach

A vendor whose SaaS platform stores your customers' personal data on your behalf is your data processor, because storage counts as processing in the DPDP Act's own definition. Once the Act's duties apply on 13 May 2027, in a third-party data breach, three provisions put that processor's incident on your desk.

Section 8(1) makes a data fiduciary responsible for processing done on its behalf by a data processor, whatever the contract says. An indemnity clause moves money. It does not move accountability. Section 8(5) requires reasonable security safeguards for personal data in your possession or under your control, including data your processors handle, to prevent a breach.

Section 8(6) requires you to notify both the Data Protection Board of India and each affected Data Principal if a breach occurs. Rule 7 asks for an initial description to the Board without delay and a detailed report within 72 hours of becoming aware. The report covers the facts, causes, mitigation, findings on who caused the breach, remedial measures, and the notices sent to individuals. Most of those facts are held in your processor's systems, not yours.

The Act lets you use a data processor to offer goods or services only under a valid contract. Rule 6 requires that contract to provide for reasonable security safeguards. A contract that never obliges the vendor to share logs and findings quickly leaves you writing a Board report from the outside. That is why vendor contracts are often the biggest blind spot.

If nobody recorded what a vendor's integrations could read, the notice to each affected Data Principal cannot say what was exposed. Whoever is at fault, the notice carries your name.

Third Party Risk Management Lessons: What Good Looks Like

The AU Small Finance Bank probe shows why good third-party risk management is not a questionnaire filed at onboarding. It is a record that stays true as the relationship changes:

• Know which vendor holds which data, for what purpose, and which integrations can reach it. A data inventory is where that record starts.
• Sign contracts that support your DPDP duties. They should include the security safeguards Rule 6 requires, breach notice without delay with the facts for your Rule 7 report, and erasure on your instruction.
• Check access controls instead of assuming them. Look at connected apps and what each can read, admin accounts, and limits on where access can come from. Ask for evidence from the platform.
• Review risk when things change, such as a new integration, a renewal, or a breach claim naming the vendor.
• Plan a clean exit, with tokens revoked and deletion confirmed in writing. Once the specified purpose is no longer served, the Act requires you to cause your processor to erase the data you made available, unless the law requires retention. Rule 8(3) sets a one-year minimum for certain logs.

For a full programme, read the guide to incident management under DPDP and the DPDP compliance guide for 2026.

The 90-day implementation guide shows the order of work.

For vendor questions, read what a DPDP compliance platform needs to have in 2026 and IDfy's seven things an ideal DPDP solution should have.

How Privy’s DPG Helps You Govern Your Processors

Putting these third-party risk management lessons into practice is the work Privy by IDfy's Data Processor Governance (DPG) is built for. DPG governs your processors from onboarding to exit, so the questions a breach raises already have answers before anyone asks them.

• Know who holds what. Each processor is registered and mapped to its purposes and the personal data it holds. So "which vendors had our customers' data?" is answered from a record, not a scramble.
• Read the contract before you rely on it. Upload a processor's contract and DPG flags which clauses DPDP expects are present and which are missing, and pulls out the personal data and purposes it covers.
• Assess, then reassess. Run risk assessments on each processor and repeat them as the relationship changes. A completion score shows how far each vendor has moved through onboarding, assessment, and contracting.
• Track risk as it changes. Each engagement's risk is tracked over time: a contract missing the clauses DPDP expects, an assessment showing weak access controls, or a vendor whose onboarding has stalled.
• Act on breach signals. When a third party appears in breach-related activity, DPG raises a risk signal with the evidence behind it. The conversation with that vendor starts from facts, not headlines.
• Exit with proof. When consent is withdrawn, a purpose is met, or an engagement ends, DPG sends a deletion request to each mapped processor. The processor records its confirmation in its own portal, and each confirmation is kept in an audit log your DPO can rely on.

For the wider module, see Third-Party Risk Management and Incident Management.

Banks and NBFCs can start with our banks and NBFCs page. Any enterprise can start with the DPDP readiness assessment.

Why 60+ Enterprises Are Implementing Privy

Privy by IDfy has 60+ enterprise implementations in progress across banks, NBFCs, insurers, fintechs, healthcare, retail, telecom, and manufacturing. We think that makes Privy the best partner for governing processors, and we would rather you check than take our word for it. IDfy brings 15+ years of experience handling 50+ types of Indian personal data. Some programmes cover eight or more companies in one group. Privy is also ranked #1 in the MeitY-NeGD DPDP Innovation Challenge, and the official result has the details. Processor governance is one of 10 modules across 3 pillars, so you can start there and add the rest later.

Conclusion

A vendor's platform can be secure, and data can still leave through it. The Salesloft Drift case showed how: an integration nobody reviewed, or an access rule nobody set. Third-party risk management closes that gap, because it covers the keys platform security never sees.

These third-party risk management lessons from the AU Small Finance Bank probe come down to one question for your next vendor review. It is not whether the platform is secure. It is whether you know who can reach your customers' data through it. Your vendor secures the platform. You answer for the data.

To see how Privy by IDfy can govern your processors from onboarding to exit, book a demo or write to shivani@idfy.com.

FAQ's

What happened in the AU Small Finance Bank data leak probe?

On 30 October 2026, AU Small Finance Bank said it is probing a possible data leak involving a SaaS platform that Salesforce manages and hosts. The platform holds limited data on its vehicle loan customers. A hacking group, ScarlettGroup, claims to hold customer and internal data. The group's claims have not been independently verified.

Is the AU Small Finance Bank data breach confirmed?

The bank has said it is investigating a potential data leak. It says its own systems are not affected, and it has not said whether the platform is the source of the data the group claims to hold. Salesforce has denied any vulnerability in its platform.

What is third-party risk management?

Third-party risk management is the process of knowing which vendors hold your data, checking the controls around it, and reviewing the risk as the relationship changes. Under DPDP, it also covers contracts, breach notice, and proof of deletion.

Who is responsible after a SaaS data breach?

The vendor secures its platform. You decide who and which connected apps can get in, and you answer to your customers. A SaaS vendor that stores your customers' personal data on your behalf is a data processor. Under Section 8(1), you stay responsible for its processing, whatever the contract says.

What does DPDP require after a third-party data breach?

From 13 May 2027, you must tell the Data Protection Board without delay and send a detailed report within 72 hours. You must also tell each affected Data Principal. Most of the facts for that report are held by your processor, so your contract has to make the vendor share them quickly.

What should a vendor contract include under DPDP?

It should provide for reasonable security safeguards, as Rule 6 requires. It should also require breach notice without delay with the facts you need for your Rule 7 report, and erasure on your instruction.

What are the main third-party risk management lessons from a SaaS data leak?

The AU Small Finance Bank probe points to four lessons. Security is shared: the vendor secures the platform, and you decide who and which connected apps can get in. Keep a record of what each integration can read. Sign contracts that make the vendor share breach facts quickly. Plan a clean exit with deletion confirmed in writing.