DPDP for the Product head in BFSI

Under PMLA and RBI's KYC Master Direction, keep identity records for at least five years after the relationship ends, and transaction records for at least five years from the transaction. During that time, keep them only for that legal purpose. After it, erase or anonymise unless another law requires more.

Section 8(7) allows retention where a law requires it. PMLA and RBI's KYC rules are such laws. Section 8(7) · Rule 8 · Section 7

1. List KYC and transaction record types.
2. Set the start date: end of relationship or date of transaction.
3. Restrict access to closed-account records.
4. Erase or anonymise after the period.
5. Explain this in erasure replies.

• Retention schedule
• Access restrictions on closed accounts
• Deletion logs

• Keeping everything for ever
• Deleting before the legal period
• Using closed-account data for marketing

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

Ask four questions at the design stage: what personal data, why, for how long, and who sees it. Then build in what the Act assumes: a notice, consent where needed, role-based access, logs of record views, a way to delete, and a way to answer requests. Adding these after launch costs far more.

Sections 5 to 12 assume systems that can show notices, record consent, limit access, log, delete and answer requests. Section 5 · Rule 3 · Section 6 · Section 8(5) · Rule 6 · Section 8(7) · Rule 8 · Sections 11–14 · Rule 14

1. Add the four questions to design templates.
2. Drop data you do not need.
3. Build access roles and record-view logs.
4. Build deletion and request export.
5. Register the system in the inventory at launch.

• Design review records
• Inventory entries
• Deletion tests

• Privacy review only at launch
• Collecting 'in case we need it'
• No delete function

Yes, where the use fits the purpose people were told, or you have consent for it. Improving the service people signed up for usually fits. Selling insights, profiling for third parties or targeting children does not. Mask or aggregate wherever the question allows, and give analysis copies their own deletion date.

Section 4 needs a lawful basis for each purpose. Section 6 needs specific consent. Section 9 bars behavioural monitoring of children. Section 8(3) asks for accuracy when data drives decisions. Section 4 · Section 6 · Section 9 · Rules 10, 12 · Section 8(3)

1. Write the question and the data needed.
2. Check the purpose people were told.
3. Mask or aggregate by default.
4. Get consent for uses outside the purpose.
5. Set a deletion date for the copy.

• Purpose checks
• Data specifications
• Retention entries

• Using all data because it is there
• Analysis copies with no end date
• Profiling children

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

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

Withdrawal must be as easy as giving consent. Once someone withdraws, you and every vendor working for you must stop that use within a reasonable time. What was done before withdrawal stays lawful, and data that a law requires you to keep is kept.

A customer taps 'stop offers' in the app. The dialler, SMS tool and partner insurer must all stop within a day.

Section 6(4) to 6(6) give the right to withdraw at any time, with the same ease, and require processors to stop as well. Section 8(7) then asks for erasure unless a law requires retention. Section 6 · Section 8(7) · Rule 8 · Section 8(1)–(2)

1. Give one simple way to withdraw on every channel where consent is taken.
2. Record the withdrawal against the person and the purpose.
3. Push the change to every system and vendor that uses that purpose.
4. Confirm to the person, in writing, what has stopped and what is kept by law.
5. Check a sample every month to see that the change actually reached every list.

• Withdrawal log with time stamps
• Proof that downstream systems and vendors updated
• Confirmation sent to the person

• Withdrawal by email only, while consent was one tap in an app
• Stopping in the main system but not in vendor lists
• Deleting records a law requires you to keep

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

By law, only Significant Data Fiduciaries must do a yearly impact assessment. For everyone else it is good practice for high-risk changes: new tracking, profiling, large data sharing, children's data or moving data abroad. A short assessment before the change is cheaper than fixing it later.

Section 10 and Rule 13 require a yearly impact assessment for Significant Data Fiduciaries. Section 10 · Rule 13 · Section 9 · Rules 10, 12 · Section 16 · Rule 15

1. Define what counts as a high-risk change for you.
2. Use a two-page template.
3. Record the data, purpose, risks and safeguards.
4. Get the DPO's view before approval.
5. Keep it with the project record.

• Assessment template
• Completed assessments
• DPO views

• Treating it as paperwork after launch
• A 40-page template nobody completes
• No trigger list

Send a summary of the personal data you hold about them and what you do with it, and the names of the other organisations you shared it with and what was shared. Check the person's identity first, log the request and keep a copy of your reply.

The summary should list partner insurers, credit bureaus and collection agencies that received data.

Section 11 gives the right to a summary and the list of organisations it was shared with. Rule 14 asks you to publish how requests are made and to answer within the period you publish. Sections 11–14 · Rule 14 · Section 8(9)–(10) · Rules 9, 14

1. Log the request in one register the day it arrives.
2. Verify identity using details you already hold.
3. Search every system, including vendors' copies.
4. Write a plain summary: what data, why it is used, who received it.
5. Send it, and file the request, search notes and reply.

• Request register
• Search notes for each request
• Copy of each reply with date

• Sending raw database dumps
• Forgetting data held by vendors
• No identity check before sending