DPDP for Internal Auditors: What to Test When Reviewing Privacy Controls

The most common failure mode in privacy audits is confirming that a policy exists and stopping there. A privacy policy that says 'we retain data only as long as necessary' tells you nothing about whether retention is actually enforced anywhere in the systems that hold data. Every test in this review should end with evidence of a control operating, not a citation to a document describing intent.

Structure the audit around the Act's actual obligations rather than a generic security checklist — Sections 5, 6, 8, 11 and 12 give a natural map of what to test: notice, consent, general obligations, access rights, and correction/erasure rights.

Sample actual consent capture points (signup forms, cookie banners, in-app consent prompts) and check whether they meet Section 6's standard: a genuine opt-in action, not a pre-ticked box or consent bundled unavoidably with acceptance of terms of service.

Test withdrawal, not just collection — pick a live account, walk through the actual withdrawal or unsubscribe mechanism, and verify it takes effect across every system the data was shared with, not just the front-end flag. This is one of the highest-value tests in the whole review because it's rarely tested end-to-end outside audit.

Request evidence of access controls and logging for systems holding personal data (Section 8(5)) — actual access logs and role configurations, not a policy stating that access is restricted. Confirm logs are retained consistent with the baseline expected under the DPDP Rules.

Pull a sample of Data Processor contracts and check them against Section 8(2) expectations directly — purpose limitation, security terms, sub-processor visibility, deletion at termination — rather than accepting a vendor list as evidence that contracting has happened.

Ask to see the breach response plan tested, not just documented — has a tabletop exercise or a real incident walked through the intimation steps to the Board and to Data Principals required under Section 8(6), and how long did each step actually take versus what the plan assumes.

Sample closed rights requests (access, correction, erasure) and trace them from intake to closure: was identity verification proportionate, was the response substantively responsive to what was asked, and did erasure actually propagate to backups, exports and downstream systems rather than just the primary record.

Check whether the internal grievance mechanism required before a Data Principal can escalate to the Data Protection Board under Section 13 is documented, published, and has actually been used — a mechanism that exists on paper but has never processed a real grievance is a control that hasn't been tested by anyone yet, including the organisation itself.

Build your test plan around the Checklist Generator's obligation list, and use the Evidence Tracker to verify that documented remediation from prior audits actually closed out rather than lingering as 'in progress' indefinitely.