DPDP Act 2023 Section 6 Consent: Free, Specific, Informed, Unconditional and Unambiguous

Under the Digital Personal Data Protection Act, 2023, Section 6 demands strict conditions for valid consent. The Data Principal must give consent that is free, specific, informed, unconditional, and unambiguous. A clear affirmative action is required. This rule establishes a hard baseline. A business collects only the personal data strictly necessary for a stated purpose. Section 4 limits processing to lawful purposes based on this consent or specific legitimate uses. Startups can no longer bundle unnecessary data requests to gate software access. If an app requests irrelevant personal details, the consent fails the Section 6 standard entirely.

For Seed and Series B founders, this standard dictates product user interfaces and enterprise sales cycles. Pre-ticked boxes fail the DPDP Act test. Bundled permissions fail the test. With 246 days remaining until the 13 May 2027 compliance deadline, engineering teams face a strict requirement to overhaul data collection flows. Founders need verifiable consent records to clear investor due diligence. Enterprise security questionnaires ask directly about consent logging practices. A failure to show distinct affirmative opt-ins stalls procurement.

Section 6 forces strict limitations on data collection logic. The Act provides an explicit illustration involving a telemedicine application. A user downloads the application and faces requests for two separate items. The app asks to process personal data for telemedicine services. It also asks for access to the mobile phone contact list. The law intervenes here. Because a phone contact list has no necessity for telemedicine services, valid consent covers the telemedicine data only.

Each adjective in Section 6 maps to a technical requirement. Free means the user has a real choice. They face no penalty for declining optional data fields. Specific requires the consent request to map exactly to one data category and one defined purpose. Informed connects directly to Section 5. A notice must accompany or precede the consent request. This notice details exactly what data you process and why you need it. It also explains how the user can make a complaint to the Data Protection Board.

Unconditional prevents service gating. You cannot lock core product features behind a demand for unrelated personal data. Unambiguous requires a distinct affirmative action from the Data Principal. This bans passive acceptance completely. Implied agreement through continued website navigation violates the statute. Pre-checked boxes carry no legal weight. The user must actively click, swipe, or toggle to accept the defined data processing purpose.

The DPDP Rules, 2025 define the mechanics of presenting these requests. A single massive terms of service document fails to provide lawful consent. The Rules mandate itemised notices. Data Fiduciaries must present clear information before asking for the data. Businesses face an obligation to offer this notice in English and the 22 languages specified in the Eighth Schedule to the Constitution. Building multi-language delivery systems requires immediate engineering bandwidth.

Enterprise deal unblocking depends heavily on these verifiable records. When a corporate client deploys your software, they act as the Data Fiduciary. Your startup acts as the Data Processor. The enterprise buyer audits your platform heavily. They verify you capture precise consent logs. Corporate procurement needs the exact timestamp and the specific notice version presented. They also check the context of the user action. If your software lacks this structured audit trail, procurement teams block the deal.

Fixing your consent architecture requires a systematic approach across your product.

1. Map existing data collection points across the application and website. Document every form, popup, and API that ingests personal data.

2. Unbundle your permissions. If your software requires an email address for account creation and a phone number for marketing, separate these into distinct actions.

3. Deploy an itemised Section 5 notice before the consent event. State the exact data and purpose plainly. Avoid legal jargon entirely.

4. Remove all pre-ticked checkboxes. Redesign the interface so the Data Principal performs a definitive action to opt in.

5. Store consent logs as structured data. Record the notice version, the date, and the specific affirmative action taken.

Section 5 details the precise components of the required notice. The Act uses a bank account illustration to clarify this duty. An individual opens a bank account using a mobile application. The bank requires a live, video-based customer identification process to meet Know-Your-Customer laws. The bank must accompany this request with a clear notice. This notice explains the processing of personal data for the KYC purpose. It also provides instructions on how the user can exercise their rights under Section 6 and Section 13.

Founders often assume data collected before the DPDP Act avoids the new rules. This is a severe miscalculation. The Act requires Data Fiduciaries to send a new, itemised notice to Data Principals who gave consent previously. You must evaluate whether past agreements meet the new strict standards. Many legacy flows relied on bundled terms. A due diligence checklist will explicitly ask for your mechanism to track notice delivery to legacy users. If you cannot produce these logs, the valuation of the company takes a direct hit. Investors know that non-compliance carries penalties up to 250 crore rupees.

Another frequent error involves building complex consent flows for every data interaction. Section 4 states a person may process personal data for a lawful purpose based on consent or certain legitimate uses. Section 7 details these legitimate uses. A business does not need consent for specific scenarios like responding to medical emergencies or processing data for employment purposes. Identify these exemptions correctly. Do not force user opt-ins for data you process legally under Section 7.

Constructing a verifiable consent engine in-house diverts engineering focus from core product features. Developers have to build multi-language notice delivery, timestamp logging, and withdrawal mechanisms from scratch. They also need to maintain compliance with future updates to the DPDP Rules. A credible third-party solution handles these components automatically. Outsourcing this architecture gives you a verifiable posture for data privacy. Your sales team can answer vendor security questionnaires with hard evidence.

With 246 days remaining until enforcement, deploying a pre-built platform accelerates your compliance timeline. Automating your DPDP obligations preserves financial runway. It removes privacy objections during enterprise sales cycles. Verifiable consent logs prove to enterprise buyers that your software meets the strict standards of Section 6. To evaluate your current exposure and automate consent workflows, run a quick check at freescan.complydp.com.