DPDP for the Records and archives department in BFSI

Reviewed by InfraVeritas360 ResearchFirst published 10 October 2026Last reviewed 11 October 2026

Sources: DPDP Act, 2023 and DPDP Rules, 2025 (MeitY) · RBI KYC Master Direction · RBI · RBI · RBI

Records and archives hold account opening forms, KYC copies, loan files and closed-account records, often for many years.

Written for: Records and archives department, Banking, financial services and insurance. Open this seat in the interactive tool

What is different here

PMLA and RBI's KYC rules set the floor: 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 the records are kept only for that legal purpose. After it, erase or destroy them unless another law or a pending case needs them.

The first four things to sort out

Set the retention start for each record type: relationship end or transaction date.
Keep closed-account KYC files in a separate vault with logged access.
Get destruction certificates from the record storage vendor.
Keep a legal-hold list for records under dispute or investigation.

A worked example

Records and archives department

Applying the KYC retention period at the archive vendor

Month 1The archive vendor holds boxes of account opening forms and loan files, labelled only by branch and year.
Month 2Records works with the vendor to add the account closure date to each box, using the core banking archive.
Month 3Boxes more than five years past closure, with no legal hold, are destroyed. The vendor issues a certificate for each batch.
AfterClosed-account boxes stay in a restricted vault, and each retrieval is logged with its reason.

Evidence kept

Box-level inventory
Legal-hold list
Destruction certificates
Retrieval log

Retention runs from the closure date, so record it on every box.

What others in the sector usually do. Many banks start by asking their record storage vendor for a box-level inventory with dates, so the schedule can actually be applied.

Where it usually goes wrong, by organisation type

Organisation type	Hotspots
Scheduled commercial bank	Cross-selling insurance and mutual funds on account terms; Business correspondent devices and paper forms in villages; Old core banking archives with no deletion path
Co-operative bank (urban or rural)	Vendor-run core banking with admin access from the vendor's office; Member and share registers kept on open shelves; Directors and staff who are also members and relatives of borrowers
NBFC and digital lender	Apps asking for contacts, photos and call logs; Collection agents sharing borrower details with family or employers; Leads bought from aggregators with no consent record
Insurance company (life, general or health)	Medical reports passed to TPAs and hospitals by email; Agent and broker access to policyholder data; Claims data kept long after the claim is closed
Broking, depository and wealth	Authorised persons with client lists on personal phones; Research-tip calls to people who never consented; Client KYC copies shared over email with partners
Payments and fintech	Card numbers in logs and support tickets; Merchant onboarding documents in shared drives; Fraud models that use data beyond what users were told

7 questions the Records and archives department asks, answered in full

How long must we keep KYC and transaction records, and what happens after?

Short answer: At least five years after the relationship ends; then erase

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.

What the law says

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

Steps

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

Evidence to keep

Retention schedule
Access restrictions on closed accounts
Deletion logs

Common mistakes

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

How long can we keep personal data?

Short answer: For the legal or business period, then erase

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.

From your seat: Records and archives department. Own the schedule and the destruction log.

Example in BFSI

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

What the law says

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

Steps

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

Evidence to keep

Retention schedule approved by Legal
Deletion log
Shredding or disposal certificates

Common mistakes

'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?

Short answer: Yes, unless a law requires you to keep it

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.

From your seat: Records and archives department. Explain clearly what is kept and why.

Example in BFSI

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

What the law says

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

Steps

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

Evidence to keep

Erasure log
Vendor deletion confirmations
Reply to the person

Common mistakes

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

Does deletion have to reach backups and test copies?

Short answer: Yes, through a written backup-expiry rule

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.

From your seat: Records and archives department. Old backups are records too.

Example in BFSI

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

What the law says

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

Steps

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

Evidence to keep

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

Common mistakes

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

Someone asks what data we hold about them. What do we send?

Short answer: Yes, a clear summary, inside the published timeline

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.

From your seat: Records and archives department. Find records fast when someone asks.

Example in BFSI

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

What the law says

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

Steps

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

Evidence to keep

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

Common mistakes

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

Police, a court or a regulator asks for someone's data. What do we do?

Short answer: Yes, when the request is lawful and in writing

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.

From your seat: Records and archives department. Log what was released.

Example in BFSI

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

What the law says

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

Steps

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

Evidence to keep

Authority request log
Copies of requests
Record of what was sent

Common mistakes

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

Something has gone wrong. What happens in the first 72 hours?

Short answer: Six hours for CERT-In; without delay for people and the Board; 72 hours for the detailed report

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.

From your seat: Records and archives department. A missing file is a breach.

Example in BFSI

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

What the law says

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

Steps

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

Evidence to keep

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

Common mistakes

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

The sections you will use most

Section 8(7) · Rule 8: Erasure and retention. PMLA and KYC periods set the floor. After them, erase.
Section 8(5) · Rule 6: Security safeguards. Core banking, policy and trading systems are already under regulator security rules. DPDP adds a duty owed to the customer.
Sections 11–14 · Rule 14: Rights of people. Customers can ask for a summary of what you hold and who you shared it with: partner insurers, bureaus, collection agencies.

Other rules that sit alongside DPDP

Rule	What it says	What it means alongside DPDP	Source
Prevention of Money-laundering Act, 2002 and RBI KYC Master Direction, 2016	Keep transaction records for at least five years from the transaction, and identity records for at least five years after the relationship ends.	These periods override an erasure request. Explain the retention to the customer and stop every other use.	RBI KYC Master Direction
RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices, 2023	In force from 1 April 2024 for commercial banks, larger NBFCs, credit information companies and all-India financial institutions. Requires IT governance under the board, audit trails, logging and incident reporting to CERT-In and RBI.	Most of the DPDP security duty is already here. Map controls once and use the evidence for both.	RBI
RBI Master Direction on Outsourcing of IT Services, 2023	The regulated entity stays responsible for outsourced IT, with contracts, audit rights and exit plans.	Line up DPDP processor contracts with this direction, so one schedule meets both.	RBI
RBI direction on storage of payment system data, 2018	All data relating to payment systems must be stored only in India.	This is stricter than DPDP Section 16, and it continues to apply.	RBI
RBI rules on card storage and tokenisation (from 1 October 2022)	Only card issuers and card networks may store actual card data. Others use tokens, created with the cardholder's explicit consent.	Check logs, call recordings and support tickets for card numbers.	RBI
RBI (Digital Lending) Directions, 2025	Collect only need-based data with prior explicit consent and an audit trail. Apps should not access contacts, files, media or call logs; one-time access to camera, microphone or location is allowed for onboarding or KYC with consent.	Your app permissions and lending partner contracts are where DPDP and RBI meet.	RBI
IRDAI Information and Cyber Security Guidelines, 2023	Report cyber incidents to CERT-In within six hours, and to IRDAI within 24 hours of the CERT-In report.	One incident plan should run the CERT-In, IRDAI and Data Protection Board steps together.	IRDAI
SEBI Cybersecurity and Cyber Resilience Framework (CSCRF), 2024	Security, logging and incident-reporting duties for SEBI-regulated entities. Stock brokers and depository participants report cyber incidents within six hours.	Use CSCRF evidence for DPDP security, then add notices, consent and rights.	SEBI
CERT-In Directions, 28 April 2022	Report specified cyber incidents within six hours. Keep ICT logs for 180 days within India. Sync clocks to Indian time sources.	Applies to every BFSI entity in addition to the regulator's own clock.	CERT-In
Credit Information Companies (Regulation) Act, 2005	Governs what credit information is shared with credit bureaus and how errors are corrected.	Credit bureau sharing has its own law; DPDP rights requests about bureau data should point to that process too.	Act
RBI Integrated Ombudsman Scheme, 2021	Customers can escalate unresolved complaints to the RBI Ombudsman.	Privacy complaints may reach both the Ombudsman and the Data Protection Board. One complaint log helps.	RBI