DPDP for the Records and archives department in Central government

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

Sources: DPDP Act, 2023 and DPDP Rules, 2025 (MeitY) · MeitY · MeitY · MeitY · SFLC.in summary

The record room and the retention schedules decide what the department keeps, what it destroys, and whether a file can be found when a citizen asks.

Written for: Records and archives department, Central government: ministries and departments. Open this seat in the interactive tool

What is different here

Because Section 17(4) lifts DPDP erasure for the State, retention follows the Public Records Act, 1993, the Public Records Rules, 1997 and approved schedules. Records must still be secured while kept, and errors still corrected. Data in e-Office and portals needs the same schedules as paper files.

The first four things to sort out

Confirm the approved retention schedule for each record type.
Log every destruction against its schedule item.
Lock record rooms and log file movement.
Apply the same schedules to e-Office and portal data.

A worked example

Records and archives department

A record room past its dates

Week 1A review finds old application files, with ID copies, kept well past their scheduled period.
Week 2Files linked to pending cases, audits or RTI appeals are set aside.
Week 4The rest are destroyed as the approved schedule allows, with an entry in the destruction register.
AfterThe review runs every year, and the scheme register shows the schedule for each record type.

Evidence kept

Retention schedule
Hold list
Destruction register

Records kept past their schedule carry risk without serving any purpose.

What others in the sector usually do. Some departments now review retention schedules alongside the scheme register, so each scheme's records have a period.

Where it usually goes wrong, by organisation type

Organisation type	Hotspots
Ministry of Ports, Shipping and Waterways and its offices	Port entry passes with ID copies held by many parties; Seafarer records shared with training institutes and agencies; Terminal operator systems outside the ministry's direct control
Ministry of Road Transport and Highways and its offices	Bulk or API access by private entities; Accident and challan data; Toll and FASTag transaction data with vendors
Ministry of Chemicals and Fertilizers and its departments	Aadhaar authentication at retailer PoS devices; Farmer purchase data visible to companies and dealers; Kendra operators holding prescriptions and customer details
Other line ministries and departments	Beneficiary lists published or shared in spreadsheets; System integrators with admin access; Grievance records with personal details
Citizen portals and DBT schemes	Aadhaar numbers stored outside a data vault; Bulk beneficiary data sent to states by email; Dashboards showing names and amounts publicly
Regulators and statutory bodies	Orders and filings published with personal details; Complaint data shared with regulated entities; Investigation files on shared drives

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

Must a ministry delete data when a citizen asks?

Short answer: No, but correction and security still apply

No. Section 17(4) says the erasure duty in Section 8(7) and the erasure right in Section 12(3) do not apply to processing by the State. Retention follows public records rules and schedules. Correction rights and all other duties, including security and breach reporting, still apply.

What the law says

Section 17(4) lifts DPDP erasure for the State. Public records rules govern destruction. Section 8(7) · Rule 8 · Sections 11–14 · Rule 14 · Section 8(3)

Steps

Apply record retention schedules.
Correct errors when asked.
Tell the citizen why data is kept.
Destroy records as the schedule allows.
Keep access limited while records are kept.

Evidence to keep

Retention schedule
Correction log
Destruction register

Common mistakes

Thinking no duties apply
Ignoring correction requests
Keeping open access to old records

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 Central government

Record retention schedules under public records rules decide periods.

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 Central government

Section 17(4) lifts DPDP erasure for the State; public records schedules apply.

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 Central government

Backups of scheme systems must be offline or immutable against ransomware.

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 Central government

A beneficiary can ask what the department holds and who it was shared with, such as states and banks.

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 Central government

Requests from other agencies need a written basis and a log.

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 Central government

A leaked beneficiary list is a breach; CERT-In and the Data Protection Board both need to hear.

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. Section 17(4) lifts DPDP erasure for the State; public records rules decide retention.
Section 8(5) · Rule 6: Security safeguards. Security safeguards apply in full to government systems.
Sections 11–14 · Rule 14: Rights of people. Citizens can ask for a summary of what is held. Correction rights apply; erasure on request does not.

Other rules that sit alongside DPDP

Rule	What it says	What it means alongside DPDP	Source
DPDP Act, Section 7(b) and 7(c) with Rule 5 and the Second Schedule	The State may process personal data without consent to provide a subsidy, benefit, service, certificate, licence or permit, and to perform functions under law. Rule 5 asks that this processing follow the Second Schedule standards: lawful, for the stated use, limited to necessary data, accurate, kept only as long as needed, secured, and with a contact for questions and rights.	Consent is not the basis for most scheme work. The standards are, and they need evidence.	MeitY
DPDP Act, Section 17(4)	For processing by the State, Section 8(7) (erasure) and Section 12(3) (erasure on request) do not apply, and where no decision affecting the person is made, Section 12(2) does not apply either.	Retention follows public records rules rather than DPDP erasure. Security, accuracy, breach reporting and grievance duties still apply.	MeitY
DPDP Act, Section 17(2)	The Central Government may exempt notified instrumentalities for sovereignty, security, public order and related interests, and processing for research, archiving or statistics that does not lead to decisions about individuals.	An exemption applies only if notified. Do not assume it.	MeitY
RTI Act, Section 8(1)(j), as amended by DPDP Section 44(3) (in force 13 November 2025)	Personal information is now exempt from disclosure under RTI, without the earlier public-interest test.	Train CPIOs on the new wording; the amendment is being challenged before the Supreme Court, so watch for changes.	SFLC.in summary
Public Records Act, 1993 and Public Records Rules, 1997	Central government records may be destroyed only under approved record retention schedules.	Erasure of personal data in files follows these schedules, since Section 17(4) lifts DPDP erasure for the State.	National Archives of India
Aadhaar Act, 2016	Section 7 allows Aadhaar for subsidies and benefits. Section 29 limits sharing of Aadhaar numbers and core biometric information. UIDAI asks entities storing Aadhaar numbers to keep them in an Aadhaar Data Vault.	Scheme systems should store Aadhaar numbers only in a vault and show them masked.	UIDAI
CERT-In Directions, 2022 and IT Act Section 70	Report cyber incidents within six hours; keep ICT logs 180 days in India. Systems declared as protected systems under Section 70 come under NCIIPC.	Ministries and their portals follow these in addition to DPDP.	CERT-In
MeitY Email Policy and IT resources policy for Government	Official communication should use government email and approved resources.	Personal email and chat apps for files with citizen data break both these policies and DPDP safeguards.	MeitY
Guidelines for Indian Government Websites (GIGW)	Government websites must carry standard policies, including a privacy policy.	Update website privacy policies to DPDP notice standards with the contact person.	MeitY / NIC