Ch IPreliminary
S.1 Short title and commencementS.2 DefinitionsS.3 Application and scopeCh IIObligations of Data Fiduciary
S.4 Grounds for processingS.5 NoticeS.6 ConsentS.7 Certain legitimate usesS.8 Data Fiduciary obligationsS.9 Children’s dataS.10 Significant Data FiduciaryCh IIIRights and duties of Data Principal
S.11 Right to accessS.12 Correction and erasureS.13 Grievance redressalS.14 Right to nominateS.15 Duties of the Data PrincipalCh IVSpecial provisions
S.16 Transfer outside IndiaS.17 ExemptionsCh VData Protection Board of India
S.18 Establishment of the BoardS.19 Composition of the BoardS.20 Salary and term of officeS.21 DisqualificationsS.22 Resignation and vacanciesS.23 Proceedings of the BoardS.24 Officers and employeesS.25 Members as public servantsS.26 Powers of the ChairpersonCh VIBoard powers and procedure
S.27 Powers and functions of the BoardS.28 Procedure followed by the BoardCh VIIAppeal and dispute resolution
S.29 Appeal to the Appellate TribunalS.30 Tribunal orders as a decreeS.31 Alternate dispute resolutionS.32 Voluntary undertakingCh VIIIPenalties
S.33 Penalties and the ScheduleS.34 Penalties to Consolidated FundCh IXMiscellaneous
S.35 Good-faith protectionS.36 Power to call for informationS.37 Blocking of accessS.38 Consistency with other lawsS.39 Bar of jurisdictionS.40 Power to make rulesS.41 Laying of rules before ParliamentS.42 Power to amend the ScheduleS.43 Power to remove difficultiesS.44 Amendments to other ActsData mapping collection · Acting on requests
A Data Principal’s request is only as quick as your data map is accurate. This guide shows how to use the map to find a person’s data, act on it across systems and processors, and keep the evidence. It includes a free Excel worksheet.
In short
A request-ready data map takes you from a Data Principal’s request to the systems, processors and data that answer it, then to an action and a record of what you did. The Act does not require a map or a request log. Without one, every request becomes a search through other teams’ inboxes.
The basics
It means using your inventory, flow map and processor register to answer one question quickly: where is this person’s data, and who has to act on it?
For each request the map tells you four things. Which systems to search, from the personal data inventory. Which vendors to ask, from the flow and processor map. Whether the right applies and on what ground the data is held, from the purpose and basis map. And what you may need to keep, from the retention and erasure register.
It is not a rights guide or a request-handling policy. For the wording of each right read the Act pages for Section 11, Section 12, Section 13 and Section 14, and the glossary entries on access, correction and erasure, grievance redressal and nomination. For withdrawal of consent use the consent withdrawal guide.
The law
Sections 11 to 14 and Rule 14 set the rights and the published routes. The map has to be able to supply what each one asks for. The table paraphrases the provisions. Read the Act text before relying on a wording.
| Provision | In plain words | What the map must supply |
|---|---|---|
| Section 11 Access | On request, a summary of the personal data being processed and the processing activities. The identities of all other Data Fiduciaries and Data Processors it has been shared with, and a description of the data shared. Other prescribed information. | Activities and data from the inventory. Recipients from the processor register and flow map. |
| Section 12(2) Correction | On request, correct inaccurate or misleading data, complete incomplete data and update data. | Where each field is edited, and which copies carry it. |
| Section 12(3) Erasure | On request, erase the data unless retention is necessary for the specified purpose or to comply with a law. | Every location and copy. The keep reason from the retention register. |
| Section 13 and Rule 14(3) Grievance | Readily available means of grievance redressal, with a response within the prescribed period. Rule 14(3) requires a published timeframe not exceeding ninety days. The Data Principal must use this route before approaching the Board. | The route, the owner and the systems behind a complaint. |
| Section 14 and Rule 14(4) Nomination | A Data Principal may nominate someone to exercise her rights on her death or incapacity. | A record of who may act for whom. |
| Rule 14(1) Published means | Publish how a request can be made and the particulars, such as a user name or other identifier, needed for identification. | The identifier each system uses to find a person. |
Scope. Sections 11(1) and 12(1) refer to a Data Fiduciary to whom the Data Principal has previously given consent, including consent under Section 7(a). We found no express text on whether these rights reach processing under other Section 7 uses. Record the ground for each activity and take advice on edge cases. Time. We found no provision that sets a response time for access, correction or erasure requests. Do not import a deadline from another law.
The method
Every request follows six links: request, systems, processors, data, action and evidence. The map supplies links two to four. A missing link is a gap, and gaps are what make requests slow.
Use the map
Each type of request uses a different part of the map. This table is the centrepiece of the worksheet: a row for the request, the systems to search, the processors to ask, the checks and the evidence to keep.
| Request | Search these | Ask these | Check before acting | Keep as evidence |
|---|---|---|---|---|
| Access Section 11 | Every system holding the person’s activities | Processors listed against those systems | Recipients in the processor register and flow map | The summary sent, the recipient list, the date |
| Correction, completion, update Section 12 | Systems where the field is edited, plus copies and exports | Processors holding a copy | Which copy is the source of truth | What changed, who changed it, the date |
| Erasure Section 12 | Every system, copy, export and backup | Every processor holding the data | Retention register for a keep reason. Ground in the purpose and basis map. | Erasure log, processor confirmations, the reason for anything kept |
| Withdrawal of consent Section 6 | Systems running the consent-based activity | Processors for that activity | The stop route. Other activities resting on other grounds may continue. | Time-stamped withdrawal and stop confirmation |
| Grievance Section 13 | The systems behind the complaint | Processors involved | The published route and timeframe under Rule 14(3) | Complaint, reply and dates |
| Nomination Section 14 | Where nominations are recorded | Usually none | Who may act for whom, and the nominee’s identity | The nomination record |
Use the map
A customer asks the store to erase her data. The map shows four systems, three processors and one record the store may need to keep. The outcome is partly erased, with the reason written down.
The request arrives by email as R-003. The owner checks the sender against the account email, then opens the Systems sheet for activities PA-001 to PA-004 and the retention register for the keep reason. The store and every vendor here are fictional.
| System | Data found | Processor | Action | Evidence |
|---|---|---|---|---|
| Web shop | Profile, address book | P-001 | Account deletion job run. Profile removed. | Job log |
| Order database | Three past orders with contact fields | P-001 | Kept until the retention date in the register. The law behind the period is to be confirmed with counsel. | Retention entry and a written reason |
| Email platform | Newsletter record. A campaign export in a shared drive. | P-002 | Contact deleted, address added to the suppression list, export edited. | Platform log and vendor confirmation |
| Helpdesk | Two tickets | P-003 | No erase route was recorded. The owner asked the vendor to delete both tickets and then wrote the method into the Systems sheet. | Vendor confirmation |
The retention reason is a placeholder. It is not a legal conclusion about any real business.
Use the map
Five checks come before any search: who is asking, whether the right applies to this activity, whether anything must be kept, whether a child is involved and whether someone is acting for the person. Each has an answer in the map.
| Check | What to consider | Where in the map |
|---|---|---|
| 1. Who is asking? | Rule 14(1)(b) refers to particulars, such as a user name or other identifier, needed for identification. The Act sets no single procedure. Section 15(e) asks a Data Principal to furnish only verifiably authentic information when exercising the right to correction or erasure. Ask for no more than you need. | Systems sheet: identifier used |
| 2. Does the right apply? | Sections 11 and 12 are framed around data processed on consent, including under Section 7(a). We found no express text on other Section 7 uses. | Purpose and basis map: ground |
| 3. Must anything be kept? | Section 12(3) allows retention where necessary for the specified purpose or to comply with a law. Write down which reason applies. | Retention register |
| 4. Is a child involved? | The Act’s definition of Data Principal includes the parent or lawful guardian of a child. Section 9 sets separate rules for children’s data. | Inventory: child data flag |
| 5. Is a nominee acting? | Section 14 and Rule 14(4) let a Data Principal nominate someone to exercise her rights on death or incapacity. | Requests sheet: whose request |
Section 11(2) says the recipient details in Section 11(1)(b) and (c) do not apply to sharing with another Data Fiduciary authorised by law, made on its written request, for preventing, detecting or investigating offences or cyber incidents, or for prosecuting or punishing offences. Take legal advice before relying on it.
Use the map
Most delays come from a handful of gaps in the map, not from the request itself. Fix them once and every later request gets faster.
| Gap | What happens | Fix |
|---|---|---|
| A system is missing from the map | The search misses data and the answer is incomplete. | Reconcile the map with IT and finance software lists each quarter. |
| No identifier recorded | Staff cannot tell which record is hers. | Record how each system finds a person. |
| No correct or erase route | The request waits for the one person who knows how. | Write the route on the Systems sheet. |
| Copies and exports not listed | Data survives in spreadsheets, shared drives and mailboxes. | Record copies per system and search them. |
| A processor with no contact route | The vendor request goes nowhere. | Keep a named contact and a route in the processor register. |
| No owner | Nobody answers. | One owner for each system and each request. |
| Stale rows | The map describes last year’s systems. | Record a verified date and recheck when a vendor or tool changes. |
We found no provision on backups. Record where they exist, how long they last and what happens when they expire, as in the retention and erasure guide.
Build and use it
The worksheet has a Systems sheet for the lookup and a Requests sheet for the log, with examples, a summary and lists. Enter your details on the download page to get the link.
Excel (.xlsx), about 26 KB. Sheets: Start here, Requests (60 rows), Systems (40 rows), Example requests, Example systems, Summary, Lists. Gap flags are formulas. The examples are fictional and are not legal conclusions.
The Requests sheet logs each request from receipt to evidence in 14 fields. The Systems sheet records, for each system, the identifier, how to search, correct and erase, copies and backups, processors, owner and verified date. The Summary sheet has an optional internal target in days. It is your own number and not a legal deadline.
A flag shows the first gap in a row, such as identity not checked, no systems searched, no reason written, no evidence kept, no way to erase recorded or copies not checked. It is a prompt to check, not a finding of non-compliance. Record categories of data in the log, not the data itself, and limit who can open the file.
Build and use it
Build the systems lookup, link processors, add the ground and keep reason, set up intake and the log, run a dry run, then review after every request. Each step has an output you can check.
Build and use it
Most failures come from searching too little, deleting too much or recording too little. These seven are the usual causes.
| Mistake | Why it hurts | Fix |
|---|---|---|
| 1. Searching only the main database | Copies in exports, mailboxes and vendor tools stay behind. | Search every system and copy on the Systems sheet. |
| 2. Erasing without a keep check | You may delete data a law or the purpose requires you to keep. | Check the retention register first and write the reason for anything kept. |
| 3. Forgetting processors | You stay responsible for processing done on your behalf. | Ask every processor on the row and keep its confirmation. |
| 4. Copying the data into the log | The log becomes another store of personal data. | Record categories and references only. |
| 5. Over-asking for identity | Collecting an ID document where an email match would do adds data you must then protect. | Use what you already hold and ask for no more than you need. |
| 6. Borrowing a deadline from another law | We found no response time for these requests in the Act or Rules. Rule 14(3) concerns grievances. | Set and publish your own target. |
| 7. Building the lookup once | Systems and vendors change, and the lookup goes stale. | Record a verified date and recheck on change. |
Questions
No. We found no provision that requires a data map, a systems lookup or a request log. The Act does require outcomes, such as correction and erasure on request, that are hard to deliver without knowing where the data is. A map is the practical way to get there.
A summary of the personal data being processed and the processing activities, the identities of all other Data Fiduciaries and Data Processors the data has been shared with and a description of the data shared, and any other prescribed information. The inventory and the processor register supply the first two.
We found no provision that sets a time for these requests. Rule 14(3) requires a published grievance timeframe not exceeding ninety days. Set and publish a realistic target of your own, and do not assume a deadline from another law.
Sections 11(1) and 12(1) refer to a Data Fiduciary to whom the Data Principal has previously given consent, including consent under Section 7(a). We found no express text on other Section 7 uses. Record the ground for each activity and take legal advice on edge cases.
Section 12(3) says to erase unless retention is necessary for the specified purpose or for compliance with a law. If you keep something, record which reason applies. Telling the person why is good practice. We found no provision that sets the form of the reply.
Section 8(1) makes the Data Fiduciary responsible for compliance, including for processing done on its behalf by a Data Processor. In practice, the processor has to act and confirm. We found no provision that prescribes how the instruction must be given.
The Act sets no single procedure. Rule 14(1)(b) refers to particulars, such as a user name or other identifier, needed for identification. Use what you already hold, such as the account email, and avoid collecting more than you need.
For a child, the Act’s definition of Data Principal includes the parent or lawful guardian. Section 14 and Rule 14(4) let a Data Principal nominate someone to exercise her rights on her death or incapacity. Record who is acting and on what basis.
No. Record categories of data and references to tickets and confirmations. We found no provision that requires a log, so keep it lean and restrict who can open it.
We found no provision on backups. Record where backups exist, how long they last and what happens when they expire, and apply the same plan to every request. The retention and erasure guide covers this.
Related
Go to the full method, the legal text and the practical tools. When you are ready to move from records to working controls, see the DPDP implementation framework.
Sources
Consultant-led and partner-backed.