HIPAA Compliant Database: Requirements and Configuration Checklist for Storing PHI

Short answer: No database is HIPAA certified. A HIPAA compliant database is one you configure to meet the Security Rule's technical safeguards (access control, audit controls, integrity, authentication and transmission security), run under a signed business associate agreement with your hosting provider, and back with documented policies, tested backups and a current risk analysis.

Related guides:

• HIPAA compliance in cloud-based healthcare
• HIPAA encryption requirements
• What is considered PHI under HIPAA?

Key takeaways

• Compliance is a property of your setup, not the engine. PostgreSQL, MySQL or a document store can all hold ePHI. What matters is how you configure, operate and document them.
• Your managed database provider needs a BAA. HHS treats a cloud provider that stores ePHI as a business associate even when it cannot read the encrypted data.
• Map each technical safeguard to a concrete database control. Unique accounts, audit logs, integrity checks, strong authentication and TLS are the core of HIPAA database security.
• Backups are required, and restores should be proven. A data backup plan and disaster recovery procedures are required specifications, and testing is addressable, which means you must assess it and document your decision.
• Keep real PHI out of dev and test. Use synthetic or properly de-identified data so your lower environments stay out of scope.

---

Is there such a thing as a HIPAA certified database?

No. There is no government certification for HIPAA compliant databases or any other product. In its cloud computing guidance, the HHS Office for Civil Rights (OCR) states plainly that it "does not endorse, certify, or recommend specific technology or products."

When a vendor calls its database "HIPAA compliant" or "HIPAA eligible," it usually means two things: the service can be configured to support the Security Rule, and the vendor will sign a business associate agreement (BAA) for it. Neither makes your deployment compliant on its own. You still own the configuration, the access model, the monitoring and the evidence.

So instead of asking "is this database HIPAA compliant?", ask whether the provider will sign a BAA covering the service, whether you can enforce encryption with keys you control, export audit logs, restore backups on demand and separate environments cleanly. Without the BAA, the rest does not matter for production ePHI.

Do you need a BAA with your database provider?

Yes, if the provider creates, receives, maintains or transmits ePHI for you. HHS is explicit that encryption does not change this: "Lacking an encryption key for the encrypted data it receives and maintains does not exempt a CSP from business associate status," according to the same HHS cloud computing guidance.

Major cloud platforms and many managed database providers offer BAAs, but scope varies. In our experience:

• The BAA covers a list of eligible services. A provider may sign a BAA that applies only to services named on its own HIPAA page. A database product, a read replica feature or a backup add-on may or may not be on that list.
• The BAA depends on your plan. Some managed database vendors only sign BAAs on higher pricing tiers or enterprise contracts.
• Adjacent services fall outside the BAA. Analytics, support attachments and log exports can move PHI outside BAA coverage.

Verify eligibility on the provider's own HIPAA or compliance page, keep a copy of the signed agreement, and recheck it whenever you add a feature. Our guide to what a HIPAA business associate agreement must include covers the contract terms themselves.

Which HIPAA safeguards apply to a database?

All five technical safeguard standards in 45 CFR 164.312 apply to any database that holds ePHI. Some implementation specifications are "required" and some are "addressable." Addressable does not mean optional: under 45 CFR 164.306(d), you must implement the specification when reasonable and appropriate, or document why not and implement an equivalent alternative where reasonable.

Standard (164.312)	What the rule asks for	Database controls that satisfy it
(a) Access control	Unique user identification and emergency access (required); automatic logoff and encryption (addressable)	Named accounts per person and per service, no shared admin logins, role-based access control (RBAC) with least privilege, row-level security where tenants share tables, documented break-glass access, idle session timeouts, encryption at rest
(b) Audit controls	Mechanisms to record and examine activity in systems containing ePHI	Database audit logging for logins, privilege changes, schema changes and reads of sensitive tables, shipped to a separate log store with restricted write access
(c) Integrity	Protect ePHI from improper alteration or destruction; authentication mechanism (addressable)	Constraints and transactions, restricted DELETE and UPDATE grants, write-ahead log or change history, checksums on backups, soft deletes for clinical records
(d) Person or entity authentication	Verify that anyone seeking access is who they claim to be	SSO or IAM-based database authentication, multi-factor authentication for human access, short-lived credentials or rotated secrets for services
(e) Transmission security	Integrity controls and encryption in transit (addressable)	Enforced TLS on every connection, certificate verification in clients, private networking, no public database endpoints

Two administrative safeguards also apply. 45 CFR 164.308 requires procedures to "regularly review records of information system activity, such as audit logs," and policies for authorizing, establishing and modifying access to ePHI. Schedule both reviews.

How should you encrypt PHI and manage keys?

Encrypt at rest and in transit by default, and keep keys separate from the data. Encryption is technically addressable, but for a production ePHI database it is very hard to document a reasonable alternative. Encryption also matters for breach response: HHS breach notification guidance treats PHI encrypted consistent with NIST guidance as unusable, unreadable or indecipherable to unauthorized persons, provided the key has not been breached. The same guidance says decryption keys "should be stored on a device or at a location separate from the data they are used to encrypt or decrypt."

A layered approach works well for most HealthTech stacks:

1. Storage encryption. Turn on volume or tablespace encryption for the database, its replicas, snapshots and backups. Check that all four are covered, not just the primary.
2. Customer-managed keys. Use a cloud key management service or hardware security module, with key policies that limit who can use and administer keys. Log every key use.
3. Field-level encryption or tokenization. Encrypt the most sensitive columns, such as diagnoses, notes or government identifiers, in the application before they reach the database, or replace them with tokens from a separate vault. A database administrator with full table access then still cannot read them.
4. TLS everywhere. Require encrypted connections at the server, not just in the client config, and verify certificates.

What about backups, retention and disposal?

Backups are required, restores should be tested, and disposal needs a written procedure. Under the contingency plan standard in 45 CFR 164.308(a)(7), a data backup plan that creates "retrievable exact copies" of ePHI and disaster recovery procedures to "restore any loss of data" are required. Testing and revision of the plan is addressable.

For a database, that translates to:

• Automated backups and point-in-time recovery, encrypted with keys you control and stored in a separate account or project from production.
• Scheduled restore tests into an isolated environment, with the result recorded as evidence. A backup you have never restored is an assumption.
• Defined recovery objectives per database, reflected in your backup and recovery policy.
• Retention rules for backups and snapshots so old copies of PHI do not pile up indefinitely. Medical record retention periods usually come from state law and customer contracts, not HIPAA, so confirm them with counsel.
• Disposal procedures. 45 CFR 164.310(d) requires policies for the final disposition of ePHI and the media it is stored on. In the cloud, document how you delete instances, snapshots and keys, and when crypto-shredding (destroying the key) is your disposal method.

Keep the documentation itself, too. 45 CFR 164.316(b)(2) requires you to retain Security Rule policies, procedures and required records for 6 years from creation or the date they were last in effect, whichever is later.

How do you keep PHI out of dev and test?

Separate environments completely and use data that is not PHI below production. Every copy of production data you restore into staging or a developer laptop expands your HIPAA scope, your audit logging requirements and your breach exposure.

Practical rules:

• Separate accounts or projects for production, staging and development, with no network path from lower environments into the production database.
• Synthetic data by default for development and automated tests.
• De-identified data when you need realism. HHS recognizes two methods under the Privacy Rule, Safe Harbor and Expert Determination, and its guidance confirms that properly de-identified data is no longer PHI. Simply masking names usually does not meet either method.
• Restricted production access. Debug through approved, logged, time-limited access, not by copying data out.

HIPAA database configuration checklist

Use this table as a working checklist for each database that stores ePHI. Pair it with your HIPAA risk assessment so every control traces back to a documented risk.

Area	Configuration item	Evidence to keep
Contract	Signed BAA covering the database service, region, backups and support access	Executed BAA, provider eligibility page snapshot
Network	Private endpoints only, no public IP, security groups limited to app tier	Network config export
Transit	Server-enforced TLS, certificate verification in clients	Parameter settings, connection test
At rest	Storage encryption on primary, replicas, snapshots and backups	Encryption settings per resource
Keys	Customer-managed keys, restricted key policy, rotation schedule, key use logging	Key policy, rotation record
Sensitive fields	Field-level encryption or tokenization for highest-risk columns	Data classification, design doc
Identity	Unique named accounts, SSO or IAM auth, MFA for humans, no shared admin	User list, auth config
Authorization	RBAC with least privilege, row-level security for multi-tenant tables, break-glass procedure	Role definitions, access review sign-off
Audit	Login, privilege, schema and sensitive read logging, shipped to separate store	Log config, sample entries, review record
Integrity	Constrained write grants, change history, backup checksums	Grant list, sample history
Backups	Automated backups and point-in-time recovery in a separate account	Backup config
Restore	Periodic restore test with recovery time recorded	Restore test report
Retention and disposal	Backup and snapshot retention rules, documented deletion and crypto-shredding	Policy, deletion log
Environments	Separate prod, staging and dev, synthetic or de-identified data below prod	Account structure, data source description
Review	Scheduled access reviews and audit log reviews	Review records

Will the proposed Security Rule update change this?

Possibly, but it is still a proposal. HHS published a notice of proposed rulemaking in the Federal Register on January 6, 2025, with comments due March 7, 2025. Among other changes, it proposes making encryption and multi-factor authentication required rather than addressable in most cases.

As of October 2026, the proposal has not been finalized. The HHS NPRM page states that "the current Security Rule remains in effect" while the rulemaking continues.

How SecureSlate helps

SecureSlate gives HealthTech teams a built-in HIPAA framework with controls mapped across SOC 2, ISO 27001, HITRUST and other frameworks, so database safeguards you implement once count everywhere. Agentless read-only cloud integrations collect configuration evidence from your cloud accounts, and access reviews sync accounts from connected integrations so you can record who has access to production data. Risk management helps you track the risks from your HIPAA risk analysis, vendor risk management tracks providers such as your managed database host, and audit management gives auditors a workspace with an evidence tracker.

Start your free SecureSlate trial

FAQ

Is PostgreSQL or MySQL HIPAA compliant?

Neither is compliant or non-compliant on its own. Both can store ePHI if you configure encryption, access control, audit logging and backups to meet the Security Rule, and host them under a BAA with any provider that manages them for you.

Does encrypting the database remove the need for a BAA?

No. HHS guidance says a cloud provider that maintains encrypted ePHI is still a business associate even without the key, so you still need a BAA with that provider.

Is encryption at rest required for HIPAA?

Under the current Security Rule, encryption is an addressable specification. You must implement it when reasonable and appropriate, or document why not and use an equivalent alternative. For a production database holding ePHI, most teams find encryption is the reasonable choice.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.