DPDP for the Training and L&D department 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

Everyone who handles personal data needs short, practical training on what to do in their own job. Front-line staff need examples from their counter or desk. Managers need to know the clocks and their own duties. Management needs to know what to ask.

Branch staff need examples: KYC copies, walk-in requests, wrong sends.

Section 8(4) and 8(5) ask for appropriate technical and organisational measures. Training is part of showing those measures work. Section 8(5) · Rule 6

1. Group staff by what they handle: front line, back office, IT, managers, management.
2. Write three to five real scenarios for each group.
3. Keep sessions short: 20 to 30 minutes.
4. Test with a few questions, and record attendance.
5. Repeat every year, and at joining.

• Training plan by group
• Attendance and test results
• Scenario material

• One long legal lecture for all
• Training once and never again
• No record of attendance

Sending personal data to the wrong chat or a personal account is one of the most common breaches. Banning messaging rarely works. Give staff an approved tool that is easy to use, set simple rules, and make it safe to report a wrong send at once.

Relationship managers share lead lists and statements on chat. Give them a CRM route.

Section 8(5) asks for reasonable safeguards. A wrong send is a breach under Section 2(u), and Section 8(6) applies. Section 8(5) · Rule 6 · Section 8(6) · Rule 7

1. Ask teams how they actually share files and photos today.
2. Provide an approved tool for that job.
3. Set three simple rules: approved tool, no personal accounts, report wrong sends.
4. Teach the rules with real examples from your own work.
5. Treat a quick report as good behaviour, not a disciplinary case.

• Approved-tool policy
• Training record
• Incident reports of wrong sends

• A ban with no alternative
• Punishing people who report
• Ignoring group chats with vendors

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

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

Usually not for normal employment purposes. Section 7(i) lets you process employee data for employment, such as payroll, attendance, safety and preventing corporate espionage. Anything beyond that, such as wellness apps, photos for marketing or sharing with a bank for offers, needs consent.

Background and credit checks on staff are employment purposes; explain them in the staff notice.

Section 7(i) covers employment purposes and safeguarding the employer from loss or liability. Notice, security, retention and rights still apply to employees. Section 7 · Section 5 · Rule 3 · Section 8(7) · Rule 8 · Sections 11–14 · Rule 14

1. List what you collect from staff and why.
2. Mark which items are employment purposes and which are extra.
3. Take consent for the extras, separately.
4. Give staff a short employee privacy notice.
5. Set retention for ex-employee records.

• Employee data list with basis
• Employee privacy notice
• Consent for extras

• A blanket consent clause in the offer letter
• Keeping candidate data forever
• Sharing staff data with vendors without terms

No. A policy shows what an organisation intends. It does not show that the control runs. To show operation you need records: a deletion log, an access review sign-off, a drill report, a sample of requests answered on time. Auditors and regulators look for these.

Section 8(4) asks for appropriate technical and organisational measures to ensure compliance. Being able to show those measures work is part of meeting that duty. Section 8(5) · Rule 6 · Section 8(1)–(2)

1. For each policy, write the record that would show it working.
2. Check whether that record exists for the last quarter.
3. Where it does not, start producing it.
4. Sample a few records every quarter.
5. Keep the samples with the policy.

• Policy-to-record map
• Quarterly samples
• Gaps and actions

• Approving policies with no record behind them
• Showing a policy when asked for evidence
• Records that exist only before an audit