Implicit vs Explicit Consent: DPDP Act India Explained

The Consent Question Most Enterprises Are Getting Wrong

When most enterprises are asked whether they have obtained consent from their user, their answer is always yes, but when asked whether the consent is valid under India’s Digital Personal Data Protection Act, 2023, the answer becomes less certain. For a lot of years, Indian businesses have considered consent just as a pre-ticked, check-box, that was buried under a lot of terms and conditions, or a "by continuing to use this service, you agree" banner in a footer, as these were operationally convenient. Under the DPDP Act, these practices are insufficient.

The Act sets a specific, elevated standard for what constitutes valid consent. For enterprises across BFSI, fintech, e-commerce, insurance, and digital services, the distinction between implicit and explicit consent is not a semantic nuance. It is a compliance inflection point, one with direct operational consequences.

"It would require internal systems to be rewired. It is an always-on kind of thing." - Rohit Razdan, IDfy.

Consent under the DPDP Act is not a one-time data point. It is a living, auditable, purpose-specific agreement between an enterprise and every individual whose data it holds.

What Does the DPDP Act Say About Consent

According to Section 6 of the DPDP Act, personal data can be processed on consent given or for narrow legitimate uses as mentioned under Section 7, covering legal compliance, medical emergencies, and certain employment functions. For most commercial processing, onboarding, marketing, personalization, analytics, and third-party data sharing, consent is the operative legal basis. Section 6 sets five cumulative conditions for consent to be valid. It must be free, specific, informed, unconditional, and unambiguous. 

Among these requirements, the need for unambiguous consent creates the clearest distinction between implicit and explicit consent, making it a critical consideration for organizations designing consent experiences and privacy programs. To understand the full obligations this creates for your organization, read our guide on the core principles of the DPDP Act.

Implicit vs Explicit Consent

In Implicit consent, the organizations assume that the data principle has agreed to processing their data just with pre-ticked checkboxes, bundled consent for multiple purposes, or notices that imply continued use of a service means consent has been given. In these kinds of situations, the individual's agreement is inferred rather than clearly expressed. 

Explicit consent, on the other hand, requires a clear and deliberate action from the data principal. Before consenting, the data principal must understand what data is being collected, why it is being used, and who it may be shared with. Consent must be given separately for each specific purpose and should be recorded so the organization can demonstrate that it was obtained properly.

"Do we know what data we hold, why we hold it, and who is responsible?" -Bhaskar Sharma, Independent Director, IDfy

The bundling problem is one of the most common consent failures in Indian enterprises today. A single checkbox covering service delivery, marketing, and third-party data sharing is explicit in form but implicit in substance, and it does not satisfy the Section 6 standard. For a deeper understanding of how consent has been interpreted under the Act, see Navigating Consent Under the DPDP Act.

The Section 5 Notice

The DPDP Act creates a mandatory link between notice and consent. Before or at the time of requesting consent, a data fiduciary must provide the data principal with an itemized notice in clear and plain language containing:

• Each personal data item being collected and the specific purpose of its processing
• How the data principal can exercise their rights under the Act
• How can they make a complaint to the Data Protection Board

This is not a privacy policy. It is a specific, pre-consent disclosure. Many existing privacy policies do not meet this standard. They often describe data practices in broad terms and are not presented at the point where consent is sought. They are written mainly for legal protection rather than user understanding. To comply with the DPDP Act, organizations will need to rethink how privacy notices are designed and delivered across every customer touchpoint, whether it is digital, mobile, or offline.

Granular, Purpose-Specific Consent: The Architecture Shift

One of the most operationally demanding aspects of the DPDP consent framework is the requirement for granular and purpose-specific consent. One single consent with a tick box cannot cover all the processing activities. The consent has to be collected separately for each of these processes, like KYC, Marketing, or cross-entity sharing, and each of these consents has to be personalized specifically. It has to be independently manageable by the data principal as well. 

Let's consider a bank onboarding a new customer. In this scenario, the data requirements for the bank would be name, PAN, address, income details, and bank statements for different purposes. Only some of these purposes fall under legitimate use. Other purposes like pre-approved product marketing, data sharing with group entities and personalized offers all require consent-based approval from the data principal. 

"It shifts the responsibility from just delegating to the compliance team."  Bhaskar Sharma, Independent Director

Consent architecture is not just a compliance team task. It involves product, technology, legal, and leadership stakeholders, which is why understanding what a Data Protection Officer's role covers under the DPDP Act matters for governance design.

Consent Withdrawal: The Equal Ease Requirement

Under Section 6, clause 4, it is stated that every data principal has the right to withdraw consent at any time. The withdrawal mechanism must be as easy as giving consent. If a user is connected with a single click, they must be able to withdraw consent in a single click without having to get buried in the account settings or drop an email or any long processes. 

Here's where it gets technically demanding. When a user hits that toggle, the withdrawal can't stop at the UI layer. It has to be implemented across all the systems processing their data. It generally involves marketing, third-party CRM, automation engines, ad platforms, etc. Let's assume a scenario where the data principal has withdrawn consent. How will your marketing manager know which data principal withdrew consent today? In a microservices architecture, that's not trivial. A product manager at Privy thinks about this in three layers.

Consent state layer: Privy maintains a real-time consent record for every user, every purpose, every channel. When a withdrawal comes in, that record updates instantly. This is the source of truth from which everything else reads.

Propagation layer: the withdrawal signal needs to reach every connected service that was acting on that consent. Privy does this through API orchestration, pushing the withdrawal event downstream to each integrated system synchronously, not in a nightly batch job. A marketing automation tool that was sending emails based on that consent gets the signal. The CRM sync stops. The ad platform suppression list updates. Each downstream acknowledgement is logged with a timestamp.

Evidence layer: a product manager needs to be able to show, for any given withdrawal, exactly which systems received the signal, when, and what action they took. That audit trail is what makes withdrawal defensible in front of the Data Protection Board, not just operationally complete.

Where it gets complex is the third-party integrations that don't expose real-time APIs. Some legacy CRMs and marketing platforms accept suppression lists on a schedule. A product manager has to decide on do we block that vendor from receiving the data at the consent record layer immediately, even if their system catches up on the next sync window. At Privy, the answer is yes. The consent record is the gate. If a vendor can't confirm real-time compliance, they don't get the data until they can.

Upon withdrawal of consent, the enterprise must also delete the relevant data unless another law requires retention. Processing of data that occurred while consent was valid remains lawful. Everything after the withdrawal does not.

Consent for Children's Data: A Higher Standard

Section 9 under the DPDP Act is where most ed-tech and gaming companies quietly break into a sweat. Verifiable Parental Consent isn't a policy problem. It's an engineering one.

The law states that verifiable consent from a parent or lawful guardian before any child's data is processed. Age self-declaration doesn't count for processing children’s data. Most platforms rely on a date-of-birth field and call it done, but it is considered self-declared under Section 9, and that's a compliance gap.

At IDfy, we have an Aadhaar Lite API that handles age verification without storing or exposing the full Aadhaar number of the data principal. For parent/ guardian mapping the school records, government IDs, or multi-step validation confirms the consenting adult is actually the child's parent or guardian. Through this process, the parent/guardian can be identified. Privy sits on top as we do tokenized consent records tied to a verified guardian identity, timestamped and audit-ready for the Data Protection Board.

Three things stay off the table regardless of parental agreement they are no behavioural tracking, no targeted advertising, and no processing detrimental to a child's wellbeing.

Read more: parental consent under the DPDP Rules.

The Consent Manager: India's Interoperable Consent Framework

Section 6(8) introduces a uniquely Indian construct, the Consent Manager. This is a registered intermediary that enables data principals to give, manage, review, and withdraw consent across multiple enterprises through a single, interoperable platform. Drawing conceptual inspiration from India's Account Aggregator ecosystem, Consent Managers must be incorporated in India, registered with the Data Protection Board, and must act in a fiduciary capacity towards data principals. For enterprises, this means consent systems will eventually need to be API-accessible, capable of receiving and processing real-time consent status updates relayed through Consent Manager platforms.

Enterprises that build modular, purpose-level consent records with API-accessible consent status today will be better positioned for this integration when the Consent Manager framework becomes fully operational. For a broader overview of how this fits into enterprise compliance obligations, see our DPDP Act FAQs: Consent, Rights, Notices and Penalties.

Where Most Enterprise Consent Architectures Fall Short

For most enterprises, the honest answer to "Are we DPDP consent-compliant?" is: not yet.

"Going towards the cheapest solution can lead to rework." Rohit Razdan,IDfy

The gaps are structural, not incidental. To understand processor and vendor accountability in full, read Everything a Data Processor Must Know Under the DPDP Act.

"Going towards the cheapest solution can lead to rework." 

- Rohit Razdan, IDfy

Enterprises that deploy a basic consent pop-up and a recycled privacy policy may satisfy the appearance of compliance while accumulating the underlying risk. When the Data Protection Board examines consent defensibility, the question will not be whether a notice existed; it will be whether consent was genuinely informed, purpose-specific, and withdrawable with equal ease.

How a DPDP-Ready Consent Framework Looks

A genuinely DPDP-ready enterprise can answer with documentary evidence the following at any point in time:

• What consents have been given, for what purposes, and when?
• What version of the notice was presented at the time of each consent?
• Which consents have been withdrawn, and has data been deleted accordingly?
• Can consent records be produced in an auditable, evidence-grade format?
• Are all vendor and processor relationships covered by the relevant consent scope?

The operational components required to answer these questions include:

• A purpose register - each processing purpose mapped to its legal basis, data collected, and notice presented
• A live consent record store - purpose-level records with timestamps, notice versions, and withdrawal history
• Compliant notice templates - itemized, plain-language, surfaced at the point of consent across all touchpoints
• A self-service withdrawal mechanism - meeting the equal ease standard
• An audit trail - immutable logs of all consent events, producible as evidence on demand

From Consent Capture to Consent Governance

The shift the DPDP Act demands is not from no consent to some consent. It is from consent as a one-time event to consent as a governed, operational capability. Consent capture is transactional: a user clicks a button, a record is stored, and the event is closed. Consent governance is the continuous tracking of what consent was given, for what purpose, under which notice version, managing withdrawals, triggering deletions, and producing audit-grade evidence when required. Boards and leadership teams should be asking: what is our consent coverage today, and can we demonstrate it?

"What I'm seeing in the boards is that the conversation has started." - Bhaskar Sharma, Independent Director, IDf.y

The conversation has started. But starting the conversation is not the same as building the capability. For an understanding of what board-level data governance oversight requires, read our piece on DPDP compliance and director accountability.

Conclusion: Consent Is a Governance Capability, Not a Checkbox

We are entering an era where consent is no longer a form field; it is a measure of how much your users trust you with what matters most to them. Enterprises that treat consent as a checkbox will find themselves exposed, not just to regulatory scrutiny, but to something harder to recover from: the loss of customer confidence.

The DPDP Act has not created a new burden. It has formalized what good data stewardship always looked like. Implicit consent assumed, bundled, buried, or inferred was never really consent at all. Explicit, purpose-specific, informed, affirmative, and withdrawable consent is simply what your users deserve all along.

The path forward is clear even if it is not simple: audit your existing consent mechanisms, redesign your notices, rebuild consent flows to be purpose-specific, implement equal-ease withdrawal, and establish an evidence-grade consent record store. Do not wait for an enforcement inquiry to discover where your compliance gaps are. The enterprises that build consent governance properly today are not just avoiding penalties; they are building the kind of trust that becomes a genuine competitive advantage.

Privy by IDfy is already live with Axis Bank, supporting one of India's largest financial institutions operationalize DPDP-compliant consent governance at scale. Whether you are a large BFSI enterprise, a fast-growing fintech, or a digital platform preparing for enforcement, we are here to help you move from consent capture to consent governance across the full lifecycle.

Ready to build a consent framework that holds up when it matters? Reach out to us for a deep dive into how Privy by IDfy can help your organization become genuinely, demonstrably DPDP-ready. Contact us at shivani@idfy.com. We would be happy to help.

Frequently Asked Questions

What is explicit consent under the DPDP Act? 

Explicit consent under the DPDP Act is consent expressed through a clear affirmative action for a specific, individually stated processing purpose. It must be free, specific, informed, unconditional, and unambiguous. Bundled consent, pre-ticked boxes, and consent inferred from continued service use do not meet the Section 6 standard.

Is implicit consent valid under the DPDP Act? 

No. Section 6 requires an unambiguous affirmative action. Consent inferred from silence, inactivity, or bundled terms acceptance does not qualify. Enterprises relying on legacy implicit consent mechanisms will need to redesign their consent architecture before DPDP enforcement begins.

What must a consent notice contain under the DPDP Act? 

Under Section 5, the notice must itemize each personal data type and its specific processing purpose, explain how data principals can exercise their rights, and explain how they can complain to the Data Protection Board. It must be in clear and plain language, presented before or at the time of requesting consent.

How does consent withdrawal work under the DPDP Act? 

Section 6(4) gives every data principal the right to withdraw consent at any time, with the withdrawal mechanism being as easy as giving consent. Upon withdrawal, the enterprise must cease processing the relevant data and delete it, unless another law requires retention.

What is a Consent Manager under the DPDP Act?

Section 6(8) introduces Consent Managers, registered intermediaries that enable data principals to give, manage, review, and withdraw consent across multiple enterprises through a single interoperable platform. Enterprises will eventually need API-accessible consent systems to integrate with this framework.