How to Manage a Cloud Vendor for HIPAA Compliance

HIPAA compliance is a team sport. Are you sure your vendors are equipped to support your regulatory game plan? In the second blog of our two-part compliance blog series, we address how your organization should handle cloud vendor management. 

Now that you have onboarded the new cloud vendor and started working with them, it is time to implement processes to ensure that it does not become a weak link in your HIPAA compliance strategy. Two strong methods we recommend include: investing in in-depth annual reviews and incorporating vendor management in your incident response plan (IRP). 

Invest in In-depth Annual Reviews 

As we mentioned previously, contractual obligations as part of a vendor management program should always include standard verbiage around the “right to audit” a vendor’s environment, and we recommend conducting these audits or reviews on a yearly basis.  

Annual reviews enable you to verify whether those security controls your cloud vendor demonstrated during the vendor selection process (or during the previous review) are still being implemented, updated and in line with current threats. Reviews also allow you to evaluate the current efficacy of those controls and identify areas for improvement.  

Auditing your vendor shouldn’t be a one-off exercise because, like covered entities, vendors are susceptible to compliance drift. As time goes by, some security policies might already be circumvented, and some controls can become outdated. Periodic reviews ensure both you and your vendor are continually aligned and respective responsibilities are re-emphasized. 

But not all periodic reviews work as expected. Usually, organizations conduct annual vendor reviews via questionnaire. However, the questionnaires themselves are rarely audited for accuracy or relevancy, resulting in generic – and potentially untrustworthy – security audit documents. 

As if this isn’t enough, vendors’ answers are also rarely verified. This is called “security theater.” It may allow boards and regulators to feel that risks are being actively managed, but it rarely provides a manageable security state. 

Why is this the case? Auditing vendors is an expensive and time-consuming process. Companies are required to dive deep, finding out if a vendor is executing an effective patch management program; learning what records they keep and how they secure them, where they store, process or transmit sensitive data; and so on.  

Developing effectiveness in these areas requires copious amounts of time and manpower – often at the expense of activities tied to business objectives. Because of this fact, a lack of audits is a pervasive problem; they are just too difficult and time-consuming to pull off.  

To reduce the pain of annual audits, covered entities can implement a data classification structure to determine which data can be eliminated, tokenized or encrypted. Companies tend to collect every bit of information they can because they have the tools to do so, but in reality, they only use a fragment of what they capture. Therefore, only keep and store what is absolutely needed for the process at hand. The idea here is to reduce the scope of what needs to be secured and in turn bring down financial and manpower costs.  

Incorporate Vendor Management in Your IRP 

An effective security program has an incident response plan – a documented process for responding to confirmed incidents of compromise. For companies with a network of vendors, their IRP will need to encompass policies related to vendor management. 

Looking at the general framework for an IRP, it is easy to see how vendors, and their impact, are accommodated at each stage: 

  • Containment, eradication and recovery: Businesses should have collaborative processes with vendors to jointly identify the cause and severity of the breach, contain the attack, and eradicate the threat. Cooperation is also necessary to preserve file-creation dates, log data and other ESI (electronically stored information) that may be needed in a legal hold, should a litigation or regulatory review be deemed necessary. All parties should be focused on the ability to resume operations once this stage has been completed. 
  • Remediation management: This is when policies and procedures are reviewed, contract language may be updated, and customers and employees are informed. Dialogue with the vendor should remain open through this stage. 
  • Post-incident response phase: Now is the time to determine the cause of the breach. Blame should not be pinned on the vendor, tempting though that may be. Even if the hacker entered through a vendor’s system, the vendor itself is also a victim here. But because business must go on, you will have to decide whether to rebuild trust or to terminate the vendor’s contract. If termination is chosen, there should be a plan to wind down the relationship. 

The completion of an incident response plan doesn’t mean the work is already done. That plan can’t be trusted until it is thoroughly tested with your vendor. These tests will give your vendor a better understanding of their responsibilities and help you validate the efficacy of your plan in a live environment.  

To be successful with the onboarding and management of your cloud vendors, it’s imperative to integrate them as though they are part of your environment because they are. These third parties can affect your attestation in significant ways, so it’s essential to ensure they’re capable – not to mention transparent – when it comes to HIPAA requirements for your customers’ sensitive data.  In fact, a vendor management program should be incorporated into your organization’s overall security strategy as a regular course of business. 

Visit our Security v. Compliance page to learn how Armor can help your organization achieve balance between securing your workloads and complying with standards and regulations.

Resource Center

More security resources at your fingertips.

Practical Content for Security, DevOps, & IT Professionals