Introduction
DPDPA Clause 6 sets specific conditions for consent as a lawful basis for processing personal data. Consent must be free, specific, informed, unconditional, and unambiguous. It must be as easy to withdraw as it is to give. The controller must be able to demonstrate that consent was given. These are not abstract principles. Each condition maps to a specific technical requirement that a consent management system must implement.
Most organisations approaching DPDPA consent compliance are building on top of existing web forms, checkbox flows, and terms-of-service acceptance mechanisms. These capture a consent event but not a consent record. The distinction matters: a consent event is a user action. A consent record is a structured data object containing the Data Principal identity, the notice version under which consent was given, the specific processing purpose, the timestamp, the channel, and the withdrawal status. DPDPA requires the latter.
The technical gap between a checkbox and a compliant consent management system is substantial. Versioned notices that can be updated and re-served without invalidating prior consents. Purpose-specific consent records that cannot be used as blanket authorisation for all processing. Withdrawal workflows that trigger downstream processing cessation automatically. Consent audit trails that demonstrate to the Data Protection Board of India that consent was obtained in compliance with the Act.
This blog covers what each condition in DPDPA Clause 6 requires technically, how a compliant consent management system must be architected, and how Akku’s CIAM Consent Manager addresses each requirement. All clause references are drawn directly from the DPDPA and Akku’s DPDPA compliance mapping documentation.
Notice Requirements Under Clause 5
Consent cannot be valid under DPDPA without a compliant notice. Clause 5 sets the notice requirements that must be satisfied before consent is sought. The notice infrastructure is a technical prerequisite for the consent management system.
What the clause requires
Clause 5(1) requires that a notice be given to the Data Principal before or at the time consent is sought. The notice must be in clear and plain language and must specify the personal data to be collected and the purpose of processing for which consent is sought.
Clause 5(2) requires that where personal data was collected before the Act came into force without a compliant notice, the Data Fiduciary must provide a notice as soon as reasonably practicable and give the Data Principal an opportunity to withdraw consent.
Clause 5(3) requires that notices be made available in English and in any of the languages specified in the Eighth Schedule of the Constitution, giving Data Principals the option to receive notices in a language they understand.
What this requires technically
Notice versioning is the core technical requirement. Every version of every notice must be stored with a version identifier and effective date. Consent records must reference the specific notice version under which consent was given. When a notice is updated, the new version must be served to relevant Data Principals, and their consent under the new version must be separately recorded.
Without versioning, an organisation cannot demonstrate which notice a Data Principal saw when they consented. If the notice is later found non-compliant, there is no way to determine which consents were obtained under the non-compliant version. Versioning makes both notice governance and consent validity demonstrable.
Clause 5(2)’s re-consent requirement for pre-Act data creates a specific workflow requirement: identification of Data Principals whose data was collected without a Clause 5-compliant notice, delivery of a compliant notice to each, and recording of their response, whether consent, withdrawal, or no response, with timestamp.
Akku’s CIAM Consent Manager addresses Clause 5(1), 5(2), and 5(3) through versioned notice management, multi-language notice support, and structured re-consent workflow capabilities.
Consent Validity Requirements Under Clause 6
Clause 6 sets the conditions for valid consent. Each condition has a direct technical implementation requirement. A consent system that captures user agreement without satisfying all five conditions does not produce valid consent under the Act.
What the clause requires
Clause 6(1) requires that consent be free, specific, informed, unconditional, and unambiguous. Free means not bundled with other agreements as a condition of service. Specific means tied to a defined processing purpose, not a generic authorisation for all processing. Informed means given after a compliant notice. Unconditional means not contingent on anything other than the Data Principal’s own choice. Unambiguous means expressed through a clear affirmative action.
Clause 6(3) requires that consent be as easy to withdraw as it is to give. If consent is given through a single tap on a mobile interface, withdrawal must be achievable through an equivalent single action. A withdrawal process that requires contacting support, submitting a form, or waiting for a response does not satisfy Clause 6(3).
Clause 6(4) requires that where consent is withdrawn, the Data Fiduciary cease processing the personal data and, upon the request of the Data Principal, erase the data, unless processing is required or authorised under any other law. The cessation and erasure must be actioned, not only acknowledged.
Clause 6(7) requires that the Data Fiduciary maintain a record of consent given by the Data Principal. The record must be available to demonstrate compliance.
What this requires technically
Purpose-specific consent records are the technical requirement for Clause 6(1)’s specificity condition. A single consent record covering all processing purposes is not specific. Each processing purpose requires a separate consent record, allowing Data Principals to consent to some purposes and decline others. A consent management system that captures a single agreement covering all data uses does not satisfy this requirement.
Clause 6(3)’s equal ease of withdrawal requires a self-service withdrawal interface accessible through the same channel as the original consent mechanism. For mobile applications, this means an in-app withdrawal flow. For web applications, a portal-accessible withdrawal action. The withdrawal must not require interaction with a human agent.
Clause 6(4)’s cessation requirement creates an automated downstream notification requirement. When consent is withdrawn, every system processing personal data under that consent must be notified to cease processing. This notification must be automated, not manual, at any scale. Akku’s User Lifecycle Manager addresses Clause 6(6), 8(7)(a), 8(7)(b), and 12(3) through automated deprovisioning workflows triggered by consent withdrawal events.
Clause 6(7)’s record-keeping requirement is satisfied by a consent record data model that stores Data Principal identity, notice version, processing purpose, consent timestamp, consent channel, and withdrawal status and timestamp. Every update to this record must be logged with a timestamp, creating a complete consent history for each Data Principal.
Akku’s CIAM Consent Manager addresses Clauses 4(1), 5(1), 5(2), 5(3), 6(1), 6(3), 6(4), 6(7), 8(3), and 9(1) directly, carrying 19 of the 33 total DPDPA clause mappings in Akku’s compliance documentation.
Children’s Data Requirements Under Clause 9
Clause 9 imposes additional requirements for processing personal data of children, defined as individuals below the age of 18. The technical implementation requirements are specific and add a verification layer that standard consent flows do not include.
What the clause requires
Clause 9(1) requires that before processing personal data of a child, the Data Fiduciary obtain verifiable consent from the parent or lawful guardian of the child. The consent must be verifiable, meaning the system must have a mechanism to confirm that the consenting individual is actually the parent or guardian.
Clause 9(3) prohibits Data Fiduciaries from undertaking processing of personal data of children that is likely to cause detrimental effect on their wellbeing, tracking or behavioural monitoring of children, or targeted advertising directed at children.
What this requires technically
Verifiable parental consent requires an age verification mechanism at the point of data collection and a separate consent flow for Data Principals identified as children. The age verification must be capable of identifying when a Data Principal is below 18 and routing their registration to a parental consent workflow rather than a standard consent flow.
The parental consent record must capture the guardian’s identity, the verification method used, the notice version, the specific processing purpose, and the timestamp. The technical challenge is that verifiable consent requires more than a checkbox labelled “I confirm I am the parent or guardian.” The verification mechanism must provide reasonable assurance of the consenting individual’s relationship to the child.
Akku’s CIAM Consent Manager addresses Clause 9(1) through age-gated consent workflows and parental consent record management as part of its DPDPA compliance mapping.
Consent Audit Trail Requirements
The accountability principle in DPDPA Clause 8(4) and the record-keeping requirement in Clause 6(7) together create a consent audit trail obligation. The Data Fiduciary must be able to demonstrate to the Data Protection Board of India that consent was obtained in compliance with the Act for every Data Principal whose data is being processed on the basis of consent.
What the requirements mean technically
A consent audit trail is not the same as a consent record. A consent record captures the current state of a Data Principal’s consent. A consent audit trail captures the complete history of every consent event, including initial consent, updates, purpose additions, purpose withdrawals, and full withdrawal, with timestamps and the notice version applicable at each event.
This history is what makes consent demonstrable under Clause 8(4). If the Data Protection Board examines a specific Data Principal’s consent record and asks when consent was given, under which notice version, for which purposes, and whether any changes were made, the audit trail must answer all of these questions from structured data, not from manual reconstruction.
The audit trail must also be tamper-evident. A consent history that can be modified after the fact cannot satisfy a regulatory examination. Records must be append-only: new events are added, but existing records cannot be changed.
Akku’s CIAM Consent Manager produces a full consent audit trail for every consent update, covering every change in consent status with timestamp, notice version, and channel. The append-only architecture ensures that the history cannot be modified retroactively. This satisfies both Clause 6(7)’s record-keeping requirement and Clause 8(4)’s demonstrability obligation.
How CIAM Consent Manager Addresses DPDPA Clause 6 Obligations
Akku’s CIAM Consent Manager addresses 19 of the 33 total DPDPA clause mappings in Akku’s compliance documentation, covering Clauses 4(1), 5(1), 5(2), 5(3), 6(1), 6(3), 6(4), 6(7), 8(3), 9(1), 11(1)(a), 11(1)(b), 11(1)(c), 12(2)(a), 12(2)(b), 12(2)(c), 12(3), 13(1), and 14(1).
The technical capabilities addressing these clauses include centralised consent record storage with a structured data model per Data Principal per processing purpose, versioned notice management with re-consent workflow support, preference management across web, mobile, and API channels, self-service withdrawal workflows with downstream processing cessation notifications, full consent audit trails for every consent update, and Data Principal rights fulfilment workflows for access, correction, and erasure requests.
The remaining DPDPA clause mappings outside the CIAM Consent Manager are addressed by the User Lifecycle Manager for deprovisioning and erasure workflows, the access control modules for Clause 8(4) and 8(5) obligations, and the IGA module for access governance under Clause 8(4).
Diagnostic Questions
Does your current consent mechanism store a structured consent record per Data Principal per processing purpose, or does it capture a single agreement covering all data uses?
Can you demonstrate to the Data Protection Board of India, for any Data Principal whose data you are processing on the basis of consent, the exact notice version under which consent was given, the specific purpose, and the timestamp?
When a Data Principal withdraws consent, does processing cease automatically across all connected systems within the same session, or does cessation require manual intervention across system administrators?
Does your consent withdrawal mechanism require a Data Principal to contact support or submit a form, or is withdrawal achievable through a self-service action equivalent in ease to the original consent mechanism?
For Data Principals whose personal data was collected before DPDPA came into force without a compliant Clause 5 notice, has your organisation delivered compliant notices and recorded the response of each Data Principal?
CTAs
See how Akku’s CIAM Consent Manager addresses DPDPA Clause 6 requirements across consent capture, record management, and withdrawal workflows.
Book a conversation with the Akku team to assess your current consent management infrastructure against DPDPA’s technical obligations.
FAQs
What is the difference between a consent event and a consent record under DPDPA?
A consent event is a user action, clicking agree, tapping accept, or submitting a form. A consent record is a structured data object that captures the Data Principal identity, the notice version under which consent was given, the specific processing purpose, the timestamp, the channel, and the current withdrawal status. DPDPA Clause 6(7) requires that the Data Fiduciary maintain a record of consent. A database entry recording that a user clicked agree, without capturing which notice version, which purpose, and on which channel, does not constitute a compliant consent record.
Why does DPDPA require purpose-specific consent rather than a single general consent?
Clause 6(1) requires that consent be specific, meaning tied to a defined processing purpose. A single consent covering all processing purposes does not satisfy the specificity requirement because it does not give the Data Principal meaningful choice over individual processing activities. A Data Principal may be willing to consent to processing for service delivery but not for marketing communications. Purpose-specific consent records allow this granularity. They also allow partial withdrawal, where a Data Principal withdraws consent for one purpose without affecting consent for others.
What does Clause 6(3) require for consent withdrawal, and how does a compliant withdrawal mechanism differ from current practice?
Clause 6(3) requires that consent be as easy to withdraw as it is to give. If consent is given through a single tap in a mobile application, withdrawal must be achievable through an equivalent single action in the same application. Current practice at many organisations requires Data Principals to email a privacy team, submit a data subject rights request form, or contact customer support to withdraw consent. These mechanisms do not satisfy the equal ease standard. A compliant withdrawal mechanism is a self-service action accessible through the same interface as the original consent, with immediate effect and automated downstream processing cessation.
What downstream actions must a Data Fiduciary take when consent is withdrawn under Clause 6(4)?
Clause 6(4) requires that the Data Fiduciary cease processing the personal data for which consent has been withdrawn. Where the Data Principal requests it, the Data Fiduciary must also erase the data unless processing is required or authorised under another law. Technically, cessation requires automated notification to every system processing personal data under the withdrawn consent. For workforce systems, this maps to deprovisioning access to personal data processing systems. For customer data systems, this maps to suppression flags and processing cessation workflows across the data infrastructure. Manual coordination across system administrators does not scale to this requirement.
What does DPDPA require for processing personal data of children, and how does this differ from standard consent flows?
Clause 9(1) requires verifiable consent from the parent or lawful guardian before processing personal data of a child. Standard consent flows capture the Data Principal’s agreement without verifying their age or, where they are a child, the identity and relationship of the consenting adult. A compliant children’s data flow requires an age verification mechanism at the point of registration, a separate parental consent flow for Data Principals identified as below 18, a parental consent record capturing guardian identity, verification method, notice version, purpose, and timestamp, and a prohibition on processing activities likely to cause detrimental effect on children’s wellbeing under Clause 9(3).
How does the DPDPA consent audit trail requirement differ from standard application logging?
Standard application logs record system events: page views, form submissions, API calls. A consent audit trail records the complete history of every consent event for every Data Principal, including initial consent, purpose additions, purpose withdrawals, notice version changes triggering re-consent, and full withdrawal, with timestamps and applicable notice versions at each event. The consent audit trail is the evidence base for demonstrating Clause 8(4) compliance to the Data Protection Board. It must be append-only and tamper-evident, meaning existing records cannot be modified after the fact. Standard application logs do not typically have these properties and are not structured around the Data Principal identity and processing purpose dimensions that DPDPA requires.
