Naavi.org

We are all aware that Cookies are hosted on websites and they collect some technical information from visitors.

Normally cookies are implanted in the user’s system through at a location assigned by the browser. It is a text file and may contain some information.

The session cookies are those files which exist during a session and are automatically cleared when the session ends. Persistent cookies are those cookies that remain in the system and are available for future reference.

When a person visits a websites, a “Cookie Consent” is taken in which normally an option is given to provide consent for “Necessary Cookies”, “Statistical Cookies” and “Marketing Cookies”. Necessary cookies are normally mandatory while others can be optional.

When the person visits the same website again, the web server checks for the existence of the cookie related to the webserver using the cookie identity. Once it is found, it may use the information there in, to record the current session as related to the previous session. The web server may keep its own record of the earlier session and therefore build a profile of the user in its systems.

Certain cookies (mostly in the category of necessary cookies) are meant only to record the operating system, the browser used which are required for configuration of the web page. If it identifies the person as coming from a mobile, it may present a compatible page to enhance the viewer’s experience. If the information picked up is IP address, it can be analysed to identify the user’s location. Based on the location of the user, the content can also be modified.

In such uses the identify of the individual may not be required and hence the information may remain technical and statistical information of the “De-identified Personal Information” category.

However it is possible that some cookies which are “Persistent Cookies” and not deleted after the session, may capture more identifiable data of the individual and store it for future use. In such cases, a question arises whether the Cookie is a “Personally identifiable information” as per the data protection laws such as GDPR or DPDPA.

If a person is normally visiting a website and does not provide any of the information such as his name, email address etc in the process, the Cookie can only access statistical and technical information. In such cases it may not be a “Personally identifiable information” . If however the web server maintains such data which is linked to some other identified data in its possession and can link the current session with the personal information already available with the server, then the cookie gathered information along with the available information together becomes personally identifiable and comes under data protection laws.

The consent to be taken by the web site therefore depends on what is the configuration of the Cookie and whether any personal data of the visitor is already with the web server and also whether the cookie is a persistent cookie or not.

If cookies are not “Secure Cookies” the data may be transferred on http connections without transit encryption.

Usually the web sites are managed by the hosting company and the data fiduciary may not have a clear understanding of what cookies are in place and what kind of parameters they collect.

Hence it is necessary for DPOs to collect this information and construct their cookie policy appropriately. In particular we need to understand if cookies collect information that are of personal nature and whether any copies of such information are stored in third party accessible systems.

Currently websites take a consent which is not specifically explaining what is the purpose of the cookie, what type of information it collects, how long it retains, how it is used etc. Hence it may be necessary to list each cookie and obtain consent for each cookie separately. The current practice of taking the consent for all cookies or for categories of cookies like functional cookies or advertising cookies etc. needs to be modified forthwith.

If DPOs donot take control of the cookies on their websites, they may be a source of concern at any point of time. Cookie Control may be simple but needs to be managed along with a periodical audit.

Naavi

Medianama, a well known website has commented on the Business Requirement Document (BRD) released by MeitY with the following caption.

“MeitY Explains How an Ideal Consent Management System Should Work Under DPDPA”

The perception has been that MeitY has actually released a guideline in extension of the DPDPA Rules on the Consent Management System more particularly for the Consent Managers.

We should however point out that this is a mis conception. The NeGD under MeitY has actually released this document to support a “Code Development Challenge” that it has floated for developing an open source recommendation for Data Fiduciaries.

“Consent Managers” who register themselves with DPB are also data fiduciaries but their requirement goes beyond managing the consent. They are an intermediary with multiple Data Fiduciaries whose services are used by data principals.

Further the BRD is a generic platform which requires to be customized by different data fiduciaries.

It is necessary to clarify the purpose of this document as otherwise there would be a difficulty for Data Fiduciaries who may think this is the final guideline from the Ministry.

“Consent” is the backbone of DPDPA Compliance. “Legitimate Use” is an exception and organizations need to cover as much of their management of Data protected by DPDPA through Consents.

As a result most companies are now struggling to trace the life cycle of their “Consent Management Program”.

Consent management program has a close association with the Data Life Cycle in an organization.

As per “Naavi’s Theory of Data”, data in an organization goes through a “Reversible Life Cycle”

The Reversible Life Cycle hypothesis of the theory recognizes that the status of Data in an organization is dynamic and starts from a No Data” status to “Data” which transforms into personal data, modified personal data, de-identified personal data, re-identified personal data etc until it is forensically erased and the storage medium returns to the “No Data” status.

When we try to identify a lifecycle for “Consent” for DPDPA Compliance, we need to recognize the birth of the Consent, its own development and extinguishing with the lifecycle of the personal data.

For example, Consent takes birth when a notice is accepted and received by the data fiduciary.

Prior to this stage, data exists in the company but not recognized as personal data. At this stage a data discovery process has to be initiated . The Consent lifecycle starts only when personal data is already there or is about to be collected.

The birth of the consent starts with the Notice. The notice itself has a generative process starting with the recognition of the need of a set of data aligned to a business requirement. In other words, Business needs data, the Tech department shows how it can be obtained and then the collection mechanism gets activated. At this stage the legal department or the DPO generates the purpose specific notice and tech department hosts it in such form that the acceptance can be provided by the data principal before it enters the production zone for usage.

This itself is a sub process which involves sending of the notice, receiving confirmation, documenting the receipt, noting rejections, request for modifications etc. If we take this into consideration, the origin of consent starts with the business division, passes through the tech and legal divisions before it lands into the Privacy division/DPO.

Once the consented data is in storage, whether it is for one time use or repeated use depends on the consent and accordingly it has to be managed. The access control, retention and deletion etc also depend on the consent and that needs to be managed. Consent is also a reference document whenever the data principal tries to exercise his rights. Consent may have to be retained even beyond the principal data itself for dispute management purpose.

In the Indian context, the consent may also be provided by a recognized consent manager and hence management of consent collection and subsequent operations has to accommodate the consent manager as a third party.

Finally when the consent expires there has to be a mechanism for removing the data from production, archive it to the extent necessary and discard it when relevant.

The Consent life cycle therefore starts with the “Drafting of the Privacy Notice” and goes through the collection, usage until expiry and disposal.

Once the personally identifiable data is irreversibly anonymised, it becomes “Non Personal Data” and goes out of the cycle. The reversible de-identification and pseudonymisation keeps the data in the status of a “Provisional PII” since they can be re-identified when required. The consent needs to support these activities. Since Consent is basically a permission to support a data processing operation, it is the purpose of consent which determines whether the data can be modified by the data fiduciary in any specific manner. If the purpose is over, the data is deleted and this deletion does not require a specific permission unless “Data Storage” itself is a service. Hence “Irreversible anonymization” is also a process which can be tagged to the completion of the purpose.

De-identification or Pseudonymisation for security purpose is also considered part of the permissions. “Disclosure of pseudonymised personal information” may not be strictly within the permission for processing and has to be handled with care.

In certain cases the data may belong to more than one individual and may also be a transactional data on which the data fiduciary also has a stake. In such cases the purpose closure needs to be recognized only when all the owners have indicated closure of their respective stakes.

Consent management process therefore needs to take note of all these complications.

Naavi

The stampede that occurred in Bengaluru during the celebrations of RCB’s IPL victory was very tragic both from the point of view of the losses suffered by the victims and also the scar it left on a sweet moment. In 24 hours the fortunes of RCB came down from the top of the world to the depths of the ocean.

It is now time to reflect what went wrong and how did the Police officers and RCB officials were made immediate scapegoats with further risk hanging against KSCA officials.

It must be remembered that the as per the reports, Police had denied the permission for the event. Whoever went ahead with the event had over ruled the official police denial of permission with their oral instructions. I heard some where that there was an oral permission to continue with the event. But this cannot be accepted since it was a “Deemed Permission” by the CM/DyCM/Home Minister who all participated in the event and the DyCM even went around the city with the RCB flag and lifted the trophy as if he was the manager of the team.

While everybody knows that when the political leaders want to conduct the event, neither the Police was in a position to put their foot down nor RCB/KSCA was in a position to refuse. It would have been considered as insubordination and consequences would have followed.

We the Corporate managers are in such situation many times and we need to draw lessons that we can apply in our work environment.

Lessons for the Police

Police force consists of educated IPS officers but often they are spineless followers of the instructions of the political bosses.

We know how a BJP leader was treated by the Police recently in Belagavi. We know how police withdraw cases against terrorists because the political establishment wants it. This tendency of so called professional IPS officers to toe the line of the political bosses without any respect for their profession is well known.

Public therefore will consider that even in this case, the police officers who were suspended for no fault of theirs deserve the punishment.

Police could have requested the CM office to send a fax/email confirmation granting permission before proceeding with further arrangements. Until such time, the team should have been confined at the HAL airport and if necessary should have been sent back to Ahmedabad. But they did not have the guts to stand on their earlier decision and capitulated to the political will. This is the lesson for the professionals not to trust the political bosses and always insist on written instructions in such cases.

Lessons for the RCB/KSCA

If we consider RCB/KSCA as corporate entities, the denial of police permission was critical and they should have refused permission for the use of the stadium. At best they could have attended the Vidhana Soudha event as guests and went home. KSCA is not obliged to RCB to provide its ground and should have refused to allow the event without payment and without police permission in writing with one of the office bearers of KSCA.

RCB is a marketing driven organization and marketing personnel often have no respect for law and compliance.

The RCB legal compliance team should have intervened and said that the risk of holding the event without police permission is possible arrest of its executives and prosecution. I can imagine that no body in RCB would even consult or listen to the legal counsel and hence they had no hand in approving the conduct of event over ruling the non compliance of the legal requirements.

Both Police as well as RCB/KSCA should realize that their trust in politicians was misplaced and they are paying the price for the same. The Courts have come in now and would consider the concept of “Deemed Permission” when the Home Minister/DyCM/CM are themselves participants of an event for which written permission was not available.

If the High Court takes the right decision, this should at least embolden the future police officers to remain more professional than they otherwise are.

As regard the public, we are all aware that RCB has Bengaluru only in name. In its character or composition, there is no “Bengaluru” or “Karnataka” . They have never encouraged local talent and have specifically avoided bidding for eligible local players in the auction. Our stars like K L Rahul, Karun Nair, Prasidh Krishna are in other teams. There was therefore no reason to celebrate its victory in Bengaluru with such fervour.

However, our deep condolences to the family members of the victims who are the real losers in this episode, having lost their loved children. May God give them the strength to bear the loss.

Naavi

While every body is waiting for the notification of the DPDPA 2023, the Government has released a document titled “Business Requirement Document for Consent Management under DPDPA 2023” under the banner of NeGD.

It appears that this is an advisory issued by the MeitY to the industry on how they can approach the Consent Management for compliance of DPDPA 2023. It is not clear why the Government is coming up with such an advisory].. [Ed:.refer PS below]

The document outlines the objectives and functionalities of a platform designed to align with DPDPA 2023. Perhaps the Ministry wants to host the platform itself to be of assistance to not only the data fiduciaries in the Government sector but also to the private sector. Perhaps this is an attempt by the Government to become a software solutions provider.

If the Government comes up with its own platform, other private sector solutions providers will face a significant competition in terms of pricing and perceived “Deemed Compliance benefit” if they host their consent management system on this platform.

It is also not clear if this platform can be adopted by “Consent Managers” who accredit themselves with the DPB. If so, the Consent Managers may provide the platform as a service and either let the users manage the data by themselves or provide the service as a complete service along with data management by itself.

Now that Government has owned a document of this nature, the architecture provided here becomes a Government’s own suggestion and any body who is using the platform as suggested will be “Deemed” to be in compliance of DPDPA 2023. It is difficult to argue that MeitY is different and NeGD is different and hence this is CMS system cannot be considered as a “Deemed” compliance. Only time will tell if Courts accept such artificial division.

Through this document, the Government is itself owning the responsibility to drive the community towards compliance. In case there is any deficiency in compliance arising from an improper implementation of the Business Requirement Document (BRD), the data fiduciaries will argue that this is the approved process by the Government. Whether this was desirable or not is a matter for discussion at some point of time in the future.

It is expected that this platform would be considered as a standard platform for Consent Manager accreditation and all those who are likely to take up the responsibility as a Consent Manager will adopt it for easy clearance of their application with DPB. CERT-IN itself would be the auditor for the platform as presented and other auditors need only to make some peripheral checks.

The BRD defines the functional requirements of a platform for managing the “Consent” for Personal Data under DPDPA 2023. It includes a detailed breakdown of core modules such as Consent Lifecycle Management, User Dashboard, Notifications and Grievance Redressal Mechanisms. Additionally, the document outlines administrative capabilities, including user role management and data retention policy configuration, to ensure operational efficiency and compliance.

Three objectives have been defined for the CMS namely

1. Enable Comprehensive Consent Lifecycle Management
2. Empower Data Principals
3. Ensure Compliance with DPDP Act and Rules

The document recognizes three stakeholders namely the Data Principal, Data Fiduciary and the Data Processor. Surprisingly the document states that the fourth stake holder is the DPO who acts as the primary compliance authority to oversee the adherence to the DPDPA 2023.

Judging the words used in the DPDPA draft Rules of January 2025, there was a doubt whether the DPO’s role would be limited to “Answering questions from the Data Principals”. This document clarifies that DPO is responsible to oversee the Compliance in an organization.

Six functional requirements have been identified namely,

1.Consent Collection

2.Storing Consent

3.Managing Consent

4.Consent Validation

5. Consent Renewal and

6. Audit Logs

The DGPSI system with its “Process based approach” is well suited for the requirements listed in the para 4.1.1. on consent collection. The suggestion specifically mentions that there should e no “Bundled Consent” and consent request has to be triggered when the service request is initiated. (Not earlier). It also specifies that “Consent Notice” specific to the purpose shall be displayed. The need to have multiple notices has been a bone of contention with organizations who are today accustomed to one comprehensive Privacy declaration for all present and future purposes anticipated.

The BRD ignores the need for Digital signature for the consent to be treated as an enforceable agreement. The BRD seems to be validating the “Click Agreement” which is ulra-vires the ITA 2000.

The document also seems to have ignored the parental consent requirement in case of minors or request for nomination.

The use cases referred to has not considered the “Consent Manager” as a stake holder and there would be a use case where consent is provided to the Data Fiduciary not by the Data Principal but by the Consent Manager though the request is triggered by the Data Principal.

The Consent Validation system as suggested is interesting as it prescribes a validation every time a certain data set is processed. When the same data is processed over a period multiple times, it means that validation is required repeatedly. This would introduce some complications.

The Consent update system needs to take note of disagreement if any between the Data Fiduciary and the Data Principal regarding the update.

Consent Expiry and Consent Withdrawal needs to take into account the validation and archival if required.

There is a special mention of the Cookie Consent which has not recognized the possibility that cookie information may actually be not an “Identifiable Personal Data” or “Personal Data to which DPDPA is applicable”.

A Consent notification and user notification module has been indicated which may require some elaboration.

A mention has been made on the Grievance Redressal Mechanism which is a system outside the core Consent collection, storage and retrieval system.

A mention has also been made about the Data Retention system which also is an additional sub system to be managed.

Overall, the document is a good starting point for the technical developers who were completely clueless on how to proceed. But there will be requirement of many improvements which needs to be configured.

It is interesting to observe the reaction of the community to this document and whether this will be considered as a template for architecting the consent management system.

Naavi

P.S: This is to clarify that the above document is being released as part of the initiative of NeGD to develop an open source platform for Consent Management. NeGD is in the process of organizing a “Coding Challenge” to develop the architecture and an operative platform code that can be shared on open source basis with MSMEs. Consequently the above post may kindly be read in this context. The document is not as an “Advisory” but a working document for the coding challenge. We regret the mis-understanding.

Also refer MeitY Startup hub for more details

7th June 2025

Organizations use “Brand Building” for two purposes.

The first is to inculcate a “Brand personality” within the network of organizations associated with a brand. When a company states that it is a “Godrej” or “Tata” or “Birla” Company, or belonging to “Apollo”, “Reliance” group, it reflects certain personalities associated with the philosophy of the brand. This is for internal structuring of a company and development of internal policies of management.

The second purpose is to derive benefits of the brand association in marketing of the products. Here the brand will influence the purchase decisions of the consumer since he associates the prominent brand personality perception with the product. It could be related to the reliability of the product, quality, integrity etc.

Whether the brand architecture is constructed as “House of Brands”, “Endorsed Brand”, “Sub Brand” etc the consumer is expected to infer the product benefits from the qualities perceived in the associated brand.

Marketing as a profession always tries to take positive aspects of the brand association and use it as a promotion. In the process it does not give much consideration to the possibility of “Mis-representation”. In many of the consumer product companies, “Marketing” is the most powerful division and every other department whether it is Finance or Information Security or Privacy, it has to toe the line set by the Marketing division.

In such a context, the DPOs trying to remain compliant with DPDPA will face a huge challenge.

Many times Brands are shared with competing downstream entities with their own service capabilities. Some sub brands may be better than others and unless the consumer has the clarity that he is taking the service from the sub brand and not from the main umbrella brand, there is an open invitation for litigation if things go wrong.

There are some extreme situations such as when an Indigo passenger finds a cockroach in his food, or a Zomato employee is found earing into the parcels, or a Zepto warehouse is found unhygienic, or an RCB event results in a stampede, the stigma getting attached to Indigo or Zomato or Zepto or RCB as a brand. Some of this may be a result of negligence in imparting the brand values and some may not involve any such negligence. The damage in terms of perception is however real.

When there is a positive rub off of the brand on the product sales, every one is happy. But when there is a negative impact, litigations will follow and most of the time, litigation is on the main brand for their negligence.

When it comes to collection of personal data and processing under different data protection laws, a question will arise about the responsibilities of the Umbrella brand owner and the sub brand user.

DPDPA presents a tough challenge in this context compared to other laws like GDPR.

The reason is that DPDPA expects the “Personal Data Collector” as a “Data Fiduciary” with a duty to take care of the Privacy rights of the data principal. Under GDPR, the “Data Controller” has a lower responsibility since his compliance ends with presenting a “Transparent” privacy policy. The Data Fiduciary under DPDPA however is required to ensure that there is no misrepresentation and there has to be a privacy notice and associated consent forming a valid “Contract” which can be used in future litigation.

The dilemma of companies is to decide

a) Whether my company is a significant data fiduciary because I am part of the brand which is a significant data fiduciary?

b) Can I declare myself a “Data Processor” instead of a “Data Fiduciary”

c) What is the level of disclosure I have to maintain with the consumer if I am sharing the personal data with my brand owner for purposes not related to what I have collected it for.

d) How will a Consumer Activist react if there is a loss caused by me as a sub brand operator?… Will he litigate against the Brand owner because it is more useful in the Courts?

The difficulty lies both for the Brand owner as well as the Brand user since depending on the convenience, a litigant can proceed either against the Brand user or the Brand owner.

This is a matter of serious and in depth debate but under DGPSI, FDPPI adopts the principle of recognizing a “Super Data Fiduciary” who owns the brand and “Data Fiduciary” who operates under the brand as distinct from “Joint Data Fiduciary” and “Data Processor”.

The policies to be adopted, contracts to be drawn need to be tailored to the recognition of this “Status” of an organization. The DPO of the Super Data Fiduciary has to absorb certain vicarious responsibilities for managing the DPO responsibilities of individual sub brand user entities. In some cases the sub-brand entities may be “Group Companies” and amenable to oversight. But if the sub brand entities are independent companies and part of joint ventures with other super data fiduciaries, the task of the DPOs are more complicated.

FDPPI would be interested in getting the reactions of the professionals in this regard.

Naavi