This article is part of a series on the operational impacts of India's DPDPA. The full series can be accessed here.

Published: July 2024

Contributors:

Raktima Roy

Navigate by Topic

Since the August 2023 enactment of India's Digital Personal Data Protection Act, all sections of industry have been working to establish compliance mechanisms and strategies. Under the newly constituted government, Union Minister for Railways, Communications, Electronics and Information Technology Ashwini Vaishnaw has stated subordinate legislation, in the form of rules, is almost finalized and will soon undergo industry consultation.

Once the law is declared to be in force, a new category of entities, known as consent managers, is poised to enter the market to help companies fulfill DPDPA obligations.

Defining consent managers

The DPDPA defines consent manager as a single point of contact to enable data principals — the users of a service — to give, manage, review and withdraw consent for personal data processing, through an accessible, transparent and interoperable platform. Consent managers are to be registered with the Data Protection Board of India, a new oversight body established under the law.

The DPDPA requires the data principal's consent to be free, specific, informed, unconditional and unambiguous, with clear affirmative action. It should signify an agreement to the processing of personal data for a specified purpose and be limited to personal data that is necessary for the purpose.

In the Srikrishna Committee Report of 2017 — one of the first guiding documents that informed the DPDPA — consent managers were envisaged as trusted intermediaries between users and businesses, operating a "dashboard" enabling users to choose consent preferences for various data types from a menu of options.

We can consider an example of how this would work. A user signs up with a company that is registered as a consent manager and sets their default data collection preferences. When a new company seeks to collect a set of the user's personal information, the consent settings they chose with the consent manager would be the default. This is designed to reduce consent fatigue while giving users more control over how their data is shared.

Responsibilities and oversight

Consent managers are required to be accountable to the data principal and to act on their behalf. Every consent manager is required to register with the new board, which will prescribe the technical, operational, financial and other conditions of its operation.

Consent managers should also provide data principals a way to redress complaints. The board can investigate failures to offer redress and impose penalties on the consent manager. Thus, companies planning to provide these services can expect to be heavily supervised by the board.

Operational details of dashboards

The DPDPA leaves many important details to be ironed out through subordinate legislation, including the operational and technical aspects of the consent management industry.

The law states the Indian government will provide for "the manner of accountability and the obligations of Consent Manager," as well as "the manner of registration of Consent Manager and the conditions relating thereto."

Despite the law's lack of specific details, existing businesses that offer consent management solutions to businesses are gearing up to customize their offerings under the DPDPA, relying on various previously released government policy documents to get a sense of how consent managers may be expected to operate.

A policy document titled Data Empowerment and Protection Architecture, published by NITI Aayog, the public policy think tank of the Indian government, provides insight into the technical aspects of consent dashboards. It explains the consent manager would only collect "consent artifacts," meaning it would track consent preferences of the data principal regarding their personal data and not have access to any of the actual personal data.

The Srikrishna Committee report explained the plan is designed to replace costly and cumbersome data sharing practices that "disempower individuals," such as physical submission of documents, username and password sharing, and terms of service requiring blanket consent.

In the DEPA's visualization of its architecture, the consent manager sits between three separate players: the data principal or user, a company that is a data provider, and another company that is the data requester.

The data provider is an entity, like a bank or a government tax portal, that has secure access to user data. The data requester could be, for instance, a credit company that needs data to provide services to the user. The consent manager has access to the user's preferences and consent regarding data sharing.

So, when a data requester seeks access to several pieces of information, the consent manager will help secure transmission of the data for which permission is provided — through secure application programming interfaces without storing any actual data — and refuse consent for other information.

The Srikrishna Committee Report observed that a system like this would require "significant interoperability" between the consent manager and various businesses.

Current Indian ecosystem

The idea of a trusted intermediary handling consent between a user and a service provider is not new in Indian law.

Similar intermediaries, known as account aggregators, exist in the financial sector. They help users share confidential financial information with banks and other financial institutions to obtain loans and other services. The account aggregator does not collect the data, but helps transfer it through secure channels between parties, enabled through an API connection between the account aggregator and the financial institutions.

More recently, under India's Digital Health Mission, a similar consent manager framework has been proposed as a way to authorize consent-driven health care data sharing between health care providers and users.

Concerns with interoperability

While the success of account aggregators in the financial sector has encouraged replication of this model across other legal frameworks, it is worth noting the financial sector is tightly regulated in India and both the account aggregator and financial institutions are under the jurisdiction of the same regulator, the Reserve Bank of India.

The RBI publishes technical specifications for all participants of this ecosystem, including technical details of the APIs. All participants in the ecosystem build their IT infrastructure in accordance with these specifications, thus ensuring interoperability.

On the other hand, in the case of the DPDPA, the board can only specify the operational and technical requirements for the consent manager's information technology infrastructure. It does not have that jurisdiction over other players in the ecosystem. Hence, ensuring interoperability would pose a different kind of challenge.

The Indian government has experimented with building interoperable platforms in the fields of payments and e-commerce. The idea is similar: a base public infrastructure different private players can plug in to through APIs.

The government's flagship payment infrastructure company, the National Payments Corporation of India, has built the infrastructure for the Unified Payment Interface. Banks and payment apps like Google Pay have plugged into the UPI infrastructure to provide interoperable money transfer services between any two bank accounts regardless of whether a user has a particular bank account or payment app — after being mandated to do so by the financial sector regulator.

A similar effort has been made with the Open Network for Digital Commerce to get e-commerce companies on an interoperable platform so any seller on any platform — Amazon for example — can engage directly with any buyer on another platform — like Walmart. However, this project has not taken off as planned. Adoption has been a major roadblock, and the ONDC has not hit critical mass in any major Indian city.

The high adoption of interoperable platforms in the financial sector, a tightly regulated sector with one centralized regulator, in contrast with the lack of adoption in the field of e-commerce, which has no centralized regulator, might suggest it is much harder to drive adoption of a new technology on the basis of market incentives alone and without a regulator to impose technical specifications on all players through delegated legislation.

The DEPA document states it seeks to create a competitive ecosystem under the DPDPA, in which any presumably private consent manager can plug in to a network built on the public infrastructure of information providers and users without needing to set up "expensive, duplicative and exclusive bilateral data sharing mechanisms." However, it remains unclear what kind of regulatory interventions and market incentives would be needed to ensure that level of interoperability and foster a truly competitive ecosystem.

Another concern is the success of this framework depending on the level of security in the underlying public infrastructure. If this is not secure, there would be understandable reluctance to adoption by companies and users alike. It is worth noting there have, indeed, been data breaches in the past.

The way forward

Companies that act as data fiduciaries and controllers will need to focus on:

• Engaging with the board, when it is set up, to ensure subordinate regulation is well-designed and commercially feasible.
• Establishing contractual safeguards to cover any liability arising from issues at the end of the consent manager.
• Instituting mechanisms for immediate communication of any changes in consent artifacts through the consent managers, so data deletion procedures or other relevant next steps can be instituted promptly.
• Giving feedback on any mandatory integration with public infrastructure.

Companies that seek to act as consent managers should also engage with the board to ensure any technical specifications imposed are in line with commercial best practices and to ensure they are legally safeguarded from repercussions if they follow its standards. They should also confirm they do not have visibility of any personal data of users, since this can invite additional obligations.

Consent managers have proliferated across the globe for specific purposes — under the California Consumer Privacy Act in the U.S. and the EU General Data Protection Regulation for example — especially for managing cookie consent. As noted in a previous IAPP article, these are far from foolproof.

What India's DPDPA seeks to undertake is a scaled-up version of the same. While the intent to reduce consent fatigue through consent dashboards is commendable, the actual operation of this system will require well-thought-out regulations and market incentives at a scale not attempted yet in other markets.

The IAPP Resource Center additionally hosts an "India" topic page, which updates regularly with the IAPP's latest news and resources.