Preparing for a customer who asks what data you hold

“What information do you hold about me?” sounds like a simple question until the answer is spread across sales software, invoices, support tickets and a delivery spreadsheet. A useful response depends on the organisation’s ability to find and explain its processing, not just export one account screen.

The DPDP access right in section 11 concerns a fiduciary to whom the person previously gave consent, including the section 7(a) situation. It includes a summary of personal data and processing activities, and specified information about sharing. As of 22 October 2026, the right is scheduled for May 2027 under the commencement notification.

Receive the request without making it a puzzle

Publish a clear route and the particulars needed to identify the person, as envisaged by rule 14. Staff receiving a request through another ordinary channel should know where to send it internally. A customer should not need to use a particular legal phrase before the team recognises a privacy question.

At intake, record the request, the date, contact route and any useful scope clarification. If the customer asks about a particular service or period, preserve that detail. Clarification can help locate records, but it should not become a repetitive exercise designed to discourage the request.

Verify identity proportionately before disclosing information. An existing authenticated account may provide useful assurance; a request from a new address may need additional checks. Do not automatically demand a full identity-document copy for every low-risk request.

Search by workflow, not just by name

Consider a hypothetical repair subscription service. Its customer system uses an email address, finance uses an invoice account number and engineers use job references. A search for the customer’s name alone could miss records or capture another person with the same name.

Map the identifiers connecting these systems. Assign each relevant owner a bounded search task: the person, systems, date range where applicable and information needed for the response. Include processors that hold records on the business’s behalf, using the agreed request-assistance route.

Keep a search log recording where the team looked and any limitations. It need not reproduce all the personal data found. Its purpose is to show that the response was assembled deliberately rather than guessed from the first application available.

Explain the processing in useful language

The response should describe the personal-data categories and what the business does with them. “Customer management” may be too broad to help someone understand appointment scheduling, payment reconciliation, support and promotional messaging.

Section 11 also addresses the identities of other fiduciaries and processors with whom data was shared and a description of the shared data. A generic list of every possible supplier does not necessarily answer what happened to this person’s information. Use the actual records and explain any uncertainty honestly.

The Act contains a specified carve-out for certain legally authorised sharing for offences or cyber incidents. Do not improvise a broader secrecy exception. Equally, do not promise an unrestricted copy of every internal document, another customer’s information or all law-enforcement-related disclosures.

Review before releasing

A second authorised person should check the identity match, scope, recipient address and accidental inclusion of other people’s data. For the repair service, a shared household account or a group support ticket may require careful separation before anything is sent.

Choose a delivery method appropriate to the information. A password-protected portal or another secure route may be suitable; the exact method is a risk-based implementation choice. Sending sensitive records to an unverified new email address can create a fresh disclosure problem while trying to answer the request.

Explain what the response covers and how to raise a concern about it. If something could not be located, describe the relevant limitation rather than claiming absolute completeness without evidence.

Keep deadlines accurate

Rule 14 sets a maximum ninety-day period for the grievance-response system. It should not be copied into policy as a universal deadline for every access request. Set an internal service target that reflects the legal position, the request’s circumstances and any other applicable regime.

Track progress so a request cannot sit unnoticed while teams wait for one another. If a grievance arises, route it through the appropriate process with clear ownership. A request tracker should help staff complete work, not become a second uncontrolled repository of all the disclosed records.

Practise with a dummy customer before the later phase begins. The exercise will show whether identifiers, vendor assistance and response review work together. A credible access workflow ends with an intelligible, safely delivered account of processing supported by the search that produced it.