Discussions of HIPAA compliance tend to center around what your organization should be doing to protect ePHI. However, because IT security is such a rapidly innovating sphere, HIPAA does not name specific technologies, required to fulfill compliance safeguards. It is important to note that there is no official “certification” or solution that automatically makes an organization HIPAA compliance. Security teams implement proper security safeguards and policies and continue maintain their HIPAA security program over time.
For this reason, it can be just as helpful to jump straight into what you shouldn’t do. In this post, we’ll take a look at some of the most common HIPAA compliance mistakes organizations make when managing PHI in AWS, and how to avoid them.
Mistake #1: Assuming that using AWS makes you compliant.
Amazon Web Services (AWS) is a popular choice for startups, health providers, and healthcare software vendors for a reason. As one of the largest HIPAA-compatible cloud vendors, AWS is both scalable and has the appropriate security infrastructure needed for healthcare solutions to stay HIPAA compliant. But there’s an important caveat: while AWS can be made HIPAA compliant, it does not meet HIPAA security standards out of the box.
Amazon AWS operates on a shared responsibility model, meaning that it provides physical security for the cloud (data centers, etc.) and provides a Business Associate Agreement (BAA), while the user is responsible for determining and setting the necessary security controls and policies in the cloud. Overlooking this second piece means all your ePHI may not be in compliance with HIPAA — and your organization may be vulnerable to breaches and potential HIPAA penalties. Policies must be set for all containers, packages, and services, as well for each of your assets, in order to avoid HIPAA compliance issues.
Mistake #2: Not taking inventory of your system to determine which parts contain ePHI.
This is a common-sense step that, nonetheless, is easy to overlook. There are 18 key identifiers for data that is considered ePHI. Important dates like date of birth and date of admission, geographical information, IP addresses, treatment plan, and patient photographs are among the data deemed protected by HIPAA, and leaving any of it exposed is a HIPAA compliance issue that can result in heavy fines for your organization.
Every AWS HIPAA compliance plan should include a full inventory of the cloud services, infrastructure, and containers, that comes into contact with ePHI. The safest way to account for all the ePHI your organization handles is to work backwards. First, consider all the types of ePHI you collect or store; then, track the locations in which each is hosted and apply the appropriate controls.
Mistake #3: Securing your data “at-rest” but not “in-transit”.
Imagine a bank removing its cash holdings from its high-security vaults, loading them onto a public bus, and hoping for the best. That scenario is almost as obviously ill-fated as its cloud equivalent: securing data at rest but not in transit.
When the ePHI you’ve collected or stored leaves your cloud, you are responsible for what happens to it at every point in its journey. All your ePHI should be encrypted in-transit using the highest standards and best practices. AWS provides specific security settings for encrypting resources such as EBS Volumes and S3 Buckets. Customers must configure encryption standards for data “in-transit”. This can be done by enforcing a SSL/TLS connection, limiting Security Groups to specific ports, and applying specific encryption protections to other cloud services.
It is also recommended to automate data leak detection so that in case of an in-transit breach, your organization can address it as quickly as possible.
Mistake #4: Not keeping a log of changes.
Every change to your AWS cloud environment, as well as to data in it, needs to be documented. Not being able to account for which changes were made, when they were made, or who made them is a sure way to get into hot water with HIPAA. Retroactive documentation invites human error and can be a security vulnerability in itself.
HIPAA best practices include implementing automatic documentation of changes through software solutions (Dash ComplyOps is a great example). This makes it easy to review changes in real-time and prove your technical compliance during a HIPAA security assessment.
Dash is a leading HIPAA compliance solution for cloud-based healthcare organizations, software vendors, and application developers. To learn more about how Dash can help you get continuously compliant or to request a free demo, get in touch with us.
Mistake #5: Failure to document compliance.
In the same vein as logging changes, your wider AWS security strategy must also be documented. If a tree falls in a forest and no one hears it, it may still make a sound, but if a HIPAA compliance standard is implemented and no one documents it, it won’t help you prove your compliance. While documenting may seem simple enough in theory, your cloud environment and the instances and assets in it are constantly changing as your software or organization scales. Documenting policies and controls for all your assets in real-time is essential to pass a HIPAA security assessment, and it can also be the toughest piece to manage as your organization scales.
Here again, manual documentation is a barrier to HIPAA compliance. Implementing a continuous compliance solution that automates documentation at all points, like Dash ComplyOps, is one of the most important things you can do now to help yourself down the road when it’s time to pass a HIPAA security assessment.
Mistake #6: Not implementing authentication.
Limiting the individuals who can make changes to your assets and who can access ePHI in the cloud is an important component of lowering the risk of a breach. AWS offers access control via Amazon Identity and Access Management (IAM).
Compliance leaders must ensure that permissions for IAM users and roles are limit access to only necessary services. User permissions should be reviewed on a periodic basis, with temporary and outdated accounts and permissions being removed. If you plan to start using a compliance management solution, consider a solution that offers authentication management and monitoring for a smoother documentation process.
Mistake #7: Inadequate training.
Your employees are your greatest asset — and all too often, your greatest security risk. HIPAA requires that staff receive HIPAA training on at least an annual basis. This training can be provided in-house or by a third party, and should provide an overview of identifying ePHI, managing data, and reporting potential incidents. Employees should be trained on security best practices like logging out and recognizing phishing emails.
Although this HIPAA compliance issue is not specific to AWS, staff security issues can certainly able to bring down even the best architected AWS cloud compliance system. Make sure that your employees understand their responsibilities for HIPAA compliance and are equipped with the knowledge to securely interact with your data–on and off the cloud.
While managing HIPAA compliance in Amazon Web Services (AWS) may seem like a challenging, organizations can utilize AWS security program and Dash ComplyOps to avoid HIPAA compliance issues and jumpstart their compliance efforts. Learn how your organization can build for HIPAA compliance in AWS by reading our guide to architecting for HIPAA compliance.
FAQ: Avoiding Overlooked HIPAA Compliance Risks in AWS
Are encrypted backups enough to protect ePHI from ransomware?
No. Encryption protects confidentiality, but an attacker with sufficient permissions may still delete or corrupt backups. Restrict backup administration, isolate recovery copies from production access, and consider immutable retention where appropriate. Test restoration to confirm that usable data and essential application dependencies can be recovered.
Can production ePHI be copied into development or testing environments?
Copying ePHI into a testing environment does not remove HIPAA obligations. Prefer synthetic data or data properly de-identified under HIPAA. When real ePHI is necessary, assess the environment’s risks and apply appropriate safeguards, access restrictions, and vendor agreements before transferring it.
Should AWS resource names and tags contain patient information?
Avoid placing patient names, medical details, or other PHI in resource names, tags, and similar metadata fields. These values may appear in billing records, inventories, logs, and integrated tools with broader access than the underlying data. Use non-sensitive operational labels and keep patient information in appropriately protected application storage.
Does an AWS BAA cover third-party software and SaaS integrations?
An AWS BAA does not automatically cover separate vendors connected to your application. Assess each vendor’s role, data access, and safeguards. If a vendor creates, receives, maintains, or transmits PHI on your behalf as a business associate, establish an appropriate BAA before sharing that information.
Does AWS patch every component of a healthcare application?
No. Patching responsibilities depend on the service. AWS manages underlying infrastructure for managed services, while customers remain responsible for components under their control, such as application code, dependencies, container images, and EC2 guest operating systems. Define ownership and verify that vulnerability fixes reach deployed workloads.
What should you do after discovering exposed ePHI in AWS?
Promptly contain the exposure while preserving relevant evidence. Determine which data was affected, how long it was exposed, and whether unauthorized access occurred. Follow your incident response process, involve the responsible security and privacy personnel, and assess applicable notification obligations. Correcting the configuration alone does not complete the response.
