With all the things you have to track in the healthcare business to keep up with various compliance standards (HIPAA, HITECH, PCI-DSS, the list goes on…), do you really need another thing like third-party risk to worry about?
Well like it or not, third-party risk is real and it is coming for your compliance. While you can control employees with policies, procedures, and technical controls, third parties such as vendors often prove tricky to lock down and can put your compliance status in danger. Here are some problem areas to keep a close eye on and best practices to control them.
No BAA? Bad News for You
Most healthcare IT managers are aware of the Business Associate Agreements (BAAs) that are required under the HITECH Act for any provider that handles your organization’s PHI. So, this is an obvious step one for all healthcare systems that utilize the help of vendors. If you don’t have any relevant providers under a BAA, you are not only out of compliance, but you could also be without recourse against a vendor who has a breach that affects your PHI. Remember, under the law, you are responsible for your patient’s data that you collect and can be fined or sanctioned, even if the breach is caused by a third party or vendor.
Another danger is software as a service (SaaS) providers. More and more software used these days is through external software providers using the SaaS model. The data stored on these services may not be within your corporate infrastructure and under your controls and protections, but you are still responsible for it as if it was. And with more and more services being outsourced to the cloud, this problem is only going to grow. Whether on-prem or off-prem, BAAs still have to be signed when a vendor is handling PHI– no exceptions.
Speaking of PHI, do you have policies and technical controls in place to keep vendors who are not supposed to from seeing PHI? If you don’t, an inadvertent mistake by a vendor could cause them to view PHI. Depending on the size and duration of the exposure, this might count as a reportable incident under HIPAA. While some vendors will need to view your PHI as part of what they do, most vendor reps have no need to see this sensitive information. You need to have strong policies and controls to keep this from happening. Otherwise, a vendor just trying to be helpful could actually cause a reportable incident.
Payment Systems Can Make You Pay
PCI-DSS is another area where vendors can rock your compliance world (and not in a good way). Practically every medical outlet has to take payment cards and is subject to the PCI-DSS compliance standard. Accepting payment cards requires bringing a host of vendors onto your network and the accompanying risks along with them. Are these devices properly secured and patched?
Are the vendor reps who come onto your network to services these devices properly controlled and monitored? Being lax in this area can be a big mistake as genealogy site MyHeritage.com learned the hard way when 92,000,000 of their customer records were stolen after a payment systems vendor was hacked. These vendors and their systems need to be secured the same way you’d secure your own servers and workstations, or even more so, given that they are often the target of hackers.
Hackers are Down with Downtime
With the rise in ransomware and its monetization via Bitcoin, cybercrime organizations are increasingly looking to take down systems, so that organizations must pay the ransom to get their data and systems back online. There has been a shift in focus during the last year from the theft of data (though that is still going on) to destruction or ransoming of data. This is a very real threat and hackers have followed through with it when victims have refused to pay. Outages caused by breaches must be reported to the OCR and ones that affect patient care are likely to result in fines or other sanctions. And that’s beside the existential and legal threat that extended downtime can be to any healthcare organization. Vendor systems being down due to a cyber attack affects the entities that rely on them.
For instance, when a SaaS vendor PercSoft had their customer files encrypted by ransomware, dozens of dental practices lost access to their patient’s medical records that were stored there. Many of these customers had no backup for these records.
Does your organization have a fallback plan if key outsourced services go offline? How would you continue to operate? Answering these key questions BEFORE an incident is critical to any modern medical practice’s IT disaster plans.
Zombie Data Can Come Back to Haunt You
Finally, a poorly secured third-party vendor can come back to bite you long after their contract has ended and they no longer provide services to you. Indeed, some of the recent third-party breaches have been from vendors who had client data on their systems long after the client terminated the relationship. There is often no provision in contracts for deletion of client data after a contract expires and many companies keep this data for years, out of complacency or in hopes that the customer may come back.
Make sure that contracts and BAAs with vendors who store your data off-prem cover deletion and removal once the relationship ends. Without these stipulations, you will have very little leverage to force vendors to remove your data when you are no longer a customer and it could remain a zombie, waiting to be stolen.
Protect Your Data and Reputation
Obviously, there are a lot of other areas that third-party risk can affect your compliance; IoT, medical device security, contractors, privacy laws, and others that could easily be the subject of entire articles or books. These are just a few of the big ones. Clearly, managing third-party risk is becoming a bigger and bigger part of healthcare cybersecurity and compliance. Having and implementing a robust vendor management and third-party risk program which includes all the controls listed above is a good first start.
About the Author
Howlett is a published author and speaker on various security, compliance, and technology topics. He serves as President of (ISC)2 Austin Chapter and is an Advisory Board Member of GIAC/SANS. He is a certified AWS Solutions Architect and holds the CISSP, GNSA certifications, and a B.B.A in Management Information Systems. He is currently the CISO of SecureLink, a vendor privileged access management company based in Austin.