When a customer writes to you about their personal data, they are rarely asking for the same thing twice. One wants a wrong phone number fixed. Another wants to stop your promotional messages. A third wants to know which courier company has their address. The DPDP Act 2023 gives each of these a different legal basis, a different answer, and in some cases a different set of reasons you may hold something back. This guide sets out every type of request a business can receive, what each one obliges you to do, and how to tell them apart when they arrive in the same inbox.
It is written for business owners and the Chartered Accountants who advise them. If you are a customer wanting to use these rights yourself, see Know Your Rights as a User. For the step-by-step process of receiving and logging requests, see Customer Data Rights and DSR Handling.
Quick Answer: What Types of Data Requests Can a Customer Make?
Under the DPDP Act 2023, a customer (the Act calls them the Data Principal) can make eight kinds of request to a business: access to a summary of their data and how it was used (Section 11(1)(a)); a list of who it was shared with (Section 11(1)(b)); correction, completion or updating (Section 12(2)); erasure (Section 12(3)); withdrawal of consent (Section 6(4)); a grievance (Section 13); a nomination of someone to act for them (Section 14); and a plain question about how their data is processed (Section 8(9)). The DPDP Rules 2025 require you to publish how these rights can be exercised (Rule 14(1)), how consent can be withdrawn (Rule 3) and who answers questions (Rule 9), and to answer grievances within a period you publish, no longer than 90 days (Rule 14(3)).
DSR (data subject request) and DSAR (data subject access request) are GDPR terms. Indian law does not use them. The DPDP Act speaks of the Data Principal and places the rights in Chapter III, Sections 11 to 14. Using “DSR” as shorthand inside your team is fine. In your privacy notice, describe each right in plain words, because your customer will not know the acronym.
The Eight Requests at a Glance
Keep this table beside whoever opens your privacy inbox. The first job with any request is to work out which row it belongs to, because the customer will rarely use the legal name.
| Request | What the customer usually says | Where it comes from | What you owe them |
|---|---|---|---|
| Access | “What data do you have on me?” | Section 11(1)(a) | A summary of their personal data and the processing you have done with it |
| Sharing list | “Who have you given my details to?” | Section 11(1)(b) | The names of every other business and service provider you shared it with, and what you shared |
| Correction, completion, updating | “My address is wrong.” “You have my old number.” | Section 12(2) | Fix what is wrong, fill in what is missing, bring up to date what has changed |
| Erasure | “Delete my data.” “Close my account and remove me.” | Section 12(3), Section 8(7) | Erase it, and have your service providers erase their copies, except what the law or an open purpose requires you to keep |
| Withdrawal of consent | “Stop sending me offers.” “I no longer agree to this.” | Section 6(4) to 6(6) | Stop the processing that relied on consent, and have your service providers stop too, within a reasonable time |
| Grievance | “You have not replied.” “You misused my data.” | Section 13, Rule 14(3) | A response within the period you published, which cannot exceed 90 days |
| Nomination | “If something happens to me, my son should handle this.” | Section 14, Rule 14(4) | Record the nominee, and later accept requests from them on the customer’s death or incapacity |
| Question | “Why do you need my date of birth?” | Section 8(9) | A straight answer from the contact person you have published |
1. Access: “What Data Do You Hold About Me?”
Section 11(1)(a) entitles the customer to “a summary of personal data which is being processed” by you “and the processing activities undertaken” with it. Note the word summary. The law does not ask you to export every database row. It asks for a clear account a customer can read: the categories of data you hold about them, the actual values where that is sensible (name, phone, address, order history), and what you have used them for.
A good access response for a small business fits on one page:
- The personal data you hold, grouped plainly: contact details, order and payment history, delivery addresses, messages and support tickets.
- What you used each group for: delivering orders, issuing GST invoices, sending order updates, sending offers if they agreed to them.
- Where the data came from, if not from the customer directly.
- How long you intend to keep it, and why.
The practical difficulty is not writing the summary. It is finding the data. A customer’s details usually sit in your billing software, your website or marketplace account, a spreadsheet, a WhatsApp chat and an email list at the same time. This is why every compliance programme starts with a list of where customer data lives, before any request arrives.
2. Sharing List: “Who Have You Given My Details To?”
Section 11(1)(b) is a separate entitlement, and it is the one businesses most often forget. The customer can ask for “the identities of all other Data Fiduciaries and Data Processors with whom the personal data has been shared”, together with a description of the data shared. In plain terms, that means naming the payment gateway, the courier company, the SMS or WhatsApp messaging provider, the accounting firm, and any partner business you passed their details to, and saying what each received.
There is one narrow exception. Under Section 11(2), you need not disclose sharing with a body authorised by law to obtain the data, where that body asked in writing for the purpose of preventing, detecting or investigating offences or cyber incidents, or for prosecution. A written request from the police is the common example. Apart from this and the general exemptions in Section 17 (covered below), the whole list must be given, so a list of your service providers, kept current, is the fastest way to answer this request.
3. Correction, Completion and Updating
Section 12(2) names three distinct actions, and it helps to keep them apart:
- Correction is for data that is wrong or misleading: a misspelt name, a wrong flat number.
- Completion is for data that is incomplete: a missing pin code, a GSTIN the customer now wants on their invoices.
- Updating is for data that was right but has changed: a new phone number, a new address after a move.
These are usually the easiest requests to fulfil, and the most damaging to mishandle. A customer who asked for a new phone number and received an account deletion has lost their order history for no reason. Read the request before acting on it.
Two limits apply. Section 12(1) says the right is exercised “in accordance with any requirement or procedure under any law”, so a change to a regulated record, such as a name on a bank KYC file, still follows that sector’s own procedure. And Section 15(e) places a duty on the customer to furnish only information that is “verifiably authentic” when seeking a correction. You may ask for reasonable proof before changing something that matters, such as a legal name on an invoice.
4. Erasure: “Delete My Data”
Under Section 12(3), on receiving an erasure request you must erase the customer’s personal data “unless retention of the same is necessary for the specified purpose or for compliance with any law”. Section 8(7)(b) adds that you must also cause your Data Processors to erase the data you gave them. An erasure that stops at your own systems, while the customer’s details remain with your messaging provider, is incomplete.
The two grounds for keeping data are both real, and both narrow:
- The purpose is still being served. If the customer has paid for an order that has not yet been delivered, you still need their address to deliver it. The Act’s own illustration to Section 6(5) makes this point for withdrawal of consent, and the same logic applies here.
- Another law requires you to keep it. GST law requires accounts and invoices to be kept for 72 months from the due date of the annual return for that year. Banks must keep customer identity records for a period after an account closes. The Act’s illustration to Section 8(7) uses exactly that bank example.
There is a third, less known point. Rule 8(3) of the DPDP Rules 2025 requires every Data Fiduciary to retain personal data, traffic data and processing logs for at least one year from the date of processing, for the purposes listed in the Rules’ Seventh Schedule. An erasure request does not override that one-year minimum.
What you keep, you keep only for the reason that allows it. GST invoices kept for tax law are not a marketing list. Your reply to the customer should say plainly what was erased, what was kept, and which law or purpose required it.
5. Withdrawal of Consent: “Stop Using My Data for This”
Withdrawal of consent is not listed among the Chapter III rights, but it is the request you will receive most often, usually as “stop sending me messages”. Section 6(4) lets a customer withdraw consent at any time, and requires that withdrawing be as easy as giving consent was. Section 6(6) then requires you, within a reasonable time, to stop the processing and to cause your Data Processors to stop, unless another law requires or allows the processing to continue without consent.
Withdrawal is narrower than erasure. It ends the processing that relied on consent, for the purpose the customer names. A customer who opts out of promotional messages has not asked you to delete their order history or stop sending delivery updates for an order in transit. Section 6(5) also makes clear that processing done before the withdrawal remains lawful, and that the customer bears the consequences of withdrawing: if they withdraw consent to the processing needed to run their account, you may stop providing that service.
Under Section 8(7)(a), once consent is withdrawn you must also erase the data that relied on it, unless another law requires you to keep it. So a withdrawal often leads to an erasure step as well, handled with the same care about what must stay. For the full consent picture, see what valid consent looks like under Section 6.
6. Grievance: “You Have Not Dealt With This Properly”
A grievance is a complaint about how you have handled the customer’s data or their rights. It may follow an unanswered request, or stand alone: an unwanted message after an opt-out, a data leak, a request refused without reasons. Section 13(1) requires you to provide a “readily available means of grievance redressal”, and Section 8(10) requires an effective mechanism to redress grievances.
Two provisions give the grievance its weight. Rule 14(3) requires you to publish the period within which you will respond, and that period cannot exceed 90 days. And Section 13(3) requires the customer to exhaust your grievance process before approaching the Data Protection Board. Your grievance process is therefore the last point at which a complaint is still yours to resolve. Once it passes to the Board, the Board decides.
A customer also has a duty under Section 15(d) not to register a false or frivolous grievance. That duty is enforced by the Board, which can impose a penalty of up to ₹10,000 on the customer. It is not a reason for you to leave a grievance unanswered. Reply to every one, with reasons.
7. Nomination: “Someone Else Should Handle This If I Cannot”
Section 14 lets a customer nominate another individual who will exercise their rights on their death or incapacity. Incapacity has a specific meaning in Section 14(2): inability to exercise the rights because of unsoundness of mind or infirmity of body. Rule 14(4) allows the customer to nominate one or more individuals, using the means you publish and in accordance with your terms of service.
A nomination request therefore arrives twice. First, the customer asks you to record the nominee. Later, the nominee writes to you to exercise a right. At the second stage, you need reasonable evidence of the event before acting, such as a death certificate or a medical certificate of incapacity, and evidence that the person writing is the one who was nominated. This matters most for clinics, hospitals, insurers, banks and any business that keeps records a family may need.
8. Question: “Why Do You Need This?”
Not every message is a formal request. Section 8(9) requires you to publish the business contact details of a Data Protection Officer, where you have one, or of “a person who is able to answer” questions from customers about how their data is processed. Section 6(3) requires those contact details to appear in every request for consent.
A question such as “why does your form ask for my date of birth?” deserves a direct answer from that person. Answered well, it usually ends the matter. Answered badly or not at all, it tends to return as a grievance.
Who Is Allowed to Make a Request?
Before deciding what a request asks for, confirm who is asking. The Act recognises five kinds of requester:
| Requester | Legal basis | What to check |
|---|---|---|
| The customer | Sections 11 to 14 | That they match the account, using the identifier you publish under Rule 14(1)(b) |
| A parent or lawful guardian of a child (under 18) | Section 2(j)(i) | The relationship to the child; see our guide to parental consent |
| The lawful guardian of a person with disability | Section 2(j)(ii); Rule 11 by analogy | That the guardian was appointed by a court, a designated authority or a local level committee under the applicable law |
| A nominee | Section 14, Rule 14(4) | That the customer nominated them, and evidence of death or incapacity |
| A registered Consent Manager | Section 6(7), Rule 4 | Registration with the Board; applies to giving, reviewing and withdrawing consent |
Consent Managers are platforms registered with the Data Protection Board through which a person can manage consents across many businesses. Rule 4, which governs their registration, takes effect on 13 November 2026, so withdrawals routed through one may begin to reach businesses after that date.
On verification, Rule 14(1)(b) asks you to publish the particulars you need to identify a customer under your terms of service, and Rule 14(5) gives examples: a customer ID, application number, email address, mobile number or licence number. Ask for those, and not more. Collecting a copy of someone’s Aadhaar card to confirm a request to update their email address gathers more personal data than the task needs, which is the opposite of what the Act asks of you.
When Can You Decline or Hold Back Part of a Request?
Most requests should simply be fulfilled. The grounds for holding back are specific, and it is good practice to name the one you rely on in your reply:
- A law requires you to keep the data. Section 12(3) and Section 8(7). Tax, accounting, banking and sector records are the usual cases.
- The purpose is still being served. Section 12(3). An order in transit, an open service contract, a pending refund.
- The one-year log minimum. Rule 8(3). Processing logs and associated data are kept for at least a year.
- Sharing with law enforcement on written request. Section 11(2). Limited to the sharing list and prescribed information, not the whole access request.
- The Section 17(1) exemptions. Chapter III does not apply where processing is necessary to enforce a legal right or claim, for courts and regulators performing their functions, or for preventing, detecting or investigating offences, among other listed cases.
- The requester cannot be verified. Acting on an unverified erasure or access request can itself harm the real customer. Ask for the published identifier and wait for it.
- The data was not processed on consent. Sections 11 and 12 apply to data processed on the customer’s consent, including data they gave voluntarily for a purpose under Section 7(a). Data you process under another legitimate use in Section 7, such as employment records under Section 7(i), falls outside the literal text of these two sections. If a request concerns such data, take advice before refusing, and explain your position in writing.
Section 17(3) also allows the Central Government to notify certain classes of business, including startups, to which Section 11 will not apply. Unless a notification specifically covers your business, assume every right applies.
The Act does not expressly require you to give reasons, but a refusal without one, or no reply at all, will usually become a grievance under Section 13, and it is the hardest position to defend before the Board. Failing to honour these rights falls under the general entry in the Schedule to the Act, with a penalty that may extend to ₹50 crore. See how DPDP penalties are decided for how the Board weighs a case.
How Fast Must You Respond to Each Type?
The law is more specific about some requests than others:
- Grievances: within the period you publish, which cannot exceed 90 days (Rule 14(3)).
- Withdrawal of consent: within a reasonable time (Section 6(6)). For promotional messages, that should mean before the next campaign goes out.
- Access, sharing list, correction, erasure, nomination: no fixed period in the Act or the Rules. Rule 14(1) requires you to publish the means of making each request.
In practice, a request that is not answered becomes a grievance, and the grievance clock applies. The simplest safe policy is one published period for every request type, commonly 30 days, measured from the date a verified request is received, with a written acknowledgement sent on the day it arrives. Rule 14 and the other core obligations apply from 13 May 2027, and your privacy notice is where the published period belongs.
What Should Your Request Log Record?
If a complaint ever reaches the Board, your log is the evidence of what you did. For every request, record:
- The date received and the channel it came through.
- The request type, using the eight categories above. One message can contain two, such as a withdrawal and an erasure; log both.
- Who made it, and how you verified them.
- What you did, in each system, and which service providers you instructed.
- What you kept, and the law or purpose that required it.
- The date you replied and the date the request was closed.
This is the same discipline that applies to consent records, and a CA reviewing a client’s readiness will look for both. Our DPDP audit checklist for CAs covers what a reviewer should ask to see.
How EasyDP Handles These Requests
EasyDP’s customer data request feature gives your customers a short link, from your website footer, an SMS or WhatsApp, where they verify themselves and choose the kind of request they want to make, rather than writing a free-text email. Each request lands in a queue with its received date, your published deadline and its current state, so the team can see what is due this week. Every request, response and completion is timestamped into the audit log, including the legal-retention exceptions you configure.
References & Sources
- India Code — Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023): Section 2(j) (Data Principal, including parents and lawful guardians); Section 6(3)–(7) (consent contact details, withdrawal, Consent Managers); Section 7 (legitimate uses); Section 8(7), 8(9), 8(10) (erasure, contact person, grievance mechanism); Sections 11–15 (rights and duties of Data Principals); Section 17 (exemptions); the Schedule (penalties).
- Ministry of Electronics & IT — Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E), 13 November 2025): Rule 1 (commencement), Rule 4 (Consent Managers), Rule 8(3) (one-year minimum retention of logs), Rule 11 (lawful guardians of persons with disability), Rule 14 (rights of Data Principals).
- Ministry of Electronics & IT — Commencement notification, G.S.R. 843(E), 13 November 2025.
- Central Goods and Services Tax Act, 2017 — Section 36 (retention of accounts and records for 72 months from the due date of the annual return).
This article is general information about the DPDP Act 2023 and DPDP Rules 2025, not legal advice. Section and rule references are cited from the official text as of September 2026; verify against the current notified version for your specific situation.