Rule 3 - Notice given by Data Fiduciary to Data Principal

Rule 3: Notice Given by Data Fiduciary to Data Principal

Commentary

Rule 3 is one of the most consequential provisions in the operational architecture of the DPDP Rules because it transforms the relatively concise notice obligation in Section 5 of the DPDP Act into a more detailed set of requirements concerning the form, content and accessibility of the notice.

Section 5 establishes the statutory obligation. Every request made to a Data Principal under Section 6 for consent must be accompanied or preceded by a notice. The Act requires the notice to inform the Data Principal about the personal data and purpose of processing, the manner in which certain rights may be exercised, and the manner in which a complaint may be made to the Board. Section 5 also deals with consent obtained before commencement of the Act and requires the Data Fiduciary to subsequently provide notice in relation to that processing.

Rule 3 does not replace Section 5.

It operationalises it.

That distinction is important because the Rule begins by prescribing what the notice shall do. The language is mandatory. The Data Fiduciary therefore does not have discretion to decide whether these requirements are preferable or merely good practice.

The Rule contains three principal requirements:

• first, the notice must be independently understandable;
• second, it must provide a fair and sufficiently detailed account of the processing necessary to obtain specific and informed consent;
• third, it must provide practical mechanisms for withdrawal of consent, exercise of rights and complaints to the Board.

These requirements collectively indicate that the Rules are attempting to move the Indian privacy notice away from a purely formal model of disclosure towards a model in which the notice is intended to perform an informational and decision-making function.

1. “Shall be presented and be understandable independently”

The first requirement under Rule 3(a) is that the notice must be presented and be understandable independently of any other information that has been, is or may be made available by the Data Fiduciary.

There are potentially two distinct requirements embedded in this language.

The first concerns presentation.

The second concerns understandability.

The requirement that the notice be presented independently appears designed to prevent the privacy notice from being submerged within other contractual or informational material.

For example, a Data Fiduciary may provide a user with:

• Terms and Conditions;
• a subscription agreement;
• a cookie policy;
• a refund policy;
• community guidelines;
• marketing information; and
• a privacy notice.

Rule 3(a) indicates that the notice cannot merely exist somewhere within this collection of documents and then be treated as having been provided.

The notice has to stand on its own.

The second requirement is that it must be understandable independently. This creates a more difficult interpretive question.

Does "independently" mean that the notice must be capable of being understood without reference to another document?

Or does it additionally require that the notice be displayed separately from other information?

The drafting appears to support both elements because the provision separately uses the expressions "presented" and "understandable."

This distinction matters.

A notice may be displayed on a separate page but still say:

"Your personal data will be processed in accordance with our Privacy Policy and applicable terms."

Such a notice may technically be separate but would not necessarily be independently understandable if the Data Principal has to consult another document to understand what data are being processed or why.

Conversely, a very detailed notice might be independently understandable but buried inside a lengthy contractual document.

Rule 3(a) appears designed to address both problems.

The requirement is therefore not merely separateness.

It is functional independence.

This is also consistent with the concern raised during consultation that the phrase "presented and be understandable independently" could create ambiguity as to whether the requirement concerns presentation, comprehension, or both.

2. “Clear and plain language”

Rule 3(b) requires the notice to be given in clear and plain language.

This requirement must be read together with Section 6(3), which already requires every request for consent to be presented in clear and plain language, with an option to access it in English or a language specified in the Eighth Schedule to the Constitution.

The Rule therefore reinforces a principle already present in the Act.

The significance of this is that the Data Fiduciary cannot satisfy the notice obligation merely by reproducing technically accurate legal language.

A notice may be legally precise but practically incomprehensible.

For example:

"The Data Fiduciary may process information for the purposes of service optimisation, personalisation, analytics, fraud prevention and ancillary commercial activities."

This sentence may appear sophisticated, but it leaves several questions unanswered.

What information?

What does "service optimisation" mean?

What constitutes "personalisation"?

What commercial activities are contemplated?

What is the relationship between each category of data and each purpose?

Rule 3's reference to a "fair account" becomes important here.

3. “A fair account of the details necessary”

The expression "fair account" is arguably one of the most important phrases in Rule 3.

The Rule does not require the Data Fiduciary to provide every conceivable fact about its information infrastructure. Nor does it permit the Data Fiduciary to provide only those facts that make the processing appear innocuous.

It requires a fair account of the details necessary to enable specific and informed consent.

The word "fair" introduces a qualitative requirement.

A technically accurate notice could still be problematic if it presents information selectively, obscures material processing activities, or gives prominence to innocuous uses while minimising significant uses.

Consider a mobile application that collects a user's:

name;

email;

precise location;

contacts;

device information; and

behavioural information.

If the notice prominently states that the information is used to "provide personalised services" but does not adequately explain that behavioural information is used to construct advertising profiles, the notice may be technically informative in one sense but arguably fail to provide a fair account.

The phrase therefore moves the notice obligation beyond truthfulness towards material completeness.

The purpose of the disclosure is also expressly identified:

to enable the Data Principal to give specific and informed consent.

This is important because the notice and consent provisions form a chain.

Notice → understanding → consent → lawful processing.

If the notice does not contain sufficient information to understand the processing, the consent mechanism becomes questionable because Section 6 requires consent to be informed and specific. Section 6 also requires consent to relate to a specified purpose and to be limited to personal data necessary for that purpose.

Rule 3 therefore gives operational content to the standards contained in Section 6.

4. “Specific and informed consent”

Rule 3 expressly refers to specific and informed consent, rather than merely "consent."

This is significant because the Act distinguishes between the existence of consent and the legal quality that consent must possess.

Section 6(1) requires consent to be free, specific, informed, unconditional and unambiguous, with clear affirmative action. It must signify agreement to processing for the specified purpose and must be limited to the personal data necessary for that purpose.

The Rule therefore cannot be read independently of Section 6.

A notice is not an end in itself.

Its purpose is to enable a legally valid consent decision.

This has a direct consequence for drafting. Data Fiduciaries should not begin with the question:

"What information can we put into our privacy policy?"

The better question is:

"What information does the Data Principal need in order to understand the particular processing for which consent is being requested?"

That distinction is fundamental.

5. “At the minimum”: the notice contains a floor, not necessarily a ceiling

Rule 3(b) states that the fair account shall include, at the minimum, two categories of information.

This wording creates a minimum content standard.

The first is an itemised description of the personal data.

The second is the specified purpose or purposes, together with a specific description of the goods or services to be provided or uses to be enabled by the processing.

The phrase "at the minimum" is important because it prevents an interpretation under which compliance is achieved merely by reproducing these two elements while omitting other information necessary to make the consent decision genuinely informed.

The listed requirements therefore establish a floor.

They do not necessarily exhaust the information that may be required in a particular context.

6. “Itemised description” of personal data

Section 5 of the Act speaks of informing the Data Principal of the personal data proposed to be processed. Rule 3 goes further by requiring an itemised description.

This is a significant operational development.

An organisation should therefore avoid vague formulations such as:

"We may collect information about you."

Instead, the notice should identify the relevant categories with sufficient specificity.

For example:

name, email address, mobile number, billing address, payment information, device identifier and location information.

The requirement becomes even more important where different data categories serve different purposes.

Suppose an application requires:

Personal data Purpose

Name Account creation

Mobile number Account authentication

Location Delivery

Contact list Referral feature

Browsing behaviour Personalisation

A single sentence stating that "personal data may be collected for service provision and improvement" would undermine the function of itemisation.

Itemisation enables the Data Principal to understand what is being taken and why.

It also creates a useful compliance record for the Data Fiduciary because the notice itself becomes a reference point against which later processing can be assessed.

7. “Specified purpose or purposes”

The expression "specified purpose" is already defined in Section 2(za) of the Act as the purpose mentioned in the notice given by the Data Fiduciary in accordance with the Act and Rules.

This creates an important circularity in the architecture of the statute.

The notice identifies the specified purpose.

The specified purpose then helps determine the scope of the consent.

The scope of consent determines what processing is authorised.

Therefore, the notice is not merely descriptive.

It helps define the legal boundary of consent-based processing.

For example, if a Data Fiduciary obtains consent for processing an email address to create an account, it should not assume that the same consent automatically authorises unrelated marketing.

The purpose stated in the notice becomes legally significant.

This also strengthens the relationship between Rule 3 and the purpose limitation principle embedded in the DPDP framework.

8. “Specific description of goods or services”

The Rule additionally requires a specific description of the goods or services to be provided or uses to be enabled by the processing.

This requirement is particularly significant for digital businesses because it requires the notice to connect processing with the actual service.

For example, instead of:

"Your information will be processed to provide our services."

a stronger notice would identify the service:

"Your mobile number will be processed to send one-time passwords required to authenticate your account."

The second formulation tells the Data Principal both what data is involved and what function it performs.

The requirement may therefore discourage abstract descriptions of processing.

It also creates a distinction between:

purpose of processing

and

service or use enabled by processing.

They may overlap, but they are not necessarily identical.

For example:

Purpose: fraud prevention.

Use enabled: allowing secure completion of online transactions.

This distinction is valuable because it forces the Data Fiduciary to articulate the operational relationship between processing and the service being offered.

9. The architecture of Rule 3(c)

Rule 3(c) moves from information to action.

The notice must provide the particular communication link for accessing the Data Fiduciary's website or app, or both, and describe other means, if any, through which the Data Principal may:

withdraw consent;

exercise rights under the Act; and

make a complaint to the Board.

This is important because privacy transparency is ineffective if the Data Principal is informed of rights but is not told how to exercise them.

The provision therefore has an architectural logic:

Tell me what you are doing.

Tell me why you are doing it.

Tell me how I can reverse or challenge it.

That is considerably more meaningful than a notice that simply informs the Data Principal of the existence of privacy rights.

10. Withdrawal must be as easy as consent

Rule 3(c)(i) expressly carries the Section 6(4) principle into the notice framework.

Section 6(4) gives the Data Principal the right to withdraw consent at any time, with ease comparable to the ease with which consent was given. Section 6(6) further requires the Data Fiduciary, within a reasonable time, to cease and cause its Data Processors to cease processing where consent has been withdrawn, unless processing without consent is otherwise required or authorised.

The importance of Rule 3(c)(i) is therefore not limited to providing a withdrawal link.

The mechanism itself must be comparably easy.

If consent is obtained through:

one click → consent

but withdrawal requires:

login → settings → account → privacy → email request → verification → customer support → manual confirmation

the organisation may face a serious question as to whether withdrawal has been made comparably easy.

The provision consequently has implications for user-interface design, not merely privacy-policy drafting.

A legal notice that provides a theoretical withdrawal mechanism while the product architecture makes withdrawal difficult would defeat the purpose of the provision.

11. Exercise of rights

Rule 3(c)(ii) requires the notice to identify how the Data Principal may exercise rights under the Act.

This is broader than withdrawal of consent.

The Act contains rights concerning access, correction and erasure, grievance redressal and nomination, subject to the precise statutory conditions governing those rights.

The Rules later provide more detailed operational mechanisms for exercising rights. Rule 14, for example, requires the Data Fiduciary and, where applicable, the Consent Manager to prominently publish the means through which Data Principals can make requests for exercising their rights.

This creates a useful relationship between Rule 3 and Rule 14.

Rule 3 tells the Data Principal where and how to begin.

Rule 14 provides the more detailed operational architecture for exercising rights.

The notice therefore becomes an entry point into the broader rights-management system.

12. Complaints to the Board

Rule 3(c)(iii) requires the notice to provide the means through which the Data Principal may make a complaint to the Board.

This is significant because the notice is not confined to the bilateral relationship between Data Fiduciary and Data Principal.

It also connects the Data Principal to the regulatory enforcement mechanism.

The Data Fiduciary is therefore required to make the regulatory remedy visible at the point at which personal data processing and consent are introduced.

This supports a broader principle of procedural empowerment.

A right that is difficult to locate or exercise is weaker in practice than a right whose mechanism is made immediately accessible.

13. Does Rule 3 apply only to consent-based processing?

This is one of the important interpretive questions.

Section 5 is expressly framed around a request for consent under Section 6. Section 5(2) separately addresses consent obtained before commencement of the Act.

Rule 3, however, is framed generally around "the notice given by the Data Fiduciary to the Data Principal."

The stronger reading is that Rule 3 operates within the notice architecture established by Section 5, and therefore primarily concerns notices associated with consent-based processing and the transitional notice contemplated by Section 5(2).

It should not automatically be interpreted as creating a universal notice obligation for every form of processing undertaken under Section 7.

This distinction matters because Section 7 contains several "certain legitimate uses" where processing may occur without consent.

The fact that Rule 3 uses broad language should not by itself be converted into a conclusion that every processing activity under Section 7 necessarily requires a Rule 3 notice.

At the same time, Data Fiduciaries should not use the existence of Section 7 as a reason to provide no transparency whatsoever. Other provisions of the Act and Rules may independently require communication or publication.

The better interpretation is therefore:

Rule 3 gives detailed content and structural requirements to the notice regime connected with Section 5; it should not be treated as silently rewriting the statutory distinction between consent-based and non-consent-based processing.

14. The problem of long notices

There is also a tension inherent in Rule 3.

The Rule seeks both clarity and specificity.

But specificity can make notices longer.

If an organisation processes dozens of categories of personal data for dozens of purposes, an attempt to itemise every category and purpose could produce a notice that is technically compliant but practically unreadable.

This is a genuine regulatory tension.

A notice that says too little risks failing the informed-consent requirement.

A notice that says everything in exhaustive legal prose risks defeating comprehension.

The answer is not necessarily to reduce the information.

It is to improve its organisation.

A layered structure can potentially reconcile these objectives:

What data? → Why? → What service? → How to withdraw? → How to exercise rights? → How to complain?

The critical point is that additional information should not be allowed to obscure the mandatory information.

15. Rule 3 as a product-design requirement

One of the most significant consequences of Rule 3 is that it should not be treated solely as a document-drafting requirement.

It affects product architecture.

A Data Fiduciary should be able to demonstrate consistency between:

privacy notice

and

actual data flows.

If the notice says that location is processed only for delivery but the application collects continuous location data for analytics, there is a disconnect between the legal representation and actual processing.

Similarly, if the notice provides a withdrawal mechanism that does not actually propagate withdrawal to relevant Data Processors, the organisation may have a problem under Section 6(6).

Rule 3 therefore encourages a form of privacy-by-design through notice architecture.

The privacy lawyer, product team, engineering team and compliance function cannot necessarily operate independently.

The notice describes the processing.

The product implements the processing.

The rights mechanism controls the consequences.

The audit function must be able to reconcile all three.

16. Practical example

Consider an online education platform. It collects:

• student's name;
• age;
• parent email;
• attendance information;
• learning activity;
• device information; and
• behavioural data. A weak notice might state: "We collect personal information to provide and improve educational services." A Rule 3-oriented notice would need to be much more precise. It would identify the categories of data, explain the specific educational purposes, identify the services enabled by processing, and provide a practical route for withdrawal, rights requests and complaints. The difference is not merely stylistic. The first notice describes the organisation's perspective. The second is designed around the Data Principal's decision. That is the fundamental shift created by Rule 3.

17. Overall assessment of Rule 3

Rule 3 can therefore be understood as a provision that converts notice from a disclosure document into an instrument of informed choice.

Its most important features are:

Requirement	Legal function
Independent presentation	Prevents concealment within unrelated information
Independent understandability	Requires the notice to make sense on its own
Clear and plain language	Reduces technical and legal opacity
Fair account	Prevents materially incomplete disclosure
Itemised personal data	Identifies what is processed
Specified purpose	Establishes why it is processed
Specific goods/services or uses	Connects processing with the service
Particular communication link	Makes rights operationally accessible
Comparable ease of withdrawal	Prevents difficult withdrawal mechanisms
Rights mechanism	Converts abstract rights into an actionable process
Complaint mechanism	Connects the Data Principal to the Board

The deeper significance of Rule 3 is therefore that it attempts to close the gap between formal consent and meaningful consent.

A Data Principal cannot make a genuinely informed choice if the organisation has not explained what it is doing.

But an organisation also cannot satisfy the rule merely by making information technically available.

The information has to be independently understandable, sufficiently specific and practically actionable.

Rule 3 therefore sits at the intersection of transparency, consent, purpose limitation, user autonomy and rights enforcement.