DPDP Act Consent Requirements Explained

The Digital Personal Data Protection Act, 2023 establishes consent as the primary legal basis for processing personal data. Yet the DPDP Act consent requirements are significantly more demanding than what most regulated enterprises currently have in place. Banks, insurers, NBFCs, and healthcare providers that have relied on broad, bundled consent clauses buried in terms and conditions are facing a structural gap between their existing mechanisms and what the law now demands.

This gap is not merely a legal technicality. It creates operational exposure, regulatory risk, and potential enforcement action once the Data Protection Board becomes active. Understanding the precise contours of valid consent, and where your existing frameworks fall short, is the first step toward compliance.

What Constitutes Valid Consent Under the DPDP Act

Section 6 of the DPDP Act lays out five characteristics that consent must satisfy to be legally valid. Each imposes specific constraints on how regulated entities design their consent collection workflows.

Free

Consent cannot be coerced or made a precondition for accessing a service unless the data processing is genuinely necessary for that service. Consider a private sector bank that requires customers to consent to marketing analytics as a condition for opening a savings account. Under the DPDP Act, this bundling invalidates the consent entirely. The customer must have a genuine choice to refuse data processing for purposes beyond what is strictly necessary for account operation.

Specific

Consent must relate to a defined purpose. Blanket authorizations like “we may use your data for improving our services and those of our partners” fail this test. Each distinct processing purpose requires its own consent. For a general insurer processing health data for underwriting, claims adjudication, and fraud detection, these represent three separate purposes requiring three separate consent items.

Informed

The Data Fiduciary must provide clear information about what data is being collected, why it is being processed, and how the Data Principal can exercise their rights. This information must be presented in plain language, available in English or any of the 22 languages specified in the Eighth Schedule. A notice buried in a 40-page PDF policy document does not meet this standard.

Unconditional

Consent cannot be tied to conditions that are unrelated to the processing purpose. Offering a discount or benefit in exchange for consent to unrelated data processing introduces conditionality that undermines the validity of consent.

Unambiguous

Consent must involve a clear affirmative action. Pre-ticked checkboxes, silence, or inactivity do not constitute valid consent. The Data Principal must actively opt in, and there must be a clear record demonstrating that they did so.

These five requirements, taken together, represent a significant departure from the consent practices prevalent across Indian regulated industries. The obligations placed on Data Fiduciaries under the DPDP Act extend well beyond simply collecting a signature or click.

Consent for Existing Data: The Deemed Consent Provisions

One of the most operationally complex questions facing regulated entities is what happens to personal data already collected before the Act comes into force. Section 5(2) addresses this through the concept of deemed consent, but its applicability is narrower than many compliance teams assume.

The Act provides that personal data processed before its commencement may continue to be processed if the processing was for the same purpose for which it was originally collected. However, the Data Fiduciary must still provide a notice to the Data Principal as soon as reasonably practicable, informing them of the processing and their right to withdraw consent.

Consider a large NBFC with a customer base of 15 million accounts. Each account was opened under varying terms and conditions over the past decade. Some customers consented to broad data usage, others to narrow purposes. The NBFC must now map its existing data processing activities against the original collection purpose for each customer segment, identify gaps, and issue notices. For processing activities that go beyond the original purpose, fresh consent must be obtained.

This creates three structural challenges that most compliance functions are not equipped to handle. First, historical consent records may be incomplete or poorly documented. Second, the mapping between current processing activities and original collection purposes requires cross-functional coordination between legal, technology, and business teams. Third, the volume of notice and re-consent requirements may be enormous, requiring systematic workflows rather than ad hoc outreach.

Legitimate Uses Without Consent Under the DPDP Act

The DPDP Act recognizes that not all processing requires consent. Section 7 provides for “legitimate uses” where processing is permissible without the Data Principal’s explicit consent. Understanding these provisions is critical for regulated entities to avoid over-reliance on consent (which creates withdrawal risk) and to correctly identify processing activities that have an alternative legal basis.

For BFSI entities in particular, the “legal obligation” basis is significant. RBI’s Master Direction on KYC, SEBI’s cybersecurity reporting requirements, and IRDAI’s data submission mandates all constitute legal obligations that do not require separate consent. However, the key distinction is that the legal obligation must be precise and specific. A general regulatory expectation to “maintain good data governance” does not constitute a legal obligation for the purpose of Section 7.

The practical implication is that regulated entities need a clear mapping of their processing activities against both consent and legitimate use bases. Activities relying on legitimate use must be documented with the specific legal provision that supports them. Activities requiring consent must meet the full Section 6 standard. This mapping exercise is foundational to any compliant data protection framework.

Consent Withdrawal and Its Operational Impact

Section 6(4) grants every Data Principal the right to withdraw consent at any time, with the same ease with which consent was given. This provision creates significant operational challenges for regulated entities whose processes are deeply intertwined with ongoing data processing.

Consider a mid-sized insurance company that uses customer health data for three purposes: underwriting (legal obligation under IRDAI guidelines), personalized wellness recommendations (consent-based), and aggregate analytics for product development (consent-based). When a policyholder withdraws consent, the insurer must immediately cease processing for the two consent-dependent purposes while continuing processing for the legitimate use purpose. This requires granular, purpose-level data processing controls that most legacy systems simply do not support.

The withdrawal must also be operationally simple. If consent was collected through a mobile app with a single tap, withdrawal must be achievable through an equally straightforward mechanism. A process that requires the customer to visit a branch, submit a physical form, or navigate a complex IVR system will not satisfy the “ease of withdrawal” requirement.

The consequences of withdrawal add another layer of complexity. Section 6(5) clarifies that withdrawal does not affect the lawfulness of processing that occurred before the withdrawal. However, the Data Fiduciary must cease processing and, unless retention is required by law, erase the data within a reasonable period. For banks subject to RBI’s record retention requirements, or insurers with IRDAI-mandated claim data retention periods, the interaction between withdrawal and retention obligations requires careful navigation.

Why Most Existing Consent Mechanisms Won’t Meet DPDP Act Consent Requirements

The gap between current practices and DPDP requirements is not subtle. It is structural. Most regulated entities in India have built their consent infrastructure around three patterns, all of which are inadequate under the new regime.

The Bundled Terms and Conditions Approach

A single document presented at onboarding covers everything from service terms to data processing to dispute resolution. The customer signs once, and this signature is treated as consent for all data processing. Under the DPDP Act, this fails the “specific” requirement. It likely also fails the “informed” requirement because the data processing terms are inseparable from unrelated commercial terms.

The Pre-Ticked Default Approach

Digital onboarding journeys frequently present consent checkboxes that are pre-selected, requiring the customer to actively opt out rather than opt in. This directly contradicts the “unambiguous” requirement. Even if the customer proceeds without unticking, no valid consent has been obtained.

The All-or-Nothing Approach

Many regulated entities present a single consent mechanism that covers all processing purposes. The customer either consents to everything or cannot access the service at all. This fails the “free” requirement whenever the bundled purposes include processing that is not necessary for delivering the core service.

The compliance gap assessment for most banks and financial institutions will reveal that their existing consent architecture needs fundamental redesign, not incremental adjustment. A comprehensive DPDP Act compliance checklist should treat consent mechanism redesign as a priority workstream alongside notice management and data principal rights implementation.

Building a Consent Framework for Regulated Entities

A compliant consent framework under the DPDP Act requires deliberate architecture across legal, operational, and technological dimensions. The following components are essential for regulated enterprises.

Purpose Mapping and Granularity

Every data processing activity must be mapped to a specific, articulated purpose. Purposes must be granular enough to allow meaningful choice. “Marketing” is not a single purpose if it encompasses SMS campaigns, email personalization, third-party data sharing, and behavioral profiling. Each distinct processing operation that serves a materially different interest requires separate consent.

Notice Design

Notices must be clear, standalone, and presented at the point of consent collection. They must explain the data being collected, the purpose of processing, the identity and contact details of the Data Fiduciary, and the Data Principal’s right to withdraw. For entities operating across multiple languages and customer segments, this requires a systematic notice management capability rather than one-off document creation.

Consent Collection Infrastructure

The technical infrastructure must support granular, purpose-level consent collection with clear affirmative actions. It must record the timestamp, version of the notice presented, the specific items consented to, and the channel through which consent was obtained. This record becomes critical evidence during regulatory audits or enforcement proceedings.

Withdrawal Mechanisms

Withdrawal must be as easy as collection. If consent was collected digitally, withdrawal must be available digitally through the same channel or one of equivalent accessibility. The withdrawal must propagate across all systems processing data for that purpose within a defined timeframe.

Integration with Regulatory Obligations

The consent framework must account for processing activities that continue on a legitimate use basis even after consent withdrawal. For banks navigating DPDP compliance, this means clearly delineating which processing activities are consent-dependent and which rest on RBI regulatory mandates. The framework must handle scenarios where the same data is processed for multiple purposes under different legal bases simultaneously.

Audit Trails and Evidence Management

When the Data Protection Board evaluates whether consent was validly obtained, the burden falls on the Data Fiduciary to demonstrate compliance. This requires comprehensive, tamper-evident records of every consent transaction, including the exact notice shown, the affirmative action taken, and any subsequent modifications or withdrawals. Managing this evidence at scale, across millions of customer interactions, demands purpose-built infrastructure.

Platforms like eQomply provide the evidence management and compliance tracking architecture that makes this operationally feasible. When consent records must be retrievable across multiple regulatory contexts, including RBI inspections, SEBI cybersecurity audits, and Data Protection Board inquiries, a centralized, auditable compliance infrastructure eliminates the fragmentation that creates enforcement risk.

Moving from Gap to Framework

The DPDP Act consent requirements represent a fundamental shift in how regulated entities must approach data processing authorization. The transition from broad, bundled consent clauses to granular, purpose-specific, freely given, and easily withdrawable consent is not a minor update to privacy policies. It requires rethinking consent architecture from the ground up.

For compliance leaders at regulated enterprises, the immediate priorities are clear: conduct a gap assessment against the five validity requirements, map processing activities against consent and legitimate use bases, design withdrawal workflows that meet the “ease” standard, and build evidence infrastructure that can withstand regulatory scrutiny.

The enterprises that treat this as a document revision exercise will find themselves exposed when enforcement begins. Those that build systematic, auditable consent frameworks will have both regulatory resilience and the operational clarity to adapt as the Data Protection Board issues guidance and rules.

If your team is assessing how to structure consent management within a broader DPDP compliance program, a focused walkthrough of eQomply’s compliance infrastructure can help clarify what the operational framework looks like in practice.