DPDP for the DPO / Privacy lead 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?

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

• How long can we keep personal data?
• Someone asks us to delete their data. Must we?
• Does deletion have to reach backups and test copies?

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?

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?

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

• How do we handle a privacy complaint within 90 days?
• Someone asks us to delete their data. Must we?
• Where does personal data live in our organisation?

Publish one clear way to complain, log every complaint, give it an owner and reply within the period you publish, never more than 90 days. People can go to the Data Protection Board only after using your process, so a good process keeps most matters with you.

A privacy complaint may also reach the RBI Ombudsman. One log, tagged for both, avoids two different answers.

Section 8(10) requires a working grievance process. Rule 14(3) caps the reply time at 90 days. Section 13 says people must use your process before approaching the Board. Section 8(9)–(10) · Rules 9, 14 · Sections 11–14 · Rule 14 · Sections 18–26

1. Publish one contact for privacy complaints on your website, app and notices.
2. Log each complaint with the date, channel and a named owner.
3. Acknowledge within a few days, and set an internal target well under 90 days.
4. Find and fix the cause, not just the single case.
5. Reply in writing and close the entry with the date.

• Complaint register with dates
• Replies sent
• Monthly summary to management

• Mixing privacy complaints into general complaints with no tag
• No owner, so nobody counts the days
• Closing a complaint without fixing the cause

• Someone asks what data we hold about them. What do we send?
• Someone asks us to delete their data. Must we?
• Someone withdraws consent. What has to stop, and how fast?

Keep data for as long as its purpose needs, or as long as a law requires, and then erase it. Every organisation must keep personal data and logs for at least one year under Rule 8(3). Write a retention schedule by record type, with the law or reason against each period.

PMLA and RBI KYC rules set the floor at five years for identity and transaction records.

Section 8(7) asks for erasure when the purpose is over, unless a law requires retention. Rule 8(3) sets a one-year minimum for personal data, traffic data and logs. Section 8(7) · Rule 8 · Section 8(5) · Rule 6

1. List the record types you hold.
2. Write the period for each, with the law, regulator rule or business reason.
3. Set a trigger for the period to start: end of relationship, date of transaction, exit date.
4. Automate deletion where you can; for paper, schedule shredding.
5. Keep a deletion log.

• Retention schedule approved by Legal
• Deletion log
• Shredding or disposal certificates

• 'Keep everything forever' because storage is cheap
• Deleting before the legal minimum
• Forgetting email, shared drives and backups

• Someone asks us to delete their data. Must we?
• Does deletion have to reach backups and test copies?
• Where does personal data live in our organisation?

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?

Contain it, then tell people. A reportable cyber incident goes to CERT-In within six hours of being noticed. Under DPDP, each affected person and the Data Protection Board must be told without delay, and the Board needs a detailed report within 72 hours. Sector regulators may have their own clock too.

A partner API leak may need CERT-In in six hours, your regulator's report, and the DPDP messages.

Section 8(6) and Rule 7 set the DPDP steps. The CERT-In Directions of 28 April 2022 set the six-hour report. A breach includes accidental disclosure and loss of access, not only hacking. Section 8(6) · Rule 7 · Section 8(5) · Rule 6

1. Name one incident lead and a back-up, with phone numbers that work at night.
2. Write the first-hour steps: isolate, preserve logs, tell the DPO and the incident lead.
3. Keep ready-made drafts for CERT-In, the regulator, the Board and affected people.
4. Decide in advance who signs off each message.
5. Rehearse once a year with the people who would actually be called.

• Incident plan with clocks
• Rehearsal record
• Incident log with times of each step

• Waiting to finish the investigation before telling anyone
• Treating a wrong email or a lost laptop as 'not a breach'
• Only IT knowing the plan

• Which logs must we keep, for how long, and where?
• What must a vendor contract say about personal data?
• Does deletion have to reach backups and test copies?

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?