Healthcare organisations frequently turn to managed service providers (MSPs) to deploy and manage private, hybrid or public cloud solutions. MSPs play a crucial role in ensuring that healthcare organisations maintain secure and HIPAA compliant infrastructure.
Although most MSPs offer the same basic services – cloud design, migration, and maintenance – the MSP’s security expertise and their ability to build compliant solutions on both private and public clouds can vary widely.
Hospitals, healthcare ISVs and SaaS providers need an MSP that meets and exceeds the administrative, technical, and physical safeguards established in HIPAA Security Rule. The following criteria either must or should be met by an MSP:
1. Must offer business associate agreements
An MSP must offer a Business Associate Agreement (BAA) if it hopes to attract healthcare business. When a Business Associate is under a BAA, they are subject to audits by the Office for Civil Rights (OCR) and could be accountable for a data breach and fined for noncompliance.
According to HHS, covered entities are not required to monitor or oversee how their Business Associates carry out privacy safeguards, or in what ways MSPs abide by the privacy requirements of the contract. Furthermore, HHS has stated that a healthcare organisation is not liable for the actions of an MSP under BAA unless otherwise specified.
An MSP should be able to provide a detailed responsibility matrix that outlines which aspects of compliance are the responsibility of whom. Overall, while an MSP allows healthcare organisations to outsource a significant amount of both the technical effort and the risk of HIPAA compliance, organisations should still play an active role in monitoring MSPs. After all, an OCR fine is often the least of an organisation’s worries in the event of a security breach; negative publicity is potentially even more damaging.
2. Should maintain credentials
There is no “seal of approval” for HIPAA compliance that an MSP can earn. The OCR grants no such qualifications. However, any hosting provider offering HIPAA compliant hosting should have had their offering audited by a reputable auditor against the HIPAA requirements as defined by HHS.
In addition, the presence of other certifications can assist healthcare organisations in choosing an MSP that takes security and compliance concerns very seriously. A well-qualified MSP will maintain the following certifications:
- SAS70 Type II
- SOX Compliance
- PCI DSS Compliance
While these certifications are by no means required for HIPAA compliance, the ability to earn such qualifications indicates a high level of security and compliance expertise. They require extensive (and expensive) investigations by 3rd party auditors of physical infrastructure and team practices.
3. Should offer guaranteed response times
Providers should indicate guaranteed response times within their Service Level Agreement. While 24/7/365 NOC support is crucial, the mere existence of a NOC team is not sufficient for mission-critical applications; healthcare organisations need a guarantee that the MSP’s NOC and security teams will respond to routine changes and to security threats in a timely manner. Every enterprise should have guaranteed response times for non-critical additions and changes, as well.
How such changes and threats are prioritized and what response is appropriate for each should be the subject of intense scrutiny by healthcare organisations, who also have HIPAA-regulated obligations in notifying authorities of security breaches.
4. Must meet data encryption standards
The right MSP will create infrastructure that is highly secure by default, meaning that the highest security measures should be applied to any component where such measures do not interfere with the function of the application. In the case of data encryption, while HIPAA’s Security Rule only requires encryption for data in transit, data should reasonable be encrypted everywhere by default, including at rest and in transit.
When MSPs and healthcare organisations encrypt PHI, they are within the “encryption safe harbor.” Unauthorised disclosure will not be considered a breach and will not necessitate a breach notification if the disclosed PHI is encrypted.
Strong encryption policies are particularly important in public cloud deployments. The MSP should be familiar with best practices for encrypting data both within the AWS environment and in transit between AWS and on-site back-ups or co-location facilities. We discuss data encryption best practices for HIPAA compliant hosting on AWS here.
It is important to note that not all encryption is created equal; look for an MSP that guarantees at least AES-256 Encryption, the level enforced by federal agencies. It is useful to note that AWS’ check-box encryption of EBS volumes meets this standard.
5. Should have “traditional IT” and cloud expertise
Major healthcare organisations have begun to explore public cloud solutions. However, maintaining security in public clouds and in hybrid environments across on-premises and cloud infrastructure is a specialty few MSPs have learned. “Born in the Cloud” providers, whose businesses started recently and are made up exclusively of cloud experts, are quite simply lacking the necessary experience in complex, traditional database and networking that would enable them to migrate legacy healthcare applications and aging EHR systems onto the public cloud without either a) over-provisioning or b) exposing not-fully-understood components to security threats.
No matter the marketing hype around “Born in the Cloud” providers, it certainly is possible to have best-in-class DevOps and cloud security expertise and a strong background in traditional database and networking. In fact, this is what any enterprise with legacy applications should expect.
Hiring an MSP that provides private cloud, bare metal hosting, database migrations, legacy application hosting, and also has a dedicated senior cloud team is optimal. This ensures that the team is aware of the unique features of the custom hardware that currently supports the infrastructure, and will not expose the application to security risks by running the application using their “standard” instance configuration.
6. Must provide ongoing auditing and reporting
HIPAA Security Rule requires that the covered entity “regularly” audit their own environment for security threats. It does not, however, define “regularly,” so healthcare organisations should request the following from their MSPs:
- Monthly or quarterly engineering reviews, both for security concerns and cost effectiveness
- Annual 3rd party audits
- Regular IAM reports. A credential report can be generated every four hours; it lists all of the organisations users and access keys.
- Monthly re-certification of staff’s IAM roles
- Weekly or daily reports from 3rd party security providers, like Alert Logic or New Relic
7. Must maintain compliant staffers and staffing procedures
HIPAA requires organisations to provide training for new workforce members as well as periodic reminder training. As a business associate, the MSP has certain obligations for training their own technical and non-technical staff in HIPAA compliance. There are also certain staff controls and procedures that must be in place and others that are strongly advisable. A covered entity should ask the MSP the following questions:
- What formal sanctions exist against employees who fail to comply with security procedures?
- What supervision exists of employees who deal with PHI?
- What is the approval process for internal collaboration software or cloud technologies?
- How do employees gain access to your office? Is a FOB required?
- What is your email encryption policy?
- How will your staff inform our internal IT staff of newly deployed instances/servers? How will keys be communicated, if necessary?
- Is there a central authorisation hub such as Active Directory for the rapid decommissioning of employees?
- Can you provide us with your staff’s HIPAA training documents?
- Do you provide security threat updates to staff?
- What are internal policies for password rotation?
- (For Public Cloud) How are root account keys stored?
- (For Public Cloud) How many staff members have Administrative access to our account?
- (For Public Cloud) What logging is in place for employee access to the account? Is it distinct by employee, and if federated access is employed, where is this information logged?
While the answers to certain of these questions do not confirm or deny an MSP’s degree of HIPAA compliance, they may help distinguish a new company that just wants to attract lucrative healthcare business versus a company already well versed in such procedures.
8. Must secure physical access to servers
In the case of a public cloud MSP, the MSP should be able to communicate why their cloud platform of choice maintains physical data centres that meet HIPAA standards. To review AWS’s physical data centre security measures, see their white paper on the subject. If a hybrid or private cloud is also maintained with the MSP, they should provide a list of global security standards for their data centres, including ISO 27001, SOC, FIPS 140-2, FISMA, and DoD CSM Levels 1-5, among others. The specific best practices for physical data centre security that healthcare organisations should look out for is well covered in ISO 27001 documentation.
9. Should conduct risk analysis in accordance with NIST guidelines
The National Institute of Standards and Technology, or NIST, is a non-regulatory federal agency under the Department of Commerce. NIST develops information security standards that set the minimum requirements for any information technology system used by the federal government.
NIST produces Standard Reference Materials (SRMs) that outline the security practices, and their most recent Guide for Conducting Risk Assessments provides guidance on how to prepare for, conduct, communicate, and maintain a risk assessment as well as how to identify and monitor specific risk factors. NIST-800 has become a foundational document for service providers and organisations in the information systems industry.
An MSP should be able to provide a report that communicates the results of the most recent risk assessment, as well as the procedure by which the assessment was accomplished and the frequency of risk assessments.
Organisations can also obtain NIST 800-53 Certification from NIST as a further qualification of security procedures. While again this is not required of HIPAA Business Associates, it indicates a sophisticated risk management procedure — and is a much more powerful piece of evidence than standard marketing material around disaster recovery and security auditing.
10. Must develop a disaster recovery plan and business continuity plan
The HIPAA Contingency Plan standard requires the implementation of a disaster recovery plan. This plan must anticipate how natural disasters, security attacks, and other events could impact systems that contain PHI and develops policies and procedures for responding to such situations.
An MSP must be able to provide their disaster recovery plan to a healthcare organisation, which should include answers to questions like these:
- Where is backup data hosted? What procedure maintains retrievable copies of ePHI?
- What procedures identify suspected security incidents?
- Who must be notified in the event of a security incident? How are such incidents documented?
- What procedure documents and restores the loss of ePHI?
- What is the business continuity plan for maintaining operations during a security incident?
- How often is the disaster recovery plan tested?
11. Should already provide service to large, complex healthcare clients
Although the qualifications listed above are more valuable evidence of HIPAA compliance, a roster of clients with large, complex, HIPAA-compliant deployments should provide extra assurance. This pedigree will be particularly useful in vendor decision discussions with non-technical business executives. The MSPs ability to maintain healthcare clients in the long-term (2-3+ years) is important to consider.
The post Is Your Cloud Provider HIPAA Compliant? 11 Point Checklist appeared first on Gathering Clouds.