HIPAA Compliance for SaaS: A Complete Guide

Safeguarding electronic protected health information (ePHI) is an essential function for any company that handles this type of sensitive data. Under the Health Insurance Portability and Accountability Act (HIPAA), you could face serious penalties for letting ePHI go unguarded. 

HIPAA applies to covered entities (healthcare providers, health plans, and clearinghouses) and their business associates (companies that perform functions or provide services that involve PHI). If you work in the SaaS industry and partner with any covered entities, you’re likely a business associate. 

Business associates’ HIPAA compliance requirements are laid out in the Security Rule, which was expanded to cover ePHI in the HITECH Act of 2009 and the HIPAA Omnibus in 2013. Here’s everything from those bills SaaS providers need to know, and how to put it into place inside your organization. 

Do You Need to be HIPAA Compliant As a SaaS Provider?

Not every SaaS provider needs to be HIPAA compliant, but if any of your target customer segments are in or adjacent to healthcare organizations, HIPAA should be on your radar. Any SaaS tool that is involved in:

• Creating
• Receiving
• Storing, or
• Transmitting

ePHI is subject to HIPAA. This includes companies that collect information that may be shared with a medical provider. Therefore, if you have any exposure to healthcare and related industries, it’s smart to make sure you’re following HIPAA requirements.

Governance Requirements: BAAs, Policies, and Training

To comply with the HIPAA Security rule, your SaaS company must provide administrative, technical, and physical safeguards to protect medical records or other ePHI. Developing strong governance policies will help you cover the first and last items on that list. Here’s how to go about it.

Vendor and Entity BAAs

A Business Associate Agreement, or BAA, is considered an official attestation of HIPAA compliance. That means you’ll be asked to sign a BAA by any covered entity that contracts you to provide services that require it to create, receive, store, or transmit ePHI. You’ll also need to get BAAs from any of your vendors who might come into contact with ePHI. 

Your BAAs should cover how ePHI can and cannot be used, require the signer to implement safeguards that will bring it in line with the Security Rule, and lay out breach notification requirements, among other things. HHS provides a sample BAA you can adapt to your needs.

Access, Data Handling, and Breach Response Policies

In order to sign that BAA, you’ll need policies that address all of its provisions. 

Access policies restrict who can access ePHI, and for what purposes. The covered entities you work with may have specific requirements, but in general, employees should only access ePHI when it’s necessary. 

Data handling policies cover what employees may do when working with ePHI. This may include restrictions on who can access the data and where they may access it—perhaps it’s only allowed from certain machines or only by on-site employees. Your data handling policies should also cover how information will be safely disposed of, along with procedures for monitoring the company’s data handling practices.

Finally, breach response policies cover the procedures your company will follow when sensitive data like ePHI is exposed. HIPAA’s Breach Notification Rule defines what a data breach is and who you must notify. It’s smart to go beyond these requirements and lay out what actions you’ll take to assess the situation, mitigate harms, and remediate the problems that caused the breach.

Workforce HIPAA Training

Policies are only useful when your employees understand what they mean and why they’re in place. Employees who have access to ePHI should be trained upon moving into their role or otherwise gaining access. While HIPAA is vague on the details, your training should require general cybersecurity best practices as well as guidelines for handling ePHI. 

We recommend providing annual refresher courses, training whenever your HIPAA compliance practices change, and remediation for any employee who breaches HIPAA requirements.

Technical Safeguards for SaaS Environments

HIPAA was designed with some flexibility, meaning it doesn’t require companies to use specific technological solutions to safeguard ePHI. Instead, it sets forth standards companies must meet and leaves the specific implementation up to them. 

Below are the four security measures your company should prepare to meet.

Data Encryption, in Transit and at Rest

To prevent unauthorized access to ePHI, it must be protected by encryption that meets standards set by the National Institute of Standards and Technology (NIST). The encryption must cover data when it’s at rest (or stored and in a static state) and in transit (moving between locations). This means individual machines, disks, folders, or files must have encryption protections. You’ll also need network protections in place. 

There are multiple ways you can address HIPAA encryption requirements, so it’s up to your team to weigh the tradeoffs for each method and choose the practices that best meet your needs without endangering ePHI. 

Configure Access Controls and Multi-Factor Authentication (MFA)

The access and data handling policies you wrote to comply with your BAA requirements shouldn’t rely on goodwill alone: you’ll need technical safeguards to enforce them. Access controls restrict which accounts and devices can be used to access sensitive information like ePHI. They’re typically put in place by your IT team and cannot be changed by individual employees.

Successful access controls rely on your organization’s ability to authenticate users’ identities. Therefore, the stronger your authentication methods, the better your access controls—otherwise, a lost password or hacked account could result in an unauthorized person gaining access to sensitive data. 

Multi-factor authentication, which requires something the user knows (like a password) along with something they have (like a phone or hardware token) or are (like a face or fingerprint scan), keeps ePHI safer than simple password logins. 

Detailed Audit Logs and Audit Trails

To prove your compliance, you need system-level monitoring that covers all access to and interactions with ePHI.

Audit logs show who has accessed ePHI and when. Collecting this information allows you to spot if any unauthorized users have been able to see sensitive information they should not have. It also helps you determine authorized users’ access patterns. Any access that occurs outside the pattern is a warning sign of unauthorized activity that your company will need to follow up on. 

Your audit log should also include information on user access levels, when users are added or removed, and firewall and anti-malware activity.

Audit trails are a safeguard created by logging specific records of user activities in applications and across your systems. Data you should collect for a full audit trail includes:

• Log-on attempts (successful and unsuccessful)
• Log-on ID or username
• Log-on device and IP address
• Date and time of log-ons and log-offs
• Password updates
• Application access attempts (successful and unsuccessful)
• Application data files opened
• Application data files closed
• ePHI records created, read, edited, or deleted

Audit trails help you determine when ePHI is being inappropriately used or accessed under your access and data handling policies. 

Effective audit logging policies also include procedures for actively monitoring the data you collect. However, access to audit logs and trails should be restricted to monitors and auditors.

Cloud Services Configuration

Most SaaS companies rely on cloud services for functions like data storage or server space. However, most of these services are not HIPAA-compliant out of the box. Major cloud providers support HIPAA compliance, but it’s up to your team to make sure they’re configured correctly.

These services may already have a BAA in place that you can execute or opt into. They typically also have guidance on configuring their tools to fulfill HIPAA regulations. As you read these guides, you’ll typically see instructions for ensuring technical controls we already discussed (like audit logs and access controls) are appropriately configured. 

Make sure you read and follow all applicable instructions—simply opting into the BAA isn’t enough to ensure your environment is free of vulnerabilities.

Shared Responsibility: You, the Cloud Provider, and the Customer

The Shared Responsibility Model is a compliance framework organizations and cloud service providers use to ensure ePHI stays protected as required by HIPAA. Amazon created the model for AWS, but other large vendors like Google and Microsoft Azure also use it.

Under the shared responsibility model, the cloud service providers are required to monitor and respond to security threats that may affect their systems. They must also create a secure network and infrastructure for their services to run on. However, organizations (including you and your healthcare industry clients) are responsible for making sure your data and assets are protected. That means controlling access to and disclosure of ePHI, securing connected apps and platforms, and ensuring your devices have adequate protection is up to your team. 

The BAA you sign with your cloud services provider will likely outline what HIPAA precautions they take and which you are expected to own as a company. In return, you agree to properly configure your cloud environment and provide technical safeguards on your end to keep ePHI safe.

Risk Assessment and Continuous Monitoring

After setting up your HIPAA compliance practices, it’s time to transition to maintaining a safe environment for ePHI. These ongoing processes both support your compliance efforts and ensure you face lower penalties should a breach occur.

Annual HIPAA Risk Assessments

A HIPAA risk assessment is the best tool in your arsenal for identifying risks, evaluating them, and prioritizing your organization’s mitigation efforts. Performing one early in your HIPAA compliance process will help you spot immediate gaps in your security procedures that you need to fix before you represent your organization as HIPAA compliant. 

After you reach initial compliance, it’s smart to run risk assessments at least once per year. Systems change, procedures morph once they meet your workforce, and mitigations must be adapted to meet your new reality. 

Ongoing Risk Monitoring

Once you identify risks, you need to set up a method to track them. Internal risks may be joined by those associated with your cloud service providers, vendors, and customers. Risk monitoring includes:

• Logging all risks (in a risk register or similar format)
• Assigning owners to each risk and tracking their progress on mitigation efforts
• Mapping risks to controls
• Continuously testing controls
• Remediating issues highlighted by failed tests

The more frequently you can perform risk monitoring duties, the better for your security practices. It’s never fun to realize one of your controls has failed and wonder how long the ePHI under your care has been exposed for.

Automating HIPAA Readiness

Because HIPAA is such a sprawling rule with so many standards, it’s easiest for most organizations to invest in a HIPAA compliance automation system. 

Automated risk management makes it easy to track the multiple controls and parties you’ll be responsible for monitoring. Tools built for this purpose allow you to get a quick view of your security posture with a centralized dashboard and real-time risk reports. Automation also makes it easy to perform control testing regularly and alert the right person when remediation is necessary. 

Get HIPAA-Ready with Drata

If you work with a covered entity, HIPAA compliance is essential proof that you can safeguard the most sensitive health data. Drata helps you get there faster.

Our Trust Management platform automates the grind: pre-mapped HIPAA controls, continuous monitoring, and workflows that replace screenshots with real evidence. Our policy templates and employee training cover the administrative safeguards, while integrations handle the technical side (i.e., access controls, MFA, and audit logging). 

But the most important part is that your HIPAA compliance doesn’t stay buried in binders. With our Trust Center, you can publish your compliance posture for prospects and partners and turn regulatory obligations into a visible advantage.

Discover more about how Drata can help you get and stay HIPAA compliant. Book your demo today.

HIPAA Compliance for SaaS Frequently Asked Questions (FAQs)

Still have questions about HIPAA compliance for SaaS? We answer common queries below.

What is a BAA, and Do We Need One With Our Cloud Provider?

Business Associate Agreements, or BAAs, are legal attestations of HIPAA compliance required for organizations that create, receive, store, or transmit electronic protected health information (ePHI). You do need a BAA with any cloud provider you use, but you’ll also need to make sure you configure your workspace settings to protect ePHI.  

Does HIPAA Apply If We Don’t Store PHI, But Only Process It?

Yes, HIPAA applies to organizations that process ePHI. Because you have custody of this sensitive data, you need to take steps to safeguard it.

Can We Be HIPAA Compliant If We Host On AWS or GCP?

Yes, cloud service providers like AWS and GCP allow you to be HIPAA compliant. However, you’ll need to familiarize yourself with the cloud service provider’s HIPAA-related settings and configure your environment before you can use it to store or transmit ePHI.

Is SOC 2 Enough for HIPAA?

SOC 2 compliance isn’t enough to ensure you’re following HIPAA, but there’s a big overlap between the two frameworks. If you’re already in compliance with SOC 2, you’ll need to add a few elements, like breach notifications, and expand your attestation report.