Amazon S3 can be used in a HIPAA compliant manner alongside other AWS services. Read about necessary security configuration for S3.
Amazon S3 is listed as HIPAA-eligible service by Amazon Web Services (AWS), meaning that it can be configured and used in a HIPAA compliant manner. That said, your organization is responsible for managing specific administrative and technical requirements under the AWS Cloud Shared Responsibility Model. Just using a HIPAA-eligible service from Amazon does not make your organization compliant. It is possible to build on HIPAA-eligible services and still not be in compliance with HIPAA.
Under the shared responsibility model, AWS will manage HIPAA physical requirements such as locking facilities, limiting employee access.
Steps for HIPAA Compliance in S3
Your organization should consider the following steps, when building on Amazon S3, as well as other AWS cloud services.
Sign The AWS BAA
When configuring AWS cloud services in a HIPAA compliant manner, your organization must first sign a Business Associates Agreement (BAA) with AWS. This agreement will lay out the responsibilities your organization must manage and that AWS must manage.
Set Administrative Policies
Organizations must create and manage HIPAA administrative policies. Additionally, organization’s must conduct an annual risk assessment and perform periodic reviews on all policies, procedures, and technical implementation. Essential compliance policies include:
- Risk Management
- Staff Roles
- Disaster Recovery
- Vulnerability Scanning
- Employee Training, and more..
These policies define which individuals will be responsible for managing technical implementation and organization security plan. Dash platform can generate customized administrative policies.
Set Technical Controls
Alongside Administrative Policies, your organization must implement technical safeguards such as proper user authentication, audit logging, vulnerability scanning, and backup and recovery.
HIPAA compliance reaches far outside of just S3. For your AWS account as a whole, your team should determine the best architecture and solutions for logging, backup, and other technical controls. S3 technical implementation should include the following:
- S3 Versioning should be implemented
- S3 Buckets should be replicated or backed up
- S3 Buckets with PHI should not be “Public” or available to everyone
- S3 Read/Write Access should be limited to only those necessary
Further security best practices and compliance requirements can be read in Dash’s guide to Managing HIPAA in AWS.
Managing S3 Compliance
Organizations must set proper Amazon S3 security settings and configuration and maintain an active security plan to maintain HIPAA compliance. Many teams turn to consultants and numerous solutions to meet requirements. Dash custom administrative policies and continuous compliance monitoring make it easy for organizations to manage HIPAA compliance in AWS and S3.
Generally, no single solution makes an organization HIPAA compliant. Organizations must select appropriate technologies, build and follow administrative policies, and address technical concerns. Learn how Dash automates compliance management for AWS
FAQ: Amazon S3 and HIPAA Compliance
Which encryption option should I use for buckets that hold PHI?
S3 encrypts all new objects by default with SSE-S3, which satisfies encryption at rest but gives you no control over the key. For PHI, SSE-KMS with a customer managed key is usually the better choice: it separates key permissions from bucket permissions, produces a CloudTrail record of key usage, and lets you scope a key per environment or workload. SSE-C is rarely worth the operational burden because you manage the keys entirely and AWS cannot help you recover data if they are lost.
Is bucket-level Block Public Access enough, or do I need the account-level setting?
Enable both. Account-level Block Public Access applies to every bucket in the account, including buckets created later by a developer, a script, or a misconfigured template. Bucket-level settings protect individual buckets but depend on someone remembering to apply them. A bucket policy that denies public access is useful as defense in depth, but it does not cover every path to exposure, such as ACLs or a future policy change.
Should I use bucket policies or ACLs to control access?
Use bucket policies and disable ACLs where you can. ACLs are a legacy mechanism that is easy to misconfigure and hard to audit, and S3 Object Ownership settings let you turn them off so that the bucket owner always owns objects. Centralize access in bucket policies that reference IAM principals, conditions, and VPC endpoints, then review those policies as part of your access review cycle.
How do I find out which buckets actually contain PHI?
Do not rely on bucket names or team knowledge. Use S3 Inventory to enumerate buckets and objects at scale, tag buckets by data classification, and run a sensitive data discovery tool such as Macie to detect identifiers in object contents. Classification is the prerequisite for everything else, because encryption, retention, and access rules only apply correctly if you know which data they protect.
How do I audit who accessed a PHI object?
Enable CloudTrail data events for S3 on the buckets that hold PHI, because object-level read and write activity is not captured by default management events. Server access logs give you request-level detail but are delivered on a delay and are harder to query. Send both to a centralized, access-controlled logging account so that someone with access to the data bucket cannot also erase the record of their access.
Does S3 Versioning count as a backup for compliance purposes?
No. Versioning protects against overwrites and accidental deletion inside the same bucket, but it does not protect against account compromise, a malicious actor with delete permissions, or a regional failure. Pair versioning with replication or AWS Backup into a separate account, and consider MFA delete for the small number of buckets where permanent deletion must be tightly controlled.
How should PHI be disposed of when it is no longer needed?
Define retention periods per data category, implement them with lifecycle rules, and confirm that versioned objects and noncurrent versions are also expired. Where a KMS customer managed key protects the data, deleting the key renders the ciphertext unreadable, which is a practical way to achieve cryptographic erasure. Note that Object Lock and legal holds prevent deletion by design, so retention policy and disposal obligations have to be reconciled before you enable them.
Are presigned URLs safe for sharing PHI?
They can be, if they are short-lived, issued only over TLS, scoped to a single object, and generated for an authenticated user whose access you have already authorized. The risk is that a presigned URL is a bearer token: anyone who obtains it can use it until it expires. Keep expiry times short, avoid placing them in logs or emails, and log the underlying access so you can trace who requested the object.
Should PHI buckets be reachable from the internet at all?
Generally no. Restrict access to a VPC endpoint and add a bucket policy condition that denies requests not arriving through that endpoint, so the bucket cannot be read even if credentials leak. This also removes the temptation to use S3 static website hosting, which requires public access and is incompatible with storing PHI.
Does replicating PHI to another region create new obligations?
Yes. The destination region must be covered by your BAA, the replica must be encrypted as strictly as the source, and the destination bucket’s access controls and logging need the same scrutiny. Replication also copies delete markers only if you configure it to, so verify what happens to replicas when a source object is deleted. Many teams replicate into a separate, tightly restricted account to reduce the blast radius of a compromise.
