Having an “I agree” checkbox is not the legal test. The test is whether you can show the person understood a defined purpose, actively agreed, had a real choice, gave only necessary data, can withdraw easily, and whether you can prove it.
Under Section 6 of India’s Digital Personal Data Protection Act, 2023, consent is valid only when it is free, specific, informed, unconditional and unambiguous, and the Data Principal signifies agreement through a clear affirmative action. The consent must relate to a specified purpose and cover only the personal data necessary for that purpose. A Data Fiduciary relying on consent must also be able to prove that the required notice was given and valid consent was obtained.
The practical question for a company is not “Do we have a checkbox?” It is: can we prove that this person understood a defined purpose, actively agreed to it, was not forced into unrelated processing, gave only necessary data, and can withdraw as easily as they consented?
Valid consent under Section 6 is a constrained authorisation for a defined processing purpose. It is not a general permission to collect, retain, profile, share or reuse a person’s data however the company later chooses. Section 6 requires consent to be:
The consent must also cover only the personal data necessary for the specified purpose.
The Act does not mandate a checkbox, a toggle, a cookie banner, a preference centre, a Consent Management Platform, a separate consent database, or any specific screen design. These can be useful operational controls, but a design is legally meaningful only if it satisfies the actual Section 6 test.
Design consent journeys so an independent reviewer can reconstruct the purpose, notice, individual choice, affirmative action, data scope, timing, change history and withdrawal path.
Consent is one lawful basis for processing under the DPDP Act, not the only one. Section 4 permits personal-data processing for a lawful purpose where the Data Principal has given consent, or for certain legitimate uses described in Section 7.
| Provision | Role |
|---|---|
| Section 4 | Establishes that personal data may be processed only in accordance with the Act and for a lawful purpose |
| Section 5 | Requires notice before or with a consent request |
| Section 6 | Defines consent, withdrawal and consent-related proof obligations |
| Section 7 | Lists certain legitimate uses that can permit processing without consent in stated circumstances |
Do not use consent as a catch-all where a Section 7 basis clearly applies, such as compliance with law, specified employment purposes or medical emergencies. Equally, do not label ordinary commercial activities “legitimate uses” merely to avoid consent. Optional marketing, advertising, partner sharing, unrelated profiling, personalisation, AI training or secondary use each need their own legal-basis and purpose analysis.
Section 6 can be applied as a six-part practical test. All six must hold for consent to be valid, and a seventh statutory limit - necessity of the data for the specified purpose - must also be met.
Beyond the six qualities of consent, Section 6 imposes a separate limit: only the personal data necessary for the specified purpose may fall within that consent. This is not just another adjective describing consent - it is an independent statutory boundary on scope. Data is not necessary merely because it is available.
| Requirement | What it means in practice | Example |
|---|---|---|
| Free | The person has a genuine choice | Newsletter consent is optional when downloading a requested guide |
| Specific | Consent relates to a defined purpose | Separate purpose for account creation and marketing |
| Informed | The person receives understandable information | Notice identifies data and explains why it will be processed |
| Unconditional | Consent is not tied to unrelated or prohibited conditions | A service does not require consent to unrelated behavioural advertising |
| Unambiguous | The person’s decision is clear | The interface clearly states what agreement means |
| Clear affirmative action | The person actively signifies agreement | An unticked checkbox or affirmative button click |
| Necessary data only | Only data necessary for the specified purpose is processed | A telemedicine app does not collect contact-list data merely because it can |
For each consent flow, can your organisation answer all five?
If you cannot reconstruct these answers later, your consent design may have an evidence problem even if the interface contains an “I agree” button.
Understand where your organisation may have gaps across consent, notices, rights, governance and implementation.
Take the readiness assessmentFree consent means the Data Principal must have a meaningful choice. A company should not use essential access, unequal pressure or unnecessary conditions to force agreement to optional or unrelated processing. The Act does not define every form of coercion or list every prohibited pattern, but a consent request that gives no meaningful choice may be difficult to defend as “free.”
Illustrative implementation example - not a prescribed statutory interface. The Act does not label interfaces “legal” or “illegal”; it asks whether the six-part test is met and whether you can prove it.
| Pattern | Why it creates risk |
|---|---|
| “Accept marketing or you cannot create an account” | Marketing may be unrelated to account creation |
| “Allow contact access or you cannot use telemedicine” | Contact list may not be necessary for telemedicine |
| “Agree to targeted advertising to complete checkout” | Advertising may be unrelated to order fulfilment |
| “Agree to all future uses” | The person cannot understand or meaningfully choose unknown uses |
| “Consent to waive your DPDP rights” | Consent cannot override statutory rights |
| Refusal option hidden behind multiple screens | Makes refusal materially harder than agreement |
| Pattern | Why it is easier to defend |
|---|---|
| Separate optional marketing choice | Preserves choice |
| Service access independent of optional analytics | Avoids forced consent for unrelated use |
| Clear explanation of the consequences of refusal | Enables an informed decision |
| Separate third-party-sharing choice | Keeps the sharing purpose distinct |
| Equal prominence for accept and decline | Supports meaningful choice |
| Easy preference-management route | Supports later modification and withdrawal |
For every optional purpose, make refusal possible without depriving the Data Principal of an unrelated core product or service. Sector-specific necessity examples appear in Industry examples below.
Specific consent means the Data Principal agrees to a defined purpose, not to a vague, unlimited or future category of uses. “Business purposes,” “service improvement” or “all future uses” are not good substitutes for a clearly explained processing purpose.
| Weak statement | Why it is weak | Stronger approach |
|---|---|---|
| “We use your data to improve services” | Does not identify the processing activity or data use | “Use feature-usage events to identify recurring product errors and improve platform reliability” |
| “We may share your data with partners” | Does not identify the purpose or sharing context | “Share your registration details with the co-host of this webinar so it can send event-related follow-up” |
| “We may use your data for marketing” | Overbroad if multiple channels and activities are involved | “Send product updates by email,” and separately “send promotional SMS” |
| “We may use your data to improve AI” | Does not explain training, evaluation, prompts or reuse | “Use de-identified support-ticket content to evaluate support-response quality,” where legally justified |
| “We may contact you” | Does not distinguish service communication from promotion | Separate service alerts, account notices and marketing communications |
The Act does not say that every business purpose requires a separate checkbox. But the more different the purpose, data category, recipient, consequence and user expectation, the harder it becomes to show that a single consent was genuinely specific. Consider separating consent where purposes are materially different - for example account creation, marketing email, promotional SMS, WhatsApp marketing, personalised recommendations, third-party sharing, product analytics, behavioural advertising, customer research, loyalty programmes, and AI model training.
Consent for one purpose does not automatically extend to a new purpose.
| Original purpose | Proposed later use | Required question |
|---|---|---|
| Create an account | Send promotional offers | Was marketing separately disclosed and consented to? |
| Provide telemedicine | Build an advertising audience | Is this necessary for telemedicine? If not, what ground and purpose support it? |
| Deliver an order | Share data with commercial partners | Was third-party sharing specifically explained and authorised? |
| Customer support | Train a general AI model | Does the original purpose cover this secondary use? |
| Employee onboarding | Cross-sell retail financial products | Is there a separate lawful basis and purpose? |
Consent is informed only when the Data Principal receives the information needed to understand the proposed processing before or with the consent request. The Section 5 notice is therefore central to Section 6 consent. The notice must inform the person about the personal data proposed to be processed, the purpose, how to withdraw consent, how to exercise rights, and how to complain to the Board. Section 6(3) additionally requires the request to be in clear and plain language, available in English or a language in the Eighth Schedule, with contact details of a Data Protection Officer where applicable.
Rule 3 requires the notice to be independently understandable, clear and plain, and to give a fair account of the personal data and specified purpose. It must provide itemised descriptions of the personal data, the specified purpose or purposes, and communication links or other means for withdrawal, rights exercise and Board complaint.
| Item | Purpose | Automatically enough for valid consent? |
|---|---|---|
| Privacy policy | Broad transparency document | No |
| Section 5 notice | Explain the proposed data and purpose before or with the consent request | Necessary where consent is requested |
| Consent request | Ask for the person’s affirmative agreement | Must satisfy Section 6 |
| Consent record | Prove notice and consent later | Necessary to meet the proof burden in practice |
A privacy-policy link alone may be insufficient if the person cannot reasonably identify what data are requested, the specified purpose, optional versus necessary processing, the withdrawal route, the rights and grievance route, and what action actually signifies consent. A privacy policy is not automatically a substitute for the notice and consent process.
Use a concise, just-in-time notice for the immediate decision, and link to the privacy policy for fuller context. Preserve the version of both where the consent request relies on them.
Unconditional consent means a company should not make consent subject to conditions that are unrelated to the specified purpose or that attempt to take away rights under the DPDP Act. Bundling means combining multiple purposes or conditions so a person cannot meaningfully agree to one while refusing another.
| Pattern | Risk assessment |
|---|---|
| Account creation + necessary account data | May be appropriate if data are necessary for the stated account purpose |
| Account creation + optional product marketing | High risk if the user cannot refuse marketing and still create an account |
| Telemedicine + medical details needed for consultation | May be appropriate where data are necessary |
| Telemedicine + phone contacts | High risk where contact-list access is unnecessary |
| Insurance policy + data processing needed to issue the policy | May be appropriate where necessary and otherwise lawful |
| Insurance policy + waiver of DPDP complaint rights | Invalid to the extent it infringes the Act |
The Act gives an example of an insurance-policy consent request where the person agrees both to processing needed to issue the policy and to waive the right to complain to the Data Protection Board. The Act states that consent is invalid to the extent the waiver infringes the Act. A waiver of statutory rights cannot be cured by an “I agree” button.
A company should not ask a person to agree to:
Create a design-review rule: no consent flow may include a waiver of DPDP rights, or combine optional commercial processing with an unrelated essential service, without privacy or legal approval.
Clear affirmative action means the Data Principal must actively signify agreement. The Act does not prescribe a single interface format - there is no mandated checkbox, toggle, CMP or screen - but the action must reliably show what the person agreed to.
| Pattern | Assessment under Section 6 | Why |
|---|---|---|
| Unticked checkbox beside a defined purpose | Usually easier to evidence | A clear action can be tied to the stated purpose |
| Toggle off by default for optional marketing | Usually easier to evidence | Active opt-in is visible |
| “I agree” button after clear notice | May be defensible | Depends on whether the button meaning and purpose are clear |
| Signed form | May be defensible | Preserve form version, identity and date |
| Verbal “yes” in a recorded call | May be defensible | Preserve script, recording, identity check and purpose |
| OTP-confirmed consent event | May be defensible | Preserve underlying notice, OTP event and identity linkage |
| Pre-ticked optional-marketing choice | High risk | Harder to prove affirmative, free and unambiguous action |
| Silence or no response | High risk | Does not show active agreement |
| Continued browsing | High risk | May not demonstrate agreement to defined processing |
| “By continuing” language | Context-dependent, often high risk | Must clearly show what action authorises which processing |
| Device permission prompt | Not automatically DPDP consent | Operating-system permission is distinct from purpose-specific consent |
A mobile operating system may ask the user to allow camera, microphone, contacts, location or notifications. That technical permission does not automatically establish that the person received a Section 5 notice and gave valid Section 6 consent for each intended processing purpose.
Map every app permission, SDK, tracker and API to a documented processing purpose, lawful basis, notice, consent state, retention rule and processor or vendor.
Section 6 limits consent to the personal data necessary for the specified purpose. A company cannot rely on consent to justify collecting data merely because it is available, technically convenient or commercially useful. The Act illustrates this with a telemedicine app: a person consents to processing for telemedicine and to the app accessing their phone contact list. Because the contact list is not necessary to provide telemedicine, consent is limited to the data necessary for that service.
It is not “did the user click Allow?” It is: was this personal data necessary for the specified purpose for which consent was requested?
| Data or permission | Possible purpose | Necessity question |
|---|---|---|
| Name and mobile number | Account verification or appointment confirmation | Is it needed to identify or contact the patient? |
| Health symptoms | Telemedicine consultation | Is it needed for the clinical service? |
| Camera | Video consultation or remote KYC | Is it necessary for the stated service? |
| Microphone | Video / audio consultation | Is it necessary for the stated service? |
| Location | Emergency dispatch or location-specific service | Is it necessary for that service, or merely useful? |
| Phone contacts | Telemedicine | Usually difficult to justify as necessary |
| Call logs | E-commerce checkout | Usually difficult to justify as necessary |
| Device identifiers | Fraud / security | Assess whether necessary, proportionate and clearly disclosed |
| Advertising ID | Behavioural advertising | Not necessary to provide most core services |
Yes - a Data Principal may withdraw consent at any time, and withdrawal must be as easy as giving consent. The Data Fiduciary must stop consent-based processing within a reasonable time and cause its Data Processors to stop, unless another law or DPDP ground authorises or requires continued processing.
| How consent was collected | Comparable withdrawal approach |
|---|---|
| Website form | Website account or preference option, or a clear digital route |
| App toggle | In-app preference control |
| Email opt-in | Unsubscribe or preference mechanism |
| SMS opt-in | Clear SMS or digital opt-out route |
| Call-centre consent | Call-centre, written or digital withdrawal route |
| Paper form | Accessible written, digital or assisted route |
| Partner-collected consent | Clear route through the responsible Data Fiduciary, with downstream propagation |
The Act does not mandate “one-click withdrawal.” But if consent takes seconds and withdrawal requires a phone call, paper letter, multiple support tickets or unexplained authentication steps, the company may struggle to show comparable ease.
Withdrawal stops processing that was based on consent. It does not automatically mean every record must be deleted immediately. Data may need to be retained where another legal ground applies, where retention is required by law, or where tax, accounting, KYC, AML, fraud, security, dispute or litigation requirements apply. Retained data should not, however, continue to be used for unrelated consent-based marketing, profiling or commercial reuse.
Yes. Section 6 allows a Data Principal to give, manage, review or withdraw consent through a Consent Manager. But a statutory DPDP Consent Manager is not the same as ordinary consent-management software, a cookie banner, a CRM preference field or an internal consent database.
Section 6 provides that:
Section 6(9) and Rule 4 are scheduled to commence on 13 November 2026. The remaining core consent provisions in Section 6 - including Sections 6(1)–6(8) and 6(10) - are scheduled to commence later, on 13 May 2027. That creates an important distinction as of August 2026:
| Question | Position as of August 2026 |
|---|---|
| Is the statutory Consent Manager framework notified? | Yes |
| Does the Act define the Consent Manager role? | Yes |
| Is Consent Manager registration under Section 6(9) operative yet? | No - scheduled for 13 November 2026 |
| Can any vendor call itself a DPDP-registered Consent Manager today? | Not without official Board registration once the registration regime is operative |
| Must every Data Fiduciary use a Consent Manager? | No |
| Does a company’s CMP or CRM automatically qualify as a Consent Manager? | No |
A Consent Manager does not remove the Data Fiduciary’s responsibility to:
A Consent Manager may help a person manage consent, but it does not turn invalid consent into valid consent. The six-part test and the necessity limit still apply to the underlying request.
Rule 4 and Schedule I set out the registration and operating requirements for Consent Managers. Among other obligations, a Consent Manager must maintain records of consent given, denied or withdrawn; of the notices preceding or accompanying consent requests; and of the sharing of personal data with transferee Data Fiduciaries. It must give the Data Principal access to those records, provide machine-readable information on request in line with its terms of service, retain the records for at least seven years unless a longer period applies, use reasonable security safeguards, act in a fiduciary capacity toward the Data Principal and avoid conflicts of interest with Data Fiduciaries.
The word “consent” appears in many products. Only one of these is the statutory role.
| Statutory Consent Manager | CMP / cookie tool | CRM preference field | |
|---|---|---|---|
| What it is | A Board-registered entity defined by Section 6 and Rule 4 | Software that captures and stores consent choices | A field or flag inside a sales or marketing system |
| Registered with the Board? | Required once 6(9) and Rule 4 commence | No | No |
| Accountable to | The Data Principal, in a fiduciary capacity | The company that licenses it | The company that operates it |
| Statutory records duty? | Yes - Schedule I | No (contractual only) | No |
| Turns invalid consent valid? | No | No | No |
Do not wait for the Consent Manager ecosystem to mature before building your own consent records, withdrawal workflow and processor-propagation controls. The proof burden sits with the Data Fiduciary regardless of whether a Consent Manager is involved.
During 2026, companies should prepare to:
The Section 6 test is common across sectors, but the necessity, retention, vendor and user-expectation analysis changes by industry. Each sector below links to its dedicated DPDP hub.
| Purpose | Likely consent question |
|---|---|
| Teleconsultation | Are health details, camera and microphone necessary for service delivery? |
| Appointment reminders | Is the communication purpose clear and separate from marketing? |
| Health research | Is secondary research clearly covered by the original purpose or another lawful basis? |
| Advertising | Is patient data being repurposed for a commercial purpose? |
| Contact-list access | Can the provider show it is necessary for telemedicine? |
| Purpose | Likely consent question |
|---|---|
| Account setup | Which data are necessary to create and secure the account? |
| Service telemetry | Is the telemetry necessary for service and security, or an optional analytics purpose? |
| Marketing | Is marketing separate from account communications? |
| Product improvement | Does the notice clearly explain the intended use? |
| AI training | Is data reused beyond the original customer-service purpose? |
The RBI Directions already require need-based collection, prior explicit borrower consent and auditable consent trails. They restrict Digital Lending App access to files and media, contact lists, call logs and telephony functions, while allowing limited one-time access to camera, microphone, location or another facility when necessary for onboarding or KYC and explicitly consented to. These requirements apply within their regulatory scope and do not extend to businesses outside it.
A lender should separate: KYC and identity verification; underwriting; fraud prevention; loan servicing; recovery; statutory and regulatory reporting; marketing; cross-selling; and partner sharing.
| Purpose | Likely consent question |
|---|---|
| Fulfil order | Which delivery and payment data are necessary? |
| Create account | Is account data distinct from optional marketing? |
| Loyalty programme | Is participation voluntary and purpose-specific? |
| Personalised offers | Is profiling separately explained where consent is relied on? |
| Third-party promotions | Is partner sharing distinct and clear? |
Where the Data Principal is a child, Section 9 requires verifiable parental or lawful-guardian consent before processing, subject to limited exemptions. Rule 10 prescribes verification approaches, while Rule 12 and the Fourth Schedule contain narrow exemptions. Ordinary Section 6 consent design is not sufficient where children’s-data requirements apply - a Section 9 and Rule 10 assessment is needed in addition.
A Data Fiduciary relying on consent must be able to prove that it gave the required notice and obtained consent in accordance with the Act. Section 6(10) contains this proof burden, which makes evidence design a core compliance control. The Act does not prescribe a standard “consent receipt,” a mandatory ledger product or a fixed evidence schema.
The Act creates a proof burden but does not prescribe this exact schema. Preserve consent evidence with appropriate access controls, integrity protection, version history and retrieval capability. The strongest consent record is one that can be retrieved quickly and explained clearly in an audit, complaint or Board proceeding.
marketing_consent = true enough evidence?A single boolean flag in your CRM, such as marketing_consent = true, records a preference state. On its own it does not evidence the consent event: what the person was shown, which purpose they agreed to, when, through what action, and whether that agreement still stands. If a complaint or Board proceeding asks you to prove valid consent, a lone true/false value cannot answer those questions.
Section 6(10) places the burden of proving notice and valid consent on the Data Fiduciary. The Act does not define how or where you store it.
Treat the boolean as an enforcement flag that downstream systems read, kept linked to an immutable consent event record (purpose, notice version, timestamp, affirmative-action type, channel). The flag tells systems what to do now; the event record proves why you were allowed to.
Section 6 does not assign internal roles. But valid consent breaks in practice when no single function owns each part of it. A workable division of responsibility:
| Function | Owns |
|---|---|
| Legal / Privacy | Lawful basis, purpose definitions, notice and consent wording |
| Product | The consent journey, user controls, withdrawal being as easy as giving |
| Engineering | Consent state, evidence capture and enforcement across systems |
| Marketing / Growth | Using data only for the purpose consented to, with no scope creep |
| Procurement / Vendor | Ensuring processors and partners honour consent and withdrawal |
| Audit / GRC | Testing evidence, retrieval and readiness for a Board query |
This is an accountability model, not a structure the Act mandates. Map these owners to your real teams. The common failure mode is consent that is captured by Product but never enforced by Engineering or respected by Marketing.
If your organisation receives leads or data from another organisation, do not rely on a generic assurance that “consent was obtained.” Before relying on externally collected consent, can you establish:
Use this checklist to assess a current consent mechanism. It stays on this page and indexable - knowledge is not gated.
The readiness assessment walks your organisation through consent, notice, rights, governance and implementation, and flags where the gaps are.
Take the readiness assessmentEach of these is principle-based risk, not an automatic finding of illegality - but each makes consent materially harder to defend or prove.
Consent is valid only when it is free, specific, informed, unconditional and unambiguous, given through a clear affirmative action, connected to a specified purpose and limited to the personal data necessary for that purpose (Section 6).
No. The Act does not prescribe a checkbox, toggle or particular consent-interface design. It requires a clear affirmative action and compliance with the full Section 6 test.
The Act does not expressly name pre-ticked boxes. However, a pre-ticked optional-consent choice is higher risk, because the company may struggle to prove clear affirmative action, free choice and unambiguous agreement.
Section 6 requires a clear affirmative action. Silence, inactivity or unclear implied agreement is therefore difficult to defend where a company relies on consent.
The Act does not ban every combined interface. But a company should not bundle unrelated optional processing, such as marketing or behavioural advertising, with necessary service processing if doing so prevents meaningful choice or makes consent conditional.
The Act does not expressly address browsing behaviour. But continued browsing alone may be difficult to establish as a clear affirmative action for a defined processing purpose.
No. The Act’s insurance illustration states that consent is invalid to the extent it infringes the Act, including where a person is asked to waive the right to complain to the Data Protection Board.
Yes. A Data Principal may withdraw consent at any time, and withdrawal must be as easy as giving consent.
The Act does not prescribe a universal renewal period for ordinary consent. But a company should reassess consent where purposes materially change, evidence is weak, data are legacy records, or later processing extends beyond the original purpose.
The Act requires the Data Fiduciary to be able to prove that notice was given and valid consent obtained. A practical record preserves the person’s identifier, purpose, data categories, notice version, consent wording, affirmative action, timestamp, channel and withdrawal history.
This guide is general information about the DPDP framework, not legal advice. Confirm application to your organisation with a qualified Indian privacy-law adviser.