“There is absolute lack of clarity around what critical data could mean. When we are re-engineering our systems to comply with the current laws, how do we factor in the uncertainty and the lack of predictability on something like this?” Shweta Rajpal Kohli, Salesforce’s country director for government affairs and public policy (India and South Asia), said. Microsoft’s S Chandrashekhar, also agreed that gaps in the Personal Data Protection Bill makes it difficult to predict additional operational burdens placed on companies.

Because of lack of clarity on definitions, companies like Salesforce are quite anxious. “There could be additions and deletions, there could changes, making it very hard for companies that putting in place large-scale infrastructure plans and working towards complying with large privacy legislations to work with,” Kohli said. They were speaking at MediaNama’s June 26 discussion on the impact of the Personal Data Protection Bill, 2019, on cloud and telecom services, that was supported by Microsoft and Google. Comments have been edited for clarity and brevity.

Cloud service providers: Data processors or data fiduciaries under the Bill?

In certain cases, an entity might be both a data fiduciary and a data processor, depending on its products and functions. Microsoft is one such case.

Microsoft is both a data fiduciary and a data processor. We have our services like Office 365 and Dynamics and various other services including our AI and cognitive services where we are a fiduciary, and we have our plain play Azure, IAS and PAS where we are a data processor. For consumer-centric services like Office 365, etc., we have an increased burden about where all the data will flow. For example, the authentication data, which is the active directory, currently resides in various parts of the world so that users do not have a problem from accessing it from anywhere in the world. Also, in terms of redundancy, if there is one data centre which goes down, it’s important for the data to be located in different parts so that it can easily come back to life despite any problem with the disaster. There is an additional compliance burden related to data localization that we closely watching. We have not yet been able to compute the exact extra effort required because of gaps in the Bill, but additional effort will definitely be required.” — S. Chandrasekhar, group director of policy and government affairs at Microsoft India

Bill not clear on whether cloud service providers should be treated as data fiduciaries

“If cloud service providers are infrastructure-based services, pure hosting, pure storage, etc., then they must not be considered as a fiduciary,” Nikhil Narendran, partner at Trilegal, said. However, he clarified that if more services are provided on cloud, or if “data fiduciaries themselves do not have much control over how the data is processed on the cloud”, or they don’t have much visibility into the processes executed in the backend, that is a grey area where the Bill lacks clarity. UK’s Information Commissioner’s Office, for instance, has a checklist to determine if an entity is a data controller or a data processor, he said.

Jyotsna Jayaram, counsel at Trilegal, said that in terms of defining data fiduciaries and data processors, the Bill has gone as far as it could. As per the Bill, if an entity determines the purpose and means of data processing, it is a data fiduciary. The problem arises because this is a functional classification where determining roles up-front is difficult, especially because cloud service providers no longer have a passive role, she said. “The scope and therefore the demarcation of responsibilities would be important in the contract,” she said. Under Section 31, the data fiduciary can use a data processor only if there is a formal contract, and the fiduciary is the one accountable and responsible for data processing, until and unless the data processor violates the contract or does not have appropriate security safeguards in place.

Could contractual obligations be the way forward?

This, as Narendran said, is a global issue. “Companies and lawyers across the globe consider this on purely contractual terms wherein someone is designated as the data fiduciary, that is, the customer of the cloud service, and the relationship between them is managed contractually,” he said. When cloud service providers provide particular software or processing services, it is always considered whether these should be put in the contract so that they aren’t classified as data controllers under the GDPR, he explained. All contracts must be carefully drafted to take care of lack of definitional clarity of data fiduciary so that a processor doesn’t end up being classified as a fiduciary, he said.

The confusion about the role of the cloud service providers will worsen in the next couple of years as “equipment on the edge”, including IoT devices, collect, process, and transfer data to the cloud, Narendran warned. In that case, “companies will have to take extra steps while contracting or while determining internal standards to ensure that they are safe, or there is always a risk of them being classified as a fiduciary since the actual data fiduciary, who is contractually liable to the customer, doesn’t necessarily have control over the processing of the data that happens at a processor’s end, that is, at the cloud service provider’s end,” he said.

“It might be better to go by contractual obligations between the data processor and the data fiduciary instead of blurring the line between the two in the law as it creates more complications,” Kohli said. Clear delineation between the two is very important, she said, and “robust contractual agreements between the two” would be better.

Anjali Hans, senior vice president of regulatory and corporate affairs at Vodafone Idea, agreed and said that “there should be a contractual agreement between the controller [fiduciary] and the processor as to how the data shared with the processor is processed”. Even if the processor has to collect data from the users directly, it would still be a B2B arrangement where this will be done for the provision of service promised by the data fiduciary to the user, she said.

Allocating liability

Jayaram said that impact assessments are necessary for both the processor (the cloud service provider) and the customer (the data fiduciary) so that the fiduciary knows whether the processor will have the adequate technological safeguards and if it understands the means of processing, and the processor will know if the fiduciary may need handholding through the process. Through this process, the nature of contracts will change from having a couple of clauses on data protection and cybersecurity to having far more extensive provisions on indemnities, service-level agreements, and even termination grounds that would account for such compliances, she explained.

What happens to processors contracted by exempted government agencies? Jayaram cited Section 35 of the Bill under which the government can exempt any of its agencies from being subjected to the Bil. “But what happens to the data processors that the government engages to carry out the functions of these agencies?” she asked. It is not clear if this means that only these data processors will be held liable when the government has exempted itself from liability. “It would be strange for a processor — acting in accordance with the instructions of the fiduciary — to be liable when the fiduciary itself is not,” she said. In this case, it is important to look at how the government regulates it own cloud service, MeghRaj, and regulations for providing cloud services to the government, she said. Also, if processors contracted by the government are exempted via Section 35, does it mean they are also exempted from the data localization requirements for government purposes, she asked?

Bill does not account for technically unsophisticated data fiduciary

In cases where the data fiduciary may be less powerful, or less technically sophisticated than the data processor, under the Bill, the processor will not be liable in case of a mishap as long as it follows the fiduciary’s instructions as per the contract and has adequate security safeguards, Jayaram said. “Thus, when an ill-informed fiduciary is itself not able to envisage all of the different types of processing or the categories of data it would actually need processed, that enhances the liability that a processor may take on because they could be directly liable for failing to meet the security standards,” she explained. In terms of contractual liability, she said, we will move away from standard contracts or click-wrap contracts that are available for platform hosting and cloud services.

Cloud service providers don’t have visibility into data being processed

“Talking in terms of storage or space or hosting in terms of cloud became obsolete ten years ago. Any cloud service provider like us is concerned about how to run particular types of workloads. We do not have access to customer data. It may technically be possible to access unencrypted data but typically customers would ideally encrypt any kind of sensitive data encrypted while storing it, so we cannot have access to it,” Tarun Dua, CEO of E2E Network, a company that provides cloud services to MSMEs in India, said. Storage itself is incidental to the cloud business, which is primarily data processing, he said.

Dua explained that customers usually use their own codes, or license it from another company, to process the data using the processing power that the cloud service provider provides. “A cloud essentially provides a computing environment. We have absolutely no control over what data is brought in, what software is run apart from the fact that we would ensure that our customers can use common commercially acceptable open source software like CentOS, Ubuntu or Debian kinds of distributions of Linux which are primarily used for processing,” he said. He compared this to how HP or Dell have no control over what kind of data is stored or processed on their devices.

Even when cloud service providers offer a suite of services including analytics, infrastructure, etc., “in almost all cases, they are not aware of what they are processing on behalf of their data controllers [GDPR equivalent of data fiduciaries],” Venkatesh Krishnamoorthy, the country manager for India for BSA (The Software Alliance), said.

Should cloud service providers be held responsible for the security safeguards they implement? When a data processor is not aware of what data it is handling, it cannot implement the appropriate level of safeguards, Krishnamoorthy pointed out. In that case, using data protection impact assessments may be useful along with considering other kinds of agreements and certification mechanisms, he said, that don’t place undue burden on data processors.

Recommendations

  1. Complete predictability around definitions and classifications: “We would want no room for changes and complete predictability coming in, and more clarity when we talk about those classifications [of personal data] mean and what the government really means when it says storage, processing, etc.,” Kohli said, and Hans agreed.
  2. Give a timeline for compliance just as the GDPR had given a two-year window for compliance, Kohli and Hans said, otherwise companies will have to rush through complying with the Act.
  3. Public consultation process to define different categories of data: Hans said when government decides to expand the definition of sensitive personal data, it should be subjected to a consultation process so that people are aware of the realistic impact of classifying different types of data under a particular field.
  4. No retrospective application of the Act: Hans said that the Act should not be used to make entities fix their past data.
  5. Consider the principle of proportionality while classifying data: While defining sensitive and critical personal data, the reasons for classifying data as such must be made clear, Hans said.
  6. Carve out a different definition for data processing done by cloud service providers: When any code can be run by a client on an external cloud service provider, in the absence of insight into data that is processed, it allows for “very arbitrary processing of the data and manipulation of storage,” Dua said. Thus, while the definition of “processing” needs to include storage, a processing done by cloud service providers needs to be differentiated, he said.
  7. Allow processors to engage sub-processors: The Bill currently does not allow data processors to engage sub-processors without getting contractual permission from the fiduciary. Krishnamoorthy suggested that there could be a mechanism by which processors can get advanced clearance and notify the fiduciary when are hiring a sub-processor.
  8. Only data fiduciaries should pay damages to data principal: Krishnamoorthy recommended that data fiduciary alone should be responsible for any compensation that may need to be given to the data principal, and if any compensation needs to be paid by the processor, it should be decided via the contract itself. Currently, the adjudicating officer can decide if and how much the data processor may need to pay in compensation.
  9. Don’t include non-personal data within the Bill, Kohli said, especially since another MEITY committee is already looking at its governance.
  10. Reduce the age until which parental consent is required from 18 years to at least 16 years, Hans and Chandrasekhar recommended. 18 years is very high, Chandrasekhar said, especially given that today internet is used for e-learning, in schools, and children start accessing internet from a very young age. At 18 years, it will be “nightmarish” to comply with, he said.

Read our complete coverage of the discussion here.