How to Classify Personal Data Under the DPDP Act: A BFSI Guide

Every bank, NBFC and insurer in India holds personal data. Under the Digital Personal Data Protection Act, 2023 (DPDP Act), you must know what that data is and why you hold it. If you classify it wrong, you process data without a lawful basis, you fail an audit, and you risk a penalty. This guide shows BFSI teams how to classify data the way the Act expects — and how Promiz turns that classification into working controls, with every field tied to a purpose, a lawful basis and proof you can export on demand.

What counts as personal data under the DPDP Act

The DPDP Act uses one clear test. Personal data is any data about an individual who can be identified by that data, or in relation to it. If a field points to a real person, alone or in combination, it is personal data.

Some data is personal on its own:

• Name, phone number and email address
• PAN, Aadhaar number and customer ID
• Bank account number and card number
• Photograph and biometric records

Other data becomes personal only in combination. A single row in a report may look harmless. Join it to a name, a branch or a timestamp, and it identifies a customer. A loan amount, a device ID or a location trail all become personal data the moment they can point back to a person.

The point most guides get wrong: there is no “sensitive data” category

Many articles tell BFSI teams to sort data into “sensitive” and “non-sensitive” buckets. That advice comes from GDPR and from India’s older SPDI Rules, 2011. It does not match the DPDP Act.

The DPDP Act does not create a separate legal class for sensitive personal data. It treats all personal data under one definition. Financial data, health data and biometrics get no special statutory tier of their own. This is a deliberate change from the earlier regime.

So does sensitivity stop mattering? No. It still shapes two things:

• Significant Data Fiduciary (SDF) status. The Act uses the sensitivity and volume of the data you hold to decide if you are an SDF, which carries extra duties.
• The size of a penalty. After a breach, the type of data involved is a factor in how large the penalty is.

The takeaway for BFSI: do not build your programme around “sensitive vs non-sensitive” labels. Build it around one question — is this personal data, and what is my lawful basis for it? Then apply strong security to the data that would cause the most harm if it leaked.

Purpose drives classification

Under the DPDP Act, the same field can carry different duties, based on why you hold it. Purpose, not the field name, decides how you handle the data.

Take a mobile number. As a KYC field, you hold it on a legal obligation, and a customer cannot ask you to erase it while the law makes you keep it. As a marketing contact, you hold it on consent, and the customer can withdraw at any time. Same number, two purposes, two sets of rules.

This is why every data set needs three things tied to it: a clear purpose, a lawful basis, and a retention period. Without them, you cannot prove the data is lawful when the Data Protection Board asks.

How this looks in BFSI: five real cases

Notice the pattern. The hard part is not spotting a name. It is proving why you hold each field, and keeping that proof current as purposes change.

What misclassification costs

Under-classify a data set — treat personal data as harmless — and you skip the notice, the consent and the security you owe. That is unlawful processing. Under the DPDP Act, penalties can reach ₹250 crore for a failure to keep reasonable security safeguards. Failures around breach reporting and children’s data carry their own high penalties.

A practical way to classify your data

1. Map every field. List each data field, where it comes from, and which system holds it.
2. Apply the identifiability test. Can it point to a person, alone or combined? If yes, it is personal data.
3. Tie each set to one purpose and one lawful basis. Keep required purposes and optional purposes apart.
4. Set a retention period per purpose. Decide when the data must stop being used, and when it must be erased.
5. Flag children’s and guardian data. Data of a person under 18 needs verifiable guardian consent and limits on tracking.
6. Keep the proof. Store the notice version, the consent record and the deletion evidence for every data set.

When in doubt, classify up, not down. It is cheaper to hold a borderline field to a higher standard than to explain to the Board why you left it out.

Classification is step one. Promiz runs the rest.

Getting the labels right is the easy part. The legal risk sits in what happens next — proving what you showed, acting on a withdrawal across every system, erasing on time, and answering a rights request before the deadline. This is where most tools stop, and where Promiz is built to work.

Consent comes in from every channel — your website, forms, KYC desks, back-end API and email links. Promiz holds it as one chained, tamper-evident record, with each choice tied to a notice, a purpose and a deadline. When a customer withdraws, Promiz opens a stop-processing task and fires a signed webhook to your CRM, ad tools and partners at once, so no system keeps using data it may no longer touch. Retention clocks run per purpose. A breach starts a 72-hour countdown that ends in a structured report. When the Data Protection Board asks for proof, you export it the same day — the notice a customer saw, the consent they gave, and the date you erased their data.