Skip to main content
Top Button
On Cloud Nine - OCR’s Guidance on HIPAA and Cloud Computing On Cloud Nine - OCR’s Guidance on HIPAA and Cloud Computing

On Cloud Nine - OCR’s Guidance on HIPAA and Cloud Computing

Businesses of all types, including HIPAA covered entities (CE) and business associates (BA), depend on cloud solutions to meet their data management needs. Properly managed, the cloud may be more secure than paper or portable media, which can be physically lost or stolen. Other benefits include automatic software integration, simplified backup and recovery, access to data from multiple locations, almost unlimited storage, and rapid deployment – all without additional investment in hardware. Countering these benefits, however, are the risks attendant to the cloud customer's loss of control over its data. Covered entities and business associates must balance these benefits and risks when considering whether to maintain electronic protected health information (ePHI) in the cloud.

Regulated entities are not performing this risk/benefit analysis in a vacuum: the U.S. Department of Health and Human Services, Office for Civil Rights (OCR) also has cloud computing on its radar screen. OCR has settled three cases of alleged HIPAA Rule violations directly related to the covered entities' use of cloud services. Further, the agency recently issued highly-anticipated guidance to industry on cloud-related compliance. Finally, on October 13, 2016, OCR released a memorandum entitled Health Information Privacy in the Digital Age: Where to Focus Enforcement Efforts, in which it advises regulated entities to “get out in front of problems" with guidance-related topics (presumably including the cloud) before they amount to violations. The memorandum also emphasizes that OCR will "continue" to focus its enforcement efforts and its resources on cases that “identify industry-wide noncompliance, where corrective action under HIPAA may be the only remedy, and where corrective action benefits the greatest number of individuals.”

The takeaways?
  • Covered entities and business associates should direct compliance efforts toward cloud issues before they become violations.
  • If a cloud-related violation does occur, OCR may be less likely to resolve it through technical assistance or voluntary compliance, and more likely to turn to a monetary settlement and corrective action plan or a civil money penalty. As noted in OCR's October 13 memorandum, the agency's expenditure of resources and enforcement efforts signals that it has identified the cloud as an area of industry-wide noncompliance, an issue for which corrective action may be the only remedy, and/or a circumstance for which corrective action benefits the greatest number of individuals.
  • Third, if OCR does seek a resolution involving a monetary settlement or a civil money penalty, the amount will likely be higher because the CE or BA will have a hard time demonstrating that it did not know it was violating the HIPAA Rules, that it could not have known of the violation despite exercising reasonable diligence, or even that the violation was due to reasonable cause rather than willful neglect.[1]
  • To minimize risks to ePHI, CEs and BAs should approach the cloud thoughtfully, avoiding user-level/ad hoc decisions, and include proposed cloud solutions in their Security Rule risk analyses and risk management plans.

While "the cloud" has become a modern buzz phrase, it is a relatively new business model and a solid definition can be elusive. Simply put, cloud computing is the use of remote computing resources, as opposed to in-house, hosted computer infrastructure. The cloud operates on the core characteristics of on-demand self-service, broad network access, resource pooling, rapid elasticity or expansion, and measured service.[2] In 2011, the U.S. Department of Commerce's National Institute of Standards and Technology (NIST) described cloud computing 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."[3]

Cloud service providers (CSPs), generally offer the following deployment models:[4]
  • Public Clouds. The CSP makes infrastructure and computational resources available to the general public over the internet. The platform is owned and operated outside customers' organizational environments.
  • Private Clouds. The computing environment is operated exclusively for a single organization, and may be managed and/or hosted internally or externally.
  • Community Clouds. Infrastructure and computational resources are exclusive to two or more organizations with common privacy, security, and regulatory considerations.
  • Hybrid Clouds. Typically involve a composition of two or more clouds. Each member remains a separate entity, but is tied to the others through standardized or proprietary technology that enables application and data portability.
In practice, CSPs offer a multitude of cloud-based models that incorporate unique functionality to make specialized offerings to their customers.

NIST notes that "[w]hile the choice of deployment model has implications for the security and privacy of a system, the deployment model itself does not dictate the level of security and privacy of specific cloud offerings. That level depends mainly on assurances … furnished by the cloud provider or independently attained by the [customer] (e.g., via independent vulnerability testing or auditing of operations)."[5]

Clouds also conform to a variety of service delivery models, including:[6]
  • Software-as-a-service (SaaS): The CSP provides applications, and the computational resources to run them, on demand as a turnkey service. The CSP carries out most security provisions. Customers' control over the underlying infrastructure and individual applications is limited to "preference selections and limited administrative application settings."
  • Platform-as-a-service (PaaS): The CSP provides the platform as an on-demand service on which customers can develop and deploy applications. The CSP and customers share security provisions. Customers control applications and the platform's application environment settings.
  • Infrastructure-as-a-service (IaaS): The CSP provides servers, software, and network equipment on-demand on which customers can establish a platform to develop and execute applications. The customer carries out security provisions beyond the basic infrastructure. The customer chooses the operating system and development environment.
NIST notes that "[t]he service model to which a cloud conforms dictates an organization's scope and control over the computational environment ….."[7]


The Security Rule does not directly address cloud services. It does, however, require CEs and BAs to ensure: (i) the confidentiality, integrity, and availability of "all" ePHI they create, receive, maintain, and transmit;[8] (ii) protection against reasonably anticipated threats or hazards to security or integrity;[9] (iii) and protection against reasonably anticipated uses and disclosures that violate the Privacy Rule.[10]

To achieve these goals, CEs and BAs must implement specified administrative, physical, and technical safeguards.[11] However, this can be challenging for CEs and BAs who rely on a CSP to maintain ePHI. The Security Rule requires CEs and BAs to conduct an accurate and thorough assessment of potential risks and vulnerabilities to all ePHI they hold (i.e. a risk analysis).[12] In a cloud environment, a CE or BA must consider the potential risks and vulnerabilities inherent to the CSP, and how the CSP is managing them to a reasonable and appropriate level. Because a CSP that creates, receives, maintains, or transmits ePHI on the CE's or BA's behalf is a business associate, the Security Rule requires that the CE or BA obtains "satisfactory assurances" from the CSP, in the form of a business associate agreement, that the CSP will appropriately safeguard the information,[13] including assurances that it will use appropriate safeguards and comply with the Security Rule regarding ePHI.[14] CEs and BAs must also consider other measures, such as independently reviewing the CSP’s risk assessment and risk management plan, if the CSP’s assurances are not enough to discharge the CE's or BA's duty to protect ePHI. This will be a fact-specific inquiry considering such factors as the nature and amount of ePHI, and the current threat environment.

Ultimately, regulated entities must ensure that any move into the cloud can withstand the rigors of the HIPAA Rules.


Past OCR enforcement underscores several points that apply generally to regulated entities. CSPs that are business associates, as well as their covered entity clients, should consider the importance of an enterprise-wide risk analysis that considers less conventional or traditional ePHI repositories, such as the cloud. Regulated entities must follow up on their risk analysis by implementing an informed risk management plan designed to reduce identified risks and vulnerabilities to a reasonable and appropriate level.

Make no mistake: risk analysis and risk management are the cornerstone of a CE's or BA's compliance program. On October 19, 2016, at a conference entitled Safeguarding Health Information: Building Assurance Through HIPAA Security (hosted by OCR and NIST), OCR Director Jocelyn Samuels discussed risk analysis in her keynote address, and emphasized is both "fundamental" and "foundational" to an organization's security management process.

Regulated entities should also attend carefully to the specifics of their business associate relationships with CSPs. OCR's enforcement history makes clear that a business associate agreement is more than a “check-the-box paperwork exercise.” It is “critical” for regulated entities to know to whom they are disclosing ePHI, and to obtain assurances that the recipient will protect the information.

In addition to these generally-applicable settlements, OCR has entered into three settlements directly related to covered entities' management of ePHI in the cloud.

1.      Phoenix Cardiac Surgery, P.C. (2012)

OCR began an “extensive” investigation of Phoenix Cardiac Surgery, P.C. (PCS) after receiving a report (perhaps from a patient) that workforce members were posting patients’ clinical and surgical appointments on a publicly-accessible internet-based calendar. OCR’s investigation revealed that PCS failed to implement reasonable and appropriate administrative and technical safeguards for ePHI, failed to conduct a risk analysis, and failed to obtain satisfactory assurances from the CSP offering the internet-based calendar that it would appropriately safeguard the provider's ePHI.

PCS agreed to a settle potential HIPAA Rule violations by paying a $100,000 resolution amount, and implementing a corrective action plan that included developing, maintaining, implementing, and distributing policies and procedures that addressed, at a minimum: a risk analysis and risk management plan that included the internet-based calendaring system; identifying a security official; entering compliant business associate agreements with each person that receives, maintains, stores, or transmit ePHI on the PCS's behalf; and workforce training.

Former OCR Director Leon Rodriguez commented:

This case is significant because it highlights a multi-year, continuing failure on the part of this provider to comply with the requirements of the Privacy and Security Rules. We hope that health care providers pay careful attention to this resolution agreement and understand that the HIPAA Privacy and Security Rules have been in place for many years, and OCR expects full compliance no matter the size of a covered entity.
2.      St. Elizabeth's Medical Center (2015)
OCR investigated a complaint against St. Elizabeth's Medical Center in Brighton, Massachusetts, alleging that workforce members stored at least 498 individuals' ePHI using an internet-based document sharing application without first analyzing associated risks.[15] OCR determined St. Elizabeth’s wrongfully disclosed at least 1,093 individuals’ PHI – including those whose PHI was stored in the application[16] – and failed to implement security measures for transmitting and storing ePHI sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level (i.e., failed to implement a risk management plan).[17]
The hospital agreed to pay a $218,400 resolution amount, and entered into 1-year a corrective action plan with OCR requiring the hospital to, among other things:
  • Conduct a self-assessment of workforce members’ familiarity and compliance with hospital policies and procedures for transmitting ePHI using unauthorized networks, and storing ePHI on unauthorized information systems;
    • Conduct unannounced site visits to hospital department to assess implementation of these policies and procedures; and
    • Interview 15 randomly-selected workforce members with access to ePHI, including interns, residents, and fellows;
  • Provide OCR a report documenting the self-assessment, identifying material compliance issues and recommending improvements to policies and procedures, oversight and supervision, and training;
  • As necessary and informed by the self-assessment:
    • Revise policies and procedures, develop an oversight mechanism reasonably tailored to ensure that all workforce members follow them, and submit the revised policies and procedures and oversight mechanism to OCR for review; and
    • Draft appropriate revisions to workforce training materials and submit them to OCR for review;
  • Distribute a “security reminder” reflecting the content of the revised policies and procedures and training materials to all workforce members with access to ePHI, incorporate the training into its next annual refresher training, and provide training to new workforce members with access to ePHI within 60 days of employment; and
  • Upon determining that a workforce member failed to comply with applicable policies and procedures, report the event to OCR, describing the event, the actions taken to address the matter, mitigate harm, and prevent reoccurrence, and sanctions imposed.
Commenting on the settlement, OCR Director Jocelyn Samuels stated
Organizations must pay particular attention to HIPAA’s requirements when using internet-based document sharing applications. In order to reduce potential risks and vulnerabilities, all workforce members must follow all policies and procedures, and entities must ensure that incidents are reported and mitigated in a timely manner.
3.      Oregon Health & Science University (2016).

OCR began investigating Oregon Health & Science University (OHSU) after the provider submitted multiple breach reports affecting thousands of individuals. OCR's investigation revealed evidence of "widespread vulnerabilities" within OHSU's compliance program, including the storage of more than 3,000 individuals' ePHI on a cloud-based server without a business associate agreement. More than 1,300 of these individuals were significantly harmed because of the disclosure of their sensitive diagnoses. Although OHSU has performed many risk analyses, they were not enterprise-wide as the Security Rule requires. Further, the provider did not timely implement safeguards to reduce identified risks and vulnerabilities to a reasonable and appropriate level.
OCR Director Jocelyn Samuels commented:
From well-publicized large scale breaches and findings in their own risk analyses, OHSU had every opportunity to address security management processes that were insufficient. Furthermore, OHSU should have addressed the lack of a business associate agreement before allowing a vendor to store ePHI. This settlement underscores the importance of leadership engagement and why it is so critical for the C-suite to take HIPAA compliance seriously.

Given OCR's enforcement history and its October 13 memorandum, regulated entities are well advised to prioritize risk assessment and management for their cloud-based activities. However, rather than thoughtfully approaching cloud solutions from a security management perspective, many CEs and BAs continue to: (1) persist in using cloud services ignorant of, or willfully blind to, HIPAA implications; (2) reject the cloud out of hand, on the assumption they can never be compliant; or (3) take no official internal position on cloud computing, with workforce members making ad hoc decisions that may be inconsistent and almost certainly put ePHI at risk.
OCR's recent guidance acknowledges that cloud services are quickly becoming ubiquitous in the regulated community. Its stated goal is to help HIPAA-regulated cloud service providers (CSPs) and their customers (CEs and BAs) understand their various roles and responsibilities. Using a question-and-answer format, the guidance states:
1.      A covered entity or business associate can engage cloud services, but only after implementing administrative, technical, and physical safeguards for ePHI.
The regulated cloud services customer (a CE or BA), must:
  • Have executed a business associate agreement with the CSP before disclosing ePHI. This is the primary lesson from the OHSU settlement. When a covered entity or business associate uses a CSP to create, receive, maintain, or transmit ePHI on the CE's or BA's behalf, the CSP is a HIPAA business associate. The CSP and its customer must treat the relationship as a business associate relationship, even if the CSP provides "no-view" services (i.e., maintains only encrypted ePHI and cannot decrypt it and access or view it). A regulated customer cannot disclose ePHI to a CSP (i.e., transmit the data to the cloud platform) unless and until the CSP provides written "satisfactory assurances" that it will appropriately safeguard the information.[18] This means that the CSP and its customer must execute a HIPAA-compliant business associate agreement."[19]
The parties should also consider whether to execute a service-level agreement (SLA). Generally, an SLA "describes levels of service using various attributes such as availability, serviceability or performance. The SLA specifies thresholds and financial penalties associated with violations of these thresholds."[20] These attributes and thresholds can relate to various aspects of HIPAA compliance. The SLA is a cloud computing concept: the HIPAA Rules do not define, address, or require SLAs. Still, the parties should ensure that the terms of their BAA are consistent with the SLA’s provisions.
  • Conduct a risk analysis and implement a risk management plan. The Security Rule requires that regulated entities implement a security management process that includes a risk analysis and risk management plan. A risk analysis is an "accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI" held by the CE or BA.[21] The purpose of the risk analysis – like all Security Rule standards and implementation specifications – is to enable CEs and BAs to carry out their mission of ensuring the confidentiality, integrity, and availability of “all” ePHI they create, receive, maintain, or transmit, wherever it is located.[22] A risk analysis cannot account for "all" the CE's or BA's ePHI unless the entity knows where its data is located. An enterprise data map diagramming the location and interior and exterior flows of ePHI is essential to the RA and must include unconventional and perhaps ad hoc repositories such as the cloud.
  • The regulated customer must understand the CSP's unique environment or solution in order to effectively identify attendant risks and vulnerabilities in the risk analysis. For example, is the service model software, platform, or infrastructure? Is the deployment model private, community, public, or hybrid?
  • A risk management plan follows on the risk analysis and consists of security measures sufficient to reduce the identified risks and vulnerabilities to a "reasonable and appropriate level."[23]
  • Carefully consider mobile device security. Mobile device security is a hot-button issue with OCR, and many enforcement actions have lost, stolen, or compromised smartphones, laptops, and thumb drives at their root. The guidance makes clear that CEs and BAs may use mobile devices to access ePHI in the cloud, so long as the appropriate administrative, technical, and physical safeguards are in place (for example, risk analysis and a risk management plan; physical device security; access controls; and employee training), and there are compliant business associate agreements in place.
  • Consider the implications of servers located outside the United States. A CE or BA can contract with a CSP that stores ePHI on servers outside the U.S., so long as the parties enter into a business associate agreement and otherwise remain compliant. However, OCR does not set specific requirements for protecting ePHI processed in this way, and advises CEs and BAs that risks and vulnerabilities may vary greatly depending on physical location. The parties should account for these risks and vulnerabilities in their risk analyses and risk management plans.[24]
2.      Consider the implications for no-view CSP relationships.

Business Associates, Not Conduits
A business associate is a person who creates, receives, maintains, or transmits ePHI on behalf of a covered entity performing HIPAA-covered functions.[25] Cloud providers that receive and/or maintain ePHI on behalf of the CE (rather than for their own purposes) meet the definition of BA, and both parties must treat the relationship as such, including entering a compliant business associate agreement. It would be difficult to imagine an arrangement between a cloud provider and a CE or BA that is not a BA arrangement. Further, OCR makes clear that a CSP who creates, receives, maintains, or transmits PHI on a regulated customer's behalf is a business associate, even if it cannot view the ePHI because it is encrypted and the CSP does not have the decryption key.
OCR rejects the argument that no-view CSPs are "mere conduits" rather than business associates. The conduit exception to business associate status arose in connection with the United States Postal Service and private mail couriers. These entities transport PHI, but do not access it other than on a "random and infrequent" basis attendant to the transportation function. OCR recognizes that these conduits are not business associates because the covered entity does not intend any disclosure, and because there is only a "very small" probability that PHI will be exposed to the conduit.
The conduit exception, however, is limited to transmission services in which the conduit has only transient access to ePHI. A CSP that maintains ePHI for storage purposes has persistent access to the ePHI, even if it cannot view the information. Even if the CSP also provides transmission services, is still a business associate because conduit status is limited to entities that only transmit data, but do not store it (except perhaps for temporary storage incidental to the transmission service).
While these CSPs are not exempt from HIPAA Rule requirements, the parties have flexibility to structure their business associate relationship.
Security Rule
When the CSP provides no-view services, the Security Rule allows the parties flexibility to structure the BAA appropriately. For example, if the CE or BA customer implements its own reasonable and appropriate unique user identification[26] and authentication[27] controls, the parties may agree that the CSP need not implement redundant controls. However, the CSP may retain responsibility for other safeguards related to the customer's ePHI (such as encryption),[28] as well as the full suite of security measures for its own administrative tools (storage, memory, network interfaces, CPUs, etc.).
Privacy Rule

Even if the CSP cannot access the customer's encrypted ePHI, it still must use and disclose it only as the BAA and Privacy Rule permit, or as the law requires. This means, for example, that the CSP may not block or terminate the customer's access to data to resolve a payment dispute. Further, the BAA must address how the CSP will allow the customer to meet its obligations to individuals who want exercise their rights regarding ePHI. For example, the BAA may provide that if an individual wishes to exercise her right to request an amendment of her ePHI, the CSP will make the data available to the customer, but only the customer will make the amendments.

Breach Notification Rule

A no-view CSP must notify its customer of a breach of unsecured protected health information.[29] Electronic protected health information is "unsecured" unless it has been rendered unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology or methodology specified by HHS.[30] Encryption can render ePHI unusable, unreadable, or indecipherable, but only if the encryption meets HHS standards as described in HHS's Guidance to Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals. Encrypted ePHI is "unsecured" if the encryption does not meet this standard, or if the decryption key is compromised.

If unsecured ePHI is acquired, accessed, used, or disclosed in a manner contrary to the Privacy Rule, the CSP must report the incident to its customer unless it determines there was no "breach" (i.e., that the incident did not compromise the privacy or security of the ePHI), or unless a breach exception applies.[31]

3.      What if a CSP does not know a regulated entity is using its services to create, receive, maintain, or transmit ePHI?

The Enforcement Rule establishes an affirmative defense for CSPs in this position. HHS cannot impose a civil money penalty for an alleged violation of the HIPAA Rules if the CSP demonstrates that the violation was not due to willful neglect, and corrects the violation within 30 days of the date it knew (or by exercising reasonable diligence would have known) the violation occurred.[32] Therefore, when a CSP learns it is maintaining ePHI, it has 30 days to either come into compliance (including executing a BAA), or securely return the ePHI to the regulated entity (at which point it is no longer a BA).

4.      CSPs who are business associates must report security incidents to their regulated customers.

A "security incident" is the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system.[33] The Security Rule requires business associates (including CSPs) to report known security incidents, including breaches of unsecured PHI, to the CEs and BAs that engage them.[34]

The Security Rule takes a flexible approach to notice and the parties may set out different levels of reporting detail, frequency, and format depending on the level of threat or exploited vulnerabilities involved in the security incident.[35] The Breach Notification Rule, however, takes a much more regimented approach to breach notification (including strict time limits for notice), and the parties are much less free to modify Breach Notification Rule requirements.[36]

OCR has issued guidance on reporting security incidents.[37]

5.      Can regulated customers demand to audit a CSP's security practices?

The HIPAA Rules do not expressly require BAs (including CSPs) to submit to customer audits or provide customers with documentation of their security practices. However, the Rules do not prevent a customer – based on the customer's risk analysis and risk management plan –from requiring additional security assurances in the BAA, an SLA, or otherwise. The question then becomes whether the parties will choose to work together.


Cloud computing has far-reaching privacy and security implications for HIPAA covered entities and business associates. As NIST notes,"[m]any of the features that make cloud computing attractive … can also be at odds with traditional security models and controls."[38] OCR's recent guidance emphasizes actions CEs and BAs should take to help ensure that any cloud solution they employ is consistent with the goal of safeguarding the confidentiality, integrity, and availability of ePHI:

1.      Be proactive. Incorporate proposed cloud solutions into your risk analysis and risk management plan before you deploy them. Post-deployment security management is more difficult and costly, and exposes the organization to unnecessary risk.

2.      Understand what the CSP offers. Regulated entities should understand not only the CSPs service and deployment models, but also how privacy and security responsibilities will be assigned. This includes:
  • Where possible, independently verifying the CSP's assurances supporting privacy and security claims, and any certification or compliance review the CSP provides.
  • Understanding the CSP's policies, procedures, and technical controls. This is important for conducting your own risk analysis and risk management plan.
3.      Analyze the CSP's system architecture to more fully understand the associated privacy and security controls.         

4.      Make sure the cloud solution satisfies your organization's privacy and security needs. Remember:
  • A CSP's "default" configuration, deployment, and management may not suit your data, your business, or your risk tolerance.
  • A CSP's "non-negotiable" SLA may, in fact, have some give. Specific areas to consider for a negotiated service agreement include employee vetting, data ownership and exit rights, data encryption and segregation, and the like. If negotiation is not possible, your organization may be able to include compensating controls in your risk management plan to manage risks and vulnerabilities to a reasonable and appropriate level. Other deployment models, such as an internal private cloud, may also manage risks and vulnerabilities.
5.      Ensure your own computing environment can meet the cloud's more exacting demands. This includes addressing the security risks attendant to apps and web browser add-ons; maintaining physical security for portable electronic devices; and examining your use of social media and personal webmail (which can be vectors for social engineering-based cyberattacks).

6.      Remain accountable for the privacy and security of data and applications in public cloud computing environments. Continue to employ appropriate security management processes, including continuous monitoring of information systems. This may be challenging because the CSP controls much of the cloud environment. Risk analysis and risk management are central to reducing risk to an appropriate level, as is ensuring that security and privacy controls are implemented, work as intended, and meet the organization's needs. If at any point in the relationship the CSP cannot continue to provide "satisfactory assurance" that it can safeguard the customer's ePHI, the HIPAA Rules may require the customer to terminate the relationship.


Cloud computing offers myriad data management benefits to covered entities and business associates, but is not without significant risk to the confidentiality, integrity, and availability of ePHI. Regulated entities now have OCR guidance to assist in structuring relationships with cloud service providers to appropriately safeguard ePHI. CEs and BAs should ensure their risk analyses and risk management plans incorporate proposed cloud solutions, and that they carefully attend to the business associate aspects of relationships with CSPs.

For more information on HIPAA compliance and cloud computing, please contact Kim Metzger, Sid Bose, or a member of our Data Security and Privacy team.

This publication is intended for general information purposes only and does not and is not intended to constitute legal advice. The reader should consult with legal counsel to determine how laws or decisions discussed herein apply to the reader’s specific circumstances.

[1] See 45 CFR 160.404 – the amount of the civil money penalty OCR can seek increases with the CE’s or BA’s level of culpability. Available amounts are lower for the “did not know” and “reasonable cause” violation categories, and higher for the “willful neglect” categories.
[2] Id.
[3] NIST SP 800-145, The NIST Definition of Cloud Computing.
[4] Id. p. 3.
[5] Id. pp. 3-4
[6] Id. p. 4
[7] Id.
[8] 45 CFR 164.306(a)(1)
[9] 45 CFR 164.306(a)(2)
[10] 45 CFR 164.306(a)(3)
[11] 45 CFR 164.306 – 164.314
[12] 45 CFR 164.306
[13] 45 CFR 164.308(b)(2)
[14] 45 CFR 164.314(a)(2)(i)(A)
[15] In a separate incident, St. Elizabeth's notified OCR of a breach of 595 individuals’ unsecured ePHI stored on a former workforce member’s personal laptop and flash drive.
[16] 45 CFR 160.103 and 164.502(a)
[17] 45 CFR 164.308(a)(1)(ii)(B)
[18] 45 CFR 164.502(e)(1)(i)
[19] 45 CFR 164.504(e)(1)
[20] Cloud Standards Consumer Council, Practical Guide to Cloud Service Agreements, Version 2.0.
[21] 45 CFR 164.308(a)(1)(ii)(A)
[22] 45 CFR 164.306(a)(1)
[23] 45 CFR 164.308(a)(1)(ii)(B)
[24] 45 CFR 164.308(a)(1)(ii)(A) and (a)(1)(ii)
[25] 45 CFR 160.103
[26] 45 CFR 164.312(a)(2)(i)
[27] 45 CFR 164.312(d)
[28] 45 CFR 164.312(a)(2)(iv)
[29] 45 CFR 164.410(a).
[30] 45 CFR 164.402.
[31] An unauthorized acquisition, access, use, or disclosure is not a reportable breach unless it "compromises the security or privacy of the [PHI]." (45 CFR 164.402). However, a breach is presumed unless the CSP demonstrates--based on a risk assessment –a low probability that the PHI has been compromised. (45 CFR 164.402
[32] 45 CFR 160.410(b).
[33] 45 CFR 164.304
[34] 45 CFR 164.314(a)(2)(i)(C)
[35] 45 CFR 164.306(b)
[36] 45 CFR 164.410
[37] Although the guidance specifically addresses covered entities who are health plans, it is generally applicable to other types of CEs, and to BAs.
[38] NIST SP 800-144, supra, at vi.
View Full Site View Mobile Optimized