AWS Shared Responsibility Model: Healthcare Compliance Tips
Post Summary
Managing healthcare data on AWS requires understanding the shared responsibility model. AWS secures the infrastructure, but you are responsible for protecting patient data, ensuring compliance with HIPAA. Here’s a quick breakdown of key actions healthcare organizations must take:
- Sign a Business Associate Agreement (BAA): A legal requirement for storing Protected Health Information (PHI) on AWS.
- Use HIPAA-Eligible Services Only: Ensure PHI is processed/stored only on services listed as HIPAA-compliant by AWS.
- Enforce Strong Access Controls: Use Multi-Factor Authentication (MFA) and least privilege IAM policies to control data access.
- Encrypt Data: Use AWS KMS to encrypt PHI at rest and in transit with TLS 1.2 or higher.
- Enable Logging & Monitoring: Activate CloudTrail, CloudWatch, and GuardDuty for audit trails and real-time monitoring.
- Perform Regular Backups: Use AWS Backup for automated, encrypted backups with disaster recovery plans in place.
- Conduct Risk Assessments: Use AWS Config and Security Hub for continuous compliance checks and audits.
- Manage Vendor Risks: Leverage tools like Censinet RiskOps to monitor third-party compliance.
How to Build This | S2E1 Build for HIPAA Compliance on AWS
sbb-itb-535baee
1. Sign a Business Associate Agreement with AWS
If you're planning to store Protected Health Information (PHI) on AWS, the first step is signing a Business Associate Agreement (BAA). This isn't just a formality - it's a legal requirement under HIPAA. Without a BAA in place, you're violating the law, even if your data is encrypted and AWS doesn't have access to the decryption keys. This agreement is a cornerstone of AWS's shared responsibility model for compliance.
According to guidance from the Department of Health and Human Services (HHS), AWS is considered a "business associate" when handling PHI. The BAA outlines AWS's responsibilities, including breach notifications within 60 calendar days. Penalties for non-compliance are steep, ranging from $100 to $50,000 per violation, with annual caps of up to $1.9 million per violation category [1]. Skipping this agreement leaves you exposed to these potential penalties.
To get started, log in to the AWS Management Console with administrative access and navigate to AWS Artifact. This self-service portal contains the AWS Business Associate Addendum. Download and review the document to understand critical details like breach notifications and audit rights. Once you're ready, click "Accept Agreement" to finalize the process. Keep in mind, the signed BAA covers your entire AWS account but only applies to HIPAA-eligible services. Using non-eligible services like Amazon Lightsail or AWS Amplify for PHI would still violate HIPAA, even with a signed BAA.
"AWS customers looking to create, receive, maintain, or transmit PHI should sign an AWS Business Associate Agreement (BAA)."
– AWS Security Blog [2]
Hold onto the signed BAA for at least six years, as required by HIPAA. If you're using multiple cloud providers, remember that each one requires its own BAA as part of your healthcare third-party risk management strategy. For example, a BAA with AWS won't cover services from Azure, Google Cloud, or other platforms [1]. After this step, make sure you're only using HIPAA-eligible AWS services for handling PHI.
2. Use Only HIPAA-Eligible AWS Services for PHI
Once you've signed a BAA with AWS, it's critical to ensure that PHI is only stored or processed using HIPAA-eligible services. The AWS HIPAA Eligible Services Reference page lists all services covered under your BAA. As of April 13, 2026, this list includes services spanning compute, storage, databases, AI, networking, and security categories [3]. If PHI is used with a service not on this list, it breaches your BAA, no matter what other security measures you have in place.
"If PHI ends up in a service that isn't on that list, you're outside the terms of the BAA regardless of what else you have in place."
– Absolute Ops [6]
It's essential to review the eligible services list regularly, especially before deploying PHI to any new service. AWS updates this list frequently based on customer needs [4]. However, be mindful of feature exclusions within eligible services. For instance, while Amazon Pinpoint is HIPAA-eligible, its Voice Message capabilities and WhatsApp Channel are not [3]. Similarly, Amazon SageMaker AI is eligible, but features like Studio Lab and Public Workforces are excluded [3].
Proper configuration of eligible services is just as important. This includes enabling encryption, logging, and role-based access controls. AWS emphasizes: "Customers still must configure these services consistent with HIPAA requirements" [3]. To avoid accidental use of non-eligible services, implement Service Control Policies (SCPs) to block PHI from being routed incorrectly [6]. Non-eligible services can still exist within your AWS account, provided they do not interact with PHI in any way [3][4].
3. Set Up Multi-Factor Authentication and IAM Policies
Once you've established a secure environment for PHI using HIPAA-eligible AWS services, the next step is to tighten access controls. Protect PHI access with strong authentication and carefully designed authorization policies. Multi-Factor Authentication (MFA) adds an extra layer of protection against compromised passwords, while well-structured IAM policies enforce the principle of least privilege. This ensures users can only access the data and services necessary for their role [6].
Starting in 2024, AWS will require MFA for root user access on all accounts [12]. To enhance security, enforce MFA for all IAM users and federated identities. AWS recommends phishing-resistant MFA methods, such as passkeys or FIDO-based keys, over virtual authenticators [8]. Additionally, AWS allows users to register up to 8 MFA devices per account, providing backup options in case of device loss [8][12].
You can enforce MFA through policies by using the aws:MultiFactorAuthPresent condition key to block PHI-related API calls unless MFA is active [7][10]. For particularly sensitive PHI access, consider adding the aws:MultiFactorAuthAge condition key to require re-authentication if the MFA session exceeds a set timeframe, such as 300 seconds [7][10]. Another option is implementing a "Force MFA" policy, which denies all actions except those needed for users to manage their MFA devices until they sign in with MFA [9][11].
"Least privilege sounds simple until you're looking at a 200-line IAM policy that nobody on the current team wrote."
– Absolute Ops [6]
For additional security, replace long-lived access keys with IAM roles whenever possible. This reduces the risk of credential leaks [6]. If access keys are unavoidable, make sure to rotate them every 90 days or less [12]. Use AWS IAM Access Analyzer to identify overly permissive policies and conduct regular reviews to simplify outdated or overly complex IAM policies [6].
4. Encrypt PHI at Rest and in Transit Using AWS KMS
When managing PHI in your AWS environment, encryption is critical. HIPAA technical safeguards mandate that any storage resource handling PHI must be encrypted. This includes Amazon S3 buckets, EBS volumes, RDS instances, and DynamoDB tables. For this, AWS Key Management Service (KMS) is your go-to tool.
For most workloads, AWS-managed KMS keys with automatic rotation are sufficient. However, if specific requirements arise, you can opt for customer-managed keys. Don’t stop at primary resources - extend encryption to secondary data like RDS snapshots and CloudWatch log groups.
"For data in transit, TLS 1.2 is the floor."
– Absolute Ops [6]
To secure PHI in transit, always use TLS 1.2 or higher. Additionally, keep traffic within AWS's private network by leveraging VPC endpoints or AWS PrivateLink.
Legacy resources can pose compliance risks, so it's essential to address them. Conduct audits to:
- Review EBS volumes created before encryption was set as the default.
- Enforce account-level encryption settings.
- Verify that EC2 instances and Lambda functions writing to CloudWatch use encrypted storage.
5. Turn On Logging with CloudTrail and CloudWatch
HIPAA mandates not just the protection of PHI (Protected Health Information) but also the ability to prove that protection. Without detailed audit trails, it’s nearly impossible to demonstrate compliance during an investigation or audit.
"HIPAA requires organizations to 'regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports'."
– U.S. Department of Health & Human Services (HHS)[5]
To meet this requirement, logging plays a critical role. Start by enabling AWS CloudTrail across all regions, not just your primary ones. This ensures that every API call in your AWS account is logged, capturing key details like who accessed what, when, and from where. For resources managing PHI, enable data event logging for Amazon S3 and AWS Lambda. This lets you track file access and function executions, providing a more granular view of activity.
Store these logs in a dedicated, version-controlled S3 bucket with MFA Delete enabled for added security. Encrypt the logs using AWS KMS and retain them for at least six years to align with HIPAA's record-keeping requirements. These steps form the backbone of your audit trail and support real-time monitoring through CloudWatch.
Using AWS CloudWatch, you can monitor activity as it happens. Set up CloudWatch alarms to detect unusual behavior, such as repeated failed login attempts or unexpected MFA deactivations. Pair these alarms with SNS notifications and incident response tools to ensure swift action when needed.
Consider this: in early 2025, PHI breaches impacted more than 31 million individuals, with an average cost of $7.42 million per breach[5]. This highlights why using healthcare cybersecurity tools for automated monitoring isn’t just a good idea - it’s a necessity for maintaining HIPAA compliance and safeguarding PHI. By combining CloudTrail and CloudWatch, you create a robust framework for managing and verifying PHI security effectively.
6. Set Up Monitoring and Auditing with GuardDuty and Config
Logging helps you look at past events, while monitoring gives you a view of what's happening right now. Tools like CloudTrail and CloudWatch are great for creating audit trails, but AWS Config goes a step further by continuously tracking your resource configurations. It flags any deviations from compliance. On the other hand, AWS GuardDuty analyzes data from CloudTrail, VPC Flow Logs, and DNS logs to detect potential threats, offering visibility into suspicious activity. This aligns perfectly with HIPAA Technical Safeguard 164.312(b).
"Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic health information." – HIPAA Technical Safeguard 164.312(b) [13][14]
To get started, enable AWS Config in every region where you store or process Protected Health Information (PHI). Make sure to select "All resources" and "Include global resources" so that critical configurations, like those for IAM, are always monitored. Next, deploy the HIPAA Conformance Pack. This pack includes a set of managed Config rules validated by AWS Security Assurance Services LLC, which directly map to HIPAA controls. Some of the rules you'll find include:
ec2-ebs-encryption-by-defaults3-bucket-ssl-requests-onlyiam-root-access-key-check
These rules automatically detect configurations that are out of compliance.
For even more efficiency, connect Config rules to AWS Systems Manager Automation Runbooks. This setup allows you to automatically fix issues like unencrypted EBS volumes without needing to take manual action. To stay informed, set up Amazon SNS notifications. These can alert your team via email, SMS, or platforms like Slack whenever non-compliant events occur. This creates a seamless workflow: identify the issue, alert the team, and remediate it.
Use the Config Timeline feature to generate JSON snapshots of your resource configurations. These snapshots are essential for audit documentation. If your organization has specific needs, you can create custom Config rules using AWS Lambda. For example, you could enforce encryption on certain S3 buckets or ensure that resources tagged with PHI="Yes" meet specific security requirements. This proactive approach helps you maintain security and compliance in your cloud environment.
7. Apply Role-Based Access Controls and Least Privilege
Once you've established strong Identity and Access Management (IAM) practices, the next step is enforcing role-based access controls (RBAC) to ensure that only the right people have access to Protected Health Information (PHI). At the heart of this is the principle of least privilege: users and services should only have the permissions they absolutely need to perform their tasks. Start with the bare minimum and add permissions only when necessary. This strategy lays the groundwork for precise IAM configurations and advanced resource-level controls.
"The principle of least privilege states that identities should only be permitted to perform the smallest set of actions necessary to fulfill a specific task." – AWS Well-Architected Framework [15]
To implement this, you can use AWS IAM to create role-based groups tailored to specific functions - for example, billing, clinical staff, or IT security. Assign the appropriate permissions to each group. For applications managing Electronic Health Records (EHR), tools like Amazon Verified Permissions with Cedar allow you to enforce granular rules, such as restricting access to patient records based on roles like "Doctor" to comply with HIPAA requirements [15][16].
For even more control, apply resource-level policies to services like S3 buckets. If you're using data lakes, AWS Lake Formation can enforce access controls down to the column, row, or even cell level [18]. By tagging resources with attributes like DataSensitivity: PHI or Environment: Production, you can streamline permission management using Attribute-Based Access Control (ABAC) as your infrastructure scales [15].
To fine-tune your policies, take advantage of IAM Access Analyzer, which uses CloudTrail logs to identify overly permissive policies. Pair this with IAM Access Advisor to spot and remove unused permissions, reducing the risk of permission creep [15][17]. For added security, set permissions boundaries to limit the maximum permissions developers can assign when creating roles [15].
Discovering and securing sensitive data is also critical. Tools like Amazon Macie (for S3) and Amazon Comprehend Medical (for unstructured text) can help identify where PHI resides, making it easier to apply the right access controls [18]. These steps collectively strengthen your least privilege environment, ensuring your AWS infrastructure is both secure and compliant.
"Least privilege is a journey, because change is a constant. Your builders may change, systems may change... what you consider least privilege today may be considered insufficient by your users tomorrow." – AWS Security Blog [17]
8. Schedule Regular Backups and Plan for Disaster Recovery
In the AWS Shared Responsibility Model, healthcare organizations are tasked with backing up, encrypting, and classifying data stored "in" the cloud [21]. To ensure effective recovery, it's crucial to define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). These determine how quickly systems need to be restored and how much data loss is acceptable. For instance, a four-hour RTO means recovery must occur within four hours [20].
AWS Backup simplifies data protection by offering a centralized, policy-driven approach across multiple AWS services and accounts [21]. Services like Amazon Aurora and Amazon DynamoDB support automated, continuous backups with point-in-time recovery, allowing you to restore data down to the second within a 35-day window [21]. To guard against ransomware, store backups in separate AWS accounts with tight access controls, and mark backup vaults as read-only [19][21]. Additionally, enabling the Amazon EC2 Recycle Bin ensures that deleted EBS snapshots and AMIs are retained for a set period, acting as a safeguard against accidental or malicious deletions [21].
"The message is clear: automated backup validation is no longer optional: it's a fundamental requirement for modern business continuity." – AWS Storage Blog [22]
Testing backups regularly is essential. AWS Backup restore testing can automate this process, allowing you to schedule validations and retain restored data temporarily (from 1 to 168 hours) before it’s automatically deleted [24]. This proactive approach prevents unexpected issues, such as realizing during an incident that a database restore takes six hours instead of the expected four due to a configuration oversight [23]. Tools like AWS Backup Audit Manager help generate compliance reports, demonstrating recovery readiness to auditors. This is a key component of measuring cybersecurity effectiveness in healthcare. For critical systems, align testing frequency with their importance - daily or weekly tests may be necessary [22][23]. A robust backup plan like this complements other cyber risk management strategies.
"The time to validate your backups is before you need them. Don't wait for a crisis to discover gaps in your recovery capabilities." – AWS Storage Blog [23]
For disaster recovery, consider creating "golden image" Amazon Machine Images (AMIs). These pre-configured images allow for quick restoration of EC2 instances with the necessary software and security settings [21]. A pilot light environment - minimal, always-on infrastructure - can also help reduce recovery time [19]. To ensure your disaster recovery plan remains cost-effective, use the AWS Pricing Calculator to estimate expenses for storage, cross-region backups, and service usage [21].
9. Run Regular Risk Assessments and Compliance Audits
Keeping PHI (Protected Health Information) secure requires more than just setting up controls - it demands ongoing vigilance. Regular risk assessments and compliance audits are essential to ensure there are no weak spots. According to the AWS Shared Responsibility Model, healthcare organizations must consistently evaluate their cloud environments for security vulnerabilities and compliance issues. Annual audits alone won’t cut it under HIPAA rules; continuous monitoring is a must.
Tools like AWS Config simplify this process. It offers pre-built HIPAA Conformance Packs, validated by AWS Security Assurance Services (SAS). These packs include managed rules that align directly with HIPAA requirements, such as risk analysis and risk management. AWS Config works in real-time, constantly checking your infrastructure and flagging compliance gaps. This ongoing evaluation also makes it easier to keep your compliance documentation up to date.
Another helpful tool is AWS Security Hub, which consolidates findings from various AWS services. This gives you a single, unified view of your security landscape, making it easier to spot and address issues.
To stay on track, document your risk assessments and audits using a SOC 2 audit documentation checklist to ensure clear, concise reports. These should cover the scope of reviews, identified issues, and the steps taken to resolve them. These records not only help you stay organized but also demonstrate compliance during audits. Aim to conduct assessments quarterly, and for systems deemed high-risk, consider monthly reviews.
If your organization works with multiple vendors, platforms like Censinet RiskOps can be a game-changer. They centralize risk assessments across your entire healthcare network, ensuring both your cloud environment and vendor relationships meet strict compliance requirements. This unified approach helps maintain a higher standard of security and compliance across the board.
10. Use Third-Party Risk Management Platforms like Censinet RiskOps
Once you've established solid risk assessments, it's time to extend that diligence to your third-party vendors. Managing risks from third parties is a crucial part of the AWS shared responsibility model. While AWS secures the core cloud infrastructure, you're in charge of monitoring the vendors and partners interacting with your AWS setup and handling PHI. This could include anything from cloud service integrations to medical device suppliers. Relying solely on manual assessments won't cut it - especially considering that 62% of healthcare breaches in 2024 involved third-party vendors [27]. This layer of oversight strengthens your overall risk management strategy and helps maintain HIPAA compliance.
Censinet RiskOps steps in to fill this gap by automating third-party risk assessments tailored specifically for healthcare. The platform works with AWS tools like GuardDuty and Config, pulling real-time data to measure AWS services against HIPAA standards. For instance, it can check the encryption status of S3 buckets storing PHI and flag any compliance issues [25]. By automating these assessments, you save time and improve compliance outcomes.
The platform also simplifies vendor management with its collaborative features. Instead of repeatedly chasing vendors for security questionnaires, Censinet RiskOps uses AI-driven nudges to encourage faster responses - boosting questionnaire completion rates by 50%. One mid-sized U.S. hospital using AWS for EHR storage cut its third-party risk exposure by 40% in six months by identifying unpatched vendors handling PHI [26]. Similarly, a health system streamlined over 200 vendor assessments, achieving a 95% completion rate during a HITRUST audit [26].
Getting started with Censinet RiskOps is straightforward. Connect your AWS account via API, import your service inventory, and set up HIPAA-specific questionnaires. The platform's unified dashboard gives you a clear view of your vendor ecosystem, enabling early detection of potential risks. For high-risk vendors, you can configure automated alerts that integrate with AWS GuardDuty for real-time tracking. By combining vendor risk intelligence with continuous monitoring, you can ensure HIPAA compliance across your AWS environment.
While AWS provides critical security tools, Censinet RiskOps offers targeted vendor oversight, ensuring your entire healthcare ecosystem aligns with HIPAA requirements [28].
AWS vs. Customer Responsibilities: Comparison Table
AWS Shared Responsibility Model for HIPAA Compliance
For healthcare organizations, understanding the shared responsibility model is a must. AWS secures the underlying infrastructure, but you're in charge of everything you build on top of it. This separation is crucial for maintaining HIPAA compliance.
To meet HIPAA standards, healthcare organizations need to clearly define who handles what. AWS takes care of the physical and foundational layers - like data centers, hardware, and virtualization platforms. Meanwhile, you're responsible for safeguarding data, managing access, and securing applications. Here's a breakdown of how these responsibilities align with HIPAA compliance:
| Responsibility Area | AWS Responsibility (Security OF the Cloud) | Customer Responsibility (Security IN the Cloud) | Impact on HIPAA Compliance |
|---|---|---|---|
| Physical Infrastructure | Securing data centers, hardware, and global networks | None (inherited from AWS) | Meets HIPAA's physical safeguard requirements for facility access |
| Data Protection | Maintaining the virtualization layer and storage media | Encrypting PHI at rest and in transit; managing encryption keys | Ensures PHI remains unreadable to unauthorized individuals |
| Access Management | Physical access control to servers and infrastructure | Setting up IAM policies, MFA, and role-based access controls | Helps enforce HIPAA's "Minimum Necessary" access rule for PHI |
| Monitoring & Auditing | Providing infrastructure-level audit reports (SOC, ISO) | Enabling and monitoring logs (e.g., CloudTrail, CloudWatch, GuardDuty) | Ensures an audit trail for PHI access and changes |
| Software & Patching | Patching host OS and virtualization software | Patching guest operating systems and healthcare applications | Prevents application-level vulnerabilities from exposing PHI |
| Network Security | Securing the global infrastructure network | Configuring security groups, firewalls, and zone security | Controls traffic flow to systems that process or store PHI |
The level of responsibility also depends on the type of service you're using. For Infrastructure as a Service (IaaS) like Amazon EC2, you're responsible for managing the guest OS, security patches, and application software. On the other hand, for managed services like Amazon S3 or DynamoDB, AWS takes care of the OS and platform, leaving you to focus on data management and configuring IAM permissions. This means you can't just assume compliance - you need to actively configure and verify it. Implementing RiskOps for healthcare can help teams unify their response to these shared security risks.
Conclusion
Grasping the AWS Shared Responsibility Model is a must for ensuring HIPAA compliance in the cloud. AWS secures the infrastructure itself, but the responsibility for safeguarding anything involving PHI (Protected Health Information) falls squarely on you. This shared approach means that while AWS provides robust protections, it's up to you to configure and maintain the necessary controls to keep PHI secure.
The ten strategies outlined earlier provide a strong foundation for HIPAA compliance on AWS. From signing a Business Associate Agreement to implementing encryption, strict access controls, and continuous monitoring, each step plays a critical role. Overlooking even one of these measures could leave patient data exposed, increasing the risk of breaches and regulatory penalties.
Compliance isn’t a one-and-done task. Regular risk assessments, maintaining audit trails, and managing third-party tools are essential to staying secure. As your AWS environment evolves, so will your compliance responsibilities. Incorporating these practices helps ensure you’re meeting HIPAA requirements over the long term.
Healthcare organizations that fully embrace the shared responsibility model are better equipped to protect patient data and meet regulatory standards. Ultimately, your cloud security depends on the strength and consistency of the controls you establish on your end.
FAQs
What parts of HIPAA compliance does AWS handle vs. my organization?
When it comes to HIPAA compliance, AWS takes care of the security of the cloud. This includes managing the physical infrastructure, hardware, and network security. Essentially, AWS provides a secure base for your operations.
However, the security in the cloud - tasks like encrypting patient data, setting up access controls, and monitoring systems - falls on your organization. Meeting HIPAA requirements means your team must ensure data security and proper system configuration.
The key to staying compliant? Clearly defined roles and close collaboration between your organization and AWS. Both sides need to work together to ensure everything aligns with HIPAA standards.
How do I prevent PHI from being used in non-eligible AWS services?
Healthcare organizations must take extra care to ensure that Protected Health Information (PHI) is only used within eligible AWS services. Missteps in cloud configuration or access controls can lead to compliance issues. Here are some key practices to follow:
- Stick to HIPAA-eligible AWS services: Only use AWS services that meet HIPAA requirements for storing or processing PHI, and double-check that configurations are correct.
- Enforce strict access controls: Use role-based access control (RBAC) to limit access to sensitive data and enable multi-factor authentication (MFA) for added security.
- Conduct regular audits: Periodically review your AWS environment to catch and fix any misconfigurations that could put PHI at risk.
- Encrypt PHI: Protect data by encrypting it both during transmission and while stored.
- Sign a Business Associate Agreement (BAA): Ensure a formal BAA is in place with AWS and adhere to its terms.
These steps help maintain compliance and safeguard sensitive health information in the cloud.
What logs should I keep (and for how long) to support HIPAA audits?
To comply with HIPAA requirements, you need to keep tamper-proof audit logs for a minimum of six years. These logs should track key details, such as:
- User actions like reading, writing, or deleting data
- Timestamps for each activity
- IP addresses involved
- Configuration changes
It's also essential to review these logs regularly. This helps ensure both compliance with regulations and the security of sensitive information.
