Tag Archives: GDPR

Territorial Applicability of GDPR

In July, 2018 and then subsequently on 24th October, 2018 the Information Commissioner’s Office, United Kingdom (“ICO”) took its first General Data Protection Regulation (“GDPR”) enforcement action against a data controller located outside the European Union (EU) against Aggregate IQ Data Services Ltd. (“AIQ”) located in Canada.

The above incident is the first example of extraterritorial applicability of GDPR, where a data controller was located in Canada but the data processing activities were targeted towards the data subjects present in EU. AIQ was monitoring the behaviour of each data subject for the purposes of targeting individuals with political advertising messages on social media and therefore the provisions of GDPR were held to be applicable. Non-European Internet-based service providers across the globe have been concerned about the applicability of GDPR.

The European Data Protection Board (“Board”) is an independent European body, which contributes to the consistent application of data protection rules throughout the European Union, and promotes cooperation between the EU’s data protection authorities.

The Board in November, 2018 issued draft guidelines (“Guidelines”) on the territorial scope of the GDPR under Article 3. Whereas the Guidelines were released for the purpose of public consultation, nonetheless the Guidelines do provide explanations on important concepts introduced under Article 3 of the GDPR which defines the territorial scope for direct application of the GDPR.

  1. Application of the ‘Establishment’ criteria under Article 3(1)

The Guidelines specify that Article 3(1) ensures that GDPR is applicable to controllers and processors individually if any one of them or both of them have an establishment in EU, and the processing of the personal data of a data subject is in the context of the activities of such establishment, regardless of the actual place of the data processing. In order to determine the applicability of Article 3 the Board recommends few norms detailed below.

‘Establishment’ in EU

It is provided that the notion of ‘establishment’ is broad and does not necessarily imply a legal personality such as a branch or subsidiary; rather it simply implies effective and real exercise of activities through stable arrangements in EU. This interpretation is in line with the interpretation of the Court of Justice of the European Union (“CJEU”) in several of its rulings.[1]

Further, it is also provided that both these factors, i.e. (i) effective and real exercise of activities and (ii) stability of arrangements should be considered in the light of the nature of economic activities and provision of the services concerned. This means that a single employee’s or agent’s presence in EU, with sufficient degree of stability maybe sufficient to consider it as an ‘establishment’. However, the accessibility of a website in EU of a non-European entity would not be sufficient to conclude that such an entity has an establishment in the European Union.

Processing of data ‘in the context of the activities of’ the establishment

The Guidelines provide that if the controller or the processor is outside EU but there exists a local establishment in EU and if the processing of the data is in the context of the activities of an establishment then the GDPR would be applicable. The Guidelines state that the activities of the local establishment in EU should be ‘inextricably linked’ to the data processing activities of the non-EU controller or non-EU processor, regardless of whether the local establishment in EU plays any role in the actual processing of the data. The Board recommends that non-EU organisations should undertake an assessment of their processing activities in the following manner:

  1. First, by determining whether personal data is being processed
  2. Secondly by identifying potential links between the activity for which the data is being processed and the activities undertaken by the organisation having any presence in EU.

Example: A website based in X country, having a local establishment dealing with marketing campaigns towards EU markets. Since the activity of the local establishment is inextricably linked to the processing of the personal data carried out by the website, Article 3(1) is applicable where the controller or the processor is present in EU.

Application of the GDPR to the establishment of a controller/processor in the Union, regardless of whether the processing takes place in the Union.

As per Article 3(1), the processing of personal data in the context of the activities of an establishment of a controller or a processor in EU triggers the application of GDPR and the related obligations for the data controller or processor concerned.

Application of the establishment criteria to controller and processor

The establishment of a controller and that of a processor must be considered separate as there are distinct obligations for controllers and for processor listed under the GDPR. The existence of a relationship between a controller and a processor does not necessarily trigger application of GDPR to both, if only one of the entities is established in EU. The two scenarios detailed below should explain the position.

  • Where processor is located outside EU and not subject to the GDPR, but the controller is present in EU: It is provided that the controller should comply with Article 28 (3) of the GDPR and ensure that the GDPR obligations are extended to the processor by the means of a contract.
  • Where the processor is present in EU and the Controller is not: Assuming that the controller is not processing data in the context of its establishment in EU, the processor alone is subject to GDPR obligations. Therefore, unless other factors are present Article 3(1) will not apply to the controller but would apply to the processor.

Further, the Guidelines provide that the EU territory cannot be used as a ‘data haven’ and the legal obligations beyond the EU data protection law, including rules with regard to public order will have to be respected by the data processor established in EU, regardless of the location of the data controllers.

  1. Application of the Targeting criterion under Article 3(2)

Article 3(2) sets out the circumstances in which the GDPR applies to a controller or processor not established in EU, depending on their processing activities.

This criterion becomes applicable in absence of an establishment of the entity in EU, if the activities of a controller or processor of the entity are related to processing of personal data of the data subjects who are present in EU. The applicability of GDPR is triggered when the processing activity is related to (i) offering goods or services to the subject or (ii) monitoring the behaviour of the subject for profiling, etc.

In order to assess the applicability the criterion, the Board recommends a two-fold approach under the Guidelines.

Data subjects in EU

It is provided that protection under Article 3(2) extends to every natural person present in EU, irrespective of their nationality or place of residence.

The requirement of the location of natural persons in EU, must be assessed when the processing activity takes place, i.e. when the offer is made or when the monitoring in undertaken as per Article 3(2) of GDPR.

It is also provided that the element of ‘targeting’ the data subjects in EU either by offering goods or services or by monitoring them is crucial and should be present for applicability GDPR under  Article 3(2). Which effectively means that, if a tourist travelling through EU makes use of an online mapping service which is available in her country and not marketed in EU and is collecting certain personal data, this act of data processing will not fall under the ambit of Article 3(2) as the services are not primarily offered to people who are using the mobile application in EU.

  1. ‘Offering goods or services’

It is provided that the trigger activity, of offering goods or services to a data subject applies irrespective of whether a payment is required to be made by the data subject for that particular good or service. Further, there should be an ‘intention’ to offer goods or services to the data subjects who are in EU. The factors that can be considered in ascertaining the intention to offer goods or service can be the language used on the website, the currency available to use while ordering from the websites, apparent mention of the offer, etc.

  1. Monitoring of data subjects behaviour

The second activity identified under Article 3(2) is monitoring of behaviour of the subject for profiling, etc. For Article 3(2) (b) to trigger the application of the GDPR, the behaviour monitored must first relate to a data subject in EU and, as a cumulative criterion, the monitored behaviour must take place within the territory of EU.

The Guidelines state that even though recital 24 relates to monitoring of behaviour through the tracking of a person on the internet, the Board considers that tracking through other types of network or technology involving personal data processing should also be taken into account in determining whether a processing activity amounts to a behavioural monitoring, for example through wearable and other smart devices.

The Board clearly mentions that ‘monitoring’ implies that the controller has a specific purpose in mind for the collection and subsequent reuse of the relevant data about an individual’s behaviour within the EU. The Board opined that any online collection or analysis of personal data of individuals in the EU would not necessarily be considered as “monitoring” and that it would be necessary to consider the controller’s purpose for processing the data and, in particular, any subsequent behavioural analysis or profiling techniques involving that data.

  1. Processing in a place where the law of the Member state applies, by the virtue of public international law – Article 3(3)

This provision is expanded upon in Recital 25 which states that “[w]here Member State law applies by virtue of public international law, this Regulation should also apply to a controller not established in the Union, such as in a Member State’s diplomatic mission or consular post.”

The Guidelines provide the following example to illustrate the applicability of Article 3(3). The Dutch consulate in Kingston, Jamaica, opens an online application process for the recruitment of local staff in order to support its administration. While the Dutch consulate in Kingston, Jamaica, is not established in the Union, the fact that it is a consular post of an EU country where Member State law applies by virtue of public international law renders the GDPR applicable to its processing of personal data, as per Article 3(3).

Designation of Representatives in EU

Article 27 provides that whenever a controller or processor becomes subject to GDPR as per Article 3(2), it has to designate a representative in EU. The Guidelines provide guidance with respect to the designation, establishment and obligations of the representative, as mentioned below.

  • Designation of the Representative

It is provided that there should be a written mandate to the representative of the controller or processor of the GDPR obligations. A representative can be legal or a natural person, who can be appointed as a representative on the basis of a contractual relationship. One person can act as a representative for multiple entities. In case of a company or any organisation – one person is to be assigned as the lead person in charge of an entity. However, the designated representative cannot be deemed to be the external data protection officer (DPO) nor does such designation qualify as an ‘establishment’ under the ambit of Article 3(1)

  • Location of the Representative

It is provided that the criterion of establishment of the representative is the location of the data subjects whose personal data is being processed and the place of processing is not relevant. It is also provided that if significant portion of the data processed is from one member state, then the establishment of representative should be in that state, as a matter of good practice.

  • Obligations of the Representative

The obligations of the controller or the processor are distinct from the obligation of the representative. The representative acts on behalf of the controller or processor. The representative shall maintain a record of the processing activities on behalf of the controller or processor. Maintenance of such record is a joint obligation, as the controller or processor should provide accurate and updated information. The representative should perform its tasks in accordance to the mandate of the controller or processor, including cooperation with the competent supervisory authorities with regards to ensuring compliance with the GDPR.

Author: Manas Ingle, Associate at NovoJuris Legal

Source:

[1] Google Inc. v AEPD, Mario Costeja González (C-131/12), Weltimmo v NAIH (C- 230/14), Verein für Konsumenteninformation v Amazon EU (C-191/15) and Wirtschaftsakademie Schleswig- Holstein (C-210/16)

Advertisements

Data Protection and the many facets of it: Inter-collegiate Essay Competition

NovoJuris Legal is proud to announce the Inter-collegiate Essay Competition on Data Protection and its various facets. 

Data Protection has taken very high importance not only in India but across the World. The Personal Data Protection Bill, 2018 (“Bill”) and the Data Protection Committee’s (“Committee”) Report (released on 27 July 2018) provides for the framework and the policymakers’ insight on protection of individual’s privacy and personal data in India. The Bill has set high expectations particularly after the European Union’s General Data Protection Regulation (“GDPR”) came into force on 25 May 2018. It is also essential to note the important judgments including the now famous “Aadhar case” of Justice Puttaswamy (Retd.) V. Union of India.

Reserve Bank of India (RBI) in April this year has mandated that all data generated by the payment systems in India, is to be stored in India. The Ministry of Health and Welfare has also published the draft legislation called Digital Information Security in Healthcare Act, to safeguard e-health records and patients’ privacy.

Thus, all these new rules/policies/regulations (collectively referred as “the Data Protection Framework”) indicate a very strong direction that the Government wishes to undertake on protection of data including but not limited to data localisation, which helps in enforcing data protection, nation’s security and protect its citizen’s data, better control on transmission of data outside the country and more.

Topics for the Essay Competition:

The following sub-themes have been identified as requiring academic consideration:

  1. General Data Protection Regulation in European Union has raised the bar on legislation on data protection across the world. Would this be beneficial or would it stunt technological growth and innovation?
  2. Is our Privacy safe under the Aadhar scheme? A critical analysis of change in the privacy law regime post Aadhar case in India.
  3. Implication and critical analysis of the Data (Privacy and Protection) Bill, 2017.
  4. Do we need a stronger consumer centric data protection law in India like the Customer Online Notification for Stopping Edge – Provider Network Transgressions (CONSENT Act), USA in the aftermath of the Facebook data breach incident?
  5. With all the industry specific regulator (RBI, TRAI, MHoW and etc.) providing various regulations, guidelines and draft policy notes with regards to Data Protection Framework in India, what do you think the outcome will be? Is India formalizing a uniform law for data protection?

Important Dates

▪ Submission Date – The essays must be submitted on or before 11:59 PM on 30 January 2019.

▪ Declaration of the Result on 31 March 2019.  – The winners of the competition shall be notified by email and by declaration of results of the competition on this website.

Details about the prizes, guidelines for submission and other details can be found here.  Intercollegiate-Data Privacy Essay-Competition-NovoJuris

 

Personal Data Protection Bill, 2018 – An overview with brief analysis

Justice BN Srikrishna Committee (“Committee”) which was formed with an intent to have a highly effective data protection law in India has finally submitted the draft bill to the Ministry of Electronic and Information Technology (“Ministry”) on 27 July 2018. The draft bill namely Personal Data Protection Bill, 2018 (“Draft Bill”) is a great expectation particularly after the European Union’s General Data Protection Regulation (“GDPR”) came into force on 25 May 2018. The Draft Bill is introduced at very important juncture, especially after recent judicial orders and judgments in the Aadhar case and in Justice Puttaswamy (Retd.) V. Union of India and Others.

Trust: The Draft Bill introduces concepts of ‘Data Fiduciary’, ‘Data Principal’ and ‘Data Processors’ are akin to concepts of ‘data controller’ and ‘data subjects’ in GDPR. The underpinnings as per Chapter 1, Part C, of the Committee report is of “trust” between a Data Fiduciary and a Data Principal.

data protection

Extra- territorial: Like GDPR, the Draft Bill provides for protection extending beyond India. Section 2(2) states that the legislation shall apply to the processing of personal data by data fiduciaries or data processors not present with in the territory of India, if they process data in connection with business in India, goods or services offered in India, profiling of data principals in India. This may not be applicable for processing anonymised data.

It is interesting to note that State as well as the private and public private sector, come within the ambit of the legislation.

Data: Data under the Draft Bill has been defined broadly to include information, facts, concepts, opinion or instructions whether processed by humans or automated means. It is not just personally identifiable information. The Draft Bill covers issues and matters relating to data protection, collection of data, storage, purpose of collection. Section 8 of the Draft Bill lays out procedure for collection of data, notice / intimation to be provided to the Data Principal (ie., the natural person’s data) while collecting any and all kinds of data.

Disclosures: Under Section 8, there are mandatory disclosures that the Data Fiduciary (ie, any person such as State, juristic entity, individual who determine the purpose and means of processing personal data), has to provide to the Data Principal for collecting the Data. Some of them are (i) the purpose for which the Data is being collected, (ii) categories, (iii) identity and contact information of Data Fiduciary, (iv) the Data Fiduciary will have to compulsorily inform the Data Controller about the right to withdraw consent, (v) Period for which the Personal Data will be retained. It is in this regard that the Data Fiduciary while collecting such Data, shall provide the information in a clear and concise manner, and this would include giving such information to the Data Principals in “multiple languages” where necessary and practicable. The use of multiple languages to provide information would aid such Data Principals who are only familiar with their vernacular language.

Storage: Section 10 has laid down that the Data Fiduciary shall retain the Personal Data only as may be reasonably necessary to satisfy the purpose for which it is processed.  Some of the fintech companies have raised a concern that they use the data collected on regular intervals to keep a track of their customers, even after the purpose is fulfilled, as part of their business offerings itself. Data storage should be read in conjunction with various legislations which provide for data retention, for example, records supporting financial statements of a company has to be retained for 8 years.

Kinds of data:

  • Personal Data;
  • Sensitive Personal Data (“SPD”);
  • Biometric Data;
  • Financial Data;
  • Genetic Data; and
  • Health data.

Section 3 (35) defines religious and political beliefs, caste or tribe, intersex status, transgender status as SPD. Even passwords, financial data and health data fall under SPD. Certain sections of the society have opined that passwords should not be part of SPD and that it is a stretch. What perhaps should be included is a higher level of protection to the Data Principal from instances of profiling, discrimination, and infliction of harm that is identity driven.

Consent: Consent forms the basis for processing Personal Data or SPD. Section 12 details the way to obtain consent from the Data Principal, no later than prior to processing. Shouldn’t it be prior to collection? Collection and processing of SPD has a higher rigour, including explicit consent to be obtained by Data Fiduciary for processing

The consent should be free, informed, specific, clear, and capable of being withdrawn.  It is crucial to note that when the Data Principal withdraws her consent, which was necessary for the performance of the contract to which the Data Principal is a party, then all the legal consequences for the effects of such withdrawal shall be borne by the Data Principal. Wouldn’t this be a burden on the Data Principal? Opinions are also raised that such consent should not be unilaterally withdrawn by the Data Principal and such withdrawal should only be permitted in the context of the Personal Data.

Further, additional grounds have been laid down for the processing of Personal Data which includes: (i) processing for the functions of the State;(ii) processing in compliance with law or any order of the tribunal; (iii) processing which is necessary for prompt action; (iv) processing for the purpose related to employment; and (v) processing for reasonable purpose. Processing of Personal Data for the purpose for reasonable purpose, as mentioned in Section 17, is a bit wide and allows the data privacy authorities to specify the purposes on which such processing can take place. This includes a broad range of activities such as whistle blowing, mergers and acquisitions, recovery of debt, credit scoring, fraud, publicly available personal data, etc. This would need a balance of a very effective right for data erasure, which is not provided in the Draft Bill.

Data Principal Rights: Chapter VI contains the rights to the Data Principal such as (i) Right to confirmation and access; (ii) Right to correction; (iii) Right to Data Portability; and (iv) Right to be forgotten. These are similar to the rights under GDPR. However, the Right to be forgotten which is provided under Section 27 of the Draft Bill only entitles the Data Principal(s) to have the right to restrict or prevent continuous disclosure of Personal Data.  The Right to be forgotten does not include within its ambit the right of data erasure, which allows the Data Principal to erase his personal data as mentioned in GDPR. On one hand, we can interpret that a Data Principal does not have a right to erasure but on the other hand, a Data Fiduciary is mandated to retain the Personal Data only as may be reasonably necessary to satisfy the purpose for which it is processed.

Transparency and accountability measures:  Ample safeguards have been provided to ensure that the Data provided by the Data Principals should be processed in a transparent manner and the Data Fiduciary be held accountable for its action. Chapter VII of the Draft Bill provides for mechanisms to ensure transparency, security safeguards, Data protection impact assessment, Data audits, record keeping, Data protection officer, etc.

Section 32 makes it clear that the Data fiduciary shall notify the Authority of any Personal Data breach where such breach is “likely to cause harm” to any Data Principal. So, the burden of proof seems to be on the Data Fiduciary which is good, so that in a large nation like India where the Data Principal may or may not be aware of her rights, this is helpful. Should the Data Principal have this right as well, along with the Data Fiduciary included in section 32?

Significant Data Fiduciaries: Based on the factors such as volume, sensitivity, turnover, risk of harm, the Data Fiduciaries are classified as Significant Data Fiduciaries. Section 38 obligates data protection impact assessment, record-keeping, data audits and data protection officer on Significant Data Fiduciaries. Some of these obligations are necessary for other Data Fiduciaries as well.

Data localisation: Section 40 mandates that every Data Fiduciary shall store the data on a server or a data centre located in India. Some of them have opined that this may lead to State surveillance. But perhaps, this may help in better control over data breaches or emboldening the steps towards artificial intelligence.

Exceptions: One of the most talked about and discussed section of the Draft Bill is Chapter IX. It relates to many exceptions to the Data Privacy obligations for the State / Government in order to protect the national security of the State.

The argument of surveillance is not new. In the year 2007 Indian Telegraph Rules, 1951 were amended and Rule 419A was inserted in the Rules. Rule 491 A was inserted so as to provide the Government with powers under the Act and the Rules to do surveillance, intercept any message and such other powers so as to safeguard the sovereignty of our country. Then in the years 2009 and 2011 respectively, under the Information Technology Act, 2000, The Information Technology (Procedures and Safeguards for Interception, Monitoring and Decryption of Information) Rules 2009 and The Information Technology (Procedures and Safeguard for Monitoring and Collecting Traffic Data or Information) Rules, 2011 were added. These set of rules, deal in depth, with how the Government can intercept, monitor and decrypt computer systems, computer networks, internet messages basically any transmission made through Internet to safeguard our country. National security, is of-course one of the primary roles of the Government.

The Draft Bill also provides wide, discretionary and unfettered powers to the Government and the Data Privacy obligations is sub-servient to the Government’s obligations of security of the State and prevention, detection, investigation and prosecution for contravention of law.

Data Protection Authority of India: The independent regulatory body for data protection, has the power to issue directions, conduct inquiry, call for information, and conduct search and seizure, monitoring and enforcement; legal affairs, policy and standard setting; research and awareness; conducting inquiries, grievance handling and adjudication.

While this is “the” legislation for Data Protection, Section 67 envisages situations of concurrent jurisdiction and provides for a consultative approach in resolving such disputes. Therefore, the Authority has to take into considerations other laws and recommendations provided by other regulators, for example, Ministry of Information and Broadcasting or TRAI (for instance the recommendation published by TRAI on Privacy, Security and Ownership of the Data in the Telecom Sector- Dated 16 July, 2018).

Grievance handling and adjudication:  The proposal of having Appellate Tribunal as a special court, is helpful in a speedy disposal of disputes. The proposal perhaps might have come by, since the Courts are already over-burdened. Every Data Fiduciary should have proper procedures and effective mechanisms to address the grievance of Data Principal which should be resolved in an expeditious manner within a period of 30 (thirty) days. It is heartening to see time-bound approach for resolving disputes.

Penalties and remedies

The Draft Bill provides for penalties which are in consonance with GDPR and the quantum of penalty acts as a deterrent to engage in wrongful acts. It should be seen over time if this deterrence is helpful in mitigating occurrences of breaches or would it increase litigation.  Penalties have been imposed on the following activities:

  • Penalty for failure to comply with Data Principal’s requests under chapter VI of the Draft Bill,
  • Penalty for failure to furnish report, information, etc.
  • Penalty for failure to comply with the directions or orders issued by the Authority
  • Penalty for contravention when no separate penalty has been provided.

Further Section 69 (1), also makes the Data Fiduciary liable if it fails to fulfil the obligations relating to taking prompt action related to data breach or undertaking a data protection impact assessment, or conducting a data audit by a significant data fiduciary or failing to register with the authority. The penalty for Data Fiduciary under this sub-section extends to Rs. 5,00,00,000/- (Rupees Five Crore Only) or 2 (two) per cent of the total worldwide turnover of the preceding financial year, whichever is higher.

Section 69 (2) makes the Data Fiduciary liable for a penalty when it contravenes of any of the requirements as mentioned under this sub-section. The penalty may extend to Rs. 15,00,00,000/- (Rupees Fifteen Crore only) or 4 (four) percent of the total worldwide turnover of the preceding financial year, whichever is higher.

Criminal liability: Not only penalties but imprisonment has also been prescribed. For instance, any person who obtains, transfers or sells personal data which is contrary to the provisions of the Draft Bill would be liable for an imprisonment of not exceeding 3 (three) years or shall be liable for a fine which may extend up to Rs 2,00,000/- ( Rupees Two Lakhs Only) or both.  Further any person who obtains, transfers or sells SPD, would be liable for an imprisonment not exceeding 5 (five) years or shall be liable for a fine which may extend up to Rs 3,00,000/- ( Rupees Three Lakhs Only) or both. There is imprisonment for a term not exceeding 3 (three) years or a fine which may extend to Rs 2,00,000 (Rupees Two Lakhs Only) or both, when any person re-identifies the Personal Data which has been de-identified by the Data Fiduciary or Data Processor or re-identifies and processes such Personal Data without the consent of the Data Fiduciary or Data Processor.

The Draft Bill has made suitable provisions whereby the company and its directors, officers, as well as Central or State Governments along with its head of departments, officers could be made liable for offences committed under this Draft Bill.

Compensation: The Data Principal also has a right to claim compensation from the Data Fiduciary and Data Processor if it contravenes with any provisions of the Draft Bill. Section 76 states that any compensation awarded or penalty imposed under this Draft Bill would not prevent the award of compensation or imposition of any other penalty or punishment under any law for the time being in force.

We have added our thoughts as we discuss the Draft Bill above. The dynamics of this digital economy are changing rapidly, people are using more and more innovative technologies to disrupt the industry and in all of this, the most crucial element is Data. It is rightly said that data is the new oil of this digital economy and therefore this much anticipated Draft Bill is, though late, a step towards regulating use of Data.

Authors: Mr. Manas Ingle and Mr. Anuj Maharana

DISHA: Data Ownership, Security, Consent for health data.

Acting on its vision for a National eHealth Authority (“NeHA”), the Ministry of Health and Welfare had introduced a draft bill for Digital Information Security in Healthcare Act (“DISHA” or “Draft Bill”).

DISHA’s main purpose, as per its preamble is to (i) establish NeHA, State eHealth Authorities (“SeHA”) and Health Information Exchanges; (ii) standardise and regulate the process related to collection, storing, transmission and use of digital health data; (iii) and to ensure reliability, data privacy, confidentiality and security of digital health data”. Our previous note on the overview of DISHA can be read here https://novojuris.com/2018/08/12/disha-the-future-direction-of-digital-health-information-in-india/). In this blog, we are covering aspects of data ownership, security, consent and others that DISHA proposes.

The Draft Bill defines digital health data as electronic data of an individual containing information about the individual’s medical records and health information and such individual would be considered as the owner of the digital health data. DISHA grants rights to owners of digital health data such as:

  1. The right to privacy, confidentiality and security of their digital health data.
  2. The right to refuse or give consent for generation and collection of digital health data by Clinical Establishments (a defined term which you can read in our previous blog here…).
  3. The right to refuse, give or withdraw consent for storage and transmission of digital health data.
  4. The right to refuse consent thereby restricting access to or disclosure of digital health data. However, it is not clear if the Clinical Establishment can still transmit under “reasonable use”, despite refusal by the data owner. It may be noted that reasonable use is used as a wide term.
  5. The right to ensure that the data collected is specific, relevant and not excessive in relation to the purpose sought.
  6. The right to know about the Clinical Establishments or entities which may have access to the data, the recipients to whom data has been transmitted or disclosed.
  7. The right to access the health data including their consent details and access of their data by any Clinical Establishment or any other entity.
  8. The right to possess the right to seek rectification of data by a Clinical Establishment in the form prescribed by NeHA.
  9. The right to necessarily mandate express prior permission before transmission or use of data in an identifiable form.
  10. The right to be notified each time their data is accessed by a Clinical Establishment.
  11. The right to ensure sharing of data with family members in case of health emergency.
  12. The right to prevent transmission or disclosure of sensitive data that may cause distress to the owner.
  13. The right to not be refused health services in case of refusal to give consent for any of the activities or data generation, collection, storage, transmission or disclosure.
  14. The right to seek compensation for damages cause as a result of breach of data.

DISHA lists down the purposes for which data is to be collected, stored, used which are:

  1. Advancement of delivery of patient centred medical care.
  2. Appropriate information for guiding sound medical decisions at time and place of treatment
  3. Improvement of coordination of care and information among hospitals, laboratories, medical professionals through an effective infrastructure for secure and authorised exchange of data.
  4. Improvement of public health activities and facilitation of early identification and rapid response to public health threats, such as disease outbreaks and bioterrorism.
  5. Facilitation of health and clinical research and health care quality
  6. Promotion of early detection, prevention and management of chronic diseases.
  7. Carrying out public health research, policy formulation, review and analysis.
  8. Undertaking of academic research and related purposes.

Under the Draft Bill the usage of personally identifiable information can be undertaken only for advancement of delivery of patient centred medical care, appropriate information for guiding sound medical decisions at time and place of treatment and improvement of coordination of care and information among hospitals, laboratories, medical professionals through an effective infrastructure for secure and authorised exchange of data to extent of ownership rights and in the best interest of the owner. The usage of data for public health related purposes shall be undertaken only after anonymisation and de-identification of data.

No data collected shall be used for any purpose other than what has been prescribed, be provided access to or disclosure of personally identifiable information without express consent of the owner or a statutory or legal requirement. The data collected shall not be used for commercial purpose or disclosed to insurance companies, employers, human resource consultants and pharmaceutical companies, irrespective of such data being identifiable or anonymised. However, the insurance companies may seek consent of the data owner to access such data for the purpose of processing insurance claims.

A Clinical Establishment may, by consent of the owner, collect the health data after informing the owner about the ownership rights, purpose of data collection, identity of data recipients to whom data may be transmitted or disclosed or who may have access to data on a need-to-know basis. A copy of the consent form is to be provided to the owner. Moreover, an entity that engages in collection of health data would be regarded as the custodian of such data and would be responsible for protection of such data. In case the owner is incapacitated or incompetent to provide consent, the same shall be obtained from a nominated representative, one having legal capacity to give consent. In the event the person becomes competent to give consent, the owner would have the right to seek withdrawal of consent given by nominated representative and seek consent of owner for collection of health data as prescribed by NeHA. This option to consent through a nominated representative extends in the case of collection of health data of a minor as well with the minor having the option to seek withdrawal of consent of the nominated representative to give own consent.

DISHA prescribes that the storage of digital health data so collected would be held in trust for the owner and the holder of such data would be considered as the custodian of data thereby making such holder responsible to protect privacy, confidentiality and security of data. The holder of data could be a Clinical Establishment or a Health Information Exchange.

Storage of digital health data shall be stored only by a Clinical Establishment or a Health Information Exchange and shall be held on behalf of NeHA and shall be subjected to such usage as has been prescribed without compromising on the privacy or confidentiality of such data or owner.

The transmission of digital health data is required to be transmitted by a Clinical Establishment to a health information exchange in an encrypted form for reasonable use as per standards prescribed by NeHA keeping in mind the privacy and confidentiality of the owner. A Clinical Establishment or health information exchange would be allowed to transmit the digital health data only after obtaining the prior consent of the owner and giving information to the owner about their ownership rights and the purpose of collection of data. Moreover, a health information exchange is also under an obligation to maintain registers containing information regarding any and all transmissions of digital health data between Clinical Establishments and health information exchanges and between health exchanges.

The digital data collected, stored or transmitted by a Clinical Establishment or a health information exchange may be accessed by a Clinical Establishment on a need-to-know basis. Access to digital health data may be sought by the governmental departments by their secretaries in de-identified or anonymised form by submitting a request to NeHA in furtherance of public usage of health records. Moreover, access may be granted to digital health data for purpose of investigation into cognizable offences or for administration of justice subsequent to order of a competent court. In the case of emergencies, the Clinical Establishments may be granted access to the digital health data of the patient and the relatives of the owner may also be given access to the data for correct treatment of the owner. Moreover, all Clinical Establishments and health information exchanges are required to maintain registers to record purpose and usage of digital health data so accessed in a manner prescribed by NeHA.

Under DISHA, the Clinical Establishments, health information exchanges, SeHA, NeHA are duty bound to protect the privacy, confidentiality and security of digital health data of the owner. Such duty also extends to an entity which has generated and collected digital health data. Such duty is to be given effect to by undertaking necessary measures to ensure that data collected, stored, transmitted is secured and protected against unauthorised access, use or disclosure and against accidental or intentional destruction, loss or damage.

The Clinical Establishments or health information exchanges are required to notify the owners of data in cases of breach or serious breach of digital health data within 3 (three) working days. The Draft Bill does not clarify if the 3 days is to be calculated from the date of breach or from the date of becoming aware of a breach.

Some observations:

  1. The Draft Bill must identify a competent court that is authorised to pass an order for usage of data.
  2. The Draft Bill fails to provide for a penalty on Clinical Establishments and health information exchanges for storage of incorrect digital health data.
  3. The time of 3 working days for intimation of breach, may have to be 3 days and not necessarily “working” days.
  4. Although the entities have a duty to protect the data of the owner, the duty to notify the owners in cases of breach of information doesn’t extend to entities and has been limited only to Clinical Establishments and health information exchanges.
  5. The Draft Bill must provide for Right to be Forgotten.
  6. The Draft Bill must provide for a cohesive reading with (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules 2011, under the Information Technology Act.
  7. We hope that there will be sufficient Rules under the Draft Bill which can provide for specific consent specifically to certain acts and not a blanket consent.
  8. The Draft Bill should provide for specific time period for record maintenance.

Author : Mr. Spandan Saxena

The GDPR Era – First impression and observations

The European Union’s General Data Protection Regulation (the “GDPR”) that came into effect on 25 May 2018, is touted as the most widespread and robust change to data privacy and protection law in the world. Many entities around the world have been engaged for many months trying to put in place processes and mechanisms to ensure their compliance with the GDPR. Now that the regulation is effective, it will be interesting to evaluate whether on the basis of purposive interpretation, the letter and spirit of the GDPR has in fact been followed by those under its jurisdiction. In the course of this article, we will take a look at some of the most common changes and announcements made by companies around the world in order to be compliant with the GDPR and compare these changes with the corresponding GDPR principles/requirements that they have been made in response to.

GDPR

Obtaining Explicit Consent

One of the core requirements of the GDPR is to ensure that companies and entities take the explicit and active consent of all data subjects prior to collecting, storing and/or using any of their personally identifiable information (“PII”). This is in line with the GDPR’s underlying principle of ensuring that the data subjects always take priority and are the most important stakeholders. Additionally, prior to introduction of the GDPR, many experts in the field of data privacy and protection who reviewed the regulation contended that in order to take a data subject’s explicit consent, it seemed like the regulation specifically required some action or activity on the part of the data subject, such as clicking a button or an option. This is believed to be necessary to clearly and unambiguously show their agreement to a company’s usage of their PII. Consequently, if this requirement is indeed mandatory, the established practice of implying a data subjects acceptance of terms through their continued usage of a website/service, would not be sufficient any more.

However, over the last two months, as many users around the world have received communications regarding service providers’ updates to their Terms of Service and Privacy Policy, we have noticed that very few service providers have actually followed the above method of taking consent. Instead, the previous practice of implying consent has continued to be followed. The majority of the emails and the communications have contained information regarding how a company/entity has altered its Terms and/or Privacy Policy, and how it is ensuring compliance with the GDPR, but without actually asking the data subjects for their explicit consent to the changes. This may not be in conformity with the GDPR, which mandates that every data subject, whether existing (that is, before the regulation came into effect) or new, is required to provide their explicit consent before a company/entity can collect or use their PII. Only a minority of companies have been asking their data subjects to re-confirm their acceptance of the revised terms/privacy policy before continuing to use the services.

Full Disclosure

Another important requirement of the GDPR is ensuring that all companies and entities disclose all information to their data subjects, specifically with respect to any of their PII. This includes, but is not limited to, what data is being collected, how it is being stored, how it is being used, how long it is required for, whether it is/will be shared with any third-party, why such sharing is necessary etc. This requirement is important to ensure that data subjects are at all times aware of exactly how their PII is being treated, and so that they can take an informed decision regarding accepting or rejecting a company’s terms and/or privacy policy.

On a plain reading of the regulation, it would seem like all of the above-mentioned information will need to be specifically be provided by the companies/entities to the data subjects. However, most companies/entities have only been making the above disclosures in vague language. For example, instead of specifying which/what kinds of third-parties the PII is or may be shared with, many companies have simply included a blanket statement stating that the PII will be shared with third-parties/service providers ‘as may be necessary to provide the services’. Such statements provide no information as to who the PII is being shared with, what functions the third-parties are performing on the PII etc., things that the GDPR seems to hold as critical. Further, companies have used such vague language in other disclosures as well. It is possible that this may defeat the very purpose of the disclosures, as the data subjects are not truly aware of how and where their PII is being used, preventing them from being able to take informed decisions regarding the same.

Providing Data Subjects with Options

The GDPR recognises that many companies need to use and rely on multiple third-party service providers in order to provide their own end-service to the customers. Further, in the course of using such third-party service providers, many companies start adding and offering fringe/additional features and services to their customers. However, a lot of these features are often not connected or related to the core service being provided by the company – for example, Facebook may provide its users with targeted advertising on its platform, which is not connected to the main function of social networking. Yet, as the number of features available grew, in an effort to generate greater revenues companies started to club and offer all features together to their customers. This effectively meant that customers had no options with respect to which features they felt were useful and which ones weren’t – they could either subscriber to and use all features or use none.

Many data privacy experts around the world found the above situation to be unfair, as it may force users to either have their PII used for additional unnecessary purposes, or to pay for additional features that are not required by them. The GDPR sought to address this problem by stipulating that companies should stop bundling products and features together, instead specifying which features and services are necessary or critical to the core service. Any add-on features or services should explicitly be communicated to the users, and the users should have the option of deciding whether they want to subscribe to these or not, and whether their PII should be used for the same or not.

Unfortunately, it seems like this is another requirement of the GDPR that has not been followed. Companies are either continuing to club features and services or are devising ways to skirt the stipulations by arguing that even certain add-on features are critical to the core service. One of the prime examples of this is Facebook, which continues to make the usage of PII for the purposes of displaying personalised advertisements, games, application suggestions etc., mandatory for all users. In effect, one cannot use Facebook’s social networking platform unless they agree to their PII being used for all of the above purposes as well. This matter has already been acted on by Max Schrems, a prominent Austrian data privacy campaigner. He has filed a case worth USD 3.9 billion before the European regulator, contending that Facebook continues to use coercive tactics to collect unnecessary PII regarding its users, which it then uses to conduct automated profiling (an activity which requires the specific, separate, explicit consent of data subjects under the GDPR).

Way Forward

In principle, it seems as though the GDPR contains some extremely strict and robust stipulations. Yet, as has been shown above, there are many interpretations of this regulation, and companies around the world are already starting to find ways to read and implement the law in different ways. While it remains to be seen if these practices are in fact in contravention of the GDPR or not, if these practices continue the GDPR could be rendered no more effective than existing data protection laws, potentially failing to protect data subjects in the way that was initially expected. Thus, the way the above cases are handled, specifically the lawsuit filed against Facebook, could set the tone for how seriously companies take the need to adhere to the GDPR’s requirements. In our opinion, it will be more beneficial for the European regulator to take a strict view of the stipulations under the GDPR and set a precedent that pushes other companies to ramp up their compliance activities as well.

Breach Notification – A right to be informed

In November 2017, reports confirming a massive data hack at Uber compromising data of almost 57 million users surfaced online. It is pertinent to note that these reports surfaced almost one year after the actual breach occurred. Uber had not intimated when the incident occurred. This incident is an example to understand, why under GDPR providing a breach notification within 72 hours of any such breach has been mandatory if such a breach is directly going result in a risk to the rights and freedoms of natural persons.

The General Data Protection Regulation (“GDPR”) which will be effective from May 2018, will transform the way personal data of users/ individuals/ data subjects will be treated. Given the wide territorial scope of GDPR the Regulation applies to the processing of personal data of a person (data subject) who are in the EU, regardless of where the data is processed, ie. in EU or outside of EU. We believe that GDPR is setting a gold-standard for data security, across the world.

The concept of breach notification was seen under the security breach notification law enacted by the State of California in the year 2002. The security breach notification law was enacted to increase public awareness with regards security issues and risks that the internet and data industry faces.

  • Article 33(1) of GDPR mandates data controllers to “in the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.
  • Article 33(2) mandates data processors to “notify the data controller without undue delay after becoming aware of a personal data breach.”

In light of the requirements prescribed under GDPR, it is a pre-requisite to have in place an effective data security incident reporting mechanism including data breach response procedures to enable notifications to be made to data subjects “without undue delay” in the plain language in such circumstances.

GDPR prescribes that every breach notice should describe the exact nature of the personal data breach including the nature, extent and likely factors that may have resulted in breach based on preliminary assessment, where possible, the categories and approximate number of data subjects concerned and nature of data under threat or compromised, including and the categories and approximate number of personal data records concerned with an aim of charting out an effective mechanism to address the breach and resolve the issue without delay.

All entities dealing with personal data should comply with the requirements of reporting breaches in a timely manner. Every “notice of breach” should clearly indicate the cause of breach (Accident / negligent/malicious attack) due to (a) internal factors or (b) external factors and the estimated intensity and consequences of such attack. Such notices should promptly be followed by a detailed report indicating causes, consequences, action taken, including actions taken as preventive mechanism adopted to avert such instances in future.

To be compliant with GDPR, it is recommended for all data controllers and processors to have extensive internal policies within the company, including a breach notification policy addressing the procedures to be followed should there be a security breach. For ease of understanding, think of this security breach policy as a fire safety plan that has to be followed in case a fire breaks out. A fire safety plan will clearly indicate the do’s and don’ts, evacuation plan to follow, reporting mechanism, who should what, emergency numbers, internal training and all other necessary steps to be followed so as to contain and reduce the harm caused due to such an accident to the extent possible.

Similarly, a security breach policy will aid an organization to respond to such a data breach within a matter of minutes and enable them to take necessary actions so as to contain and reduce the harm. Additionally, such a policy will enable an organization to comply with the provisions of Article 33 (1) of GDPR, i.e. to report a data breach within a time frame of 72 hours.

In reference to Article 33 of GDPR data controllers may consider following points while considering the implementation of policy in their organization:

  1. Scope and intent of the policy will define how it will be implemented. There are two ways to define a scope, either you can have policy document regulating each and every aspect of GDPR to be followed all across the organization or there can be a series of policies implemented, for example, a policy specifically for security breach and notification thereunder. The second option will allow you to focus and concentrate on minute details of processes, controls, and compliances to be made at each level.
  2. Setting goals for the policy will provide you with accountability and definitive purpose for the whole organization. While setting goals for the policy do think about:
    • Practicality: Ensure that goals that you make are approachable and are ordinary in nature. At the same time keep in mind that these goals are solving the purpose of their implementation, including a way to maintain an internal log, audit trail of how data is used.
    • Risk Management: Focus on what kind of data is at risk? this may be dependent on the industry you might be doing business in. Focus on how a data breach can occur? What are the weaknesses of your system?
    • Flexibility: Try to keep your policy adaptive in nature i.e. it should be able to safeguard you in all sort of data breach situations.
    • Compliance: It should be compliant with law and aid in efficient compliance.

Data controllers, in particular, shall implement processes to identify and respond to data breaches as soon as the event occurs, to have evidence in place to show that where, when and how did data breach occur. Demonstrating that adequate security procedures were in place is essential in order to claim reduced penalties as well.

Status of data protection in India:

Information Technology Act, 2000 and Rules thereunder, ie. Rule 8 of Reasonable Security Practices and Procedures and Sensitive Personal Data or Information, Rules 2011, provides that in case of information security breach, the body corporate shall be able to demonstrate that it has implemented security control measures as per their documented information security programme and information security policies. It would be beneficial if the Rules also provided for notification of breach as well. If personal data is a Fundamental Right of the Indian citizen, then, citizens should have a right to know if such personal data has been subject to a data breach.

If an Indian company is processing data of an EU resident, then GDPR compliances become mandatory. In other cases, Indian companies can adopt best practices such as having detailed policies covering above aspects, periodical audit and availability of audit report to be shared to an external party, maintaining a log of what, how, who, why, where, data is processed. Currently, Government is not included under the ambit.

ISO 27001 certification for data security is also useful.

India would do well in having these gold-standards for data protection and it would augur well if even Government is included to follow the compliance requirements.

Author: Technology Practice Group @ NovoJuris Legal

“By Default” –  Consent By Default and Business Models

In 2003, Eric Johnson and Don Goldstein conducted a survey where the people were given two default choices, (i) people were informed that default was; not to be an organ donor (Opt-in) and (ii) other set of people were told that the default was; to be an organ donor (Opt-out). The results of this survey were surprising, in the first default choice where people had to opt-in to be an organ donor, only 42% of people opted-in or choose to become an organ donor. Whereas when people had to opt-out and make a decision that they do not want to be an organ donor, only 12% of people opted-out, 82 % of people choose to remain as organ donors.

All the major countries in European Union have laws and regulation relating to organ donation and it is exciting to see that countries with default opt-out option have an average of 97.55 % of organ donors. Below is a chart which clearly shows the difference between the numbers of organ donors in countries where default is opt-out and the numbers of organ donors in countries where default is opt-in.

Explicit Consent (opt-in, gold) and presumed consent (opt-out, blue)[1]

This study demonstrates one fact that presumed consent accompanied with an option of opting out works far more efficiently and sticks to people and develops adherent behaviour in people.

But the primary question that has to be answered here is that “why do default rules stick?”

Before moving ahead and answering this question let’s take another example to understand the realms applicability of default rules in modern day businesses.

Default rule setting has aided a company to capitalise subscription-based business model and rule the OTT entertainment segment all across the globe. Netflix in India, provides its services on a subscription-based model where a subscriber gets the first month service free of cost and the subscriber has to pay only from the second month. The FAQ section on the Netflix website says “Try us free for 1 month! If you enjoy your Netflix trial, do nothing and your membership will automatically continue for as long as you choose to remain a member.”

Folks in the industry call it as “Negative option marketing”, where people accept a free product are automatically enrolled as members of the subscription plan which carries a monthly fee.

Recently ‘Paytm’ a mobile pre-paid instrument in India introduced an option where a user can automate the process of respective bill payments. A user may now fix a date for bill payment, the Paytm wallet will by default pay the bill on that particular day until a person opts-out.

The point is default rules or settings make life easier and more efficient. There are so many use cases – Think of SaaS automated renewal, think of moving from free to paid services etc.

Default rule sticks because it is an efficient mechanism of making people do something or not to do something. Default rules tends to stick due to power of inertia, it exploits and thrives on basic human tendencies such as forgetfulness or perhaps procrastination or is it laziness. People generally like things which does not require much of an effort. Or is it perhaps because someone else has to take a decision? “the preferred approach is to select the default rule that reflects what most people would choose if they were adequately informed”.[2]

Default rules have existed even in law. For example, copyright ownership rests with the employer, in the employer-employee relationship, unless otherwise specifically agreed upon. The Hindu Succession Act, 1956 has some default settings unless and until a person executes a Will.

With the new General Data Protection Regulations (GDPR) which becomes effective end May 2018 in European Union, the active consent, ie. Active opt-in from a data subject is required to use personally identifiable information. This sure has wide repercussions in various business models.

Have you thought of using the power of default setting in your business? Do you see use-cases where you can use the power of default setting in your business? It is also perhaps time to stop and think through the default settings you may have used earlier in your business.

Author: Manas Ingle, is an Associate with NovoJuris Legal.

[1] Eric Johnson and Don Goldstein, Science Mag, VOL 302, November 21, 2003. Available at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1324774.

[2] N.Craig Smith . Smart Defaults: From Hidden persuaders to adaptive helpers.