Modern-day healthcare organizations rely on a growing array of partners and vendors to provide them with the tools they need to effectively serve patients and customers.
However, while new digital solutions and healthcare ecosystems often result in greater productivity and efficiency, they also increase the number of third parties a company must communicate with and share protected health information (PHI), requiring a business associate agreement (BAA). Unfortunately, this increases the risk of PHI being exposed, as it increases a healthcare organization’s supply chain network and the number of external organizations with access to their data, significantly raising the risk of a security breach.
This is where the concept of shared responsibility comes in.
In this article, we explore the shared responsibility model for data security, explaining the concept, the role of a BAA in shared responsibility, and why healthcare companies need to know how it works and where it factors into their HIPAA compliance efforts.
What Is The Shared Responsibility Model?
Shared responsibility is a core data security principle that divides the responsibility for protecting data between a company that collects the data and a vendor that supplies the infrastructure or systems used to process said data.
The shared responsibility model grew in prominence as more companies moved to cloud-based environments and applications. In the past, when companies kept their systems and data onsite, they had more control over who could access their data and, subsequently, a better ability to mitigate data security risks.
However, in adopting cloud-based infrastructure and applications, companies have to process and store their data in the cloud – often in shared infrastructure with other vendors using the same cloud – which consequently shifts some of the responsibility of information security to the cloud service provider (CSP) itself. This marked a profound shift in the way data was handled, transmitted, and stored – necessitating an evolved approach to data security.
This fundamental shift in the way companies consume infrastructure and use apps ushered in the shared responsibility model: Where the cloud vendor provides the infrastructure or application, including HIPAA compliant and high secure environments, but it’s still the responsibility of the client to configure and use it securely.
Business Associate Agreements (BAAs) and Shared Responsibility
By detailing the respective responsibilities of healthcare companies or Covered Entities (CEs) and their vendors or Business Associates (BAs) in securing PHI, a Business Associate Agreement is a prime example of shared responsibility.
For example, the Business Associate shoulders the responsibility of providing the data safeguards required by HIPAA to secure patient data, such as infrastructure, encryption, audit logging, and even physical onsite security.
The Covered Entity, meanwhile, is responsible for conducting risk assessments, defining access control policies and processes, configuring services accordingly, workforce training, and continuous monitoring.
Additionally, both parties have the obligation to report security incidents to each other, as well as being independently accountable to the U.S. Department of Health and Human Services (HHS).
Why Shared Responsibility Is Essential for HIPAA Compliance
For healthcare companies, having a firm grasp of the shared responsibility model for safeguarding and securing PHI, and how they fit within your overall security posture is essential (for two key reasons).
Security Gaps
Firstly, clearly understanding the shared responsibility decreases the likelihood of security gaps. If CEs are under the impression that the vendor handles all aspects of data security, they won’t be as vigilant. They’ll be less inclined to configure services, educate their staff accordingly, pay appropriate attention to vendor security alerts, etc.
But the same is also true for BAs: If they assume their client does most of the heavy lifting in securing the data disclosed to them, they could be remiss in their duties to protect it. Without shared responsibility, each side simply assumes the other is covering a safeguard, opening the door for security gaps that malicious actors can exploit.
Fortunately, by detailing both parties’ (CEs and BAs) responsibilities and liabilities regarding data protection, a BAA removes this ambiguity and, more importantly, reduces the risk of security gaps. It’s critical to know the details and work with vendors building products for compliance versus implementing a tick-box approach to compliance that places too much burden on the CE.
Covered Entities (CEs) Are Ultimately Accountable
Subsequently, the second reason why it’s essential for CEs to understand the shared responsibility model, and increase their cybersecurity readiness accordingly, is that it’s the CE that’s ultimately held accountable for data breaches.
Mistakenly thinking that a BAA automatically makes them compliant may result in healthcare companies underinvesting in training, monitoring, and incident response. Conversely, understanding that even with a BAA in place, they’re the ones primarily accountable for protecting PHI gives them a greater sense of urgency to properly implement HIPAA compliant security measures.
The Covered Entity’s Role Within Shared Responsibility
Let’s look at the ways that healthcare companies have to hold up their end in the shared responsibility model.
Choose Compliance-Conscious Vendors
First and foremost, companies have to choose the right vendors to supply them with HIPAA compliant services and solutions.
Look for companies that market themselves as HIPAA compliant and display a detailed understanding of HIPAA requirements, particularly the HIPAA Security Rule. Do your due diligence and perform deeper dives on potential vendors, researching their stated security features, reviews from existing clients, whether they have certifications like HITRUST – and if they’ve been involved in any data breaches.
Naturally, a core prerequisite of being a HIPAA compliant vendor is being willing to sign a BAA, so you can immediately rule out any vendors not willing to do so. For instance, some healthcare companies may assume they can use widely adopted solutions such as SendGrid, Mailchimp, but they don’t offer a BAA.
Once you’ve confirmed a vendor offers a BAA, look through it to establish its terms and determine if it covers the services you’re interested in.
Configuration
Another core component of shared responsibility is comprehensive configuration management. While the BA’s responsibility is to provide a secure solution that satisfies HIPAA requirements, it’s the CE’s responsibility to configure it securely to fit within their IT ecosystem.
Features that often require configuration include:
- Access control: Role-based access, Zero Trust, Multi-Factor Authentication (MFA).
- Encryption settings: Enabling encryption, choosing encryption type, enforcing forced TLS, enabling storage encryption.
- Feature restrictions: Disabling default configurations that enable integration with non-compliant tools.
- Audit logging: Enabling audit logging and configuring log formats.
- Retention settings: How long to retain audit logs and who is permitted to review them.
Finally, establishing a patch management strategy, i.e., when and how your organization applies software updates, is an important element of configuration. While the vendor must release updates to fix security vulnerabilities discovered in their solutions, it’s up to healthcare companies to deploy the patches.
Training
Regardless of how many security features a vendor bakes into their solutions, once deployed by a healthcare company, the tool is only as secure as the practices of their least security-conscious employee. Consequently, companies must train their staff on how to properly use a solution to process protected health information and sensitive data. The more an employee is required to handle PHI, the more thorough and frequent their training should be.
Key aspects of comprehensive cybersecurity training include:
- Common cyber threats: what the most prevalent cyber threats are and how to recognize them.
- Incident response: how to report a suspected security incident, i.e., who to contact and when.
- Specific solution training: how to securely use systems that process PHI
- Scope awareness: knowing which services within your organization’s IT ecosystem are HIPAA-compliant and which are not
Reporting
Although both healthcare companies and BAs have notification obligations to the HHS in the event of a data breach involving PHI, it’s the CE that bears most of the investigative burden.
Firstly, while a BA may report a security incident, it’s the CE’s responsibility to conduct a risk assessment to determine the probability of compromise of PHI, assess risk, and determine whether an official notification of a breach to HHS is necessary.
Secondly, BAs must notify the CE without unreasonable delay and no later than 60 days after discovery. Although BAs often wait to complete internal investigations before notifying the CE, the CE’s 60-day clock starts upon the BA’s discovery, not upon the BA’s report. Therefore, BA delays can create compliance risks for the CE.
To prevent this, where possible, you can include stricter contractual reporting timelines in the BAAs. This constantly keeps your company in the loop, ensuring you have sufficient lead time to complete your own investigations and your HIPAA-regulated deadlines.
LuxSci – Secure Healthcare Communications
Developed specifically to fulfil the stringent regulatory and ever-evolving data security needs of the healthcare sector, LuxSci’s secure email, text, marketing and forms solutions help companies protect PHI and personalize communications.
Equally as importantly, instead of leaving you to “figure it out” – pushing additional responsibility back onto your company – LuxSci has a reputation for the best customer support in the business, offering onboarding, detailed documentation, secure default configurations, and ongoing support to help navigate the murky waters of HIPAA compliance, while getting best-in-class performance out of your solution.
Contact LuxSci today to learn more or get a demo.
SSL and TLS play critical roles in securing data transmission over the internet, and AES-256 is integral in their most secure configurations. The original standard was known as Secure Sockets Layer (SSL). Although it was replaced by Transport Layer Security (TLS), many in the industry still refer to TLS by its predecessor’s acronym. While TLS can be relied on for securing information at a high level—such as US Government TOP SECRET data—improper or outdated implementations of the standard may not provide much security.
