Sample Read
© All rights reserved Price : ` 725 Law stated in this book is as updated till 15th September, 2026 Published by : Taxmann Publications (P.) Ltd. Sales & Marketing : 59/32, New Rohtak Road, New Delhi-110 005 India Phone : +91-11-45562222 Website : www.taxmann.com E-mail : sales@taxmann.com Regd. Office : 21/35, West Punjabi Bagh, New Delhi-110 026 India Printed at : Tan Prints (India) Pvt. Ltd. 44 Km. Mile Stone, National Highway, Rohtak Road Village Rohad, Distt. Jhajjar (Haryana) India E-mail : sales@tanprints.com Disclaimer Every effort has been made to avoid errors or omissions in this publication. In spite of this, errors may creep in. Any mistake, error or discrepancy noted may be brought to our notice which shall be taken care of in the next edition. It is notified that neither the publisher nor the author or seller will be responsible for any damage or loss of action to any one, of any kind, in any manner, therefrom. No part of this book may be reproduced or copied in any form or by any means [graphic, electronic or mechanical, including photocopying, recording, taping, or information retrieval systems] or reproduced on any disc, tape, perforated media or other information storage device, etc., without the written permission of the publishers. Breach of this condition is liable for legal action. For binding mistake, misprints or for missing pages, etc., the publisher’s liability is limited to replacement within seven days of purchase by similar edition. All expenses in this connection are to be borne by the purchaser. All disputes are subject to Delhi jurisdiction only.
Contents PAGE
Author’s Note
I-5
About the Author
I-9
How to use this book
I-11
List of Abbreviations
I-13
Chapter-Heads
I-15
PART I : THE LAW AND ITS ARCHITECTURE CHAPTER 1 GENESIS AND FRAMEWORK OF THE DPDP ACT, 2023 1.1
The constitutional foundation
4
1.2
The legislative path: Srikrishna Committee to the 2023 Act
5
1.3
Objectives and design philosophy
7
1.4
Territorial scope and applicability
8
1.5
The regulatory architecture
9
1.5.1
The data protection board of India
9
1.5.2
The appellate tribunal
10
1.5.3
The Central Government
11
1.6
Commencement timelines
11
1.7
The DPDP Rules, 2025: Structure and relationship with the Act
13
1.8
Establishment of the data protection board
14
1.9
Implementation considerations
15
1.9.1
Determining applicability
15
1.9.2
Mapping phased enforcement dates to internal planning
15
1.9.3
Identifying the organisation’s role
16
I-17
CONTENTS
I-18 PAGE
CHAPTER 2 KEY DEFINITIONS AND FOUNDATIONAL CONCEPTS 2.1
Personal data and digital personal data
18
2.2
Processing
19
2.3
Data fiduciary
20
2.4
Data processor
21
2.5
Data principal
22
2.6
Significant data fiduciary
23
2.7
Consent manager
23
2.8
Personal data breach
25
2.9
Specified purpose
25
2.10
The breadth of “Person” under the Act
26
2.11
The data protection officer
26
2.12
Additional defined terms under rule 2
27
2.13
Other institutional definitions
28
2.14
Implementation considerations
29
2.14.1
Conducting the role classification exercise
29
2.14.2
Documenting role determinations
29
2.14.3
Assessing significant data fiduciary status
30
PART II : OBLIGATIONS OF DATA FIDUCIARIES CHAPTER 3 GROUNDS FOR LEGAL PROCESSING 3.1
The binary framework under section 4
36
3.2
Consent as a lawful ground
37
3.2.1 3.3
Consent validity: The consequences of getting it wrong
Certain legitimate uses under section 7
38 40
3.3.1
Voluntary Provision for a specified purpose - Section 7(a)
40
3.3.2
State processing for subsidies, benefits, and services - Section 7(b)
41
I-19
CONTENTS
PAGE
3.3.3
State functions, sovereignty, and security - Section 7(c)
41
3.3.4
Legal obligation to disclose information - Section 7(d)
42
3.3.5
Compliance with court orders - Section 7(e)
42
3.3.6
Medical emergency - Section 7(f)
43
3.3.7
Public health measures - Section 7(g)
43
3.3.8
Disaster response and public order - Section 7(h)
44
3.3.9
Employment purposes - Section 7(i)
44
3.3.10
The absence of a general legitimate interests ground
45
3.4
Processing by the state: Standards under the second schedule
46
3.5
The boundary between consent and legitimate use
47
3.6
Record-keeping for demonstrating the lawful basis
48
3.7
Implementation considerations
49
3.8
3.7.1
Building a lawful basis register
49
3.7.2
Distinguishing consent from legitimate use in common scenarios
49
3.7.3
Illustrative template: Lawful basis register
50
3.7.4
Periodic review of lawful basis determinations
51
Audit considerations: Lawful basis compliance
52
CHAPTER 4 NOTICE AND CONSENT 4.1
The notice obligation
55
4.1.1
Notice as a standalone document
56
4.1.2
Mandatory contents
56
4.1.3
Rights exercise and complaint mechanisms
57
4.2
Multi-language accessibility
57
4.3
Transitional notices for pre-existing consent
58
4.4
The consent mechanism: From attributes to operations
59
Consent presentation requirements
60
4.4.1 4.5
Withdrawal of consent
60
4.6
Proving consent: The evidentiary burden
61
4.7
The consent manager framework
62
4.7.1
Registration conditions for consent managers
62
4.7.2
Obligations of the consent manager
63
CONTENTS
I-20 PAGE
4.8
Implementation considerations 4.8.1
4.9
4.10
Designing notice documents compliant with rule 3
Illustrative template: Model notice under rule 3
64 64 65
4.9.1
Building consent collection mechanisms
66
4.9.2
Designing the consent withdrawal mechanism
67
4.9.3
Managing the transitional notice rollout
67
4.9.4
Consent record-keeping for evidentiary purposes
67
Audit considerations: Notice and consent
68
CHAPTER 5 GENERAL OBLIGATIONS OF A DATA FIDUCIARY 5.1
Accountability: Section 8(1)
70
5.2
Engagement of data processors under a valid contract: Section 8(2)
72
5.3
Data quality: Completeness, accuracy, and consistency under section 8(3)
73
5.4
Technical and organisational measures: Section 8(4)
74
5.5
Publication of contact information: Section 8(9) and rule 9
75
5.6
Grievance redressal: Section 8(10), section 13, and rule 14(3)
76
5.7
Implementation considerations
77
5.8
5.7.1
Building the accountability framework
77
5.7.2
Illustrative template: Data processing agreement key clauses
78
5.7.3
Establishing data quality checks
79
5.7.4
Designing the grievance redressal mechanism
80
Audit considerations: General obligations
81
CHAPTER 6 SECURITY SAFEGUARDS AND BREACH MANAGEMENT 6.1
Reasonable security safeguards: Section 8(5) and rule 6
82
6.1.1
Encryption, obfuscation, masking, and virtual tokens Rule 6(1)(a)
83
6.1.2
Access controls - Rule 6(1)(b)
84
6.1.3
Logging, monitoring, and review - Rule 6(1)(c)
85
6.1.4
Business continuity and data backups - Rule 6(1)(d)
85
I-21
CONTENTS
PAGE
6.2
6.3
6.1.5
Mandatory one-Year Log Retention - Rule 6(1)(e) and Rule 8(3)
86
6.1.6
Contractual provisions with data processors - Rule 6(1)(f)
87
6.1.7
Technical and organisational measures for security observance - Rule 6(1)(g)
87
Personal data breach: Definition and notification obligations
87
6.2.1
Intimation to data principals - Rule 7(1)
88
6.2.2
Intimation to the board - Rule 7(2)
88
Penalty exposure for security and breach notification failures
90
6.3.1
Mapping existing controls against rule 6(1) minimum requirements
90
6.3.2
Building the breach response workflow
91
6.3.3
Illustrative template: Breach notification under rule 7
91
6.3.4
Log retention architecture
93
6.4
Interaction with CERT-in log retention requirements
94
6.5
Audit considerations: Security safeguards and breach management
94
CHAPTER 7 PROCESSING OF CHILDREN’S DATA AND DATA OF PERSONS WITH DISABILITY 7.1
Verifiable parental consent: Section 9(1) and rule 10
97
7.1.1
Verification Through Existing Identity Details - Rule 10(1)(a)
97
7.1.2
Verification through voluntarily provided details or virtual tokens - Rule 10(1)(b)
98
7.2
Prohibition on processing detrimental to a child’s well-being: Section 9(2)
99
7.3
Prohibition on tracking, behavioural monitoring, and targeted advertising: Section 9(3)
100
7.4
Exemptions from children’s data obligations: Rule 12 and the Fourth Schedule
101
7.4.1
Part A - Exempt classes of data fiduciaries
101
7.4.2
Part B - Exempt purposes
102
7.5
Verifiable safe processing and age threshold notification: Section 9(5)
103
CONTENTS
I-22 PAGE
7.6
Processing of personal data of persons with disability: Rule 11
103
7.7
Implementation Considerations
104
7.8
7.7.1
Designing age-gating and parental verification mechanisms
104
7.7.2
Illustrative template: Parental consent verification Record
105
7.7.3
Technical controls for prohibited processing
106
7.7.4
Assessing and documenting fourth schedule exemptions
106
7.7.5
Guardian verification procedures for persons with disability
107
Audit considerations: Children’s data
107
CHAPTER 8 RETENTION, DELETION, AND CROSS-BORDER TRANSFER 8.1
Retention and erasure: Section 8(7)
109
8.2
Deemed cessation of purpose: Section 8(8) and the third schedule
110
8.3
The forty-eight-hour pre-deletion notification: Rule 8(2)
111
8.4
One-year minimum retention of processing logs: Rule 8(3) and the seventh schedule
112
8.5
Data processor erasure obligations: Section 8(7)(b)
113
8.6
Cross-border transfer: Section 16 and rule 15
114
8.7
Data localisation for significant data fiduciaries: Rule 13(4)
115
8.8
Interaction with other laws on cross-border transfer: Section 16(2)
115
8.9
Implementation considerations
116
8.10
8.9.1
Building the retention schedule
116
8.9.2
Designing the pre-deletion notification workflow
117
8.9.3
Assessing cross-border data flows
118
Audit considerations: Retention, deletion, and cross-border transfer
119
I-23
CONTENTS
PAGE
PART III : RIGHTS OF DATA PRINCIPALS CHAPTER 9 RIGHTS, DUTIES, AND THE GRIEVANCE FRAMEWORK 9.1
Right to access information about personal data: Section 11 9.1.1
Exception for law enforcement sharing: Section 11(2)
124 124
9.2
Right to correction, completion, updating, and erasure: Section 12
125
9.3
Right of grievance redressal: Section 13 and rule 14(3)
126
9.4
Right to nominate: Section 14 and rule 14(4)
127
9.5
Duties of the data principal: Section 15
128
9.6
Manner of exercising rights: Rule 14(1) and (2)
129
9.7
Implementation considerations
130
9.8
9.7.1
Designing the rights fulfilment workflow
130
9.7.2
Building and publishing the rights request mechanism
131
9.7.3
Handling competing legal retention obligations
132
9.7.4
Nomination mechanism design
133
Audit considerations: Rights and grievance framework
133
PART IV : SIGNIFICANT DATA FIDUCIARIES AND SPECIAL PROVISIONS CHAPTER 10 SIGNIFICANT DATA FIDUCIARIES - ADDITIONAL OBLIGATIONS 10.1
Notification criteria: Section 10(1)
138
10.2
The data protection officer: Section 10(2)(a)
139
10.3
Independent data audit: Section 10(2)(b) and rule 13(1)
140
10.4
Data protection impact assessment: Section 10(2)(c)(i) and rule 13(1)
141
10.5
Algorithmic and technical risk assessment: Rule 13(3)
141
10.6
Data localisation for specified categories: Rule 13(4) – (5)
142
10.7
Implementation considerations
143
10.7.1
DPO selection, appointment, and governance integration
143
CONTENTS
I-24 PAGE
10.8
10.7.2
Selecting and engaging independent data auditors
144
10.7.3
Building the DPIA methodology
144
10.7.4
Illustrative template: DPIA structure
145
10.7.5
Annual compliance calendar for significant data fiduciary obligations
146
Audit considerations: Significant data fiduciary obligations
147
CHAPTER 11 EXEMPTIONS AND SPECIAL PROVISIONS 11.1
General exemptions: Section 17(1)
148
11.1.1
Enforcing legal rights or claims - Section 17(1)(a)
149
11.1.2
Judicial and quasi-judicial functions - Section 17(1)(b)
149
11.1.3
Prevention and Investigation of offences - Section 17(1)(c)
150
11.1.4
Offshore contracting - Section 17(1)(d)
150
11.1.5
Mergers and acquisitions - Section 17(1)(e)
150
11.1.6
Financial default disclosure - Section 17(1)(f)
150
11.2
Sovereign and security exemptions: Section 17(2)(a)
151
11.3
Research, archiving, and statistical purposes: Section 17(2)(b) and rule 16
152
11.4
Startup and small entity exemptions: Section 17(3)
153
11.5
State processing exemptions: Section 17(4)
153
11.6
Time-bound blanket exemptions: Section 17(5)
154
11.7
Implementation considerations
155
11.7.1
Documenting and maintaining the exemption register
155
11.7.2
Illustrative template: Exemption register
155
11.7.3
Ensuring compliance with non-exempt obligations
156
11.7.4
Research processing under the second schedule
156
11.7.5
Monitoring central government notifications
157
I-25
CONTENTS
PAGE
PART V : COMPLIANCE AND ENFORCEMENT CHAPTER 12 THE COMPLIANCE PROGRAMME - PLANNING, GOVERNANCE, AND READINESS 12.1
12.2
12.3
Programme planning
161
12.1.1
The implementation roadmap against May 2027
161
12.1.2
The first ninety days
162
12.1.3
Illustrative template: Compliance readiness checklist
163
Governance architecture
164
12.2.1
Programme governance structure
164
12.2.2
Policy architecture
165
12.2.3
Training and awareness
165
12.2.4
The concept of demonstrable compliance
166
12.2.5
Preparing for a data protection board inquiry
167
Interaction with existing regulatory obligations
167
CHAPTER 13 SECTOR-SPECIFIC CONSIDERATIONS 13.1
Banking and financial services
171
13.2
Insurance
172
13.3
Healthcare and health technology
173
13.4
E-commerce
174
13.5
Education technology
174
13.6
Software as a Service (SaaS)
175
13.7
Non-banking financial companies and fintech
176
13.8
Co-operative banks, regional rural banks and smaller institutions
177
13.9
Implementation considerations across sectors
177
13.10 Audit considerations: Sector specific
179
CONTENTS
I-26 PAGE
CHAPTER 14 ENFORCEMENT, PENALTIES, AND DISPUTE RESOLUTION 14.1
The data protection board of India: Establishment and composition
180
14.2
Powers and functions of the board: Section 27
181
14.3
Inquiry procedure: Section 28 and rule 19
182
14.4
The penalty framework: Section 33 and the Schedule
183
14.5
Alternative resolution: Voluntary undertaking and mediation
184
14.6
Appeal to the Appellate Tribunal: Section 29 and rule 22
185
14.7
Central Government Powers: Information-calling and the blocking power (Sections 36–37, Rule 23)
186
14.8
Implementation considerations
187
14.9
14.8.1
Preparing for enforcement readiness
187
14.8.2
Illustrative template: Board inquiry response protocol
188
14.8.3
Engaging with the board’s digital office
189
14.8.4
Voluntary undertaking as a strategic option
189
Audit considerations: Enforcement readiness
Glossary of Defined Terms
190 193
APPENDICES Appendix A: Consolidated requirements register
199
Appendix B: Digital Personal Data Protection Act, 2023
220
Appendix C : Digital Personal Data Protection Rules, 2025
272
Appendix D : Notifications
298
CHAPTER
4
Notice and Consent
The privacy notices that most organisations currently publish on their websites run to several thousand words. They are drafted by lawyers, reviewed by lawyers, and read - in practice - by almost no one. The drafters of the DPDP Act and Rules were evidently aware of this problem. The requirements they prescribe for notices are not a licence to produce more unread legal documents. They are a mandate to produce fewer, clearer, and more purposeful ones. Chapter 3 examined the lawful bases on which personal data may be processed - consent and specified legitimate uses. This chapter examines the mechanics of two of the most operationally demanding obligations in the Act: the notice that must precede or accompany a request for consent, and the consent itself. It also examines the Consent Manager framework - a distinctive feature of the DPDP regime that interposes a registered intermediary between the Data Principal and the Data Fiduciary in the management of consent. The obligations are precise. The Act and Rules together specify what a notice must contain, how it must be presented, in which languages it must be accessible, and how it must be adapted for Data Principals who gave consent before the Act came into force. They specify the attributes of valid consent, the manner in which consent requests must be presented, the mechanism for consent withdrawal, and the evidentiary burden that falls on the Data Fiduciary when consent is challenged. These are not abstract principles. They are drafting specifications.
4.1 THE NOTICE OBLIGATION Section 5(1) of the Act requires that every request made to a Data Principal for consent shall be accompanied or preceded by a notice. The timing is precise: the notice must come before the consent request or at the same time. It cannot come after. A Data Fiduciary that collects consent first and sends a notice later is in breach of Section 5(1), regardless of how thorough the notice may be. For example, a hospital that has a patient sign an 55
Para 4.1
PART II : OBLIGATIONS OF DATA FIDUCIARIES
56
admission form containing a bundled consent clause, and only hands over the privacy notice with the discharge paperwork days later, has collected consent well after the notice and is in breach of Section 5(1) irrespective of the notice’s content. The notice under Section 5(1) must inform the Data Principal of three things: the personal data and the purpose for which the same is proposed to be processed; the manner in which the Data Principal may exercise their rights under Section 6(4) (withdrawal of consent) and Section 13 (grievance redressal); and the manner in which the Data Principal may make a complaint to the Board. The notice must be given in such manner and as may be prescribed, which brings Rule 3 into operation.
4.1.1 Notice as a Standalone Document Rule 3(a) introduces a requirement that is absent from the Act’s text but carries significant practical consequences. The notice must be presented and be understandable independently of any other information that has been, is, or may be made available by such Data Fiduciary. This means the notice cannot rely on cross-references to a terms-of-service document, a general privacy policy, or any other document for its comprehensibility. A Data Principal reading the notice and nothing else must be able to understand what personal data will be collected, for what purpose, and how to exercise their rights within the ambit of this data collection. The standalone requirement effectively prohibits the common practice of embedding consent-related disclosures within a broader privacy policy and requiring the Data Principal to locate the relevant provisions. It also prohibits the practice of referring the Data Principal to a separate document for the description of rights or complaint mechanisms. Everything the Data Principal needs to give informed consent to must be mentioned in the notice itself - or be immediately accessible through the communication links provided in the notice.
4.1.2 Mandatory Contents Rule 3(b) specifies the minimum contents that the notice must include. The notice must give, in clear and plain language, a fair account of the details necessary to enable the Data Principal to give specific and informed consent. At a minimum, this must include an itemised description of the personal data to be processed and the specified purpose or purposes of processing, including a specific description of the goods or services to be provided, or uses to be enabled by such processing. Two requirements deserve emphasis. First, the description of personal data must be “itemised.” A generic statement such as “we collect your personal information” does not satisfy this requirement. The notice must identify,
57
CH. 4 : NOTICE AND CONSENT
Para 4.2
item by item, the categories of personal data to be collected - name, address, date of birth, email address, mobile Number, payment details, location data, device identifiers, and so on. The level of specificity required is the level that enables the Data Principal to understand precisely what data they are being asked to allow the Data Fiduciary to process. Second, the purpose description must include a “specific description of the goods or services to be provided or uses to be enabled.” A purpose stated as “to improve our platform” is insufficiently specific. The notice must link the processing to a concrete output: “to deliver the product you have ordered,” “to verify your identity for Know Your Customer compliance,” “to send you promotional communications about our financial products.” The specificity requirement ensures that the Data Principal can assess whether the processing is proportionate and whether they wish to consent.
4.1.3 Rights Exercise and Complaint Mechanisms Rule 3(c) requires the notice to give the particular communication link for accessing the website or application of the Data Fiduciary, and a description of other means (if any) using which the Data Principal may withdraw consent, exercise rights under the Act, and make a complaint to the Board. This is not a generic reference. The notice must contain the actual URL or working application link through which the Data Principal can take action. It must also describe and list any alternative channels - a postal address, a toll-free Number, an email address - that the Data Principal may use. The practical effect is that the notice doubles as a directory of the Data Principal’s available channels of action. An auditor reviewing the notice should be able to trace every right and remedy available to the Data Principal to a specific mechanism for its exercise, as published in the notice.
4.2 MULTI-LANGUAGE ACCESSIBILITY Section 5(3) requires the Data Fiduciary to give the Data Principal the option to access the contents of the notice in English or any language specified in the Eighth Schedule to the Constitution of India. Section 6(3) imposes the same language accessibility requirement on every consent request. The Eighth Schedule currently recognises twenty-two Indian languages: Assamese, Bengali, Bodo, Dogri, Gujarati, Hindi, Kannada, Kashmiri, Konkani, Maithili, Malayalam, Manipuri, Marathi, Nepali, Odia, Punjabi, Sanskrit, Santali, Sindhi, Tamil, Telugu, and Urdu. The obligation is not to provide the notice in all twenty-two languages simultaneously. It is to give the Data Principal the option to access the notice in English or any of these languages. The practical implementation requires a language selection mechanism - a dropdown, a toggle, or a similar interface
Para 4.3
PART II : OBLIGATIONS OF DATA FIDUCIARIES
58
element - that allows the Data Principal to choose their preferred language and view the notice in that language. The Data Fiduciary must ensure that the translation is accurate and that the translated notice conveys the same information as the English version. For organisations operating at a national scale, the twenty-two-language requirement is operationally demanding. The notice is not a static document - it will change as processing activities evolve, as new purposes are added, and as the regulatory framework develops. Every change to the English notice must be reflected in every language version almost immediately. Translation must be performed by persons with sufficient legal and technical literacy to ensure that the statutory terms - Data Fiduciary, Data Principal, consent, processing, personal data breach - are rendered accurately. Machine translation, without human review, creates the risk of inaccurate notices that fail the “clear and plain language” requirement. In practice, organisations preparing for the 13 May, 2027 commencement date should approach the twenty-two-language requirement as a two-stage programme rather than a single translation exercise. The first stage is the creation of working translations across the required languages. Machine-assisted translation tools, including the Government of India’s Bhashini initiative and other enterprise translation platforms, are increasingly capable of producing usable first drafts for this purpose. The second stage should be a prioritised human review conducted by individuals who are conversant with the language and the legal terminology of the Act and Rules. The review effort need not begin simultaneously across all twenty-two languages. A practical approach is to prioritise the languages spoken in the states where the organisation has the largest customer base and highest processing volumes. Particular care should be taken with statutory terminology such as “Data Principal”, “Data Fiduciary”, “consent”, “withdrawal of consent”, and “personal data breach”. An inaccurate translation of these concepts may create greater compliance risk than the absence of a translation because Section 6(10) places the burden on the Data Fiduciary to prove that valid notice was given and valid consent was obtained. A mistranslated notice preserved as evidence may demonstrate that the Data Principal was informed of something different from what the Act requires.
4.3 TRANSITIONAL NOTICES FOR PRE-EXISTING CONSENT Section 5(2) addresses a problem that every organisation processing personal data before the commencement of the Act will face: what to do about consent obtained before the Act came into force. The provision requires that where a Data Principal has given her consent before the date of commencement, the Data Fiduciary shall, as soon as it is reasonably practicable, give a notice informing the Data Principal of the personal data and the purpose
59
CH. 4 : NOTICE AND CONSENT
Para 4.4
for which it has been processed, the manner of exercising rights, and the manner of making a complaint to the Board. The Data Fiduciary may continue to process the personal data until the Data Principal withdraws their consent. The transitional notice is therefore an information exercise, not a re-consent exercise. The Data Fiduciary does not need to obtain fresh consent from every Data Principal with whom it had a pre-commencement relationship. It needs to inform them of the rights they now have under the Act. If a Data Principal, having received the transitional notice, takes no action, the existing consent continues to be the lawful basis for processing. The illustration accompanying Section 5(2) specifies the methods of delivery: email, in-app notification, or other effective method. The Data Fiduciary must be able to demonstrate that it delivered the transitional notice through a method that was reasonably likely to reach the Data Principal. A notice posted on the website but not actively delivered to the Data Principal - for example, through a banner on a landing page that the Data Principal may never visit - would not satisfy the “as soon as reasonably practicable” requirement. Transitional Notice - The Scale Challenge An e-commerce platform with fifty million registered users who consented to data processing before the Act’s commencement must deliver transitional notices to all of them. The operational challenge is not merely one of volume. The platform must map each user’s personal data and processing purposes, draft a notice that accurately describes the specific processing applicable to that user or user cohort, translate the notice into multiple languages, and deliver it through a channel registered by the user. Organisations that begin this exercise only after 13 May 2027 will face a compressed timeline and a high risk of incomplete delivery.
4.4 THE CONSENT MECHANISM: FROM ATTRIBUTES TO OPERATIONS Chapter 3 examined the five attributes of valid consent under Section 6(1) - free, specific, informed, unconditional, and unambiguous - as elements of the lawful basis framework. This section addresses the operational dimension: how these attributes translate into the design of consent collection mechanisms. The requirement that consent be given through a “clear affirmative action” is the starting point for mechanism design. The affirmative action must be recorded. The mechanism must capture, at a minimum, the identity of the Data Principal (or sufficient identifying information to link the consent to a specific individual), the specific purpose or purposes consented to, the categories of personal data covered by the consent, the version of the notice in effect at the time of consent, the timestamp of the consent, and the
Para 4.5
PART II : OBLIGATIONS OF DATA FIDUCIARIES
60
method of affirmative action (button click, checkbox selection, signature, verbal declaration). Each of these elements must be stored in a manner that permits retrieval and verification, because Section 6(10) places the burden of proving valid consent on the Data Fiduciary. Granularity is a design requirement, not a preference. Where a Data Fiduciary processes personal data for multiple purposes, Section 6(1) requires that consent be specific to each purpose and limited to the personal data necessary for that purpose. A single consent mechanism that bundles multiple purposes into one affirmative action does not satisfy the specificity requirement. The mechanism must offer the Data Principal the ability to consent to each purpose separately, and the Data Fiduciary must be prepared to provide the service or product even if the Data Principal consents to some purposes but not others - unless the declined purpose is genuinely necessary for the service.
4.4.1 Consent Presentation Requirements Section 6(3) prescribes three requirements for the presentation of consent requests. Every request must be presented in clear and plain language. The Data Principal must be given the option to access the request in English or any Eighth Schedule language. And the request must provide the contact details of the Data Protection Officer (where applicable) or of any other person authorised by the Data Fiduciary to respond to communications from the Data Principal for the purpose of exercising rights under the Act. “Clear and plain language” is a standard, not a format. It excludes legal jargon, technical terminology that the average Data Principal would not understand, and convoluted sentence structures. A consent request that states “the Data Fiduciary shall process personal data of the Data Principal for the specified purpose in accordance with the provisions of the Act” may be legally accurate, but it does not communicate anything meaningful to a non-specialist reader. The consent request must explain, in ordinary language, what data will be collected, what will be done with it, and what the Data Principal is agreeing to.
4.5 WITHDRAWAL OF CONSENT Section 6(4) confers on the Data Principal the right to withdraw consent at any time, with a critical operational condition: the ease of doing so must be comparable to the ease with which consent was given. If consent was given through a single button click in a mobile application, withdrawal must be achievable through a similarly simple action. A withdrawal mechanism that requires the Data Principal to write a letter, call a customer service centre, or complete a multi-step verification process that was not required at the time of consent fails the comparable-ease test. For example, if an
61
CH. 4 : NOTICE AND CONSENT
Para 4.6
e-commerce platform obtains consent to send marketing emails through a single checkbox at checkout, the user should be able to withdraw that consent by unchecking the same box or clicking a one-step ‘unsubscribe’ link. Requiring the user to log in, navigate to account settings, and submit a separate request would not provide comparable ease. Section 6(5) allocates the consequences of withdrawal. The consequences shall be borne by the Data Principal. The Data Fiduciary may cease providing services that depended on the withdrawn consent. But the withdrawal does not affect the legality of processing that which occurred before the withdrawal. The illustration accompanying Section 6(5) gives the example of an individual who consents to processing by an e-commerce platform, places an order and pays for it, and then withdraws consent. The platform may stop enabling the individual to use the app, but may not stop the processing necessary to complete supply of the goods already ordered and paid for. Section 6(6) imposes a corresponding obligation on the Data Fiduciary. Within a reasonable time of withdrawal, the Data Fiduciary shall cease and cause its Data Processors to cease processing the personal data of the Data Principal, unless such processing without consent is required or authorised under the Act, the Rules, or any other law for the time being in force in India. The obligation cascades. The Data Fiduciary must cease its own processing and must instruct its Data Processors to do the same. The illustration gives the example of a telecom service provider whose Data Processor emails bills to customers. When a customer withdraws consent for email billing and opts for in-app billing, both the provider and the Data Processor must cease email processing effective immediately. The phrase “within a reasonable time” is not defined. It will be interpreted contextually. For automated processing systems, where cessation can be achieved through a configuration change, a reasonable time may be hours or days. For complex multi-vendor processing chains, where cessation requires coordination across multiple Data Processors, a reasonable time may be longer. What is not reasonable is an indefinite delay or a processing cessation that occurs only after the Data Principal escalates the matter to the Board.
4.6 PROVING CONSENT: THE EVIDENTIARY BURDEN Section 6(10) is one of the most consequential provisions in the consent framework. Where consent given by the Data Principal is the basis of processing and a question arises in a proceeding, the Data Fiduciary shall be obliged to prove that a notice was given and consent was obtained in accordance with the Act and the Rules. The burden is on the Data Fiduciary. The Data Principal does not need to prove that they did not consent. The Data Fiduciary must prove that they did.
Para 4.7
PART II : OBLIGATIONS OF DATA FIDUCIARIES
62
This reversal of the burden has direct implications for system design and record-keeping. The consent record must be immutable - it must not be possible for the Data Fiduciary (or anyone within the Data Fiduciary’s organisation) to alter, delete, or backdate a consent record after the fact. The record must include the notice version that was in effect at the time of consent, because proving that consent was obtained “in accordance with the Act and the Rules” requires demonstrating that the notice met the requirements of Section 5 and Rule 3. A consent record that cannot be linked to the specific notice under which it was obtained is incomplete evidence. Organisations that rely on consent as the lawful basis for significant processing activities should treat their consent infrastructure as they would treat financial accounting records: designed for integrity, subject to access controls, backed up, and periodically tested for completeness. The cost of building a defensible consent infrastructure is a fraction of the cost of being unable to prove consent in a Board proceeding where the maximum penalty for the underlying breach may extend to Rs. 250 crore.
4.7 THE CONSENT MANAGER FRAMEWORK Section 6(7), (8) and (9) introduce a unique concept that has no direct parallel in the GDPR or most other data protection statutes: the Consent Manager. Under Section 6(7), the Data Principal may give, manage, review, or withdraw their consent to the Data Fiduciary through a Consent Manager. The Consent Manager is an intermediary that aggregates consent management across multiple Data Fiduciaries onto a single platform, giving the Data Principal a unified view of their consent relationships. For example, a Data Principal who has given consent separately to a bank, an insurer, and a lending app could, through a single Consent Manager dashboard, see all three consents in one place and withdraw the one given to the lending app without logging into that app separately. Section 6(8) establishes the Consent Manager’s accountability: the Consent Manager shall be accountable to the Data Principal and shall act on their behalf. Section 6(9) requires every Consent Manager to be registered with the Board, subject to technical, operational, financial, and other conditions as may be prescribed. Rule 4 and the First Schedule prescribe these conditions and obligations in detail.
4.7.1 Registration Conditions for Consent Managers Part A of the First Schedule sets out nine conditions for registration: 1. The applicant must be a company incorporated in India. 2. It must have sufficient technical, operational, and financial capacity. 3. Its financial condition and management must be sound.
63
CH. 4 : NOTICE AND CONSENT
Para 4.7
4. Its net worth must not be less than Rs. 2 crore. 5. Its business volume, capital structure, and earnings prospects must be adequate. 6. Its directors, key managerial personnel, and senior management must have a general reputation and record of fairness and integrity 7. Its memorandum and articles of association must contain provisions requiring adherence to the conflict-of-interest and related obligations under the First Schedule, and such provisions may be amended only with the Board’s previous approval. 8. The proposed operations must be in the interests of Data Principals And the applicant must hold an independent certification that its interoperable platform is consistent with such data protection standards and assurance framework as may be published by the Board. The cumulative effect of these conditions is to ensure that Consent Managers are financially stable, well-governed, and technically certified entities. The Rs. 2 crore net worth requirement, combined with the independent certification requirement and the Board’s approval over amendments to constitutional documents, creates a regulatory barrier to entry that is intended to filter out entities that lack the capacity to handle the fiduciary responsibilities of the role.
4.7.2 Obligations of the Consent Manager Part B of the First Schedule prescribes thirteen categories of obligations: (1) Obligation 1: The Consent Manager must enable Data Principals to give consent either directly to a Data Fiduciary on boarded onto the platform or through another Data Fiduciary on boarded onto the platform that maintains the personal data with the Data Principal’s consent The illustrations in the First Schedule describe a scenario involving an individual, two banks, and a Consent Manager platform: the individual may either directly consent to one bank accessing their data, or route consent through a second bank that holds their data, instructing it to share with the first. (2) Obligation 2: The Consent Manager must ensure that the manner of making available or sharing personal data is such that the contents are not readable by it. This is a critical technical constraint. The Consent Manager facilitates the flow of consent and data between the Data Principal and Data Fiduciaries, but must not have the ability to read the personal data that flows through its platform. The technical architecture must enforce this through encryption, access restrictions, or other mechanisms that render the data opaque to the
Para 4.8
PART II : OBLIGATIONS OF DATA FIDUCIARIES
64
Consent Manager. In practice, this mirrors India’s Account Aggregator model in financial services: the Consent Manager routes consent artefacts and data-sharing instructions between Data Principal and Data Fiduciary without itself decrypting or reading the underlying personal data. (3) Obligation 3: The Consent Manager must maintain records of consents given, denied, or withdrawn; notices preceding or accompanying consent requests; and sharing of personal data with transferee Data Fiduciaries. (4) Obligation 4: These records must be maintained for at least seven years, or for a longer period if agreed with the Data Principal or required by law The Consent Manager must give the Data Principal access to the records and, on request, make them available in machine-readable form. Further obligations include: developing and maintaining a website or application as the primary means of access (obligation 5); not subcontracting or assigning any obligations (obligation 6); taking reasonable security safeguards (obligation 7); acting in a fiduciary capacity in relation to the Data Principal (obligation 8); avoiding conflicts of interest with Data Fiduciaries (obligations 9 and 10); publishing information about promoters, directors, key managerial personnel, senior management, and significant shareholders (obligation 11); maintaining effective audit mechanisms with periodic reporting to the Board (obligation 12); and not transferring control of the company except with the Board’s previous approval (obligation 13). The Consent Manager and the Account Aggregator Model The DPDP Act’s Consent Manager framework draws conceptual parallels with the Reserve Bank of India’s Account Aggregator framework, which enables consentbased financial data sharing through regulated intermediaries. Both models interpose a registered intermediary between the data subject and the data holder, both require the intermediary to act in a fiduciary capacity, and both prohibit the intermediary from reading the data that flows through its platform. The DPDP framework extends this model beyond financial data to all categories of personal data and places it under the Data Protection Board’s supervision rather than a sectoral regulator.
4.8 IMPLEMENTATION CONSIDERATIONS 4.8.1 Designing Notice Documents Compliant with Rule 3 The notice is not a privacy policy. It is a specific, standalone document that precedes or accompanies a request for consent. Organisations accustomed to drafting comprehensive privacy policies must resist the instinct to produce a notice that covers every conceivable processing scenario. Rule 3(a) requires the notice to be understandable independently, and Rule 3(b) requires it to include an itemised description of personal data and a specific description
65
CH. 4 : NOTICE AND CONSENT
Para 4.9
of goods or services. These requirements favour short, purpose-specific notices over long, multi-purpose documents. A common pitfall is drafting a single notice for all processing activities. Although Rule 3 does not expressly prohibit a single consolidated notice, using one notice for unrelated processing activities can make it difficult to present each purpose and the corresponding personal data clearly. As a matter of good design, organisations should consider purpose-specific or layered notices where this improves independent comprehensibility and supports specific, informed consent. Where an organisation processes personal data for multiple purposes - service delivery, marketing communications, analytics, regulatory compliance - a single notice that lists all purposes and all data categories creates confusion rather than clarity. The Data Principal cannot determine which data relates to which purpose or what she is specifically consenting to. A better approach is to design purpose-specific notices that are presented at the point of collection relevant to each purpose. A notice for order fulfilment at checkout. A separate notice for marketing communications at the point of subscription. A separate notice for location tracking at the point of enabling location services. Each notice should be self-contained, meeting the Rule 3 requirements independently.
4.9 ILLUSTRATIVE TEMPLATE: MODEL NOTICE UNDER RULE 3 The following illustrative notice demonstrates the structure and content required by Section 5(1) and Rule 3. Each element maps to a specific statutory or rule requirement. The notice is designed for a single specified purpose; where an organisation processes personal data for multiple purposes, separate notices should be prepared for each purpose. Figure 4.1: Illustrative Notice (Online Retail — Order Fulfilment)
Legal basis
Notice under Section 5(1) of the Digital Personal Data Protection Act, 2023.
Data Fiduciary [Name of Data Fiduciary] collects and processes your personal data for the purpose of fulfilling your order, including delivery of products and processing of payment. Personal data collected [Rule 3(b)(i)]
Purpose and services [Rule 3(b)(ii)]
Full name
Delivery address
Mobile Number
Email address
Payment details (card Number, UPI ID, or net banking reference)
Your personal data is processed for: confirming your order, processing payment through our payment gateway partner, dispatching your order to the delivery address, and sending
Para 4.9
PART II : OBLIGATIONS OF DATA FIDUCIARIES
66
delivery status updates to your mobile Number and email address. Withdrawal of consent [Rule 3(c)(i)]
You may withdraw your consent at any time by visiting [URL] or by selecting “Withdraw Consent” in the Privacy section of your account settings.
Exercise of rights [Rule 3(c)(ii)]
You may exercise your rights under the Act, including the right to access, correction, and erasure of your personal data, by visiting [URL] or writing to [email address].
Complaint to the Board [Rule 3(c)(iii)]
You may make a complaint to the Data Protection Board of India by visiting [Board website URL].
Contact [Section 8(9), Rule 9]
[Name], Data Protection Contact
Language access
This notice is available in English and any languages listed in the Eighth Schedule to the Constitution of India. Select your preferred language at [URL].
[Email] | [Phone]
The notice above satisfies the standalone requirement of Rule 3(a) - it is understandable without reference to any other document. It includes the itemised description of personal data required by Rule 3(b)(i) and the specific description of services required by Rule 3(b)(ii). It provides the communication links for withdrawal, rights exercise, and Board complaint required by Rule 3(c). And it references the multi-language accessibility required by Section 5(3).
4.9.1 Building Consent Collection Mechanisms The consent collection mechanism must capture the affirmative action, link it to the specific notice version, record the timestamp, and store the result in a manner that permits retrieval for evidentiary purposes. For digital services, this typically means a consent management platform or module integrated into the user interface. The mechanism must present each purpose separately (granularity), use clear and plain language (readability), offer language selection (accessibility), and provide the DPO or contact person’s details (accountability). Pre-ticked checkboxes, bundled consents, and consent obtained through continued use of a service do not satisfy the “clear affirmative action” requirement. The mechanism must require the Data Principal to take a positive step for each purpose. Organisations should test their consent mechanisms against a straightforward question: if a Data Principal challenges the consent before the Board, can the organisation produce a record showing exactly what the Data Principal agreed to, when, under what notice, and through what action? If the answer is uncertain, the mechanism needs redesign.
DIGITAL PERSONAL DATA PROTECTION – AN ESSENTIAL GUIDE TO INDIA'S DPDP LAW AUTHOR : PUBLISHER : DATE OF PUBLICATION : EDITION : ISBN NO : NO. OF PAGES : BINDING TYPE :
Narasimhan Elangovan Taxmann September 2026 2026 Edition 9789375618614 328 Paperback
Rs. 725 DESCRIPTION Digital Personal Data Protection – An Essential Guide to India's DPDP Law is a practitioner's guide to the Digital Personal Data Protection Act 2023 and the Digital Personal Data Protection Rules 2025. It takes professionals from the statutory text to a working programme: what must change, who must be accountable, and what evidence proves compliance. Written for the period before enforcement begins, when organisations must design compliance without Indian precedent, it answers practical questions that cut across legal, technology and business functions. The result is a ready reference for building data-governance programmes that earn and preserve trust. This book is intended for the following audience: • Chartered Accountants • Company Secretaries • Internal Auditors and Independent Data Auditors • Data Protection Officers, Privacy Officers, and Compliance and Risk Professionals • Chief Information Security Officers • In-house Lawyers • HR Leaders • Technology and Product Leaders The Present Publication is the 2026 Edition, authored by CA Narasimhan Elangovan. The law stated in this book is as updated till 15th September 2026, with the following noteworthy features: • [Anchored in the Text] The analysis cites the Act and the Rules down to the section, sub-section, clause and rule, rather than relying on secondary commentary • [Recurring Disciplines] Three habits recur across the implementation sections: classify each processing activity separately, record who decided and when, and review at least annually and on any material change • [Illustrative Templates] Thirteen templates, from a model notice to a Data Protection Impact Assessment (DPIA) structure and a Board inquiry response protocol, serve as starting points to be adapted and reviewed by legal counsel • [Audit Considerations] Chapters 3 to 14 state what an auditor will test and list 57 findings that recur in practice. Chapters 3 to 10 also list the evidence to keep ready • [Consolidated Requirements Register] Appendix A restates the obligations under the Act and the Rules as 49 testable requirements across 15 subject areas, each with its legal reference and audit evidence (239 items in all), for use as a structured checklist • [Case Study Boxes] Thirty boxed notes (case studies, comparative notes, practical scenarios and short explainers) support the analysis. The case studies draw on Indian and EU court decisions and European enforcement actions, and the comparative notes cover the GDPR, the EU AI Act and the RBI Account Aggregator framework • [Regulatory Overlap Mapping] The book shows how to map DPDP duties against existing obligations, such as those of the RBI, SEBI, IRDAI and CERT-In, one obligation at a time, and where ISO 27001 and SOC 2 controls leave gaps • [Worked Scenarios] Everyday Indian scenarios, from a compliance officer at a mid-size NBFC to an e-commerce breach confirmed at 9 a.m. on a Monday, make the discussion concrete
Buy Now