The Notice Obligation - Why It Matters
Section 5 of the DPDPA establishes the notice obligation - one of the most operationally significant requirements in the entire Act. A notice is the formal mechanism through which a Data Fiduciary informs the Data Principal about the collection and processing of their personal data. Without a valid notice, any consent obtained is arguably defective because the Data Principal cannot give 'informed' consent without being informed. Notice serves as the bridge between the organisation's processing activities and the individual's ability to make meaningful choices about their data. For businesses, this means every touchpoint where personal data is collected - every web form, mobile app screen, in-store registration, call centre interaction, and IoT device deployment - must be preceded by or accompanied by a compliant notice. This is not merely a legal formality. The notice is the foundation upon which the entire consent architecture rests, and deficiencies in the notice can invalidate downstream consent and processing activities.
Section 5(1): What the Notice Must Contain
Section 5(1) specifies that every request for consent must be accompanied by or preceded by a notice. The notice must contain an itemised description of the personal data sought to be collected and the purpose of processing. It must also inform the Data Principal of the manner in which she may exercise her rights under the Act, including the right to access information about processing, the right to correction and erasure, and the right to grievance redressal. The notice must also inform the Data Principal of the manner in which she may make a complaint to the Data Protection Board. This means your notice cannot be a generic one-paragraph privacy policy. It must specifically describe what data you are collecting in that interaction, why you are collecting it, how the individual can exercise their rights, and how they can complain to the Board if unsatisfied. Each distinct purpose of processing requires distinct disclosure. If you collect email addresses for both order confirmations and marketing, both purposes must be separately stated.
- Itemised description of personal data being collected - be specific, not generic
- Purpose of processing for each category of data collected
- Manner of exercising Data Principal rights (access, correction, erasure, grievance redressal)
- Mechanism for making complaints to the Data Protection Board of India
Language Requirements - English and Eighth Schedule Languages
Section 5(3) introduces a language requirement that is unique to the DPDPA and reflects India's linguistic diversity. The notice must be made available in English and in every language specified in the Eighth Schedule to the Constitution of India. The Eighth Schedule includes twenty-two languages: Assamese, Bengali, Bodo, Dogri, Gujarati, Hindi, Kannada, Kashmiri, Konkani, Maithili, Malayalam, Manipuri, Marathi, Nepali, Odia, Punjabi, Sanskrit, Santali, Sindhi, Tamil, Telugu, and Urdu. This is an enormous operational requirement. Organisations must translate their notices into all twenty-two scheduled languages plus English - a total of twenty-three versions. Each translation must be accurate and legally equivalent to the English version. Machine translation alone is unlikely to meet this standard, as legal terminology requires precision that automated tools often cannot provide. Organisations should engage professional legal translators and maintain version control across all languages to ensure consistency when notices are updated.
- English is mandatory as the base language
- All 22 languages in the Eighth Schedule to the Constitution must be offered
- Total of 23 language versions required for each notice
- Translations must be accurate and legally equivalent - not merely machine-translated
Timing - Before or At the Time of Collection
Section 5(1) requires that the notice be given before requesting consent or at the time of requesting consent. This means the Data Principal must receive and have the opportunity to read the notice before they make their consent decision. A notice provided after data collection - for example, a privacy policy page that can only be accessed after completing registration - fails to satisfy the timing requirement. The practical implication is that notices must be presented inline within the user journey, not hidden behind links or buried in footer menus. For web forms, the notice should appear on the same page as the form, above the consent mechanism. For mobile apps, it should be presented on the screen where data is entered, with the consent toggle following the notice. For offline data collection that is subsequently digitised, the notice must be provided at the point of original collection if practicable, or at the point of digitisation as outlined in Section 3's scope provisions. The key principle is that no data should be processed before the Data Principal has been informed and has consented.
Section 5(2): Notice for Previously Collected Data
Section 5(2) addresses a critical transition issue - what happens with personal data that was collected before the DPDPA came into effect. It provides that where personal data of a Data Principal was processed before the commencement of the Act, the Data Fiduciary must give a notice as soon as reasonably practicable. This means organisations cannot simply ignore their existing databases. If you hold personal data collected under pre-DPDPA terms and conditions, you must proactively reach out to those Data Principals with a compliant notice. The phrase 'as soon as reasonably practicable' provides some flexibility in implementation timing but does not permit indefinite delay. Organisations should prioritise high-risk data - health records, financial data, children's data - for early notification. The notice for existing data must meet the same content requirements as notices for new data collection, including the itemised description of data and purposes, rights information, and complaint mechanism details.
- Applies to all personal data collected before DPDPA commencement that continues to be processed
- Notice must be given 'as soon as reasonably practicable' - delays must be justifiable
- Same content requirements apply as for new data collection notices
- Prioritise high-risk data categories for earliest notification
- If consent is required and was not previously obtained in a compliant form, fresh consent must be sought
Practical Notice Templates and Design Principles
Designing a compliant notice requires balancing legal completeness with readability. A notice that contains all required information but is written in dense legal prose defeats the purpose of informed consent. Best practices include using layered notices - a short summary layer with the key information presented prominently, and a detailed layer with comprehensive disclosures accessible via expansion or link. The summary layer should answer four questions in plain language: what data are we collecting, why are we collecting it, what can you do about it, and who do you contact if something goes wrong. Use bullet points, clear headings, and simple language appropriate for the general public, not lawyers. Visual design matters - use adequate font size, contrast, and spacing to ensure the notice is actually readable on all devices. For mobile applications, consider the constraints of small screens and design the notice to be scrollable without overwhelming the user. Every notice should include a timestamp and version number for audit trail purposes.
- Use layered notices: concise summary at the top, detailed disclosures accessible below
- Answer four key questions: what data, why, what rights, how to complain
- Write in plain language at an eighth-grade reading level
- Ensure mobile-responsive design with adequate font sizes and contrast
- Include version number and date for audit trail and change tracking
Common Mistakes and How to Avoid Them
The most common notice mistake is the generic privacy policy that attempts to serve as the notice for all processing activities. Under the DPDPA, a single all-encompassing privacy policy does not satisfy Section 5 because it fails to provide an 'itemised description' specific to each data collection interaction. The second common mistake is treating notice as a one-time obligation. Whenever you introduce a new processing purpose, collect additional categories of data, or materially change how data is used, you must update your notice and, if processing is based on consent, obtain fresh consent. The third mistake is failing to provide notices in all required languages. Some organisations plan to implement language support incrementally, but Section 5(3) does not provide for phased compliance - all twenty-three language versions are required from the outset. The fourth mistake is burying the notice behind multiple clicks. If the user must navigate away from the data collection screen to find the notice, the timing requirement is likely not satisfied.
How Kraver.ai Helps
Kraver.ai's notice management module automates the creation, translation, deployment, and versioning of DPDPA-compliant notices. Our platform analyses your data collection touchpoints - web forms, mobile app screens, APIs, offline channels - and generates tailored notices for each one that include all information required by Section 5(1). The built-in translation engine, reviewed by legal linguists, produces notices in all twenty-three required languages and maintains version consistency across updates. For existing data covered by Section 5(2), Kraver.ai generates notification campaigns with email and in-app templates to reach your existing Data Principals efficiently. The platform tracks notice delivery, acknowledgment, and consent status for every Data Principal, creating an auditable record for regulatory inquiries. When you add a new processing purpose or change data collection practices, Kraver.ai automatically flags affected notices for update and manages the re-consent workflow. Start automating your notice compliance today.