Data anonymisation: shrinking India's breach exposure

9 minutes ago

5 min read

On 21 October 2026, State Bank of India told the stock exchanges that it had reviewed about 375,000 records found on the dark web and identified 3,897 containing customer data: names, mobile numbers, dates of birth, email and home addresses. The attacker claims to also hold 2,722 PDFs, including loan applications and KYC forms. SBI hasn't said yet where the data came from.

Four months earlier, the ransomware group World Leaks published more than 200,000 files from Tata Electronics, over 630 GB including employee passport copies, component designs, and supplier bids. In July, a dark-web listing offered more than 700 GB of alleged Bank of Baroda data. The bank confirmed that an employee's email account had been compromised, and said its core banking systems were not accessed.

A bank, a manufacturer, and another bank. Different data, different attackers. What surfaced each time was files: exports, scanned forms, documents. None of these stories reads like someone cracking the core system head-on.

Many Indian companies still file breaches under "happens to someone else". The numbers disagree. IBM puts the average cost of a breach in India at ₹22 crore in 2025, the highest it has ever recorded. And the regulatory clock is running. The DPDP Rules were notified in November 2025, and most obligations under the Digital Personal Data Protection Act apply from mid-May 2027. From then on, failing to take reasonable security safeguards can cost up to ₹250 crore. A breach has to be reported to the Data Protection Board without delay, with a detailed report within 72 hours.

So the useful question for any CIO or DPO in India is simple: where does your personal data actually sit, and how much of it needs to be real?

Your data lives in more places than you protect

Production systems get the attention: firewalls, access control, monitoring, audits. But production is rarely the only place your customer data lives.

Take a typical loan-origination system at an Indian bank. Production runs in a secured data centre. Every month, a full copy is refreshed into a UAT environment so the IT vendor can test the next release. The analytics team has its own sandbox with a few years of history. Collections receives a weekly Excel extract. An auditor gets a folder of scanned KYC documents. The offshore support team can log into the test system to reproduce bugs.

The same customer now exists in six places. Production is the best protected. Each copy after that has fewer controls, more people with access, and less monitoring.

This isn't a niche problem. In a 2025 industry survey, 60% of organisations reported breaches or data theft in their development, AI, or analytics environments, a clear rise on the year before. 84% still allow compliance exceptions for non-production data.

Every format has its own weak spot

Personal data doesn't only sit in databases. It moves through spreadsheets, PDFs, images, and chat windows, and each format comes with a different level of protection.

Format	Where it typically sits	Usual protection	Typical gap
Production database	Core banking, ERP, CRM	Roles, encryption, monitoring	Strong, but every user with access sees real data
Database copy	UAT, QA, dev, training systems	Weaker roles, shared accounts	Vendors and offshore teams see real customers
Exports (CSV, Excel)	File shares, laptops, email	Often none	No access log, no expiry, easy to forward
Documents and scans	DMS, audit folders, KYC archives	Folder permissions	Faces, signatures, ID numbers in plain view
Attachments and chat	Email, messaging apps	Mailbox security	Copies multiply with every forward
AI prompts and uploads	GenAI tools, often unapproved	Usually none	Data leaves the company with one paste

The further a record travels from production, the less anyone knows where it is. Look again at what the attacker in the SBI case claims to hold: CSV rows and PDF forms.

How data actually gets out

IBM's 2025 data for India shows the most common starting points: phishing (18% of breaches), third-party vendors and the supply chain (17%), and exploited vulnerabilities (13%). On average, a breach in India took 263 days to identify and contain. Recent Indian cases match that pattern closely.

Stolen credentials. A phished password or a hijacked mailbox opens the door. Bank of Baroda's 2026 incident started with a compromised employee email account.
Third parties. In 2024, ransomware at banking technology provider C-Edge disrupted payment services at about 300 cooperative and regional rural banks. Every vendor with access to your test system is part of your attack surface.
Misconfiguration. Also in 2024, a technical glitch at ICICI Bank showed the details of about 17,000 new credit cards to the wrong customers. No attacker needed.
Hack-and-leak extortion. Groups like World Leaks copy what they can reach, then publish it if nobody pays. Tata Electronics was hit this way in June 2026.
Shadow AI. Staff paste customer lists into public AI tools. IBM found that shadow AI added ₹1.79 crore to the average breach cost in India, and only 42% of organisations have policies to manage it.

Attackers go where protection is thinnest. In most companies, that's a copy.

What anonymisation changes

Anonymisation replaces personal data with realistic values that no longer point to a real person. Ramesh Kumar from Pune becomes another plausible name in another city. His mobile number, date of birth, and PAN follow. Done well, the replacement stays consistent across every system, so a test of the loan workflow still works end to end.

Encryption protects data in storage and in transit. Anyone with legitimate access still sees the real customer: the tester at the vendor, the analyst, the support engineer with a stolen password. An anonymised copy holds far less worth stealing about real people.

A simple rule follows from this. If a system doesn't need real people, it shouldn't hold real people. That covers most test, training, and analytics environments, most document sharing with partners, and almost every AI prompt.

Diagram: a production system with real customer data, an anonymisation step, and six copies (test and UAT, dev and training sandboxes, analytics, Excel and CSV exports, documents and scans, AI prompts) that receive anonymised data

The DPDP Rules point in the same direction. Their list of reasonable security safeguards names encryption, obfuscation, masking, and virtual tokens mapped to personal data. Anonymised non-production data is one of the most direct ways to show that you took those safeguards seriously.

Anonymisation won't stop an attacker from getting in. A leaked anonymised test database is still an IT incident. In most cases, it isn't a list of thousands of real customers that you have to report to the Board within 72 hours and explain to every person affected.

Where Maya fits

Maya anonymises data in place, inside your own environment, so personal data never leaves it for processing.

AppSafe™ anonymises databases and applications, including SAP and non-SAP landscapes, so test, training, and analytics systems get production-like data without real customers in it.
FileSafe™ anonymises Excel files, PDFs, and images, so documents can go to vendors, auditors, and partners without exposing people.
AISafe™ removes personal data before it reaches a generative AI tool.

Together they support DPDP compliance across the places where most leaks start.

Start with one question: how many copies of your customer data exist today, and who can see them? If the answer takes longer than a minute, talk to the Maya India team.