DPDP for the Internal audit 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 internal audit team does the field testing: picking records, reading contracts and checking logs.

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

What is different here

Most DPDP checks fit into existing audit work on IT, vendors and records. Test what happens to real records, and test destruction against the retention schedule rather than erasure on request.

The first four things to sort out

Trace five beneficiary records end to end.
Check that every integrator admin account is named.
Check one destruction run against the schedule.
Ask for the last breach drill record.

A worked example

Internal audit department

Checking district logins on a scheme portal

Week 1Audit pulls the list of district-level logins on the portal.
Week 2Several belong to officers transferred months ago, and they still work.
Week 3The finding goes to the IT cell with a 30-day deadline. Logins are now tied to posts and reviewed on transfer.
AfterAudit checks the list again after the next round of transfers.

Evidence kept

Login list
Transfer orders compared
Finding and closure

A transfer is a leaver too; logins should move with the officer.

What others in the sector usually do. Some audit teams have added a short DPDP checklist to their IT audit programme.

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

10 questions the Internal audit department asks, answered in full

What do the Second Schedule standards ask of a scheme?

Short answer: Seven practical standards, each needing evidence

Process lawfully and only for the scheme's purpose, collect only the data needed, keep it accurate, keep it only as long as needed or required by law, protect it with reasonable safeguards, give people a contact for questions and rights, and be accountable for meeting these standards.

What the law says

Rule 5 and the Second Schedule apply to State processing under Section 7(b). Section 7 · Section 8(5) · Rule 6 · Section 8(3)

Steps

Field review: needed or not.
Accuracy: how errors are corrected.
Retention: which schedule applies.
Security: who can access.
Contact: published on the portal.
Accountability: a named officer.

Evidence to keep

Standards checklist per scheme
Correction process
Retention schedule

Common mistakes

Treating standards as a formality
No correction route
No named officer

How should scheme systems handle Aadhaar numbers?

Short answer: Vault, mask, never publish

Use Aadhaar only where a law or notification allows it, store the number only in an Aadhaar Data Vault, show it masked on screens and in reports, and never publish it. Core biometric information must never be shared. Authentication devices at the field level need vendor and operator controls.

What the law says

Aadhaar Act Sections 7 and 29 and UIDAI rules, with DPDP Section 8(5). Section 8(5) · Rule 6 · Section 7

Steps

Find every place Aadhaar numbers are stored.
Move them to a vault with reference keys.
Mask on screens, reports and files.
Check PoS and field device vendors.
Log access to the vault.

Evidence to keep

Vault design
Masking evidence
Access logs

Common mistakes

Aadhaar in spreadsheets
Full numbers on dashboards
Field operators keeping copies

Can a policy show that a control actually works?

Short answer: No; operation needs records

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.

From your seat: Internal audit department. Test five samples end to end.

What the law says

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)

Steps

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

Evidence to keep

Policy-to-record map
Quarterly samples
Gaps and actions

Common mistakes

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

What evidence should exist before management accepts that we are ready?

Short answer: Evidence for each duty, not status colours

Before accepting a readiness statement, management should see evidence for each duty: dated notices, consent records, a request register with replies, signed vendor terms, access review sign-offs, log settings, a breach drill report and a deletion log. A status colour without these is a statement, not evidence.

From your seat: Internal audit department. Ask for the evidence list first.

What the law says

The Act places duties on the Data Fiduciary as an organisation. Management is accountable for whether they are actually met. Section 8(1)–(2) · Section 8(5) · Rule 6 · Section 8(6) · Rule 7 · Section 8(9)–(10) · Rules 9, 14

Steps

List the duties that apply.
For each, name the piece of evidence that would satisfy an auditor.
Ask owners to attach it.
Mark duties without evidence as open, not ready.
Review the list before each management sign-off.

Evidence to keep

Duty-to-evidence list
Attached evidence
Sign-off record

Common mistakes

Accepting 'done' without seeing anything
Counting policies as evidence
One sign-off and no review after

Which logs must we keep, for how long, and where?

Short answer: At least one year; 180 days of ICT logs in India

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.

From your seat: Internal audit department. Check logs exist for the period.

Example in Central government

Integrator-run systems must give the department access to logs.

What the law says

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

Steps

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

Evidence to keep

Log source list
Retention settings
Alert review records

Common mistakes

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

Who should be able to see personal data in our systems?

Short answer: Only those who need it, reviewed every quarter

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.

From your seat: Internal audit department. Compare access lists with leavers.

Example in Central government

Vendor admin accounts and district-level logins are the usual weak points.

What the law says

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

Steps

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

Evidence to keep

Role matrix
Quarterly review sign-offs
Leaver removal report

Common mistakes

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

What must a vendor contract say about personal data?

Short answer: Yes, every vendor that touches personal data

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.

From your seat: Internal audit department. Read the top contracts.

Example in Central government

System integrators, NIC, state agencies and field operators process data for the department.

What the law says

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

Steps

List vendors who receive or can see personal data.
Rank them by how much and how sensitive.
Add a data-protection schedule to each contract, starting with the top ten.
Ask for evidence: certificates, test results, deletion confirmations.
Review the top vendors every year.

Evidence to keep

Vendor register
Signed data-protection schedules
Annual review notes

Common mistakes

Relying on the vendor's standard terms
No incident-notice time
No exit and deletion clause

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: Internal audit department. Check one deletion run.

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

How do we put DPDP into the risk register?

Short answer: One line per duty, with owner and evidence

Turn each duty into a risk line with an owner, a control, evidence and a review date. Map controls you already run for your regulator, auditors or certifications, so the same evidence serves several purposes. Track vendor risk separately.

From your seat: Internal audit department. Test each control.

Example in Central government

Add data protection to internal audit and risk reviews.

What the law says

The Act sets duties in Sections 5 to 12. A risk register shows management where each duty stands. Section 8(1)–(2) · Section 8(5) · Rule 6 · Section 8(6) · Rule 7 · Section 10 · Rule 13

Steps

List the duties that apply to you.
For each, write the risk in plain words, the control and the owner.
Link existing controls and audits as evidence.
Rate likelihood and impact in your usual way.
Review every quarter with management.

Evidence to keep

Risk register extract
Linked evidence
Quarterly review minutes

Common mistakes

One line saying 'DPDP compliance'
No owners
Evidence that is only a policy document

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: Internal audit department. Ask for drill findings.

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(5) · Rule 6: Security safeguards. Security safeguards apply in full to government systems.
Section 8(1)–(2): Responsibility for vendors. System integrators, NIC and state departments that process data for a scheme act for the ministry; contracts and MoUs should say so.
Section 8(6) · Rule 7: Telling people about a breach. Breaches must be reported to affected people and the Data Protection Board, in addition to CERT-In.
Section 8(7) · Rule 8: Erasure and retention. Section 17(4) lifts DPDP erasure for the State; public records rules decide retention.

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