HIPAA software category hub
HIPAA-Compliant Databases and Cloud Services: BAA Comparison
A database product is not HIPAA compliant by itself. A regulated database workflow depends on the vendor agreement and covered service scope plus encryption, identity controls, audit logs, backups, replicas, retention, deletion, monitoring, support access, non-production data, exports, and every downstream system.
Search intent and page scope
This category owns product-selection searches such as HIPAA-compliant database software, cloud databases, and managed database comparisons. It compares vendor and service scope; it does not replace architecture or control design.
Read the vendor-neutral HIPAA database security requirementsDirect answer for buyers
Compare database and cloud services by BAA scope, HIPAA-eligible service status, encryption, identity, audit logs, backups, retention, exports, and implementation risk.
| BAA question | Confirm the exact vendor agreement, covered services, account, plan, region, and support path before PHI use. |
|---|---|
| PHI warning | Non-eligible services, SQL logs, slow query logs, object names, database snapshots, read replicas, backups, queues, analytics events, and data lake exports. |
| SOC 2 caveat | SOC 2 can support security diligence, but it does not replace HIPAA, BAA, PHI workflow, or configuration review. |
| Verification focus | Is each storage, compute, database, analytics, logging, and support service listed as eligible or covered? |
Last updated: 2026-09-17
| Buyer question | Public evidence signal | Important caveat |
|---|---|---|
| What does AWS HIPAA eligibility prove? | AWS publishes a BAA framework and a dated list of services eligible to create, receive, process, maintain, or transmit ePHI. | Eligibility is a vendor-side prerequisite, not proof that the customer's account, architecture, identity, logging, backups, application, and downstream systems are compliant. |
| Should buyers compare AWS, RDS, and Aurora as the same product? | AWS is the umbrella agreement and eligible-services scope; Amazon RDS and Amazon Aurora are service-specific database choices with different engine and configuration questions. | Use the service-specific profile for engines, regions, logs, snapshots, replicas, backups, and exports instead of relying on the AWS overview alone. |
| Where do database PHI risks extend beyond storage? | Query logs, monitoring, snapshots, replicas, backups, support cases, non-production copies, analytics, and exports can all contain or reveal PHI. | Every connected service and operational copy needs eligible scope, access, encryption, retention, deletion, and incident-response review. |
How to choose cloud and database tools
Best for
- Healthcare infrastructure where the exact cloud services are HIPAA eligible and covered by a BAA.
- Application backends, Amazon RDS-style databases, storage, and analytics pipelines designed with encryption and access control from the start.
- Teams that can govern identity, logging, backups, regions, support access, and downstream subprocessors.
BAA requirements
- Confirm the BAA covers the exact services, regions, support channels, and account structure used for PHI.
- Check the vendor's current HIPAA eligible services list or covered-service documentation before implementation, especially for databases, logs, backups, and analytics.
- Document customer responsibilities for encryption, identity, network controls, logging, backups, and incident response.
PHI risk areas
- Non-eligible services, SQL logs, slow query logs, object names, database snapshots, read replicas, backups, queues, analytics events, and data lake exports.
- Support tickets, debugging traces, monitoring dashboards, third-party marketplace products, and cross-region replication.
- Non-production databases, copied seed data, BI exports, and application-layer mistakes where the cloud provider is eligible but the customer's SaaS architecture is not governed.
Recommended review order
Start with vendors that show clearer BAA signals
Treat these as higher-risk until verified
No listed vendor has an obvious public "not supported" or "unable to confirm" signal in this category, but each workflow still needs BAA, PHI, configuration, and integration review before use.
Vendor comparison table
| Vendor | Role | HIPAA signal | BAA signal | SOC 2 signal | Review focus | Last checked |
|---|---|---|---|---|---|---|
| AWS HIPAA eligible services | Cloud provider and eligible-services scope | Conditional | AWS BAA required | Public evidence | Eligible-service list, account BAA, regions, logging, support | 2026-09-17 |
| Amazon RDS HIPAA eligibility | Managed relational database service | Conditional | AWS BAA required | AWS public evidence | Engine, region, encryption, logs, snapshots, backups | 2026-09-17 |
| Amazon Aurora HIPAA eligibility | AWS-managed relational database engine | Conditional | AWS BAA required | AWS public evidence | Engine, region, replicas, logs, snapshots, exports | 2026-08-09 |
| Amazon Connect HIPAA eligibility | Cloud contact-center service | Conditional | AWS BAA required | AWS public evidence | Account BAA, region, recordings, storage, integrations | 2026-09-17 |
| AWS Bedrock HIPAA eligibility | Managed foundation-model service | Conditional | AWS BAA required | AWS public evidence | Model and region, prompts, outputs, logs, agents, knowledge bases | 2026-09-17 |
| Airtable Enterprise BAA review | Application database and workflow platform | Conditional | Enterprise Scale only | Public evidence | Enterprise Scale terms, ePHI fields, automations, exports | 2026-09-17 |
Avoid if
- The service used is not listed as eligible or covered.
- Backups, logs, snapshots, read replicas, support tickets, or exports contain PHI outside governed systems.
- Teams cannot enforce encryption, access control, and audit log requirements.
Methodology
- Separate vendor eligibility from customer implementation responsibility.
- Review exact services, database engines, regions, support plans, and logging paths.
- Map where PHI is stored, queried, logged, replicated, backed up, restored, and exported.
Verification checklist
- Is each storage, compute, database, analytics, logging, and support service listed as eligible or covered?
- For Amazon RDS or another managed database, are the engine, region, encryption, snapshots, replicas, logs, exports, and backup lifecycle covered?
- Are encryption, IAM, MFA, audit logging, retention, backup, key management, and deletion controls enabled and documented?
- Can PHI be kept out of logs, telemetry, object names, support cases, and non-production environments?
- Have downstream vendors, regions, subprocessors, and disaster-recovery paths been reviewed?
Verify the complete workflow before PHI use
Use a vendor and configuration checklist to review BAA scope, covered services, data paths, integrations, support access, and customer responsibilities. Do not submit PHI or patient details.
Related guides
HIPAA SaaS BAA Availability Index
The ComplySaaS BAA Availability Index compares public HIPAA, BAA, PHI, and SOC 2 signals across 30 core SaaS vendors. It is a research starting point,...
What Is a Business Associate Agreement (BAA)?
A Business Associate Agreement is a HIPAA contract between a covered entity and a vendor that may create, receive, maintain, or transmit PHI. A BAA do...
Can You Store PHI in SaaS Tools?
You should only store PHI in a SaaS tool after verifying that the vendor, product, plan, agreement, configuration, and connected systems support that ...
HIPAA Database Security Requirements for SaaS Teams
A database is not HIPAA compliant by itself. A HIPAA-ready database workflow requires a covered vendor or cloud service, appropriate BAA scope, encryp...
SOC 2 vs HIPAA for SaaS Vendor Review
SOC 2 and HIPAA answer different questions. SOC 2 is independent security-control evidence for a service organization, while HIPAA governs protected h...
FAQ
Are Amazon RDS and Amazon Aurora automatically HIPAA compliant?
No. Amazon RDS and Amazon Aurora may be HIPAA eligible under the AWS BAA, but the customer must still verify the exact service and engine scope, account, region, encryption, IAM, network controls, logs, snapshots, replicas, backups, exports, application behavior, and downstream systems.
What is a HIPAA-compliant database?
A HIPAA-compliant database is not just a database product. It is a governed workflow with an appropriate vendor agreement, eligible service scope, encryption, identity controls, audit logs, backup controls, retention, deletion, monitoring, and policies for how PHI is accessed and exported.
What is the difference between eligible database software and a compliant database workflow?
An eligible service and BAA are only vendor-side prerequisites. The customer still needs correct architecture, access controls, encryption, logging, backups, retention, deletion, incident response, workforce policies, and review of every system that touches PHI.
What should be checked before storing PHI in a database?
Check BAA scope, eligible services, encryption, identity controls, audit logs, backups, support access, non-production data, exports, retention, deletion, and whether PHI appears in logs or analytics.
Are Amazon Connect and AWS Bedrock covered by the AWS BAA?
AWS currently lists Amazon Connect and Amazon Bedrock as HIPAA eligible, with Bedrock exclusions for Fable and Mythos models. Each workload still needs AWS BAA acceptance plus feature, region, logging, storage, support, integration, and customer-control review.
What should buyers verify for cloud and database tools?
Verify BAA availability, covered services, product plan, data flows, admin controls, integrations, support access, retention, audit logs, and whether PHI appears in fields, messages, files, or notifications.
Does SOC 2 prove HIPAA readiness?
No. SOC 2 can provide useful security evidence, but HIPAA-regulated workflows also require BAA scope, PHI handling review, configuration, policies, and qualified legal or compliance guidance.