Cloud Computing and HIPAA Privacy and Security

Transcription

1 Cloud Computing and HIPAA Privacy and Security This is just one example of the many online resources Practical Law Company offers. Christine A. Williams, Perkins Coie LLP, with PLC Employee Benefits & Executive Compensation This Note addresses the legal and contractual considerations relating to privacy and security under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) in the context of cloud computing. The Note includes specific contract provisions that should be considered when negotiating or evaluating a contract with a cloud provider. To access this resource and others, visit practicallaw.com. Many covered entities (CEs) under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) are considering moving information, including protected health information (PHI), to cloud storage, or using software and applications that incorporate PHI and reside on the cloud. The HIPAA privacy and security rules issued by the Department of Health and Human Services (HHS) do not specifically address the use of cloud services, and there are many unanswered questions about how best to capture the predicted advantages of cloud computing while also properly protecting PHI. This Practice Note addresses legal and contracting issues related to the intersection of HIPAA privacy and security and cloud computing, including: Cloud computing service models. Business associate (BA) status and agreements. Special concerns in contracting with cloud providers. Key provisions that should be addressed in contracts with cloud providers. For more information on HIPAA privacy and security issues, see Health Insurance Portability and Accountability Act of 1996 (HIPAA) Toolkit. Definition of Cloud Computing Cloud computing is defined in guidelines issued by the National Institute of Standards and Technology (NIST) as "a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction." In plainer language, cloud computing gives users on-demand access to computing resources from any location, with the ability to increase or decrease capacity as needed, by using pooled resources that are available to multiple users. In general, the expectation of the user (and the cloud provider) is that the user will need little direct interaction with the provider after: A contractual arrangement is in place. The interface between the user and provider is set up. A user can create its own private cloud, or a group of users can create a community cloud. There are also hybrid clouds composed of two or more cloud infrastructures (for example, a community cloud and a private cloud) that share technology to allow data and application portability. The more common structure, however, is the public cloud, which is available to any user that enters into an appropriate contract with the cloud provider. Cloud Computing Service Models NIST divided cloud computing into three service models: Infrastructure as a Service (IaaS) (see Infrastructure as a Service). Software as a Service (SaaS) (see Software as a Service). Platform as a Service (PaaS) (see Platform as a Service). CEs are most likely to use IaaS or SaaS. Learn more about Practical Law Company practicallaw.com

2 Cloud Computing and HIPAA Privacy and Security Infrastructure as a Service IaaS allows the user to have access to traditional computing resources (such as storage and processing) with the ability to use operating systems and applications of the user's own choosing (for example, Box.com offers IaaS). Under this model, the user controls the operating systems, storage, and applications, and may have limited control of some networking components such as host firewalls. NIST identifies this model as: Promoting interoperability as well as portability of user workloads because network protocols, central processing unit instruction sets and device interfaces are relatively welldefined. Placing more system management responsibility on users than either SaaS or PaaS. Software as a Service SaaS makes the provider's applications (such as or productivity tools) that reside on the cloud available to users on demand (for example, Google Apps for Business). Under this model, the cloud provider is usually responsible for keeping the software updated and installing patches, while the user's control is often limited to application configuration settings. The user avoids time-consuming software installation procedures and gains the advantage of a small software footprint on the user's computers. Platform as a Service PaaS gives the user a toolkit supported by the provider to develop applications and make those applications, and applications acquired by the user, available to the user's customers (for example, both AT&T and Oracle offer PaaS). This model usually gives the user control over the user's applications and may offer the user control of configuration settings for the hosting environment. As with SaaS, the user gains the advantage of a small software footprint on the user's computers. Cloud Economics Many cloud providers predict that businesses can reduce computing and data storage costs by using the cloud because the businesses do not need to invest in ownership and maintenance of large numbers of servers or the personnel to maintain them. The SaaS and PaaS models also free users from needing to: Purchase and manage software licenses. Keep the software updated and patched. Instead, businesses can contract with a cloud provider to use what capacity and software they need, and have greater (or lesser) capacity available as needed, with system and software maintenance handled by the cloud provider at a lower total cost. In addition, the cloud may offer greater convenience and efficiency for businesses by making resources and data available as needed from any location and any device that offers an appropriate interface (for example, a browser and an internet connection). The ability to avoid significant investment in servers, staff and software may be particularly attractive to start-up companies and established companies that are testing proposed changes to systems. Cloud services are generally measured and priced in units of usage that are identified to specific users. The units might measure: Time or manner of use. Number or type of users. Number of transactions executed or number of records processed. Specific resources, such as storage, used. Bandwidth used. Other criteria identified in the contract between the cloud provider and the user. Cloud Privacy and Security for PHI Although cloud computing may provide improved efficiency and reduced cost for users, it is not a cure-all for privacy and security issues. A user might improve the privacy and security of its data by moving to the cloud, but the user must still manage privacy and security within the user's own workforce and facilities. In addition, because the cloud is accessed through a network, the user will need: A secure network that is sufficiently robust to import or export the types and amounts of data that will be stored and used. At least some IT staff to maintain the reliability of that network and any user-managed software or systems. Clouds are subject to all of the privacy and security issues that affect traditional, one-user computing systems and networks. In addition, when PHI is moved to the cloud, the CE loses some degree of control. In the public and community cloud models: Servers are not usually dedicated to particular users. The data of more than one user may be stored on a single server and user data and workloads moved from server to server (and even from one geographic location to another) without the user's knowledge. Also, cloud providers may be attractive targets for hackers because of the concentration of data. When using cloud services, the CE is relying largely on the cloud provider's expertise in managing and maintaining access to the CE's data while also keeping the data secure. Cloud providers often: Impose uniform, enterprise-wide management, privacy and security protocols. Offer users additional configurable tools to increase the privacy and security protections provided by the uniform protocols. 2

3 For example, the cloud provider will grant access to anyone who is able to log in using the required identifiers, and may establish the type and strength of the required identifiers. But the user will determine which members of its workforce are given the necessary identifiers, and may be able to require stronger identifiers than the minimum required by the cloud provider. Careful drafting of contract provisions is crucial in establishing appropriate privacy and security protections for PHI in the cloud. Also, users can mitigate the risks of moving data to the cloud by: Reviewing third-party reports on the cloud provider's privacy and security safeguards (for example, SSAE-16 reports). Examining the cloud provider's track record and user audit rights. Business Associate Status and Agreements Many of the HIPAA privacy and security requirements that apply to CEs must also be imposed by contract on companies or individuals that perform services for the CE, if those services require access to or use PHI. Currently, under the final privacy and security regulations, the CE is responsible for ensuring that an appropriate contract (referred to as a business associate agreement (BAA)) is in place. The Health Information Technology for Economic and Clinical Health (HITECH) Act makes BAs directly responsible for compliance with HIPAA privacy and security requirements, regardless of whether the CE obtains a BAA. However, final regulations implementing that requirement have not been issued and HHS has stated that it will not take enforcement action until at least 180 days after publication of final regulations. Currently, and in addition to numerous other requirements, a BAA must require the BA to: Use appropriate safeguards to prevent use or disclosure of the information other than as provided by the BAA. Implement administrative, physical and technical safeguards that reasonably and appropriately protect PHI. The status of cloud providers that hold PHI is an important but gray area with no specific guidance yet from HHS. The definition of a BA under HHS regulations offers little help. In general terms, an entity is a BA if it either: Performs or assists in performing functions or activities for a CE that involve the use or disclosure of PHI. Provides certain kinds of services to a CE, including management and administrative services, if those services involve the disclosure of PHI by the CE to the service provider. (For a discussion of BAs under HIPAA, see Practice Note, HIPAA Privacy Rule: Entities Covered by the Privacy Rule.) Whether storage of PHI that is uploaded by a CE is enough, by itself, to make a cloud provider a BA is unclear. The answer might depend on: The degree to which the cloud provider has access to the PHI. Whether the cloud provider uses the PHI in addition to storing it. Whether the receipt of PHI that the cloud provider will not access or use except in rare instances is enough to make a cloud provider a BA. For example, if a CE stores PHI on the cloud and the contract gives the cloud provider total access to the PHI (an "open box" model), HHS will almost certainly conclude that the cloud provider is a BA and a BAA must be in place. However, if the agreement with a cloud provider prohibits the provider from having access to the PHI (a "sealed box" model), the cloud provider may not fit the definition of a BA. Many agreements grant the cloud provider limited access to the data stored by the user (a "flip-top box" model), such as to assist the user if there are access problems or if the user's data is subpoenaed by a third party. In those cases, it is unclear whether the cloud provider is a BA, but the conduit exception may be a useful analogy (see Conduit Exception to Business Associate Status). Conduit Exception to Business Associate Status In the preamble to the final HIPAA privacy rule, HHS stated that a BAA is not required with an "organization that acts merely as a conduit" for PHI. The preamble gives as examples of conduits: The US Postal Service. Private couriers and their electronic equivalents. Conduits transport information but do not access it except on a "random or infrequent basis as may be necessary for the performance of the transportation service, or as required by law." According to the preamble, a conduit is not a BA because no disclosure is intended and the likelihood of exposure of any particular PHI to a conduit is very small. Although a cloud provider that stores PHI differs in some respects from a conduit that merely transports PHI, a cloud provider that offers a flip-top box model is similar in many other respects: The cloud provider does not access the PHI except on a random or infrequent basis as necessary to assist the CE if there is a problem accessing the PHI or as required by law. No disclosure of PHI to the cloud provider is intended. The likelihood of exposure of PHI is small. Whether HHS would agree that a cloud provider offering a flip-top box model is a conduit rather than a BA is unknown. The most cautious CEs will want BAAs. Many cloud providers will resist taking on all of the obligations of a BA because many of those obligations are inconsistent with the cloud provider business model. For example, the individual rights provisions of the HIPAA privacy rule that impose obligations on BAs relating to access to and amendment of PHI that is maintained in designated record sets seem ill-suited to a cloud provider that merely stores PHI (see Standard Document, HIPAA Business Associate Agreement). In addition, in many (or perhaps most) cases, the cloud provider will not know whether it is holding PHI or, if it knows that some of the data is PHI, it might not know which data is PHI and which is not. 3

4 Cloud Computing and HIPAA Privacy and Security Contracting with Cloud Providers Negotiating a contract for cloud computing services requires cooperation among several groups of the cloud user's workforce, including procurement, legal, IT, compliance and the groups that are expected to use the cloud computing services. It is highly unlikely that a cloud provider's form contract will fit every user, and the contract and service level agreements (SLAs) should address the user's particular needs. When PHI is being moved to the cloud, there is an even greater need to ensure that compliance requirements, such as privacy and security, are addressed in a way that reflects both the user's obligations and the provider's capabilities. Moving any data to the cloud raises privacy and security issues, but moving PHI to the cloud raises special concerns. When PHI resides on servers that are owned by a CE, the ability to control and protect the PHI is entirely within the CE's power. When PHI resides on the cloud, however, the CE must make sure that its contract with the cloud provider properly addresses the cloud provider's obligations, including privacy and security obligations, whether through a BAA or other contract provisions. Many public cloud providers offer their services on a nonnegotiable, take-it-or-leave-it basis, sometimes as an online clickwrap agreement. A CE should be extremely cautious before moving any PHI to a cloud provider that refuses to negotiate contract terms. One size does not fit all, and especially not when PHI is involved. In addition, most cloud providers service users in multiple business sectors (for example, retail, manufacturing and service professions) and their protocols are not specifically adapted to a particular type of data such as PHI, which has significant and specialized compliance and regulatory requirements. There is some speculation that a niche industry of cloud providers that are specifically set up and designed to handle PHI might develop. Sometimes entities referred to as integrators buy access to cloud services in bulk and resell the access in smaller increments to users. Integrators may be willing to enter into customized contracts with users, but users should determine whether the integrator is: In fact able to provide any customized services or protocols that are promised. Assuming liability beyond that of the cloud provider to the integrator. Also, the integrator's financial stability should be a crucial factor in the user's purchasing decision. Contracts with cloud providers should include all the standard provisions found in any contract for services, including: Identification of the parties. The term of the agreement. Termination provisions. Notice provisions and procedures. Liability and indemnification provisions. In addition, contracts with cloud providers should include, either in the body of the contract or as an appendix or exhibit, SLAs that establish technical performance promises and the penalties that will be paid or remediation that will be undertaken if the promised level of performance is not met. Some of the key contract and SLA provisions that should be considered when negotiating or evaluating a contract with a cloud provider include: User tools (see User Tools). Disaster recovery (see Disaster Recovery). Audit rights (see Audit Rights). Unilateral changes to protocols (see Unilateral Changes to Protocols). Security and privacy (see Security and Privacy). Return of data (see Return of Data). Intellectual property rights (see Intellectual Property Rights). Encryption (see Encryption). Data location (see Data Location). User Tools Cloud providers generally offer tools that allow their customers to establish privacy and security protocols to meet the customers' particular needs. If the customer is a CE, it should have a clear understanding of: What tools are available and how the protocols can be configured. Which privacy and security protections the cloud provider has in place on an enterprise-wide basis. Before entering into a contract, the CE should determine whether the tools and provider protections offer sufficient strength and flexibility to meet the CE's needs. It is equally important for the CE to make use of the tools to protect its data appropriately. A CE that has poor privacy and security in place at its own facilities and on its own servers, and that does not actively manage access to PHI in the cloud, might not automatically gain better privacy and security simply by moving PHI to the cloud, even if the cloud provider has strong privacy and security protections in place. Disaster Recovery Responsibility for the various aspects of disaster recovery should always be addressed in contracts with cloud providers. Recovery might be easier for data stored on the cloud rather than on a CE's own servers because cloud providers generally offer multiple redundancy, which means that: The customer's PHI is copied, updated and stored on servers at several locations. A disaster affecting one location still leaves the PHI available from other locations. 4

5 The exact requirements for redundancy should be covered in the contract. Audit Rights Cloud providers are often in the process of simultaneously: Adding capacity and customers. Making changes to their systems and protocols. Therefore, CEs should include an audit provision in their contracts with cloud providers so that a CE can periodically review whether the cloud provider is implementing all of the privacy and security protections required by the contract and by the cloud provider's own privacy and security protocols. Some cloud providers do not grant audit rights to individual customers because allowing each customer to send in its own auditors might be disruptive. Instead, those cloud providers often arrange for an independent auditor to: Review the provider's systems and protocols, both as documented and as implemented. Make that single report available to all customers, or all customers that request it. However, the difficulty with any audit is that it is a snapshot of conditions at a particular time, and the cloud provider could make changes the next day that would not be visible to the user until the next audit. In response to this concern, continuous monitoring by users is becoming more common and is required for federal agency use of cloud services. A continuous monitoring process is described in NIST Special Publication Unilateral Changes to Protocols Contracts between CEs and cloud providers should always address the security, privacy and other protocols that will be implemented by the provider. However, the best contract provisions will be of no use if the cloud provider has the unilateral right to change its protocols. If the user is relying to any extent on the provider's protocols: The user should, at a minimum, have the right to advance notice of planned changes to those protocols. The notice should be given far enough in advance to permit the user to migrate its data if it finds the planned changes unacceptable. Migrating data can be time-consuming and expensive, though, so a better contract provision would prohibit the cloud provider from unilaterally changing protocols, or at least specified protocols that are of particular importance to the user, such as those relating to privacy and security. Security and Privacy The HIPAA privacy regulations require CEs to have in place appropriate administrative, technical and physical safeguards to protect the privacy of PHI (see Practice Note, HIPAA Privacy Rule). The HIPAA security regulations require CEs to implement reasonable and appropriate policies and procedures to address the administrative, technical and physical safeguards for electronic PHI (ephi) (see Practice Note, HIPAA Security Rule). Although the security regulations address numerous aspects of the protection of ephi, with a total of 54 standards and implementation specifications, these regulations: Are not prescriptive. Do not require use of specific tools, software, hardware or other protections. Instead, the security regulations are written in terms of taking reasonable and appropriate action, based on a: Risk assessment performed by the CE. Risk management plan developed by the CE based on the findings of the risk assessment, with periodic evaluations to address changes in circumstances or environment. The security standards and implementation standards essentially identify things that the CE should address but not how to address them. Also, the security regulations: Specifically permit the CE to use any security measures that allow for reasonable and appropriate implementation of the standards and implementation specifications. Require the CE to take into account the CE's size, complexity, capabilities, technical infrastructure, hardware and software security capabilities. While this approach is intended to allow scalability and flexibility, it puts the burden on the CE to determine exactly what is reasonable and appropriate, and leaves the CE with the risk that, if a breach occurs or a complaint is filed, HHS investigators might not agree with the CE's decisions regarding what was reasonable and appropriate. In addition, other than noting that any contract with a cloud provider should address privacy and security of PHI, it is difficult to provide advice on what privacy and security requirements should be in the contract. An effective approach likely involves: An evaluation by the CE of its risk assessment to determine whether it is up to date. Revising the CE's risk management plan as necessary based on the evaluation. Determining which privacy and security protocols and tools offered by the cloud provider will best protect the PHI. If the CE determines that a cloud provider cannot provide reasonable and appropriate privacy and security protection, the CE should attempt to find a cloud provider with better protections or should defer uploading PHI. Return of Data The HIPAA privacy regulations require that PHI be returned or destroyed at the termination of a BAA. However, any cloud user (not 5

6 Cloud Computing and HIPAA Privacy and Security just a CE) should be sure it has appropriate contractual provisions in place to prevent data from being breached or otherwise falling into the wrong hands after a contract with a cloud provider ends (see Practice Note, HIPAA Privacy Rule). Requirements for secure data deletion, on the cloud user's request, should be considered for inclusion in any contract with a cloud provider. Intellectual Property Rights Some cloud provider contracts are so broad that they purport to grant the provider rights in any intellectual property that is uploaded to the provider's servers. The risks inherent in these provisions are obvious, and any cloud user (not just CEs) should avoid giving away its intellectual property. Encryption Under the HIPAA security regulations, encryption (at rest and in transmission) is an addressable implementation specification (see Practice Note, HIPAA Security Rule). Regardless of whether a CE has encrypted its PHI before moving it to the cloud, it should contract for automatic encryption of everything that it uploads with: A robust encryption algorithm. Keys of specified strength. Clear provisions covering key management and access. Encryption adds a layer of protection and, if the encryption is done in a manner that meets HHS requirements, the PHI is not subject to the breach notification obligations put in place by the HITECH Act (see Practice Note, HIPAA Privacy Rule: Notification of Breach of Unsecured PHI). The cloud provider usually keeps a copy of the encryption key so that it can assist the customer in the event of access problems. There are also technological solutions that: Allow a user to encrypt all information before it is uploaded to the cloud provider. Keep the data encrypted while it is at rest on the provider's servers, with the user holding the encryption key. Whether these solutions will become widely used remains to be seen, but in the event of an access issue, they would make it difficult for the cloud provider to assist the user. Data Location Although the HIPAA privacy and security regulations do not require PHI to be maintained within the US, a contract provision prohibiting the cloud provider from moving data outside the US may avoid problems. Data protection requirements outside the US vary widely and often differ from US requirements, and storing data outside the US can trigger application of the laws of other countries. Risking less legal protection is undesirable, but so is risking the application of laws that may require significantly different rules with which the CE or other cloud user is not familiar. In addition, in the event of litigation, data that is subject to non-us laws may: Give rise to issues of personal jurisdiction, venue and service of process. Require the retention of counsel authorized to practice in the courts of the country where the data is stored. Service Level Agreements with Cloud Providers Contracts with cloud providers should always include, either as part of the contract itself or as an appendix or exhibit to the contract, SLAs that document: The metrics by which the provider's performance will be measured. The penalties that the cloud provider will pay for failure to meet the metrics. The subjects to be addressed in SLAs will depend, in part, on the type of services the user is purchasing from the cloud provider. For example, while all cloud users will want to address service availability, users of SaaS (see Software as a Service) will also want to include SLAs that address the timing of installation of software updates and patches. All agreements with cloud providers should include SLAs that address the following issues, among others. Availability Availability refers to the ability to access and use the cloud services. One of the underlying assumptions of cloud services, and a selling point, is that the cloud allows users to access data at any time, so that workers in different time zones or with diverse work schedules can be accommodated. But the definition of availability in the SLAs is important, and even a promise of 100% availability (except for scheduled downtime) might be misleading. For example, it may be unclear whether the SLAs define the service as available when: The cloud network is functioning and responsive, even though a user cannot access specific files. The specific files can be accessed but the system is slow in responding. In addition to defining availability carefully, the metrics for availability should also be defined. As two examples: There is a big difference between loading a file of a specified size within five seconds and within 30 seconds. A metric that defines unavailability as failure to load a file after three requests is much less satisfactory than a metric that requires only one failed request. Methods of measurement, and burden of proof, are also important. If the cloud user must notify the service provider of alleged unavailability, and provide evidence, the SLAs might be worthless. However, if there is a third-party availability monitoring system in place, the user's burden will be substantially lessened. The cloud provider should specifically address: The percentage of time that systems and data will be available. The maximum of planned downtime or scheduled outages (for example, for system maintenance). The schedule of planned downtime. Use of PLC websites and services is subject to the Terms of Use ( and Privacy Policy ( 6

7 How availability will be calculated. It is common to see availability metrics approaching 100%, but the method of calculating availability might make those promises illusory. The time intervals for measuring availability vary and can range from a low of five minutes (so that a four-minute failure does not count against the availability metrics) to a high of one hour or more (so that a 59-minute failure does not count). Also, the period over which availability is measured can range from one billing cycle to a year or more. The longer the time interval and the longer the period for measuring availability, the more downtime the user may experience without the cloud provider failing to meet its SLAs. In addition, the definition of availability should be reviewed carefully, to determine whether it includes all response failures or is limited to response failures with specific causes. Data Deletion The SLAs should specify an outside time limit for deletion of data. While data deletion often occurs on a regular schedule, the metrics for data deletion in special cases (for example, if the user is served with a cease and desist order) might vary and the time limits might be relatively short. Customer Service Although one of the underlying principles of cloud computing is that there is relatively little interaction between the workforces of the user and the provider, there will always be events requiring person-to-person communication. For those events, the SLAs should place an outside limit on provider response time. Depending on the service model, this SLA might need to separately address: Call center response time. Technical support response time. System Response Speed A slow system is often as much of a problem as a system that is down. Therefore, while the availability metrics address system outages, the SLAs should also address the response speed of the systems. The appropriate metrics for system response speed will depend on the service model and the user's specific needs. Responsiveness to Load Changes Flexibility is one of the hallmarks of cloud services, and cloud users expect to be able to increase their usage rapidly and easily, within any contractual limits. The SLAs should address and limit any lag that may occur between: The user's upload of additional data. The cloud system's ability to accommodate the data. Disaster Recovery Time Cloud providers usually store users' data in multiple locations (both logically and geographically) to be able to respond to disasters and catastrophic outages or failures. The SLAs should place an outside limit on the time it will take the cloud provider to deliver availability on redundant systems. When availability is provided through redundant systems, there should also be a limit on how long it takes the cloud provider to return its other systems to availability so that any contractual terms regarding the number of redundant systems or copies of data are not violated. Other Issues Any provision in a cloud service contract that can be quantified can also be reflected in the SLAs. SLAs should also specify: How the penalties for failures to meet the metrics are calculated. How the penalties are received by the users (for example, as setoffs against fees owed by the user, no-fee extensions of services). When the penalties are received by the users (for example, setoffs against future fees or fees currently owed). For the links to the documents referenced in this note, please visit our online version at For more information on HIPAA compliance, search for the following resources on our website. Practice Notes: HIPAA Privacy Rule ( Security Rule ( Practical Law Company provides practical legal know-how for law firms, law departments and law schools. Our online resources help lawyers practice efficiently, get up to speed quickly and spend more time on the work that matters most. This resource is just one example of the many resources Practical Law Company offers. Discover for yourself what the world s leading law firms and law departments use to enhance their practices. To request a complimentary trial of Practical Law Company s online services, visit practicallaw.com or call