As companies prepare for the full implementation of the Digital Personal Data Protection Act, 2023 (“DPDP Act”), one dimension that is frequently underestimated in this preparation is consent management. The common assumption is that a Data Fiduciary - the organisation that determines why and how personal data is processed - has fulfilled its obligation to obtain the user's consent once the user clicks 'I Agree' on the concerned privacy notice. However, that is just the start of the data journey. While technical and security controls are integral to privacy compliance, organisations must also consider how consent is obtained, managed and acted upon throughout the data lifecycle. Effective consent management moves beyond a checklist obligation of recording a person's data preferences to an operational control that determines whether those preferences are actually reflected in subsequent processing.

What exactly did the User consent to?

Section 6 of the DPDP Act requires consent to be free, specific, informed, unconditional and directly related to the purpose for which it is being given. Rule 3 of the Digital Personal Data Protection Rules, 2025 (“DPDP Rules”) requires a notice to provide sufficient details to facilitate the informed consent, including details of the personal data requested and the purposes of processing thereof. Therefore, practically, a business should be able to clearly explain at every point of the data cycle: “What did the user consent to?”

This also gives rise to a material compliance question: if data is processed after 6 months from the date of obtaining user consent, can the organisation determine whether the proposed processing activity is within the scope of what the user initially consented to?

The Ministry of Electronics and Information Technology (“MeitY) sheds light on these practical aspects through its Business Requirement Document on Consent Management (“BRD”). Consent which is recorded as a simple 'Yes' or 'No' is not just insufficient but a significant missed opportunity. For example, if a user of an e-commerce company provides an email address for receiving the online receipt of a payment made, can the company, six (06) months later, use the email address to send marketing material to the user?

To answer this, the company would need to be able to trace the consent chain back to the user, including what processing purposes the user had consented to. Therefore, it is essential that the consent data itself contains enough details to answer the company's queries. This includes metadata such as user ID, timestamp, purpose ID and consent status. This also allows the organisation to determine how the data may be used in the future.

Once the organisation knows what it is allowed to do, how does that consent information reach the systems that actually do the processing?

How does consent work across the Data Ecosystem?

Once the consent is recorded in the Consent Management System (“CMS”), it can serve as the central record of the user's consent state, which downstream systems such as a CRM or marketing platform can rely on, when determining whether proposed processing is permitted.

This brings us to a practical implementation question: how frequently should consent be validated against the CMS?

If every processing activity were to be first validated against the CMS before proceeding with the actual processing, it would cause a significant scaling challenge as it would materially delay an operation requiring processing of millions of data points. Therefore, the essential implementation question is when should the validation occur?

One approach is real-time validation - which means checking the CMS just when processing is about to occur and as opposed to synchronised consent - where the processing system receives and maintains the current consent state, rather than querying the CMS every time processing occurs. Real-time validation ensures that the processing system relies on the latest consent state but may create scalability challenges, whereas synchronised consent can support high-volume processing more effectively. However, the downstream system may temporarily operate on an outdated consent state until synchronisation occurs.

These approaches solve different facets of the same problem, yet upon applying either, the core conflict becomes how current does the consent state need to be for the processing activity in question?

To solve this, organisations need to determine the appropriate control points, frequency of consent checks and synchronisation expectations based on the type of processing and the potential risks of relying on an outdated consent state. For example, the frequency of consent validation and the speed of synchronisation may need to be different for email marketing compared to using personal data to verify a financial transaction.

The practical challenge, therefore, is not only maintaining a centralised consent record, but ensuring that the relevant consent state is consistently made available to the downstream systems. Consent-management architectures can use APIs and other mechanisms to synchronise consent information across systems, allowing processing systems to act on the applicable consent state without necessarily querying the central CMS for every processing event.

However, it is worth noting that consent itself is not static and can change when a user updates or withdraws consent. If that is the case, how is the processing system impacted by withdrawal of consent?

What happens when the User withdraws consent?

Withdrawal of consent imposes a statutory obligation on the Data Fiduciary to cease, and to cause its Data Processors to cease processing user data within a reasonable time, particularly when the user's consent is the primary basis for processing data. As with giving consent, withdrawal triggers a chain of cascading effects. For example, upon a user withdrawing marketing consent, the CMS changes the consent state, which has to be reflected by the CRM and then this withdrawal has to be notified to other processors who have to reflect this change in their own systems as well. The objective is to ensure that consent-based processing does not continue after withdrawal and is concluded when the CMS records withdrawal event metadata, including user ID, purpose ID and timestamp in an immutable audit log.

Notably, withdrawal of consent generally triggers an obligation on the Data Fiduciary, and its Data Processors, to erase the concerned personal data. This obligation is not absolute: it does not apply where retention of that data is necessary for compliance with another law. Consent withdrawal and data erasure are therefore closely linked but not perfectly coextensive. Additionally, it has to be ensured that consent withdrawal propagates through the entire data ecosystem, and the relevant systems are kept updated, as failure to stop consent-based processing after a withdrawal may expose the Data Fiduciary to regulatory penalties under the DPDP Act. Internationally, the UK Information Commissioner's Office similarly emphasises that withdrawal of consent must have practical consequences for an organisation's processing, rather than merely being recorded as a change in consent status.

What should organisations be able to demonstrate?

Essentially operationalising consent requires the organisation to demonstrate that a user's consent choice is being reflected across the data ecosystem. Therefore, organisations should be able to sufficiently answer the following;

1. What did the user consent to?

2. Which systems and processors rely on that consent?

3. How current is the consent state being relied upon?

4. What happens when the user changes or withdraws consent?

5. Can the organisation demonstrate that these consent decisions were recorded, propagated and acted upon?

The capacity to answer the above questions by reviewing its data lifecycle, supported by evidence, is what converts consent from a checkbox to an operational control.

Managing and operationalising consent is not merely passive recording of a user's consent choice but allowing those choices to actively shape the processing activities of the organisation. Through these practices, consent becomes an operational control influencing the data lifecycle. As the Data Protection Board of India begins its enforcement journey, its early focus is likely to be on whether Data Fiduciaries can demonstrate that user consent choices are being consistently reflected across their data ecosystem. Organisations that treat consent management as an operational control today, rather than a compliance formality, will be better placed to meet both the letter and the spirit of the emerging regulatory posture.

Authors are advocates practicing in Delhi. Views are personal.