Business Associate Agreements and PHI. To sign, or not to sign? That is the question. Many of us often find ourselves making decisions with legal implications. Of course we consult with our legal counsel to be sure, yet sometimes things are a double-edged sword. Such is the case when signing legal documents. Today we’re going to look at Business Associate Agreements as they apply to managed service providers (e.g. IT and Cyber).
While OCR has answered this question here, there’s still some room for interpretation. We’re going to throw out several types of providers, and tell you where the lines are.
Cybersecurity Provider
For the most part, a service provider such as Secureside is like a janitor or secure shredding facility. We rarely come into contact with PHI and other sensitive data due to the nature of our services. Strategic guidance, policy writing, interfacing with clients and stakeholders – none of the activities Additionally, we we take precautions to avoid contact, such as refusing to hold credentials to as much as possible. Result: no BAA required.
It is also true that we operate as part of your internal team. During an audit or pen test we might see file names or be able to inject into a database, gaining access to a table where sensitive data would be. That doesn’t mean we actually viewed any records. Or maybe we did a “-head 5”, showing only the first 5 records as proof of the vulnerability. That’s about the full extent of things. Because we are operating under the umbrella of our client, and our access is only “just-in-time”, this is not an issue. Result: no BAA required.
There are examples where the BAA will be in the best interest of the entity. Some cyber service providers may be retaining logs or application logs, and in those logs could be PHI. The number of records may increase over time. In this case, PHI is leaving your systems and being stored, so now you need the liability protection. Another scenario would be where the cyber provider has full access to many systems. In this case, they are operating more like an IT Provider, which is discussed below. Result: BAA is required.
As we can see, most cybersecurity providers won’t need to sign a BAA unless they have a great deal of access to systems.
IT Provider
IT providers can a bit trickier, but the the default is: BAA is required.
Most IT providers have full access to the user endpoints, servers, and networking devices of their clients. This level of access alone presents significant risk. Given such broad access, an insider or hacker on the IT Provider’s side could comb through the client systems looking for PHI (and other sensitive data). A breach could become a very big deal. Result: BAA is required.
Here’s a case that is different than the above. The entity has separate, tightly controlled environment for PHI, such as a web app in AWS or Azure. All PHI resides in the cloud tenant. There is no PHI on user endpoints, internal servers, or storage devices. An occasional email may contain PHI. The IT Provider provides help desk support, as well as server and network management, and it administers access to the email system. The IT Provider’s chances of coming into contact with PHI are very low, with the quantity of records being tiny. Result: no BAA required.
Development Provider
- has all day and regular access to everything, including PHI;
- stores any PHI outside of your systems;
- or is hosting your app in their AWS tenant on your behalf;
Then a BAA is required.
- is delivering code only;
- incidentally sees PHI records during troubleshooting over a screen share with an entity employee;
- or comes into contact with PHI while deploying new code releases in the entity’s environment through limited, brokered access;
Then no BAA required.
Conclusion
In the end, entities handling PHI should err on the side of making their vendors sign a BAA. However, these entities are not protecting themselves simply by making every vendor sign a BAA.
Service providers should avoid signing a BAA because it comes with liability. Service providers should be wary of prospects who are so eager to put liability on them.
In a true partnership, both sides should determine if a BAA is necessary, and if it’s enforceable in a court of law. Just because it’s signed does not mean it’s valid.
