Section 5 - Notice

Key point

Clause-by-clause commentary on consent notices, legacy consent, language, recruitment, employment, CCTV, marketing, AI training, scraping and vendor-supported processing

Statutory provision

5. Notice. (1) Every request made to a Data Principal under section 6 for consent shall be accompanied or preceded by a notice given by the Data Fiduciary to the Data Principal, informing her,(i) the personal data and the purpose for which the same is proposed to be processed;(ii) the manner in which she may exercise her rights under sub-section (4) of section 6 and section 13; and (iii) the manner in which the Data Principal may make a complaint to the Board, in such manner and as may be prescribed.

Illustration

X, an individual, opens a bank account using the mobile app or website of Y, a bank. To complete the Know-Your-Customer requirements under law for opening of bank account, X opts for processing of her personal data by Y in a live, video-based customer identification process. Y shall accompany or precede the request for the personal data with notice to X, describing the personal data and the purpose of its processing.

(2) Where a Data Principal has given her consent for the processing of her personal data before the date of commencement of this Act,(a) the Data Fiduciary shall, as soon as it is reasonably practicable, give to the Data Principal a notice informing her,(i) the personal data and the purpose for which the same has been processed;(ii) the manner in which she may exercise her rights under sub-section (4) of section 6 and section 13; and (iii) the manner in which the Data Principal may make a complaint to the Board, in such manner and as may be prescribed.

(b) the Data Fiduciary may continue to process the personal data until and unless the Data Principal withdraws her consent.

Illustration

X, an individual, gave her consent to the processing of her personal data for an online shopping app or website operated by Y, an e-commerce service provider, before the commencement of this Act. Upon commencement of the Act, Y shall, as soon as practicable, give through email, in-app notification or other effective method information to X, describing the personal data and the purpose of its processing.

(3) The Data Fiduciary shall give the Data Principal the option to access the contents of the notice referred to in sub-sections (1) and (2) in English or any language specified in the Eighth Schedule to the Constitution.

1. “Every request made to a Data Principal under section 6 for consent”

These opening words determine the legal reach of Section 5.

Section 5(1) does not say that a statutory notice must be delivered before every processing activity. It applies specifically to a request made under Section 6 for consent.

This distinction is fundamental because Section 4 permits processing through two different routes:

1. consent under Section 6; or

2. a legitimate use under Section 7.

Section 5(1) directly governs the first route. Where a Data Fiduciary asks a person to consent under Section 6, the request must be accompanied or preceded by the prescribed notice.

By contrast, where processing rests entirely on Section 7(i) for core employment administration, Section 7(d) for a legal disclosure obligation or another legitimate use, Section 5(1) does not expressly require a consent notice because no Section 6 consent is being requested.

That does not mean that legitimate-use processing should be hidden. Other provisions, fair organisational practice, sectoral rules, contractual duties, constitutional standards or the nature of the relationship may require transparency. A Data Fiduciary may prudently issue a broader privacy statement explaining both consent-based and legitimate-use processing. But it must distinguish:

• a statutory Section 5 consent notice;

• an operational transparency notice concerning Section 7 processing;

• a contractual or sector-specific disclosure;

• a CCTV sign;

• a general privacy policy.

These documents may overlap, but they do not have the same legal function.

2. “Every request”

The word “every” means that a notice cannot be treated as a one-time licence covering all future processing.

If a Data Fiduciary introduces a new consent-based purpose that was not covered by the original notice and consent, it should provide an updated or supplementary notice before requesting consent for that new purpose.

Example

For example, a customer may originally consent to promotional email concerning hotel rooms. The hotel later proposes to:

• upload the customer’s contact information to a social-media advertising platform;

• conduct behavioural profiling;

• combine booking records with restaurant purchases;

• use customer conversations to train an AI system.

These are not necessarily the same purpose. If separate consent is required, each corresponding request must be accompanied or preceded by a notice containing sufficient information about that processing.

“Every request” does not necessarily require the complete notice to be physically reproduced beside each button. A layered notice may be used if the person can easily and immediately access the required contents before acting. However, a Data Fiduciary should not hide important information behind multiple screens, unrelated terms or inaccessible hyperlinks.

3. “Request”

A request for consent must be identifiable as a request.

The following designs are problematic:

• presenting consent as a mandatory factual acknowledgement;

• hiding consent inside employment terms;

• using a pre-ticked box;

• merging consent with acceptance of general terms;

• stating “By continuing, you consent” without a clear choice;

• using an interface in which the refusal option is difficult to find;

• seeking one blanket consent for unrelated purposes.

A person should understand that a decision is being requested and what the consequences of agreement and refusal are.

4. “Made to a Data Principal”

The notice must reach the person whose consent is sought.

A privacy notice placed somewhere on a corporate website is not necessarily sufficient where the Data Principal is interacting through:

• a mobile application;

• an employment portal;

• WhatsApp;

• a telephone process;

• a physical form later digitised;

• a kiosk;

• a chatbot;

• an outsourced recruitment platform.

The notice should be delivered through a channel reasonably connected with the consent request.

If an applicant applies through a recruitment platform, the employer cannot automatically assume that the platform’s general privacy policy provides notice on behalf of the employer. The applicant needs intelligible information about the employer’s processing.

If an employee enrols a spouse in an insurance scheme, the employer should consider whether personal data about the spouse is being provided indirectly. The employee’s request does not automatically substitute for transparency to the spouse where the spouse is a separate Data Principal and the employer seeks the spouse’s consent.

5. “Under section 6”

This phrase connects Section 5 directly to the statutory validity of consent.

A notice must do more than announce that data is collected. Its function is to enable consent that is free, specific, informed, unconditional and unambiguous.

A notice that is vague or incomplete may make the resulting consent uninformed or non-specific. A defective notice therefore creates two problems:

1. breach of Section 5; and

2. possible invalidity of consent under Section 6.

The notice should be evaluated from the perspective of the ordinary Data Principal, not merely from the perspective of the lawyer who drafted it.

6. Notice is not consent

Notice and consent are distinct legal acts.

A notice provides information. Consent records a qualifying decision by the Data Principal.

NOTICE

The Data Fiduciary explains:

• what personal data is involved;

• why it will be processed;

• how consent may be withdrawn;

• how grievance rights may be exercised;

• how a complaint may be made.

UNDERSTANDING

The Data Principal receives a real opportunity to understand the proposal.

CHOICE

The Data Principal agrees or refuses.

CONSENT

Agreement must satisfy Section 6.

A Data Fiduciary cannot obtain effective consent first and supply the notice later. Section 5(1) requires the notice to accompany or precede the request.

Similarly, merely displaying a notice does not establish consent. A CCTV sign, website privacy policy, employee handbook or recruitment notice may provide information without producing a valid Section 6 consent.

6.1 Case study 1: Pre-ticked marketing box

An e-commerce application displays a pre-ticked box stating, “I agree to offers from us and our partners,” with a link to a long privacy policy.

The policy may amount to some disclosure, but the pre-ticked box does not provide clear affirmative action. The purposes and partners are also insufficiently specific.

6.2 Case study 2: Employee privacy notice

An employer gives every employee a detailed privacy notice explaining payroll, access control, attendance and security monitoring under Section 7(i).

The notice improves transparency, but these operations do not become consent-based merely because the notice is delivered. The employer should avoid asking employees to “consent” to mandatory processing where Section 7(i) is the actual ground.

6.3 Case study 3: CCTV signage

A hotel displays “CCTV in operation for safety and security.”

The sign gives notice of surveillance. It does not necessarily satisfy the full conditions of Section 6 consent. If the hotel relies on Section 7(a), Section 7(i) or Section 7(d), the sign is operational transparency rather than a Section 5 consent notice.

7. “Shall be accompanied or preceded by a notice”

The notice must come no later than the consent request.

There are two permitted sequences.

7.1 Sequence A: Notice precedes consent

Notice → Opportunity to read → Consent request → Choice

This is the clearest model.

Example

For example, before an applicant clicks “Agree” to a background check, the portal displays:

• the data to be verified;

• the purpose;

• the verification vendor;

• withdrawal mechanism;

• grievance channel;

• complaint mechanism.

7.2 Sequence B: Notice accompanies consent

Notice and consent request shown together → Choice

This is also valid if the notice is visible, understandable and accessible at the point of consent.

7.3 Invalid sequence

Consent request → Agreement → Notice sent later

A later privacy policy cannot retrospectively make an earlier consent informed.

8. Timing in different channels

8.1 Mobile application

The essential information should appear before or with the consent control. A link to a layered notice may provide detail, but the first layer should not conceal the actual purpose.

8.2 Website

The notice should be accessible without requiring account creation or acceptance of unrelated terms.

8.3 Telephone

The Data Fiduciary may provide the essential information orally and make the full notice accessible through SMS, email or another effective channel before obtaining consent. The process should preserve evidence of what information was given.

8.4 Physical form

If personal data will later be digitised, the notice may be printed on or attached to the form. Tiny text on the reverse side that the Data Principal is unlikely to see creates a validity risk.

8.5 WhatsApp

The notice may be provided through a short message and link before the individual is asked to submit documents or click agreement.

8.6 Recruitment portal

The notice should appear before the applicant submits data or consents to additional operations, especially background checks, psychometric assessments, future retention and AI screening.

9. Rule 3: How the notice must be presented

Rule 3 of the final DPDP Rules operationalises Section 5.

It requires the notice to:

• be presented in a manner that is independently understandable from other information made available by the Data Fiduciary;

• use clear and plain language;

• provide a fair account of the details necessary to enable specific and informed consent;

• include an itemised description of the personal data;

• include the specified purpose and an itemised description of the goods or services enabled by the processing;

• provide an accessible link or other means through which the Data Principal may withdraw consent, exercise rights and make a complaint to the Board.

Rule 3 makes several important improvements to the bare language of Section 5.

10. Independently understandable

The notice must not depend on the person deciphering:

• a lengthy employment agreement;

• a forty-page terms-of-service document;

• a general corporate privacy policy;

• technical specifications;

• multiple cross-referenced policies;

• a vendor’s separate terms.

The notice may sit inside a broader document, but it must remain independently understandable.

A person should be able to answer the following after reading it:

1. What data will be processed?

2. Why will it be processed?

3. What service or activity will the processing enable?

4. How can consent be withdrawn?

5. How can rights and grievance mechanisms be used?

6. How can a complaint be made?

11. Clear and plain language

Complex legal terms should be replaced with ordinary explanations.

Instead of:

“We may process miscellaneous information for synergistic business optimisation.”

The notice should say:

“We will use your email address and booking history to send you promotional offers for hotel rooms.”

Instead of:

“Your data may be disclosed to third parties for operational purposes.”

It should say:

“We will share your bank account number and salary details with our payroll service provider to calculate and pay your salary.”

Instead of:

“We may process your data using automated technologies.”

It should say:

“We will use an automated tool to compare your qualifications with the requirements of the vacancy and assign an application score.”

12. Itemised description

The Rules require an itemised description, not a broad label such as “personal information.”

An itemised description need not necessarily list every database field. It should identify categories with enough precision for the Data Principal to understand what will be used.

13. Purpose and service connection

Rule 3 requires the specified purpose and an itemised account of the goods or services enabled by processing.

This prevents misleading consent requests that ask for more data than the relevant service realistically requires.

Example

For example:

• an address enables delivery;

• bank details enable salary payment;

• a phone number enables booking confirmation;

• health information may enable an optional wellness programme;

• a photograph may enable publication of an employee testimonial;

• a CV enables assessment for a vacancy.

The notice should not falsely present an optional commercial activity as essential to the primary service.

14. Section 5(1)(i): “The personal data”

The notice must identify the personal data proposed to be processed.

This requirement should be interpreted together with Rule 3’s demand for an itemised description.

15. Data actually proposed to be processed

The notice should reflect the real processing architecture.

If an application collects:

• name;

• mobile number;

• location;

• device identifier;

• contact list;

• browsing activity;

• purchase history;

the notice should not mention only name and mobile number.

If an AI tool generates a score or inference, the notice should describe the generated information where it is part of the proposed processing.

If CCTV includes audio, facial recognition or licence-plate recognition, a generic reference to “video footage” is incomplete.

16. Direct and indirect data

The phrase “personal data” is not limited to information directly entered by the Data Principal.

The notice may need to explain data received from:

• recruitment platforms;

• references;

• background-verification vendors;

• group entities;

• insurers;

• analytics providers;

• publicly accessible sources;

• social-media platforms;

• government databases;

• automatic system generation.

Section 5 does not contain a detailed direct-versus-indirect notice framework equivalent to GDPR Articles 13 and 14. This creates an important gap. Where valid consent is sought for data obtained indirectly, informed consent will often require disclosure of the relevant source or source category even if Section 5 does not expressly list it.

17. Inferred and generated data

A notice should not stop at source data if the proposed operation generates materially significant information.

Example

Examples include:

• suitability score;

• fraud-risk score;

• health-risk inference;

• attrition prediction;

• behavioural segment;

• facial template;

• sentiment estimate;

• customer-value score.

A person who consents to the use of attendance and performance records may not understand that the same data will be used to predict resignation. The prediction purpose and generated data should be explained.

17.1 Case study 1: Applicant screening

An employer collects a CV and uses an AI tool to assign an employability score.

The notice should identify not only the CV and application information but also the automated score and the purpose for which it will be used.

17.2 Case study 2: Loyalty programme

A retailer uses purchase history to infer whether a customer has children.

A notice referring only to “transaction data” may not fairly explain household profiling. The inference and advertising purpose should be disclosed if consent is sought.

17.3 Case study 3: Biometric attendance

An employer collects a fingerprint template for attendance.

If consent is genuinely being used, the notice should say that a digital biometric template will be produced and used to recognise the person. It should not merely say “attendance information.”

Core employee attendance may instead rely on Section 7(i), in which case Section 5 is not the direct trigger. Transparent explanation remains professionally prudent.

18. Section 5(1)(i): “The purpose for which the same is proposed to be processed”

The notice must link the identified personal data with a specified purpose.

A useful notice does not present one list of data and another broad list of purposes without showing the connection between them.

19. Data-purpose mapping

The phrase “proposed to be processed” is prospective. The Data Principal should be told what the Data Fiduciary plans to do before consent is requested.

20. Purpose must be sufficiently specific

The following are ordinarily too vague:

• business purposes;

• commercial purposes;

• improving services;

• user experience;

• research;

• analytics;

• security;

• marketing;

• AI development;

• future opportunities;

• legal purposes.

The purpose must be narrowed.

Example

Examples:

21. Bundled purposes

One consent should not be used for unrelated purposes.

Example

For example, a hotel should not ask a guest to consent in one step to:

• process a booking;

• send marketing;

• share data with promotional partners;

• create behavioural profiles;

• use conversations for AI training;

• publish photographs.

Consent should be granular wherever the person should be free to accept one purpose and reject another.

The EDPB’s transparency guidance similarly emphasises concise, intelligible, easily accessible information and clear language. The guidance also endorses layered approaches where the first layer provides the most important information and further detail remains immediately accessible. These principles are persuasive under Rule 3, although they are not binding interpretations of Indian law.

22. Section 5(1)(ii): Withdrawal of consent

Section 5(1)(ii) requires the notice to explain how the Data Principal may exercise the right under Section 6(4).

Section 6(4) concerns withdrawal of consent. The Data Principal may withdraw consent at any time, with the consequences of withdrawal being borne by the Data Principal, and the ease of withdrawal must be comparable to the ease with which consent was given.

The notice should therefore identify an actual operational mechanism, not merely state that withdrawal is legally possible.

22.1 Adequate examples

• an in-app “Withdraw consent” control;

• an account privacy dashboard;

• a consent-preference centre;

• a dedicated email address;

• a specific web form;

• a postal address where digital means are unavailable;

• a customer-support route capable of processing the request.

22.2 Inadequate examples

• “Contact us” without contact information;

• a generic switchboard where staff cannot identify the request;

• requiring an in-person visit where consent was given in one click;

• requiring a signed and notarised letter for withdrawal of online marketing consent;

• hiding withdrawal under several unrelated menus;

• requiring account deletion to stop one optional purpose.

23. Withdrawal should be purpose-specific

If a person consented separately to:

• marketing;

• future recruitment retention;

• publication of a testimonial;

• AI training;

the person should be able to withdraw one consent without necessarily ending the others.

24. Consequences should be explained honestly

If withdrawal means that an optional service can no longer be provided, the Data Fiduciary should explain that consequence.

Example

For example:

• withdrawing consent to a public testimonial ends future publication;

• withdrawing consent to a voluntary wellness programme ends participation;

• withdrawing future-talent-pool consent means the applicant will not be considered for later vacancies;

• withdrawing marketing consent stops promotional communication.

The Data Fiduciary should not exaggerate consequences to discourage withdrawal.

25. Legitimate-use processing may continue

Withdrawal affects processing based on consent. It does not automatically terminate processing supported by Section 7.

An employee may withdraw consent for a promotional photograph while the employer continues payroll processing under Section 7(i).

An applicant may withdraw future-talent-pool consent while records necessary for an ongoing legal claim are retained under another applicable provision.

The notice should explain this distinction in plain language. It should not state broadly that the organisation may continue processing under “any other lawful basis” without identifying the circumstances in which continued processing may occur.

26. Section 5(1)(ii): Grievance redressal under Section 13

Section 13 creates the right to readily available means of grievance redressal provided by the Data Fiduciary or Consent Manager.

The notice must explain how the Data Principal may use that mechanism.

A proper grievance section should identify:

• the relevant email address, form or portal;

• the office or contact responsible;

• the information required to identify the request;

• any verification process;

• expected handling route;

• escalation mechanism;

• accessibility support;

• language options.

A vague statement such as “You may contact us if you have concerns” is weaker than:

“You may submit a grievance through the Privacy Request Form available at [link] or email [address]. Please state the relevant service, account or application reference. We will acknowledge and process the grievance through our privacy grievance mechanism.”

27. Grievance is not limited to consent withdrawal

A grievance may concern:

• unauthorised collection;

• misuse;

• inaccurate information;

• failure to erase;

• excessive retention;

• marketing after withdrawal;

• vendor disclosure;

• inaccessible rights mechanisms;

• security concerns;

• failure to respond.

28. Employees

Even where core employee processing relies on Section 7(i), the organisation should provide employees with a grievance mechanism. Section 5 is directly triggered only for consent requests, but Section 13’s grievance mechanism has broader importance.

The employee privacy notice may therefore distinguish:

• consent withdrawal for optional processing;

• grievances concerning any covered personal-data processing.

29. Applicants and interns

Applicant and intern notices should provide a grievance route that remains functional after the application or programme ends. A portal that becomes inaccessible immediately after rejection or completion is not an adequate practical mechanism.

30. Section 5(1)(iii): Complaint to the Board

The notice must explain how the Data Principal may make a complaint to the Data Protection Board of India in the prescribed manner.

This requirement should be distinguished from the internal grievance mechanism.

1. INTERNAL ROUTE Data Principal → Data Fiduciary or Consent Manager → Grievance mechanism
2. EXTERNAL ROUTE Data Principal → Data Protection Board of India → Complaint in prescribed manner

A notice should not imply that the Board is part of the Data Fiduciary’s own customer-service structure.

The notice should provide the access details prescribed or made operational by the Government and the Board. If a final public complaint link or channel is not yet operational when a draft is prepared, the organisation should not invent one. It should maintain a placeholder for completion before the substantive provisions commence.

The Imperial draft’s blank statement:

“The Data Protection Board of India available at ______”

must be completed before use. An empty placeholder does not tell the Data Principal how to complain.

The notice should also avoid overstating procedural barriers. If the Act requires internal grievance exhaustion before approaching the Board in the relevant circumstances, that should be explained accurately and simply.

31. The statutory banking illustration

The Section 5 illustration concerns live video-based customer identification for opening a bank account.

Its significance lies in the timing and level of description.

Before or with the request for the live-video process, the bank must explain:

• what personal data will be processed;

• why the processing occurs.

A useful notice might explain that the bank will process:

• the customer’s live facial image;

• voice and video interaction;

• identification documents;

• date and time;

• location information, if required by the applicable process;

• responses given during verification.

The purpose might be described as:

• verifying identity;

• completing legally required customer-identification procedures;

• opening the requested bank account;

• preventing identity fraud.

The illustration does not mean that every legally required KYC operation necessarily rests on consent alone. It says that where the customer opts for processing through a live video-based method, the request must be accompanied or preceded by notice.

The bank should distinguish:

1. the legal requirement to complete KYC;

2. the optional choice of a particular verification method;

3. any additional purpose, such as recording the video for model training.

Consent to live KYC does not automatically authorise the bank or its vendor to train facial-recognition technology on the recording.

32. Section 5(2): Legacy consent

Section 5(2) addresses personal data for which consent was given before Section 5 comes into force.

This is a transitional provision. It recognises that organisations will already possess large volumes of personal data based on historical consents.

It does not require every Data Fiduciary automatically to obtain fresh consent on commencement. Instead, it requires a notice and permits continued processing until the Data Principal withdraws consent.

33. Conditions for relying on Section 5(2)

The provision applies where:

1. the Data Principal gave consent before commencement;

2. the Data Fiduciary continues to process on that consent basis;

3. the processing remains within the scope of the historical consent;

4. the Data Fiduciary gives the required notice as soon as reasonably practicable.

A business should not treat every historical record as consented merely because the data appears in its systems.

The organisation should verify:

• whether consent was actually obtained;

• what the person agreed to;

• which purpose was stated;

• what data was involved;

• whether the consent was withdrawn;

• whether the current use exceeds the historical permission.

If no consent existed, Section 5(2) cannot manufacture one.

34. “As soon as it is reasonably practicable”

This expression requires prompt but operationally realistic action.

It does not create an unlimited transition period. The Data Fiduciary should begin preparation before commencement by:

• identifying legacy consent-based databases;

• mapping communication channels;

• removing duplicates;

• identifying inactive accounts;

• locating current contact information;

• preparing language versions;

• sequencing notice delivery;

• recording failed deliveries;

• maintaining evidence.

The larger and more complex the legacy database, the more structured the remediation plan should be.

“Reasonably practicable” may account for technical complexity and the number of Data Principals. It should not excuse delay caused by lack of preparation during the transition period.

35. Content of the legacy notice

The legacy notice must identify:

• the personal data;

• the purpose for which it has been processed;

• how consent may be withdrawn;

• how grievance rights may be exercised;

• how a complaint may be made to the Board.

The tense changes from proposed processing in subsection (1) to processing that has been conducted in subsection (2). The notice must describe reality, not merely future intentions.

If an e-commerce company historically processed:

• contact details;

• delivery addresses;

• transaction history;

• device data;

• marketing preferences;

it should not send a notice mentioning only name and email.

36. Continued processing under Section 5(2)(b)

The Data Fiduciary may continue processing until the Data Principal withdraws consent.

This is not a permission to expand the processing.

Example

For example, historical consent to send product offers does not authorise:

• selling customer profiles;

• training a general AI model;

• adding facial recognition;

• sharing with unrelated companies;

• processing new categories never disclosed.

Section 5(2)(b) preserves continued processing within the existing consent. It does not create new consent.

37. Legacy consent that would fail Section 6

A difficult question arises where historical consent was technically obtained but was broad, bundled or weak.

Section 5(2) appears to permit continuation until withdrawal, but it should not be interpreted as validating activity that never rested on meaningful agreement.

A prudent approach is:

• where historical consent is clear and purpose-specific, send the Section 5(2) notice and continue until withdrawal;

• where consent evidence is incomplete, obtain renewed consent;

• where the current purpose exceeds historical consent, obtain fresh consent;

• where consent was presumed from silence, do not rely casually on Section 5(2);

• where data was acquired without consent, identify an applicable Section 7 use or cease processing.

38. Legacy-data illustration: e-commerce

The statutory illustration permits notice through:

• email;

• in-app notification;

• another effective method.

The crucial word is “effective.”

An in-app notice may not be effective for a dormant user who no longer opens the application. An email may fail where the address is outdated. A text message may be more effective for some users.

A Data Fiduciary need not guarantee that every person reads the notice, but it should use a channel reasonably likely to reach the person and retain delivery evidence.

38.1 Three legacy-data case studies

38.2 Case study 1: Active e-commerce customer

The user remains active and regularly opens the app.

An in-app notice, coupled with an account privacy centre and persistent access to the notice, may be effective.

38.3 Case study 2: Dormant customer

The user has not opened the app in four years, but the company retains transaction and marketing data.

An in-app notice alone is unlikely to be sufficient. The company should use available email or SMS contact and reassess whether continued retention remains justified.

38.4 Case study 3: Legacy applicant database

An employer has retained rejected applicants’ CVs for ten years without a defined future-hiring consent.

Section 5(2) cannot automatically convert this database into valid consent-based processing. The employer must determine whether consent was originally obtained for future retention. If it was not, the organisation should obtain fresh consent or erase the data unless another exact ground applies.

39. Section 5(3): Language choice

The Data Fiduciary must give the Data Principal the option to access the notice in:

• English; or

• any language specified in the Eighth Schedule to the Constitution.

This is not merely a translation preference. It is intended to make notice meaningful in India’s multilingual society.

40. “Option to access”

The organisation need not necessarily display every language simultaneously. It must provide a genuine option to access the notice in the Data Principal’s chosen supported constitutional language.

The language selector should be:

• visible;

• usable before consent;

• available without agreeing first;

• available on mobile devices;

• preserved when the person moves between screens;

• accessible to persons using assistive technologies.

41. Translation quality

A word-for-word machine translation may not be understandable.

Legal and technical concepts should be rendered in language ordinary users understand. The organisation should test translations with native readers, particularly for:

• consent;

• withdrawal;

• grievance;

• sharing;

• profiling;

• automated processing;

• biometric information;

• retention;

• complaint.

42. Mixed-language interfaces

A notice should not offer Hindi while leaving:

• buttons;

• purpose descriptions;

• withdrawal controls;

• grievance forms;

• error messages;

only in English.

The language option should cover the substantive consent pathway, not merely the privacy-policy page.

43. Oral and assisted access

Section 5(3) refers to accessing the contents. For persons with low literacy or disabilities, an organisation should consider:

• audio notices;

• screen-reader-compatible formats;

• assisted reading;

• large text;

• telephone explanation;

• accessible PDFs;

• captions for video notices.

The EDPB transparency guidance similarly emphasises intelligibility, accessibility and adaptation for children and vulnerable individuals. These practices are useful interpretive guidance but must be fitted to the Indian statutory language and Rule 3.

44. Applicants and recruitment notices

Applicants are ordinarily not employees. Their recruitment processing therefore requires careful separation between:

• Section 7(a) voluntary provision;

• consent under Section 6;

• any later Section 7(i) employee processing after employment begins.

45. Direct application

An applicant voluntarily submits a CV for a specified vacancy. Section 7(a) may support ordinary assessment for that vacancy.

Because Section 5 applies specifically to Section 6 consent requests, it is not automatically triggered merely because Section 7(a) applies. Nevertheless, a recruitment privacy statement remains strongly advisable to explain:

• the employer’s identity;

• information collected;

• vacancy and assessment purpose;

• sources;

• hiring-team access;

• recruitment vendors;

• retention;

• grievance route.

46. When Section 5 is directly triggered

A Section 5 notice is required when the employer asks the applicant to consent to:

• background verification;

• psychometric testing;

• contact with references;

• future-talent-pool retention;

• consideration for unrelated group companies;

• automated screening beyond ordinary assessment;

• use of application data for AI training;

• marketing of courses or services;

• publication of applicant content.

47. Recruitment notice should not mix stages

A notice should distinguish:

A single statement that data will be used for “recruitment and employment purposes” is too broad if it hides future retention, group sharing and model training.

47.1 Applicant case study 1: Named vacancy

The applicant submits a CV for Restaurant Manager.

The notice should identify the application data and explain assessment for that role. It should not describe indefinite retention as an unavoidable part of applying.

47.2 Applicant case study 2: Future vacancies

The employer wants to retain unsuccessful applicants for twelve months.

It should provide a separate notice and choice. Refusing future retention should not affect assessment for the present vacancy.

47.3 Applicant case study 3: Background verification

The employer requests consent to verify education and past employment.

The notice should identify the verification information, purpose and vendor involvement. “We may conduct all checks considered necessary” is insufficiently specific.

48. Interns and trainees

Where an intern or trainee is not an employee, the organisation should not rely automatically on Section 7(i).

Consent-based processing requires a Section 5 notice.

The notice should identify, as applicable:

• identity information;

• academic records;

• eligibility documents;

• attendance;

• access-control information;

• stipend and bank details;

• emergency contacts;

• evaluation records;

• certificate information;

• photographs;

• programme-related health or safety information.

The purposes should be separated.

Example

For example:

• administering the internship;

• paying stipend;

• controlling building access;

• evaluating performance;

• issuing completion certificate;

• publishing a promotional photograph;

• retaining records for future programmes.

The first five may be necessary for the programme. Publicity and future retention remain optional and should have separate consent choices.

If the trainee’s legal relationship is actually employment, Section 7(i) may apply to core processing. The title used by the organisation is not conclusive.

49. Employees

50. Core employment processing

Core employee processing may rely on Section 7(i), including:

• payroll;

• attendance;

• leave;

• performance administration;

• workplace access;

• training;

• discipline;

• internal investigations;

• safeguarding the employer;

• protection of trade secrets;

• benefits sought by employees.

Because this processing does not require Section 6 consent where Section 7(i) properly applies, Section 5(1) is not its direct statutory notice trigger.

An employer may and ordinarily should still provide an employee privacy statement. That statement should accurately identify the ground as Section 7(i), not falsely state that the employee “consents” to essential processing.

51. Optional employee processing

Section 5 applies where the employer requests consent for optional activities, including:

• public testimonials;

• promotional photographs;

• voluntary wellness programmes;

• optional research;

• alumni marketing;

• sharing with commercial benefit providers beyond core administration;

• unrelated AI training;

• social-media publication.

The employer must ensure that refusal produces no adverse employment consequence.

52. Mixed employee notice

A single employee privacy notice may cover both legitimate-use and consent-based processing, but it should visibly distinguish them.

A broad declaration that the employee consents to everything in the privacy notice should be avoided.

53. CCTV

CCTV is relevant to Section 5 only to the extent that consent is requested under Section 6.

54. Household CCTV

Where the personal or domestic exclusion applies under Section 3(c)(i), the Act does not apply and Section 5 is not triggered.

55. CCTV under Section 7(a)

A commercial establishment may rely on Section 7(a) where a person sees clear advance signage and voluntarily enters premises monitored for a specified security purpose.

If Section 7(a), rather than Section 6 consent, is the selected ground, the sign is not technically a Section 5 consent notice. It is transparency supporting the argument that data was voluntarily provided for the specified purpose and that the person had not indicated non-consent.

The sign should state at least:

• CCTV is operating;

• the operator;

• the security purpose;

• a contact or grievance route;

• a link or QR code to further information.

The Section 7(a) theory remains legally unsettled because voluntary entry is not necessarily the same as voluntarily providing facial and movement data.

56. Employee CCTV

Where CCTV protects the employer from loss or liability under Section 7(i), a Section 5 consent notice is not required because the employer is not seeking Section 6 consent.

Employees should nevertheless be informed of:

• camera locations;

• purpose;

• areas covered;

• access;

• general retention;

• grievance mechanism.

The employer should not present mandatory security surveillance as consent-based if employees cannot refuse.

57. Statutory CCTV

Where CCTV is required under applicable law and Section 7(d) supports the necessary recording, retention and disclosure to the State, Section 5 does not directly apply.

Mandated signage may still be required under the applicable public-safety law. It is distinct from consent notice.

58. Consent-based advanced surveillance

If a business seeks consent for facial recognition, behavioural analysis or a voluntary biometric access system, Section 5 applies.

A generic “CCTV in operation” sign would not sufficiently disclose:

• biometric template generation;

• identity matching;

• watchlist comparison;

• behavioural profiling;

• recipients;

• specific purpose.

59. Marketing notices

Marketing often begins with data collected for another transaction. Section 5 requires the marketing purpose to be made clear before consent is requested.

60. Transactional versus promotional communication

A customer may provide a phone number to receive:

• a receipt;

• delivery update;

• booking confirmation;

• service alert.

Section 7(a) may support these communications.

Using the number for promotional messages is a separate purpose and ordinarily requires consent. The Section 5 notice should identify:

• direct marketing channel;

• product or service category;

• whether affiliates or partners are involved;

• withdrawal method.

61. Third-party marketing

“Selected partners” is generally too vague where the actual arrangement involves disclosure to lenders, insurers, travel companies or advertising platforms.

The notice should identify the partner or meaningful category and explain the purpose.

62. Advertising platforms

If a business uploads customer identifiers to a social-media platform for matched audiences, the notice should explain:

• which identifiers are shared;

• that they will be matched against platform accounts;

• the advertising purpose;

• whether lookalike profiles will be created;

• how consent may be withdrawn.

62.1 Marketing case study 1: Hotel guest

A guest consents to email offers from the hotel.

The notice should say that the email address and booking preferences will be used to send offers for hotel accommodation. It does not automatically cover advertising by unrelated luxury brands.

62.2 Marketing case study 2: Employee benefit offer

A hotel proposes to share salary ranges and contact details with a bank offering personal loans.

This falls outside core employment. The employee must receive a separate Section 5 notice and genuine choice.

62.3 Marketing case study 3: Restaurant platform

A dining platform asks users to receive restaurant offers through WhatsApp.

The notice should identify telephone number and dining preferences, the promotional purpose and the withdrawal route.

63. AI training and automated processing

AI training is not automatically part of the original purpose for which personal data was collected.

Where consent is the ground, the Section 5 notice should explain the AI purpose with reasonable specificity.

64. What should be disclosed

Depending on the activity, the notice should identify:

• source data used;

• purpose of model training;

• type of model or function;

• whether the model produces individual scores or predictions;

• whether a vendor receives the data;

• whether inputs are retained;

• whether data will improve a vendor’s general model;

• how withdrawal affects future processing;

• any relevant limitations on deletion after training.

Section 5 does not expressly require a technical explanation of model architecture. The notice should explain the practical processing in terms the person can understand.

65. Employee AI

If an employer uses AI for ordinary payroll anomaly detection or security under Section 7(i), Section 5 may not be directly triggered.

If it asks employees to consent to unrelated model training, emotion analysis or optional research, Section 5 applies.

66. Applicant AI

Applicants are not employees. Section 7(a) may support assessment for the vacancy, but consent should be obtained for broader processing, especially:

• historical dataset training;

• future model development;

• cross-customer vendor training;

• retention beyond the vacancy.

67. Customer AI

Customer-support data supplied to resolve a complaint may be processed under Section 7(a) for that purpose.

Using it to train the vendor’s general commercial model is a different purpose. If consent is sought, the notice must say so expressly.

67.1 AI case study 1: Recruitment model

A company wants to use ten years of rejected applicants’ CVs to train a screening model.

A current recruitment notice cannot retrospectively authorise historical training. The company must examine legacy consent, provide Section 5(2) notice where applicable and obtain fresh consent where the historical purpose did not include model training.

67.2 AI case study 2: Hotel chatbot

A hotel uses a chatbot to answer booking questions.

If conversations are used only to answer the guest, Section 7(a) may apply. If the vendor uses the conversations to train its general model, that additional purpose requires separate assessment and, ordinarily, specific consent.

67.3 AI case study 3: Wellness prediction

Employees voluntarily join a programme predicting health risks.

The notice should identify the health information, model-generated prediction, programme purpose, recipients and withdrawal mechanism. A generic reference to “wellness analytics” is insufficient.

68. Scraping and indirect collection

Scraping exposes an important limitation of Section 5.

Section 5 is consent-centred. A scraper often does not interact with the Data Principal and therefore cannot realistically provide a notice before collecting data or obtain consent.

69. Publicly available data

If the personal data was genuinely made publicly available by the Data Principal, Section 3(c)(ii) may exclude it from the Act. In that case, Section 5 does not apply to that excluded data.

However, the exclusion must be assessed carefully. It may not cover:

• leaked information;

• hacked databases;

• restricted profiles;

• unauthorised reposts;

• hidden fields;

• inferred attributes;

• generated scores;

• combined profiles.

70. New personal data generated from public data

A person may publicly post a photograph. A company may then generate:

• facial embedding;

• identity match;

• age estimate;

• emotion score;

• behavioural profile.

The generated data is not necessarily the same personal data made public by the individual. If it remains within the Act and no Section 7 use applies, the company may need consent. Section 5 would then require notice before requesting that consent.

71. GDPR comparison

GDPR Article 14 specifically addresses personal data not obtained from the data subject and requires information about categories, purposes, legal basis, source, recipients and other matters, subject to exceptions. The DPDPA has no equally detailed indirect-collection notice provision. GDPR Articles 12 to 14 also prescribe a broader transparency framework than Section 5.

This is a major structural difference.

The broader GDPR approach may be adopted as good practice in India, but organisations should distinguish statutory minimum content from recommended fuller transparency.

72. Vendors and processor-supported notices

Engaging a processor does not transfer the Section 5 responsibility away from the Data Fiduciary.

The Data Fiduciary requesting consent must ensure that the notice accurately describes the processing, including relevant vendor involvement where omission would make the notice misleading.

73. Recruitment vendor

An employer uses a background-verification vendor.

The applicant notice should explain the verification purpose and that an authorised provider will perform the checks. If the vendor independently uses the information for a separate commercial database, that use requires its own ground and transparency.

74. Payroll provider

Payroll processing for employees may rely on Section 7(i), so Section 5 is not necessarily triggered. The employee privacy statement should still identify the use of authorised payroll processors.

75. AI provider

A customer-facing company employs an AI vendor.

The notice must distinguish:

• processing by the vendor on the company’s instructions;

• independent vendor model training;

• retention by the vendor;

• disclosure to subprocessors.

A statement that data may be shared with “service providers” may be insufficient if the vendor uses the data for its own model improvement.

76. Consent interface operated by vendor

A vendor may technically display the notice and collect consent, but the Data Fiduciary remains responsible for ensuring that:

• the correct notice is shown;

• language options function;

• consent records are available;

• withdrawal reaches the right systems;

• processor deletion is actioned;

• new vendor purposes are not introduced without approval.

77. Comparison with GDPR transparency

The GDPR’s transparency framework is broader than Section 5.

Articles 12, 13 and 14 generally require information concerning:

• controller identity;

• contact details;

• purposes;

• lawful basis;

• legitimate interests where applicable;

• recipients;

• international transfers;

• retention;

• rights;

• complaint;

• whether provision is mandatory;

• consequences of non-provision;

• automated decision-making;

• source where data was obtained indirectly.

The DPDPA’s Section 5 minimum is narrower and centred on consent. Rule 3 expands the practical detail but does not reproduce the GDPR information list.

77.1 Comparative table

The EDPB guidance is valuable in interpreting clarity, accessibility, prominence, layering, vulnerable audiences and changes to notices. It should not be used to claim that every GDPR Article 13 or 14 field is automatically an express Section 5 requirement.

78. Final interpretation

Section 5 is not a general corporate privacy-policy provision. It is a focused statutory mechanism designed to ensure that consent under Section 6 is informed and operationally controllable.

Its central conclusions are these.

First, Section 5(1) is triggered by a request for consent under Section 6. It does not expressly require the same statutory notice for every Section 7 legitimate use.

Second, legitimate-use processing should not be disguised as consent-based processing. Core employee payroll, attendance and employer-protection processing may rely on Section 7(i). Employees should receive transparency, but they should not be asked to “consent” where they have no genuine choice.

Third, applicants and potential candidates are ordinarily not employees. Section 7(a) may support data voluntarily supplied for a named vacancy. Section 5 notice is required where consent is sought for background verification, future retention, broad group sharing, AI training or other additional purposes.

Fourth, interns and trainees who are not employees should ordinarily receive a consent-based notice for programme processing, with separate consent for optional publicity, research and future retention.

Fifth, notice and consent are different. A privacy policy, CCTV sign or employee handbook may convey information without establishing Section 6 consent.

Sixth, the notice must identify actual personal data and actual purposes. Broad expressions such as “business purposes,” “AI development,” “security” and “improving services” do not provide meaningful specificity.

Seventh, Rule 3 requires the notice to be independently understandable, written in clear and plain language and to contain itemised descriptions of personal data, purposes and enabled goods or services.

Eighth, the notice must provide real mechanisms for consent withdrawal, grievance redressal and complaint to the Board. Empty email fields, broken links and vague “contact us” statements do not fulfil the operational purpose.

Ninth, Section 5(2) protects continuity for genuine pre-commencement consent but does not create consent where none existed. It also does not authorise new purposes outside the historical consent.

Tenth, legacy notices must be sent as soon as reasonably practicable through an effective channel. Organisations should not wait until commencement to identify legacy consent databases.

Eleventh, Section 5(3) requires a genuine language choice. Translation must cover the consent pathway and withdrawal mechanism, not merely a static policy page.

Twelfth, CCTV signage is not automatically a Section 5 notice. Where CCTV relies on Section 7(a), Section 7(i) or Section 7(d), signage performs a transparency function rather than establishing formal Section 6 consent. A Section 5 notice becomes relevant where the operator affirmatively seeks consent, particularly for advanced or optional surveillance.

Thirteenth, marketing must be separated from transactional processing. A phone number supplied for a receipt does not automatically become available for promotions.

Fourteenth, AI training must be described as its own purpose where it is not genuinely part of the original service. A reference to analytics or service improvement is not enough to explain general model training.

Fifteenth, public scraping may fall outside the Act only where the specific information was genuinely made public through a qualifying act under Section 3(c)(ii). Generated inferences, biometric templates and combined profiles require a separate analysis.

Finally, a notice should be treated as part of the processing architecture rather than as a legal document displayed at the end of a form. The organisation’s systems, vendors, consent records, withdrawal controls, language options and retention practices must correspond with what the notice says.

The practical standard is:

Key point

Tell the Data Principal, before asking for consent, exactly what personal data will be used, for what concrete purpose, what service or activity it enables, how consent can be withdrawn, how a grievance can be raised and how the Board can be approached. Then ensure that the actual processing never exceeds that explanation.