Naavi.org

The Air India crash has a distinct signature of what experts call as a near improbable total two engine failure. However this also significantly increases the possibility of an “Electronic Sabotage” which could have caused the fuel cut-off or hydraulic failure etc which the experts indicate as a possible reason.

Though Air India is no longer a national carrier and is as much private as any other airline, the perception is that its reputation good or bad is linked to the reputation of India. Hence the enemies of India both within the country or outside target the airline to indirectly bring down the reputation of Air India. Hence Air India faces an “Enemy Risk” which other airlines donot face.

Since today’s aircrafts are all controlled by electronics, the safety of the aircraft is very much dependent on the safety of the electronic systems just like controlling a large computer network. It appears that there needs to be a CISO for every aircraft.

The more we think Air India is the nation’s pride, the more attention we would attract of Pakistani terrorists.

One of the Risk management strategies for the airline now is to change its name though it would be a sad decision to take.

Naavi

In an interesting decision of the UP State Consumer disputes redressal Commission, WhatsApp has been considered as a “Paid Service” with the payment having been received in the form of personal data shared by the account holder.

(Refer: article the420.in)

Naavi has been advocating the “Data Valuation” as one of the essential features of Data Management in a company and valuing of data and its disclosure is a recommended procedure under the DGPSI (Data Governance and Protection Standard of India) framework of compliance.

The exact value of the data may be under dispute but the fact that data has a a value is indisputable. In this case, the value of the data has not been specified in rupee terms but whatever is the benefit used by WhatsApp is to be treated as the consideration passed.

Hope Income Tax and GST is not applicable !

Naavi

For a long time there has been a discussion on whether the computer systems of an aircraft can be manipulated through external interference.

The tragic Ahmedabad plane crash will revive this discussion since there are certain indications of the possibility of such sabotage.

Apart from the social media watchers who are revealing some earlier X posts to suggest a terror plan, astrological analysis of the event also indicate the possibility of sabotage.

It is time the technical concerns, media concerns and astrological concerns may all be put to test with the investigations of the crash.

Let’s us watch the developments.

Naavi

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