HIPAA on AWS: the BAA, eligible services and your responsibilities

When your organization buys a SaaS product that stores or processes ePHI, the business associate agreement is between you and the SaaS vendor. You do not sign a BAA with AWS just because the vendor runs on it. The vendor is the business associate that handles PHI on your behalf, and AWS is a subcontractor from the vendor's point of view. Your obligations under the Security Rule (45 CFR 164.308(b) and 164.314) are met by having that agreement in place and by assessing the vendor, not by reviewing AWS's terms alone.

• Sign with the vendor: Your BAA should name the SaaS company as the business associate and cover the PHI it touches, including data it keeps in AWS.
• Check for no separate AWS contract: Ask whether you are expected to accept AWS Artifact terms directly. Usually you are not, and the vendor should explain why.
• Review termination and return of data: The agreement should state how PHI is returned or destroyed when the contract ends.
• Confirm breach notice timing: Ask how the vendor will notify you of a security incident affecting your data, including incidents in its AWS environment.
• Ask who holds the risk analysis: The vendor must perform its own risk analysis, and the cloud configuration it chose affects that analysis.

Before signing, confirm that the vendor's BAA covers the specific services and regions it uses, and that it can show the agreement it has with AWS.

If your company builds a product on AWS and handles ePHI for covered entities, you are a business associate in your own right. You accept AWS's Business Associate Addendum in AWS Artifact to cover your use of AWS. That agreement does not replace the BAA you must sign with each covered entity customer. AWS's position is that its customers' covered entities sign with the customer, not with AWS, so your contracts with customers are the agreements that govern your handling of their PHI.

• Accept the AWS addendum: Review and accept it in AWS Artifact before you place PHI in any AWS account.
• Sign a BAA with each customer: Each covered entity or upstream business associate that sends you PHI needs its own written agreement with you.
• Keep PHI in eligible services: The AWS addendum applies to services listed as HIPAA-eligible, so confirm each service in your architecture appears on that list.
• Run your own risk analysis: Your risk analysis covers your application layer, your access model and your operations, not only the AWS infrastructure.
• Flow terms to your own vendors: Any subcontractor that handles PHI for you needs a BAA with you.

Map each customer contract to the AWS services it touches before go-live so no PHI reaches a service outside the agreed scope.

Under the Security Rule, a business associate that delegates PHI work to a subcontractor must obtain satisfactory assurances from that subcontractor, in writing, that it will protect the information in the same way. This flow-down runs through every level that creates, receives, maintains or transmits ePHI. A cloud provider that stores encrypted ePHI without holding the key is still a business associate, so the chain does not end at the application vendor. Each link must be documented, and the terms in each agreement should not be weaker than the one above it.

• Map every subcontractor: List the hosting, logging, backup, support and analytics providers that can reach PHI.
• Confirm written assurances: Each subcontractor should have an agreement with the business associate that matches its PHI role.
• Check for gaps in incident reporting: Breach notice must travel up the chain quickly enough for the covered entity to meet its own deadlines.
• Confirm data return and deletion: Each subcontractor should be bound to the same return or destruction terms.
• Track changes: Ask to be notified when the vendor adds or replaces a subcontractor that handles PHI.

Check that the subcontractor list is current at contract signing and at each renewal, because the chain changes as products grow.

When you evaluate a SaaS vendor on AWS, you can ask for evidence that its agreements and controls are in place. A vendor's word that it is HIPAA compliant is not enough, and HHS does not endorse private certifications, so the useful documents are the contracts, the vendor's own risk analysis summary and the policies that govern its handling of PHI. An independent assessor's report can help, but it does not replace the vendor's obligation to perform its own analysis.

• Request the BAA: Ask for the signed agreement with you, and confirm it names the vendor as business associate.
• Request the AWS arrangement: Ask the vendor to confirm it accepted the AWS addendum and to name the HIPAA-eligible services in use.
• Request the subcontractor list: Ask for the subprocessors that can access PHI and the status of their agreements.
• Request a risk analysis summary: Ask how the vendor identified risks to ePHI and how it tracks the remediation of those risks.
• Request the incident process: Ask for the vendor's breach notice timeline and its ransomware response plan.

Confirm each point in writing before you sign, and retain the answers in your vendor file for the next review.

As the covered entity or business associate, your organization keeps ownership of the Security Rule. AWS can run the infrastructure, but it does not perform your risk analysis, adopt your policies, train your workforce or decide who may access ePHI. Each business associate must perform its own risk analysis, and the cloud configuration you choose changes that analysis for everyone in the chain.

• Risk analysis and risk management: You document where ePHI lives in AWS, the threats and vulnerabilities you have identified, and the plan for reducing them.
• Policies and procedures: You write and maintain the policies that govern access, incident response, backups and workforce conduct.
• Workforce and access: You assign a security official, grant and remove user access, and train staff on handling PHI.
• Evidence and records: You retain the logs, reviews, tickets and documentation that show the safeguards operate over time.
• Vendor oversight: You confirm the BAAs and SLA terms for every SaaS partner that touches your ePHI.

Before you rely on any arrangement, confirm with your counsel exactly which AWS account holder signs the BAA and which of your own controls cover the rest.

AWS is responsible for the contract, the services it offers under that contract and the controls inside its own infrastructure. Its HIPAA position rests on a standard Business Associate Addendum that customers review and accept in AWS Artifact. Its obligations do not extend to how your accounts, identities or applications are configured.

• Business Associate Addendum: You accept the standard BAA in AWS Artifact, and the terms apply to the accounts covered by that acceptance.
• HIPAA-eligible services: AWS says PHI should be processed, stored and transmitted only in services listed in its HIPAA Eligible Services Reference, so each service in your design needs checking against that list.
• Infrastructure controls: AWS operates physical data centers, hardware and the underlying platform under its own risk management program.
• No certification: AWS states there is no HIPAA certification for a cloud service provider, so any claim of a "HIPAA-certified" AWS environment should be treated with caution.

Confirm the current eligible services list and the BAA terms directly with AWS before you finalize your architecture.

An implementation partner such as DeployOpen prepares the environment and evidence that your team will then own and operate. The work is typically defined in a fixed-scope written agreement that names the accounts, services, configurations and deliverables in advance. The partner does not hold the BAA, decide your risk tolerance or certify the result.

• Account and configuration preparation: Setting up accounts, identities, network boundaries, encryption and logging to match the agreed design.
• Hardening and documentation: Applying configuration baselines and writing the runbooks and system descriptions your team needs.
• Backup and testing support: Helping you configure backup and recovery, and supporting restore tests you schedule and review.
• Evidence preparation: Organizing configuration records, logs and screenshots so your team can show how safeguards were implemented.
• Ongoing support: Where you need it, a retainer for upgrades, monitoring support and periodic reviews.

Ask any partner to put its scope, deliverables and what it will not do in writing before work begins.

An independent auditor or assessor tests the program and is the only party that issues a report on it. Its work begins from the evidence you provide and the controls you say you operate, then it tests whether those statements hold. HHS does not endorse private certifications, and a third-party assessment does not prevent OCR from later finding a violation.

• Testing: The assessor samples configurations, access records, risk analysis documents and incident records to check operation over time.
• Reporting: Only the independent assessor issues a report or attestation about your program.
• Scope limits: Its conclusions cover the systems and period it examined, so confirm the boundary before relying on the result.
• Independence: The assessor should not design the controls it tests, which is why implementation partners and assessors are usually different firms.

DeployOpen prepares systems, controls and evidence for assessment. It does not issue audit reports, attestations or certifications, and it does not represent any assessment outcome.