Tag Archives: GDPR

Cyber-Security: The Vulnerability of Medical Institutions to Cyber-Attacks

McAfee researchers were able to modify the vital sign data in real time providing false information to medical personnel by switching the heartbeat records from 80 beats a second to zero within five seconds. You would have woken up to news that Medstar patient records database was subject to ransom ware cyber-attack and was asked to pay bitcoins. Unfortunately, the hospital did not have backup of medical records and in some cases, they had to turn away the patients. These incidents, unfortunately, are not stray incidents.

There are various technologies converging and a rapid increase in machine to machine communications.

It is predicted that by 2025, most hospitals will have the ability to network connect more than 90% of their devices.

However, many hospitals are yet to make their data security systems extremely robust. Data privacy and data security are the two important pillars that needs urgent consideration. Just as financial data is loved by the cybercriminals, so is health data becoming a gold-mine with the cyber offenders. Specially so when the hospitals are run on legacy systems or no dedicated framework or surveillance on its own data.

Personally identifiable data is an indicator of an individual, such as  name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;[i]

A number of cyber-attacks on medical institutions are initiated to extract the electronic health records (EHRs). These EHRs may contain personal health information of the patients, their medical history, diagnosis codes, billing information, etc. which can be exploited by the cyber offenders in various manners, for instance to get ransom from the medical institutions or to create fake IDs to buy medical equipment(s) or medication which can be resold or only sold on prescription.

Take this example. On 12 May 2017 a global ransomware attack, known as WannaCry, affected more than 200,000 computers in at least 100 countries. The ransomware attack also affected 80 out of 236 trusts (medical institutions under NHS) further 603 primary care and other National Health Service (“NHS”) organisations were infected with the ransomware virus including 595 general practitioners. The trusts which were affected with WannaCry ransomware faced issues like patient appointments being cancelled, computer being locked out, diversion of patients from accidents and emergency departments etc.

As reported in the investigation report on the WannaCry ransomware attack on NHS, published by the National Audit Office (“NAO”, an independent parliamentary body in the United Kingdom), all NHS organisations infected with the WannaCry virus had unpatched or unsupported Windows operating systems. NHS Digital (a national provider of information, data and IT systems for commissioners, analysts and clinicians in health and social care in England) informed the NAO that the ransomware spread via the internet, including through the N3 network (the broadband network connecting all NHS sites in England), though there were no instances of the ransomware spreading via NHS mail (the NHS email system).

In India, as reported by multiple news agencies, last year in the month of June Mahatma Gandhi Memorial (a trust run hospital) hospital, Mumbai (MGM Hospital) was affected by a similar cyber-attack where the hospital administrators found their systems locked, and noticed an encrypted message by the attackers demanding ransom in Bitcoins to unlock it. It was reported that the MGM Hospital had lost 15 days’ data related to billing and patients’ history, though the hospital didn’t face any financial loss.

Once these cyber offenders have access to the EHRs, they hold the systems of the medical institutions hostage for ransom, by encrypting all the systems completely inaccessible and unusable for the victimised medical institutions. The vulnerability to such cyber-attacks arises due to many reasons, outdated digital infrastructure or medical personnel not being aware or not trained about cyber-attacks. Cyber offenders may gain access to medical institutions’ systems through various ways and sometimes as simple as (a) using a USB drive; (b) exploiting vulnerable or expired software, (c) stealing medical personnel’s mobile devices, (d) hacking emails, or (e) phishing etc. It is time that our healthcare providers upgrade their technologies, networks, understanding on this subject.

Regulatory bodies across the world have suggested / adopted guidelines and standards to ensure necessary cybersecurity processes and controls which helps medical institutions to mitigate cyber risks and vulnerabilities. For the purpose of this article we will be primarily focusing on various safeguards and standards put in place by European Union and India to deal with such cyber-attacks.

Position in Europe

As a part of the EU cybersecurity strategy, the European Commission adopted the EU Network and Information Security Directive (“NIS Directive”) on 6 July 2016 and the same came into force in August 2016. As the NIS Directive is an EU directive every member state had to adopt a national legislation which would transpose the NIS Directive by 9 May 2018 and identify operators of essential services under the transposed law by 9 November 2018.

The NIS Directive has three major parts to it (i) national capabilities, (ii) cross-border collaborations and (iii) national supervision of the critical sectors including health.

  • National Capabilities: The NIS Directive mandates every member state of the EU to have certain cybersecurity capabilities, e.g. it is a mandate for every member state to have a national Computer Security Incident Response Team (“CSIRT”).
  • Cross Border collaborations: The NIS Directive encourages collaborations between EU member states like the EU CSIRT network, the NIS cooperation group, ENISA etc.
  • National Supervision of critical sectors: As per the NIS Directive every member state shall supervise the cybersecurity of critical market sectors in their respective country including health sector.

Further, as a part of the NIS Directive the NIS cooperation group through ENISA has developed guidelines regarding (i) identification criteria of cyber-attacks, (ii) incident notification, (iii) security requirements for Digital Signal Processors (DSPs), (iii)  mapping of operators of essential services (OES) security requirements for specific sectors including health and (iv) audit and self-assessment frameworks for OESs and DSPs.

With a view to prescribe certain standards of safety and quality, three recognised EU standards organisations namely (a) the European Committee for Standardisation (CEN), (b) the European Committee for Electro-technical Standardization (CENELEC) and, (c) the European Telecommunications Standards Institute (ETSI) were set up. By setting common standards across EU, CEN. ETSI and CENELEC ensures protection of consumers, facilitates cross-border trade, ensures interoperability of goods/products, encourages innovation and technological development, and includes environmental protection and enables businesses to grow.[ii]

The General Data Protection Regulations (“GDPR”)[iii] specifically defines ‘data concerning health’, ‘genetic data’ and ‘bio metric data’ and regards them as ‘special category of data’, this means that parties who are processing special category of data shall comply with additional higher safeguards and process it legitimately. Recital 53 of the GDPR states that special categories of personal data which merit higher protection should be processed for health-related purposes only.

Position in India

Personal medical/health information in India is regarded as sensitive personal information as per the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal data or Information) Rules, 2011 (“Rules”).

The Indian legislature took an important step for addressing issues relating to cyber security when it amended the Information Technology Act, 2000 in 2008, through which they established an Indian Computer Emergency Response Team (CERT), a national agency for incident response. CERT is primarily responsible for handling cyber security incidents occurring in India and analysing information related to cyber-crimes, but among other things CERT is also indulged in issuing guidelines, advisories, vulnerability notes and white papers relating to information security practices, procedures, prevention, response and reporting of cyber incident[iv].

CERT-India has been entrusted with performing the following main functions (a) collecting, analysing and disseminating of information on cyber incidents, (b) forecasting and giving alerts on cyber security incidents, (c) laying down emergency measures for handling cyber security incidents, (d) coordinating cyber incident response activities, (e) issuing guidelines, advisories, vulnerability notes and whitepapers relating to information security practices, procedures, prevention, response and reporting of cyber incidents, and (f) performing any other functions relating to cyber security as may be prescribed[v].

CERT-India in the last five years or so has focused on making various institutions who are highly dependent on cyber/digital networks ‘cyber resilient’. Being cyber resilient allows these institutions which is nothing but a process of effectively anticipating the various threats and the mechanism of dealing with the cyber-attacks. Anticipate, withstand, contain and recover are the 4 main contours of being cyber resilient[vi]:

  • Anticipate: Maintain a state of informed preparedness in order to forestall compromises of mission/ business functions from adversary attacks
  • Withstand: Continue essential mission/business functions despite successful execution of an attack by an adversary
  • Contain: Localize containment of crisis and isolate trusted systems from untrusted systems to continue essential business operations in the event of cyber attacks
  • Recover: Restore mission/business functions to the maximum extent possible subsequent to successful execution of an attack by an adversary
  • Evolve: To change missions/business functions and/or the supporting cyber capabilities, so as to minimize adverse impacts from actual or predicted adversary attacks

To strengthen the framework and to ensure that reasonable security practices and procedures are followed, the Department of Information Technology introduced certain Rules. The Rules requires each and every body corporate including medical institutions who are collecting such sensitive personal information to have security measures as documented in their security policy/programme which is considered to be a reasonable security practice keeping in mind the nature of their business and considering the fact that they are collecting sensitive personal information. One such international standard as recommended under the Rules is the IS/ISO/IEC 27001.

Taking a step further, the Ministry of Health and Welfare has introduced a draft bill for Digital Information Security in Healthcare Act (“DISHA”). One of the key purposes of DISHA is to ensure reliability, data privacy, confidentiality and security of digital health data. 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.

To bring it all together:

Majority of the cyber-attacks reported worldwide are caused due to reasons which sometimes are trivial and perhaps ignored more often, such as out-dated Windows operating system patch, lack of proper anti-virus or reasons such as phishing, lack of awareness among the people about cyber security etc.

EU, through GDPR has made data security an integral part of law and India is taking strong steps have a robust data protection and data security law. Various regulations, programmes, codes, standards etc. discussed in this article are some indicate steps that can be implemented.

Law is just one part to solve the issue. The real question is who is responsible for safety of our personal data, commercial data, data assets etc.? We secure our houses with a lock, burglar alarms, video cams because the house owner wants to protect it. Similarly, individuals, organizations, healthcare personnel, hospitals and other institutions who collect health data for multiple reasons should be aware of various cyber-threats and has to take steps to safeguard its networks and systems from such threats.

References:

[i] Article 4.1 General Data Protection Regulations (GDPR).

[ii]CENELEC, Marketing Standards for Europe, available at: https://www.cencenelec.eu/aboutus/Pages/default.aspx

[iii] GDPR (2016/679) is a regulation in EU law on data protection and privacy for all individuals within the European Union and the European Economic Area

[iv] Section 70B (4) of the Information Technology Act, 2000

[v] Supra footnote 1

[vi] CERT- In, Cyber Crisis Management Plan for Countering Cyber Attacks and Cyber Terrorism

 

This article was first published at Innohealth Magazine, Volume IV Issue II

Advertisements

Results of the Second Intercollegiate Competition on Data Protection – The New Frontier

The results of the “Second Intercollegiate Competition on Data Protection – The New Frontier” are out.

The Essay competition was devised with the intent of apprising law students with the regulatory developments in the field of data protection. We are glad to have received an overwhelmingly positive response to this initiative.

The winners of the Competition are:

1. Gayatri Puthran – Jindal Global Law School
2. Shashank Saurabh – National University of Study and Research in Law
3. Anisha Singh – Chanakya National Law University
We would like to congratulate all the winners and wish them all the very best.

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)

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.