The Complete Lifecycle of Consent: From Capture to Withdrawal
Understand how consent moves from capture to withdrawal under the DPDPA, and how organisations can manage, apply, update, and evidence Data Principal choices throughout the consent lifecycle.
Consent can change several times during a customer relationship. A Data Principal may agree to receive promotional emails, decline WhatsApp communication, update those preferences later, and eventually withdraw consent for a particular purpose. Each decision changes how an organisation should use that individual's personal data.
This is what consent lifecycle management addresses. Under the Digital Personal Data Protection Act, 2023, consent is connected to a specified purpose and, where consent is the basis for processing, the Data Principal has the right to withdraw it. For organisations working toward DPDP compliance, the practical task is to capture, maintain, apply and evidence those choices across the systems using customer data.
For Data Principals, this lifecycle answers a practical question: what happens to consent after it is given, from the moment it is collected to the moment it changes.
What Is the Consent Lifecycle Under DPDPA?
The consent lifecycle under DPDPA is the journey of a Data Principal's consent from the notice presented before collection through consent capture, recording, use, preference changes and eventual withdrawal.
A useful way to view the lifecycle is:
Notice → Choice → Capture → Record → Apply → Review or Update → Withdraw → Stop Relevant Processing → Maintain Evidence
Each stage has a different purpose. The notice provides information. Consent records the Data Principal's decision. Consent management keeps that decision connected to the relevant purpose and systems. Withdrawal changes the permission available for future consent-based processing.
Section 6 of the DPDPA states that consent must be free, specific, informed, unconditional and unambiguous, supported by a clear affirmative action and limited to personal data necessary for the specified purpose.
That makes consent lifecycle management relevant from the moment an organisation asks for your customers' consent through the point at which that consent is changed or withdrawn.
Stage 1: A Clear Notice Comes Before Informed Consent
A Data Principal needs enough information to make an informed choice before giving consent.
Under Rule 3 of the final DPDP Rules 2025, the notice is required to provide a clear account of the personal data involved and the specified purpose or purposes of processing. It must also provide a way for the Data Principal to access the Data Fiduciary's website or app and information on how consent can be withdrawn and rights exercised.
For a customer, this means the consent journey should begin with understandable questions:
What personal data is being requested?
Why does the organisation need it?
What service or use will that processing enable?
How can the consent later be withdrawn?
Where can the Data Principal exercise their rights?
For organisations, notice design is closely connected to the quality of the consent captured after it.
For a deeper explanation, see How to Build a DPDPA-Compliant Consent Notice: Language, Clarity and Opt-In Design.
Stage 2: The Data Principal Makes a Purpose-Specific Choice
Once the notice has provided the necessary information, the Data Principal can decide whether to consent.
Section 6 sets a specific standard. Consent must be free, specific, informed, unconditional and unambiguous, with a clear affirmative action. It must relate to a specified purpose and be limited to the personal data necessary for that purpose.
Consider a retail customer who provides a mobile number to receive an order update. That purpose is different from using the same number for promotional communication.
A well-designed DPDPA consent management process therefore connects a customer choice to its purpose. Different purposes may require separate choices where consent is the applicable basis for processing.
This also improves the customer experience. The Data Principal can understand what each choice controls instead of managing one broad permission covering unrelated activities.
Stage 3: Consent Is Captured Across the Customer Journey
Consent can originate through many customer touchpoints.
Depending on the business, these can include websites, mobile apps, checkout journeys, account registration, POS systems, loyalty enrolment, customer portals, call centres and messaging channels.
The challenge for consent lifecycle management is maintaining a consistent consent state when these touchpoints connect to several backend systems.
For example, a customer may provide an email marketing preference through an app while the organisation's CRM, marketing automation platform and customer service system all maintain information about the same customer.
A consent management platform can provide a central layer for capturing and managing those consent signals across connected channels. This reduces the need for individual applications to interpret customer permissions independently.
For organisations building this architecture, see How to Implement a Consent Management System Under India's DPDP Act.
Stage 4: What Should a Consent Record Contain?
A consent record provides evidence of the decision made by the Data Principal.
From an operational perspective, organisations should be able to associate the consent event with information such as:
Data Principal or customer identifier
Purpose associated with the consent
Consent status
Date and time of the event
Channel or source
Relevant notice or notice version
Subsequent preference changes
Withdrawal history
The exact architecture will differ by organisation, although the principle remains consistent: your organisation needs enough evidence to understand the current consent state and the history that produced it.
This becomes particularly relevant because Section 6 places the burden on the Data Fiduciary to prove that notice was given and consent obtained when consent is the basis of processing and a proceeding raises that question.
A consent record therefore serves both an operational and evidentiary purpose.
Stage 5: Consent Must Be Applied Where Data Is Used
Capturing consent creates a decision. Consent lifecycle management then needs to make that decision usable.
Imagine a customer has agreed to email communication and declined promotional WhatsApp messages.
That preference has limited value if the website records it correctly while an older marketing list continues to treat both channels as permitted.
A mature consent management lifecycle connects the current consent state with the systems and workflows that rely on it. Depending on the organisation, that can include CRM, marketing automation, loyalty systems, POS, customer applications and other customer engagement platforms.
This is one reason DPDP compliance involves several business functions. Legal and Privacy teams define the governance model. Technology teams connect systems. Marketing and CX teams need accurate permission states when customer communication is activated.
The lifecycle becomes operational when customer choices can influence the processing activities that depend on those choices.
Stage 6: What Happens When a Data Principal Changes Their Preferences?
Consent does not have to remain static.
A Data Principal may decide to change communication preferences or withdraw consent for a particular purpose. A preference centre or customer portal can provide a practical interface for reviewing and updating these choices.
For example, a customer may continue receiving transactional service messages connected to an ongoing service while changing a separate marketing preference, depending on the applicable basis and purpose for each processing activity.
Purpose-level management is useful here because the change can be applied to the relevant activity without treating every customer interaction as a single permission.
For organisations, preference management should therefore connect with the same DPDPA consent management infrastructure used during initial capture.
Stage 7: How Does Consent Withdrawal Work Under DPDPA?
Consent withdrawal under DPDPA allows a Data Principal to withdraw consent at any time where consent is the basis of processing.
Section 6 states that the ease of withdrawal should be comparable to the ease with which consent was given. The final DPDP Rules also require the notice to provide a link or other means through which the Data Principal can withdraw consent.
Once consent is withdrawn, the withdrawal does not make processing carried out before that point unlawful. For the affected consent-based processing, the Data Fiduciary is required to cease processing within a reasonable time and cause its Data Processors to cease as well, unless processing without consent remains required or authorised under applicable law.
The Act does not prescribe one universal number of hours or days for this reasonable-time standard. Your organisation can therefore design internal workflows that move the withdrawal through affected systems promptly and create evidence that the request was handled.
For a detailed operational guide, read When Consent Is Withdrawn: Revocation, Data Access and Customer Communication.
Stage 8: A Withdrawal Needs to Reach Connected Systems
A customer-facing withdrawal mechanism is one part of the process. The updated consent state also needs to reach the systems relying on that consent.
Consider a Data Principal withdrawing promotional consent through a preference centre.
The lifecycle may require the organisation to:
Record the withdrawal and timestamp.
Update the authoritative consent status.
Identify the purpose affected by the withdrawal.
Propagate the new state to relevant connected systems.
Stop the affected consent-based processing within a reasonable time.
Communicate the change to relevant Data Processors where required.
Retain appropriate evidence of the event and subsequent actions.
This is where a consent management platform in India can support enterprise operations. A central consent layer can help your organisation maintain a consistent view of consent and preferences across connected systems.
Stage 9: Withdrawal and Erasure Need Separate Evaluation
A Data Principal withdrawing consent and an organisation erasing personal data are connected concepts, although they should be evaluated separately.
Withdrawal changes the organisation's ability to continue processing personal data on the basis of that consent. The organisation may also need to evaluate whether the data should be erased under the applicable DPDPA provisions, while considering processing or retention that remains required or authorised under law.
This distinction matters in sectors where organisations have independent legal retention requirements.
A financial institution, for example, may need to stop a consent-based marketing activity while retaining records required under another applicable legal obligation.
The practical question after withdrawal has three parts: which processing depended on this consent, which systems perform that processing, and what data can or must continue to be retained under another applicable requirement.
That assessment keeps withdrawal aligned with both customer choice and your organisation's broader legal obligations.
Stage 10: The Consent History Becomes Part of the Compliance Record
The end of an active consent does not erase the history of the consent event.
An organisation may need evidence showing when consent was requested, which notice applied, what choice was made, when preferences changed and when consent was withdrawn.
The final DPDP Rules provide a useful regulatory signal around this concept for registered Consent Managers. Their records must include consents given, denied or withdrawn, the notices associated with consent requests and relevant data-sharing records.
A registered Consent Manager under the DPDPA is a specific statutory role and should not be confused with an enterprise consent management platform. The former acts as a registered point of contact enabling Data Principals to give, manage, review and withdraw consent. The latter is technology an organisation can use to operate its own consent processes.
Maintaining this distinction is important when your organisation evaluates DPDPA compliance software.
What Does the Complete Consent Lifecycle Look Like for a Data Principal?
From the Data Principal's perspective, a well-designed consent journey should make the status of their choices understandable throughout the relationship.
The lifecycle can be summarised as:
Understand → Choose → Give Consent → Review → Update → Withdraw
Behind those customer actions, the organisation manages another operational sequence:
Notice → Capture → Record → Synchronise → Apply → Update → Revoke → Evidence
These two journeys need to remain connected. A preference shown to the customer should correspond with the permission used by the organisation's systems.
That connection is the practical purpose of consent lifecycle management.
How OneConsent Supports Each Stage of the Lifecycle
The ten stages above share one requirement: a customer's consent decision, wherever and whenever it is made, needs to stay usable across every system that depends on it. That is the specific problem OneConsent is built to solve, rather than a general feature list layered on top of it.
At the notice and capture stages, OneConsent's purpose-based consent tools keep the notice version and the specific purpose tied to each consent event from the moment it is given, so Stage 1 and Stage 2 produce a record your organisation can stand behind later. Across the multiple touchpoints described in Stage 3, multi-channel consent capture resolves each event to a single Data Principal, so a preference set on the app and a preference set on the website do not become two disconnected records. For the record-keeping needs of Stage 4 and Stage 10, consent evidence and audit trail capabilities keep the identifier, purpose, timestamp, and notice version behind every event, ready to produce as one history rather than reconstructed from several systems.
The application and change stages, Stage 5 through Stage 8, are where consent synchronisation and Consent APIs do the connecting work: a preference update or a withdrawal propagates to the CRM, marketing automation platform, and any other connected system, closing the exact gap described when a website records a preference correctly while an older marketing list does not. Consent Lifecycle Management ties these pieces together as one ongoing process rather than a set of separate tools, so the two journeys described above, the customer's and the organisation's, stay connected in practice, not only on paper.
For organisations evaluating a consent management platform in India, the useful question is therefore broader than how the platform captures an opt-in. Teams should evaluate how the solution handles the entire consent state after capture, including changes, withdrawal, evidence and connected-system updates.
Building Consent Lifecycle Management Into DPDP Readiness
A practical review of DPDPA consent management can begin with five questions:
Can each consent be traced to a defined purpose and relevant notice?
Can your organisation identify the current consent status for a Data Principal?
Can preference changes reach the systems using that data?
Can a Data Principal withdraw consent through a process comparable in ease to giving it?
Can your Legal, Privacy or Compliance teams reconstruct the history of a consent event when required?
These questions move the discussion from consent collection toward consent lifecycle management.
For organisations preparing for the operational DPDP requirements, this provides a useful way to evaluate existing customer data workflows before selecting technology or redesigning individual consent interfaces.
Conclusion: Consent Is a Lifecycle of Customer Choices
The consent lifecycle under DPDPA follows a Data Principal's choice from the notice presented before consent through capture, recording, application, preference changes and withdrawal.
For the Data Principal, the objective is transparency and meaningful control over consent-based processing. For your organisation, the task is to ensure those choices remain connected to the purposes, systems and processing activities that depend on them.
Effective consent lifecycle management brings these two perspectives together. It gives Legal and Compliance teams stronger evidence, Technology teams a consistent consent state, Marketing and CX teams clearer permissions, and Data Principals a practical way to manage their choices.
Book a demo to see how OneConsent handles consent capture, preferences, withdrawal, synchronisation and evidence across your own compliance roadmap.
Visit OneConsent to explore the platform in more detail.
Frequently Asked Questions
Have more questions?
Search our full DPDP knowledge base for more answers.