A customer emails your support team and asks for a copy of all the personal data you hold about them. The message moves from the support agent to IT, then to the legal team, and two weeks later nobody has replied.
Situations like this are becoming easier to run into as company privacy programs grow. The Cisco 2026 Data and Privacy Benchmark Study, which surveyed 5,200 professionals across 12 markets, found that 90% of companies reported an expanded privacy program, with AI as the main driver.
Customers, meanwhile, can ask to access, correct, or delete their data at any time. That is why how to handle customer data rights requests needs to be worked out before the first request arrives.
This article covers eight practical steps for doing it, each with an example. You can adopt them gradually without waiting for a new system.
What Are Customer Data Rights Requests?
A customer data rights request is a formal request from an individual asking a company to exercise their rights over their personal data. The individual is called the data subject, and the company that stores and uses the data is called the data controller.
In Indonesia, these rights are guaranteed by Law No. 27 of 2022 on Personal Data Protection (the PDP Law). European regulation (GDPR) calls them data subject requests (DSRs), and a request specifically to see one’s data is called a data subject access request (DSAR).
Three elements make up such a request: an identifiable person, personal data that belongs to them, and a request that the company do something with that data. If the requester turns out not to be the data owner, the company must confirm this before processing anything.
The requests take many forms. These are the ones companies receive most often:
- Access and copy of data. The customer wants to know what data is stored, for example a bank customer asking for a list of the data recorded in an app.
- Correction of data. The customer asks for wrong data to be fixed, for example an old phone number that is still on file.
- Deletion of data. The customer cancels a subscription and asks for the account to be deleted.
- Restriction or objection to processing. The customer refuses to let their data be used for advertising or profiling.
- Transfer of data. The customer moves to another provider and asks for their data to be sent there.
Requests can arrive by email, web form, phone call, or social media message. Front-line staff must be able to recognize them, not just the privacy team.
Risks of Ignoring Customer Data Rights Requests
An unanswered request rarely stops at a single email. Frustrated customers tend to complain on social media, report the company to a regulator, or switch to a competitor.
The legal risk is real too. The PDP Law provides for administrative sanctions against data controllers that fail to meet their obligations, including the obligation to respond to data subjects’ rights.
Picture an online store that does not delete a former customer’s account even after being asked. When that account data leaks a few months later, the company has to explain two things at once: what caused the leak, and why the data was still being kept.
8 Ways to Handle Customer Data Rights Requests
The eight steps below run in order, from the moment a request arrives to the final report. You can work through them one by one, or use them as a checklist for a process you already have.
1. Provide a Clear Submission Channel
Customers need to know where to send a request. Publish a dedicated email address or online form on your website and in your privacy policy.
For example, a shopping app can place a “My Data Requests” menu in the account settings page. That way, requests do not get lost in the regular customer service inbox.
2. Log Every Request in a Single Register
Every request, whatever channel it came through, must be recorded in one place. At a minimum, log the date received, request type, person responsible, and current status.
Say a customer phones the call center to change an address. The agent who takes the call creates a ticket in the register instead of just answering verbally, because without a record there is no proof the request was ever made.
3. Verify the Requester’s Identity
Before any data is sent, confirm that the requester really is the data owner. Sending data to the wrong person is the same as causing a data breach yourself.
A company can ask the requester to reply from the registered email address or enter an OTP sent to the phone number on the account. Ask for only as much proof as needed, since demanding an ID photo for a trivial request just adds more sensitive data that has to be protected.
4. Set an Internal Deadline
Deadlines are where teams slip most often. The ICO’s guidance (the UK data protection authority), updated on 16 July 2026, says organizations must respond within one month of receiving a request, with up to two further months allowed when the request is complex or the person has made a number of requests.
That is one global benchmark. The PDP Law sets its own time limits for certain requests, so your legal team should confirm the applicable deadline before you set an internal target.
For example, a request arrives on 3 March. The team sets a target of 10 working days so there is still room for revisions and approval.
5. Map and Collect Data from All Systems
Customer data is rarely stored in just one place. It can sit in the CRM, the payment system, the email marketing platform, application logs, and even in staff members’ personal spreadsheets.
Imagine a team deletes a customer’s data from the CRM but forgets it is still stored in the email blast platform. The customer keeps receiving promotions and reasonably feels the request was ignored.
Data mapping and a ROPA (a record of processing activities) help the team find all of those locations quickly.
6. Review the Request Before Responding
Not every request has to be granted in full. Some data must be kept because of legal obligations, and some documents contain other people’s data.
A customer who asks for their transaction history to be deleted, for instance, is still bound by the company’s duty to keep transaction records for tax and audit purposes. In a case like this, grant what can be granted and explain the partial refusal in plain language.
If an access request includes a call recording that names another customer, redact that part first.
7. Deliver the Response Securely and Clearly
A correct answer sent through an unsafe channel creates a new problem. Use a secure portal or a password-protected download link, and avoid unprotected attachments.
For example, the company sends the data as a CSV file through a link that expires in seven days, while the password goes through a separate channel. Include a short explanation of what the file contains so the customer is not left confused.
8. Document the Outcome and Review It Regularly
Once a request is closed, keep the evidence: when it was received, who verified it, what was sent, and when it was closed. This is the record you will show when an auditor or regulator asks.
Reviews matter as well. If the privacy team checks the numbers every quarter and finds that deletion requests are usually late because they wait on the IT team, the fix is clear: add more people in charge or simplify the approval flow.
Conclusion
Handling customer data rights requests is mostly about discipline in the process. There is a clear entry point, logging, verification, a deadline, data collection, review, secure delivery, and documentation.
The eight steps depend on one another, so a gap in one usually causes the next to stall. A manual process can cope when only one or two requests arrive each month but becomes fragile as volume grows, so start with an official channel, a person in charge, and a request register.
Ready to Manage Privacy Compliance as a Business Risk?
See how GRC helps map personal data risks, monitor compliance with the PDP Law, and prepare companies for audits without complicated manual processes.
FAQ
A DSR covers all data subject requests, while a DSAR covers only requests to access data.
It depends on the regulation and request type. The UK ICO guidance sets one month, while Indonesia’s PDP Law has its own time limits.
Yes, if there is a legal basis, such as keeping transaction records for tax and audit purposes. The reason must still be explained to the customer.
