Today, the fact that business data of every kind is now being stored, managed, maintained and accessed in the cloud is inescapable, and the business reasons for this migration of data from within an organization’s network to a vended cloud provider are infinitely varied.
Whatever the reason fueling the migration of data, one thing is certain – coupled with the movement of data and the use of cloud services is the introduction of additional risk. It’s true that many companies will actually improve the security of their data by shifting to the cloud. In many cases, companies are obtaining better data security when in a cloud environment because they’re working with cloud providers that make security a top priority.
It is clear that many of the cloud providers have invested in hardening the security available to customers and that they are at the forefront of addressing cyber risks. Certainly, the security of data in the cloud is of primary importance both to the cloud provider and the cloud user. Understanding the risks specific to utilizing cloud resources is essential to managing, insuring, and avoiding those risks.
One of the primary challenges of using cloud resources is that the services offered by the cloud providers establish a shared responsibility between the cloud provider and the cloud user. Both the cloud provider and the user must be aware of system and data security to prevent a breach in the security. In addition, when a risk is realized, it may not always be clear who is at fault for the system or security failure.
Some people have misconceptions around the cloud and liability. (Insurance coverage issues specific to the cloud are discussed below.) Many companies assume that along with the transfer of their data, they have also transferred their risk to the cloud provider. Absent a clear agreement that shifts liability to the cloud provider, the practical reality is that in most cases, there’s very little protection in terms of liability with cloud providers, unless parties are willing to engage in protracted litigation to determine otherwise.
The shifting of liability is not nearly as easy as the transfer of data and often it may be the case that the responsibility for a data breach rests with the party that collected and maintained the data originally. Perhaps the most notable exception has been in the health care industry, where companies providing support often are classified as “business associates” under HIPAA (discussed below) and might be subject to the same obligations for protecting data as the entity with the original patient relationship.
Even here, some might argue that liability transfer does not occur, but rather a liability expansion that includes the cloud provider. Below are certain examples of privacy- and cybersecurity-related issues that relate to the use of the cloud.
Cloud services, including their providers and consumers, may be subject to various privacy laws in multiple jurisdictions, some of which impose substantial obligations and liabilities for non-compliance. This varied privacy landscape considerably increases the risks and potential liabilities for entities storing their data or effectively operating in the “cloud.”
The obligations that flow from the plethora of existing privacy laws are far-reaching and expand to include not only providers and cloud consumers but also onto those parties’ subcontractors or subprocessors. The newly introduced privacy laws that become effective in 2018, including the GDPR regime discussed below, expose organizations to a new set of duties and inherent risks associated with non-compliance.
Organizations may become subject to such foreign privacy laws by merely monitoring a resident of a foreign jurisdiction or by transferring “personal data” to and from an international location:
1. The New European Union Privacy Regime
The European Union General Data Protection Regulation (GDPR) is a set of rules that regulate the collection, storage, disclosure, and use of “personal data” of European data subjects. The GDPR is expected to strengthen data protection rights for individuals within the European Union. The GDPR will also establish an individual’s right to control personal data as well as establish new rights including the “right to be forgotten” and data portability concepts.
Once data is placed into a cloud environment, it can be difficult technologically for a company that has received a request from a data subject to remove the personal data or find and isolate all such personal data.
In addition, the GDPR definition of personal data is much broader than the concept of personal information in the U.S. Under Article 4 of the GDPR, personal data is defined as:
“‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a 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”.
For example, airlines that keep a record of special requests by travelers for items such as Kosher meals might need to be mindful that some might attempt to consider this preference as personal data under the GDPR, potentially asserting that it might indicate a religious affiliation. Further, like race, ethnic origins, biometric, and health data, religious affiliation might be seen as the more sensitive data types considered “special category” data, a designation that mandates additional conditions for processing compared to less sensitive “personal data.”
The GDPR entered into force on May 24, 2016, and its enforcement begun on May 25, 2018. The process of becoming fully compliant with the GDPR can consume a substantial amount of time for a business. As one example, the requirement for entities that handle EU personal data to develop methods of data maintenance that incorporate the concept of “privacy by design,” a concept that requires companies to design policies, procedures, and systems which comply with the GDPR from the inception of the product’s or processes’ development, cannot be achieved overnight. Thus, a best practice is for organizations to direct their attention towards becoming compliant as soon as possible.
Because the GDPR is not limited to a specific sector or industry, various organizations that process “personal data” were affected. Importantly, the GDPR applies to many organizations that had few or no compliance responsibilities under the existing regime (Directive 95/46/EC), but now have new or increased obligations under the GDPR.
Non-compliance with the GDPR exposes organizations to additional risks and significant financial damages. While the financial liabilities under the Directive 95/46/EC are relatively low, the financial liabilities under the GDPR are significantly higher. In particular, under the GDPR, organizations may face financial liabilities that are the greater of €10 million or 2% of global annual turnover for each act of non-compliance related to technical measures or the greater of €20 million or 4% of global annual turnover for more extreme cases of non-compliance with the key provisions of the GDPR.
2. The Payment Card Industry Data Security Standard
Organizations that process payment card data are required to comply with information security standards called the Payment Card Industry Data Security Standard (“PCI-DSS”). Although the PCI-DSS is not government regulation, its compliance is required by major payment card companies. In addition, a few states, including Minnesota, Nevada, and Washington, refer to the PCI-DSS in their laws.
The PCI-DSS purports to be aimed at reducing credit card fraud by increasing controls over cardholder data. Specifically, the PCI-DSS specifies twelve requirements for compliance which are organized into six logically related groups. Thus, to comply, the payment card industry looks to whether organizations will: 1) build and maintain secure networks, 2) protect cardholder data, 3) maintain a vulnerability management program, 4) implement strong access control measures, 5) monitor and test networks, and 6) maintain an information security policy. In addition, qualified organizations will face certain reporting requirements.
Although some would argue that the ultimate responsibility for PCI-DSS compliance lies with the cloud customer, cloud security could be viewed as a shared responsibility between both parties. Thus, the cloud provider customer’s alleged non-compliance with PCI-DSS might increase the cloud provider’s risks and might expose it to additional liabilities.
HIPAA’s Omnibus Rule, which went into effect in 2013, extends the application of HIPAA to business associates of covered entities. Companies that provide data transmission services to covered entities or provide protected health information (“PHI”) on behalf of covered entities (including the organizations that perform such activities via cloud) may be qualified as business associates and, therefore, could be subject to the HIPAA-HITECH regime.
The Health Insurance Portability and Accountability Act (“HIPAA”) and the Health Information Technology for Economic and Clinical Health Act (“HITECH Act”) specify requirements for the privacy and security of PHI and apply to healthcare providers, payers, their business associates, and subcontractors. The laws also establish strict civil and criminal penalties for breaches of PHI and additional steps that organizations must take to respond to security breaches.
HIPAA-HITECH likely applies to organizations that gather or store PHI on behalf of covered entities. Such requirements include instructions on how data is stored (“HIPAA Privacy Rule”), secured (“HIPAA Security Rule”), who has access to PHI (“HITECH Omnibus Rule”), a security breach response (“HIPAA Breach Notification Rule”), and standards for patient confidentiality (“Patient Safety Rule”).
While individuals are rarely sentenced for HIPAA-HITECH violations, organizations might fact financial liability of up to $1.5 million per violation and incur significant costs related to mandatory breach notification, including legal fees, lost business, and reputational damages.
It goes without saying that awareness of a risk is the first step necessary to begin managing and minimizing the risk. As mobile devices become ever more ubiquitous in the workplace, replete with applications that seek to improve worker efficiency and productivity, many, if not most, of these applications utilize cloud resources and the resulting data is being stored in the cloud application. This reality has spawned yet another new term: B.Y.O.C. or Bring Your Own Cloud.
In a perfect world, the company will be aware of the use of cloud resources by its employees, but companies nonetheless might not be fully aware of the extent of the internal use of cloud resources. Certain cloud providers make it simple to engage their cloud-based service with a mere exchange of credit card information.
In those instances, the cloud user might not have reviewed a long and convoluted contract; rare is the employee who actually reviews the terms and conditions for such services when presented as a so-called click-wrap agreement. It is likely that many of the individual employees are not even aware that when they use an application they are using the cloud to hold data. In the event of a breach of data from such an application, expect finger-pointing as to the issue of responsibility for the resulting liabilities.
Another less friendly term used to describe the B.Y.O.C. scenario is “shadow IT.” So-called “shadow IT” often is born of good intentions. Well-meaning employees might use – both via their work computers and their mobile devices – applications that help them be more effective at their jobs. They might be wholly unaware of the risks created by storing corporate data in an unsecured application.
The company might not know what applications and cloud providers that workers are using and what data is being stored in the cloud. The company, in such an instance, might not know what information is exposed, where it is going, and with whom it is being shared. They likely do not know if the data is being encrypted, commingled with many other customers, and at times even being mined further for useful data by the application vendor or cloud provider.
Significantly, it is common that contracts among business parties restrict not only the use of data, but also who can have access to the data. In addition, regulatory obligations also restrict the use and access to such data. When employees move restricted data into the cloud without authorization or adequate security, there is an increased risk of regulatory scrutiny involving the business and the employee, as well as the potential risk of legal action between business parties.
Another risk inherent in utilizing cloud resources arises as a result of multi-tenancy. Multi-tenancy means that multiple, usually unrelated cloud users share the same computing resources: CPU, storage, memory, namespace, and physical building, which are provided by a cloud provider.
The risk of multi-tenancy also includes the potential for the loss or misuse of data resulting from the sharing of equipment, software and resources. In a multi-tenancy cloud network, it could be possible for one flaw in the system used to partition cloud tenants’ data could allow another tenant or attacker to see all other data or allow one tenant’s data to accidentally leak into another tenant’s data partition. It is also possible that a system flaw could allow a malicious tenant to assume the identity of other tenants.
This sharing of equipment, software and resources also increases risk as a system malfunction, malware intrusion, hack, or virus experienced by one tenant could leak over to the other tenants’ data or to event corrupt the entire system.
The most obvious risk when using a cloud provider is that of data protection and data loss. Although the perception is that all the information uploaded to the cloud is secure, it nonetheless is now available to the cloud provider’s staff. How available the data is will be determined by the cloud provider and the terms of the contract for services.
Placing data into the cloud gives another entity full control of your data. The basic risk that is often overlooked by both the cloud provider and the cloud user alike: the very human risk caused by the cloud provider’s staff. It is a best practice to understand who and how many people on the cloud providers’ team have access to the company’s data.
Once a company outsources a service and data to a third-party server, that company might consider risks arising from its own staff and also the risk posed by the cloud provider’s staff. Through the cloud provider, more people now have access to the data and systems that support the cloud provider, which means extending trust to people whom the data holder has never met and over whom they have no control.
One key factor that may affect the risk posed by the cloud provider staff is the use of data encryption. Some companies rely upon the cloud provider to encrypt the data upon receipt. Arguably, this might make the data available to the cloud provider’s staff, potentially adding another layer of potential human interaction.
Many companies do not move data to the cloud without first encrypting all data. In that case, it is a best practice to know how data encryption is used and enforced and if private encryption keys are shared among tenants. Unless the company is certain that files are encoded (either by choosing a provider that guarantees it or performing the encryption themselves), it is a chance taken with every file transferred into the custody of another entity.
An additional risk that is increased is that of possible government intrusion into confidential data. Some cloud providers refuse to provide a client company’s data without a governmental order requiring compliance and notice to the company. Others may not follow this practice, so understanding how your cloud provider interprets their obligations would be a best practice.
When data leaves a company’s control, and is held by a third-party cloud provider, the expectation often is that the data will continue to be available when needed without interruption of access. Unless clearly delineated in the contract, however, there may not be suitable redundancy and fault tolerance systems in place to assure that access is not interrupted.
At times, based on the contractual terms, there may be differing levels of backup provided. Many contracts with cloud providers provide a limit on down time; the terms of service might provide recourse if the down time exceeds that limit resulting in an interruption of business.
In the event that the company relies upon the cloud provider to perform a component of the business transaction, and an unexpected security failure results in interruption of this business process, there may be a resulting loss of profits and additional expenses. Cloud users should consider such a risk when evaluating the scope of insurance coverage, they have and, when possible, ensure that their insurance policies would provide coverage for such a failure.
Another issue to consider is an instance in which a company could lose data, either due to an issue with the cloud provider or with malicious attackers. It is a best practice to understand the extent of the cloud provider’s disaster recovery policies to determine if they are adequate to protect, and if need be to restore, the data.
Unfortunately, even in the best situations, there may be irretrievable data loss. A best practice is for the parties to address insurance for the risk of data loss when entering into the agreement for cloud-based services.
The most obvious risk contemplated by companies that elect to use cloud services is that of data breach. Data breaches come in many forms, but at the very basic level they involve the disclosure of data to third parties not permitted to possess the data. Usually data breaches become an issue as the disclosed data includes either personal identifying information or protected health information.
A data breach claim against a cloud provider might be viewed as an errors and omissions (E&O) claim against the provider. The cloud provider may be viewed as not having direct liability to the individuals whose data has been breached under the current state of the law, but there may be a claim from the company for failing in their performance of services, including the securing of the company’s data.
A best practice for cloud providers is reviewing their E&O insurance (provided as a stand-alone insurance policy or as a coverage section within a cyber insurance policy) to determine whether it should provide coverage for privacy and cyber-related claims. A related best practice for cloud providers is to consider whether a company that experiences a breach of data held in the cloud due to an act, error, or omission by the cloud provider could demand indemnification based on the terms of the contract or under common law theories of recovery.
The cloud provider should consider whether damages claimed by the company could include not only third-party liability claims, but also a claim for damages incurred in responding to the data breach.
Data breaches and other malware-type issues are often the result of any number of security lapses, including, for example, the use of default passwords or flawed authentication methods. Many organizations struggle with the management of individual access and data permissions. Similarly, companies might not cut a user’s access when they leave employment or when a job change occurs.
Another attack on cloud providers involves a denial of service attack. Unfortunately, even if repelled, these assaults consume large amounts of processing power; ideally, for the cloud user, they will not be stuck with paying for the additional processing power required. Although many cloud providers may generally be more capable of handling a denial of service attack than the cloud user, they should be prepared with a mitigation plan if they face such an event.
Disclaimer: This article should not be construed as legal advice or legal opinion on any specific facts or circumstances. The contents are intended for general informational purposes only, and you are urged to consult your own lawyer on any specific legal questions you may have concerning your situation.
About the Author
Scott N. Godes is a veteran trial lawyer with experience in insurance coverage matters and technology issues. He is a partner in Barnes & Thornburg LLP’s Washington, D.C., office and is a member of the firm’s Litigation Department, the Policyholder Insurance Recovery and Counseling Group, and the Internet & Technology Law Group.