Handling Data Principal Rights Requests

The rights you must service

• Access — a summary of the personal data being processed and with whom it has been shared (s.11)
• Correction, completion and updating — and erasure where retention is no longer justified (s.12)
• Grievance redressal — a reachable channel, exhausted before the Board is approached (s.13)
• Nomination — letting a Data Principal name someone to exercise their rights on death or incapacity (s.14)

Verify identity without creating new risk

You must be reasonably satisfied the requester is who they claim to be, because disclosing to an impostor is itself a breach. Verify against data you already hold rather than collecting fresh identity documents — a request portal that demands an Aadhaar scan has made your exposure worse, not better.

Record what you checked and when. If you refuse or narrow a request, record the reason in terms you would be comfortable showing the Board.

Find every copy, not the convenient one

The common failure is scope. A request arrives through support, is answered from the CRM, and quietly misses the warehouse, the backup, the analytics copy and the vendor system. An identity graph built from discovery lets one request resolve to every system holding that person's data.

Erasure deserves more friction than a button

• Require two-person approval before anything is destroyed
• Record which systems were in scope and which were excluded, with reasons
• Issue a completion certificate naming the systems the record was removed from
• Keep the minimum proof-of-erasure record that retention and legal-hold rules require

Run it on a clock

Respond within the period prescribed by the Rules, and configure your workflow to that period rather than to a number you half-remember. Track time-to-close per request, escalate before the deadline rather than after, and keep the grievance history intact — a pattern of late responses is itself evidence of a weak programme.