DPDP for the CTO / Engineering 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

Usually in more places than anyone expects: core systems, email, shared drives, laptops, vendor systems, backups, test copies, spreadsheets and paper. A simple inventory, one row per system, is the base for every other duty.

Include data warehouses, CRM, call centre tools and partner platforms, not only core banking.

Every duty in Sections 5 to 12 assumes you know where the data is. Rule 6 needs safeguards for each system, and Section 11 needs you to find the data when someone asks. Section 8(5) · Rule 6 · Sections 11–14 · Rule 14 · Section 8(7) · Rule 8 · Section 3

1. List systems, then shared drives, email, spreadsheets and paper stores.
2. For each one, note whose data, which items, purpose, owner, hosting location and vendors.
3. Add copies: backups, test, analytics.
4. Get each owner to confirm their rows.
5. Update it whenever a system is bought or retired.

• Data inventory
• Owner confirmations
• Change log

• A 200-column spreadsheet nobody finishes
• Leaving out SaaS tools bought by departments
• No owner for each row

Deletion should reach every copy you control. For backups, the usual practice is to let deleted records expire with the normal backup cycle, never restore them into live use, and write this down. Test and training copies should use masked data.

Core banking backups often run for years. Match backup retention to the record schedule.

Section 8(7) asks for erasure. Rule 6 asks for backups for continuity. The two meet in a backup retention rule that is short enough and written down. Section 8(7) · Rule 8 · Section 8(5) · Rule 6

1. List where copies live: backups, replicas, test, analytics, laptops, vendors.
2. Set backup retention to match the retention schedule.
3. Write a rule: deleted records are not restored into live systems.
4. Mask personal data in test and training copies.
5. Get deletion confirmations from vendors.

• Backup retention settings
• Written backup-expiry rule
• Masking procedure for test data

• Ten-year backups for convenience
• Live copies in test
• Restoring old backups and bringing deleted records back

Only people who need it for their job, and only the part they need. Use named accounts, give access by role, review it every quarter and remove it on the day someone leaves. Watch privileged accounts closely.

Mark staff and VIP accounts so only a small team can view them.

Rule 6 names access control as a minimum safeguard, along with logs and monitoring that can detect misuse. Section 8(5) · Rule 6

1. Write a role matrix for each key system.
2. Replace shared logins with named accounts.
3. Use multi-factor sign-in for admin and remote access.
4. Review access every quarter with each manager.
5. Remove access on the last working day.

• Role matrix
• Quarterly review sign-offs
• Leaver removal report

• Generic logins on shared machines
• Access that only grows
• No review of vendor accounts

Keep logs that show who accessed personal data and what they did, for at least one year under the DPDP Rules. CERT-In separately asks for ICT system logs to be kept for 180 days within India. Logs must be protected so nobody can quietly change them.

Core banking, internet banking and card systems already log heavily. Check retention and that logs stay in India.

Rule 6 lists logs and monitoring as a minimum safeguard. Rule 8(3) asks for logs to be kept for at least one year. The CERT-In Directions of 2022 ask for 180 days of ICT logs kept within India. Section 8(5) · Rule 6 · Section 8(7) · Rule 8

1. List systems holding personal data and what each logs today.
2. Turn on access logging where it is missing.
3. Send logs to one protected store, with at least one year of retention.
4. Keep a copy of ICT logs in India for at least 180 days.
5. Sync clocks and review alerts every day.

• Log source list
• Retention settings
• Alert review records

• Logging only failures, not who viewed a record
• Logs stored on the same server they describe
• Clocks out of sync, so timelines cannot be built

Under DPDP, yes, unless the government restricts a country, and none had been restricted when this page was last reviewed. A sector rule can be stricter, for example RBI's rule that payment system data must be stored only in India. Remote support access from abroad also counts as data going outside India.

Payment system data must be stored only in India. Check overseas support access to core systems.

Section 16 allows transfers unless restricted, and keeps stricter sector laws in force. Rule 15 adds conditions on making data available to foreign states. Section 16 · Rule 15 · Section 8(1)–(2)

1. List where each system is hosted and where support teams log in from.
2. Check sector rules for localisation.
3. Put location and access terms in cloud and vendor contracts.
4. Keep the list current; new SaaS tools change it quietly.
5. Tell people in your notice if data goes abroad.

• Hosting and access-location list
• Contract clauses
• Sector rule check

• Forgetting email, CRM and helpdesk SaaS
• Ignoring overseas support logins
• Assuming 'Indian vendor' means 'data in 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

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