DPDP for the Legal & compliance in BFSI

Only with specific consent for that purpose. Account opening terms do not count as consent to receive offers or to have data shared with a partner insurer or fund house. Service messages about the customer's own account are different and do not need marketing consent.

Section 6 needs specific consent for each purpose. Section 5 needs a notice that names the purpose. Section 6 · Section 5 · Rule 3 · Section 8(1)–(2)

1. Separate service messages from offers in your systems.
2. Ask consent for offers and partner sharing separately, by channel.
3. Record consent by purpose and partner.
4. Check the record before each campaign.
5. Pass withdrawals to partners the same day.

• Consent records by purpose and partner
• Campaign approval with consent check
• Withdrawal logs

• Using account terms as consent
• Partners calling from their own lists
• Withdrawal not reaching partners

• When do we need consent, and when can we rely on a legitimate use?
• Someone withdraws consent. What has to stop, and how fast?
• Can we send offers to past customers and leads?

Collection agents act for you, so you are responsible for what they do. They should get only the data needed to contact the borrower, use it only for collection, and never share the debt with family, friends or employers. RBI's rules on recovery conduct, including calling hours, apply alongside DPDP.

Section 8(1) and 8(2) make you responsible for processors. Section 8(5) needs safeguards. Section 8(1)–(2) · Section 8(5) · Rule 6 · Section 6

1. Share only name, contact details and the amount due.
2. Put data terms and conduct rules in every agency contract.
3. Record calls and review a sample.
4. Ban use of the borrower's phone contacts.
5. Take back or delete data when the account closes.

• Agency contracts
• Call review records
• Data return certificates

• Sending full loan files to agencies
• Agents calling relatives
• No deletion after the account closes

• What must a vendor contract say about personal data?
• What about call recordings and customer service screens?
• How do we handle a privacy complaint within 90 days?

Only what you need, with explicit consent. RBI's Digital Lending Directions already bar access to contacts, files, media and call logs, and allow one-time access to camera, microphone or location for onboarding or KYC. DPDP adds a notice, the right to withdraw and the right to know what was collected.

Section 6 needs consent limited to what is necessary. RBI's Digital Lending Directions, 2025 set specific limits. Section 6 · Section 5 · Rule 3 · Section 8(5) · Rule 6

1. List every permission the app asks for.
2. Remove permissions not needed.
3. Ask camera and location only at the KYC step.
4. Show the notice in the app before sign-up.
5. Check partner apps the same way.

• Permission list with reasons
• App store listing
• Partner app review

• Contacts permission for 'reference checks'
• Third-party analytics SDKs collecting device data
• Partner apps not reviewed

• What should our privacy notice say, and where must people see it?
• When do we need consent, and when can we rely on a legitimate use?
• What must a vendor contract say about personal data?

For every use of personal data you need one basis: consent, or one of the legitimate uses in Section 7, such as a legal duty, employment, a medical emergency, or data a person gave voluntarily for a specific purpose. Anything beyond what the person expects, such as marketing, profiling or sharing with partners, usually needs consent.

KYC is a legal duty. Loan servicing uses data the customer gave for the loan. Cross-selling insurance needs separate consent.

Section 4 allows processing only with consent or for a legitimate use. Section 6 sets what valid consent looks like. Section 7 lists the uses that need no consent. Section 4 · Section 6 · Section 7

1. List each purpose for which you use personal data.
2. Against each purpose, write the basis: consent or the exact clause of Section 7.
3. Where the basis is consent, check that it was asked separately, with a clear action and no pre-ticked box.
4. Stop or re-paper any purpose with no basis.
5. Review the list whenever a new product, campaign or system starts.

• Purpose and basis register
• Consent records with date, version and channel
• Legal sign-off on each legitimate use relied on

• Treating account terms as consent for marketing
• Bundling several purposes in one tick-box
• Relying on 'legitimate interest', which the Indian Act does not have

• What should our privacy notice say, and where must people see it?
• Someone withdraws consent. What has to stop, and how fast?
• Can we send offers to past customers and leads?

A notice must tell people, in plain words, what data you collect, why, how they can withdraw consent, how they can use their rights and how they can complain to the Data Protection Board. It has to stand on its own, separate from long terms and conditions, and be shown at the point where data is collected.

A bank's account opening form, its mobile app sign-up and its loan application each need their own short notice, separate from the terms and conditions.

Section 5 and Rule 3 ask for a notice that can be understood on its own, with an itemised list of the data and the purpose for each item. Data you already hold from before the Act also needs a notice, as soon as reasonably practicable. Section 5 · Rule 3 · Section 6 · Sections 11–14 · Rule 14

1. List every point where personal data comes in: forms, apps, counters, calls, emails, partner feeds.
2. Write one short notice per collection point, with the data items and purpose side by side.
3. Add how to withdraw consent, how to make a request and the DPO or contact person's details.
4. Offer the notice in English and in the languages your customers actually use.
5. Keep each version with the date it went live.

• Screenshots or copies of the notice at each collection point, with dates
• Notice version history
• Translations, where used

• Hiding the notice inside terms and conditions
• One notice for everything, with no link between data items and purposes
• Forgetting old data collected before the Act

• When do we need consent, and when can we rely on a legitimate use?
• Someone withdraws consent. What has to stop, and how fast?
• Someone asks what data we hold about them. What do we send?

You stay responsible for what your vendors do with personal data. The contract should say what data they get, for what purpose, the security they must keep, how fast they must tell you about an incident, that sub-contractors need your approval, and how data is returned or deleted at the end.

Collection agencies, BCs, DSAs, KYC vendors, card processors and the core banking vendor all need data schedules aligned with RBI outsourcing rules.

Section 8(1) keeps responsibility with you. Section 8(2) allows a processor only under a valid contract. Rule 6 asks for security terms in that contract. Section 8(1)–(2) · Section 8(5) · Rule 6 · Section 8(6) · Rule 7 · Section 8(7) · Rule 8

1. List vendors who receive or can see personal data.
2. Rank them by how much and how sensitive.
3. Add a data-protection schedule to each contract, starting with the top ten.
4. Ask for evidence: certificates, test results, deletion confirmations.
5. Review the top vendors every year.

• Vendor register
• Signed data-protection schedules
• Annual review notes

• Relying on the vendor's standard terms
• No incident-notice time
• No exit and deletion clause

• Something has gone wrong. What happens in the first 72 hours?
• Can personal data be stored or accessed outside India?
• Does deletion have to reach backups and test copies?

You are a Data Fiduciary when you decide why and how personal data is used, as you do for your own staff and customers. You are a Data Processor when you handle data only on another organisation's instructions. Many organisations are both, for different data sets.

In co-lending or bancassurance, both parties may decide purposes. Write down who is fiduciary for what.

Section 2(i) and 2(k) define the two roles. Section 8(1) puts the duties on the Data Fiduciary, which must use processors only under a valid contract. Section 8(1)–(2) · Section 17(1)(d)

1. List each data set you handle.
2. For each, ask: who decides the purpose?
3. Mark yourself as fiduciary or processor, and name the other party.
4. Check that contracts match the role.
5. Route requests about processor data to the fiduciary.

• Role register by data set
• Contracts matching the role

• Calling yourself a processor for data you use for your own purposes
• No contract when you act as processor
• Answering requests that belong to your client

• What must a vendor contract say about personal data?
• Someone asks what data we hold about them. What do we send?
• Can personal data be stored or accessed outside India?

Anyone under 18 is a child under the Act. For a child's data you need verifiable consent from a parent or lawful guardian, and you must not track, behaviourally monitor or show targeted ads to children. Some classes and purposes are exempt under Rule 12 and the Fourth Schedule, for example healthcare to the extent needed to protect the child's health, and educational institutions for their educational work.

Minor savings accounts and student loans involve children's data. Parent consent and no targeted offers apply.

Section 9 sets the duties. Rule 10 explains how to verify the parent. Rule 12 and the Fourth Schedule list the exemptions. Section 9 · Rules 10, 12 · Section 6

1. Find where children's data enters: customers, dependants, interns, visitors, scholarships, app sign-ups.
2. Decide whether an exemption in the Fourth Schedule applies to that purpose.
3. Where none applies, add an age question and a parent-consent step.
4. Switch off tracking and targeted ads for under-18 users.
5. Record the decision for each channel.

• Channel-by-channel note on children's data
• Parent-consent records
• Ad and tracking settings

• Assuming 'we are B2B, so no children'
• Using the age 13 or 16 from foreign laws
• Treating a tick-box from the child as parental consent

• When do we need consent, and when can we rely on a legitimate use?
• What should our privacy notice say, and where must people see it?
• Can we send offers to past customers and leads?

Check that the request is in writing, comes from the right authority and cites the legal power. Share only what is asked for, record what you sent and to whom, and keep the request on file. The Act allows processing to meet a legal duty, but it does not mean sharing everything on a phone call.

Banks receive many police and tax requests. Route them all through one desk.

Section 7(d) and 7(e) allow processing to meet a legal duty to disclose to the State, or to comply with a judgment or order. Section 17(1)(c) exempts processing for preventing, detecting or investigating offences. Section 7 · Section 8(5) · Rule 6

1. Route every such request to Legal.
2. Check the authority, the legal power and the scope.
3. Share only what is asked, by a secure method.
4. Log the request, what was sent, by whom and when.
5. Tell the person, unless the law or the authority says you must not.

• Authority request log
• Copies of requests
• Record of what was sent

• Sharing on a phone call
• Sending whole files when a few lines were asked
• No log

• Someone asks what data we hold about them. What do we send?
• How long can we keep personal data?
• Something has gone wrong. What happens in the first 72 hours?

You must erase data that you no longer need for the purpose it was collected for, unless a law requires you to keep it. Where a law does require it, keep the data, stop using it for anything else, and tell the person why it is being kept and until when.

Closed-account KYC and transaction records stay for the PMLA period; offers and profiling stop at once.

Section 12 gives the right to correction and erasure. Section 8(7) allows retention only where a law requires it. Rule 8(3) asks every organisation to keep personal data and logs for at least one year first. Sections 11–14 · Rule 14 · Section 8(7) · Rule 8

1. Log the request and verify identity.
2. Check the retention schedule for each record type involved.
3. Delete what has no legal reason to stay, including copies with vendors and in test systems.
4. Mark what must stay, with the law and the end date.
5. Reply in plain words: what was deleted, what is kept, why and until when.

• Erasure log
• Vendor deletion confirmations
• Reply to the person

• Refusing every erasure request 'because of backups'
• Deleting records a law requires
• Not telling vendors

• How long can we keep personal data?
• Does deletion have to reach backups and test copies?
• Someone asks what data we hold about them. What do we send?