Handling Data Principal requests under the DPDP Act

Data Principal rights and the request queue

Chapter III of the Act gives every Data Principal the right to access a summary of their personal data and the processing performed, the right to correction and completion, the right to erasure, and the right to nominate someone to exercise those rights on their behalf. You must publish a way to make those requests and you must respond within a reasonable period.

For a small team, the failure mode is not refusing a request — it is losing one. Requests arrive by email, WhatsApp, a contact form and Instagram DM, and nobody owns the spreadsheet. A single intake endpoint with an auditable status trail removes that risk entirely, which is why the AssentRepo banner ships a built-in DSAR form alongside the cookie controls.

Verifying identity without collecting more data

You must not honour a deletion request from someone impersonating a customer, and you must not respond to a request by demanding a copy of an Aadhaar card. The proportionate middle ground is a confirmation link sent to the email or phone number already on the account.

AssentRepo's DSAR intake deduplicates pending requests from the same address and rate-limits submissions per site, so the queue stays usable even when a form gets scraped.

The four request types and what each requires

Each has a different fulfilment shape, and conflating them is how deadlines get missed.

• Access — a summary of personal data held and the processing performed, plus the identities of fiduciaries it was shared with
• Correction — update inaccurate data and complete incomplete data, and pass the correction to anyone it was disclosed to
• Erasure — delete, unless retention is required by law; record the exception where one applies
• Opt-out / withdrawal — cease the consented processing and propagate to processors

You have to be able to prove it

The obligation that catches most teams out is evidentiary. Under Section 8, the Data Fiduciary — you — is responsible for demonstrating compliance, including that valid consent was obtained. If the Board asks and your answer is "our banner was live", that is not evidence.

A defensible consent record contains, at minimum: a stable visitor identifier, the categories accepted and rejected, a UTC timestamp, the version of the notice shown, the policy text hash, and enough network context to establish the request was genuine without storing raw personal identifiers. AssentRepo writes exactly this record for every consent event and one-way hashes the IP address with a server-side salt, so the log is useful to an auditor and useless to an attacker.

Frequently asked questions