Skip to main content

HIPAA Compliant Database Hosting: Protecting ePHI at Rest in 2026

By Joseph Abear ·
HIPAA Compliant Database Hosting

Last updated: June 11, 2026

HIPAA compliant database hosting is a database environment that stores electronic protected health information (ePHI) under a signed Business Associate Agreement (BAA) and the HIPAA Security Rule safeguards at 45 CFR § 164.312, including encryption at rest, strict access control, audit logging, and tested backups. The database is where most of your patient data lives at rest, so it carries the heaviest share of HIPAA risk. A hardened web server in front of an exposed database still fails an audit. Both the contract and the controls have to reach the data tier.

TL;DR: Quick answer

  • A database that holds ePHI puts its host in scope as a Business Associate under 45 CFR § 160.103, so a signed BAA must be in place before any patient data lands in it.
  • The core controls are encryption at rest (§ 164.312(a)(2)(iv)), unique user IDs and access control (§ 164.312(a)), audit logging (§ 164.312(b)), integrity checks (§ 164.312(c)), and encrypted connections to the database (§ 164.312(e)).
  • The database is the highest-value target on your stack because it concentrates the most records in one place.
  • Managed cloud databases like Amazon RDS and Aurora are HIPAA eligible, but you still turn on encryption, lock down access, and enable logging yourself.
  • The most common failures are public-facing databases, default passwords, unencrypted backups, and logs that are collected but never reviewed.

What is HIPAA compliant database hosting?

Your website usually runs in layers: a web server that shows pages, an application that handles logic, and a database that stores the data. When a patient fills out an intake form or a portal saves a record, that information comes to rest in the database. Because the database "maintains" ePHI on your behalf, the company hosting it becomes a Business Associate and must sign a BAA, as required by 45 CFR § 164.308(b).

HIPAA compliant database hosting is the database tier set up to meet the Security Rule and backed by that BAA. It is a specific slice of the bigger picture. For how the whole environment fits together, see our complete guide to HIPAA-compliant hosting. This article zooms in on the part of the stack that holds the data.

Why the database is the highest-risk tier

Attackers follow the data, and the data sits in the database. A single database can hold thousands of records, so one mistake there exposes far more than a flaw on a single web page. That is also why regulators look closely at the data tier after a breach. Encryption matters here for a second reason too: under the Breach Notification Rule, properly encrypted ePHI can qualify for a safe harbor, which can spare you from having to notify patients after a lost or stolen copy. In plain terms, encrypting the database is both a safeguard and an insurance policy.

What does the Security Rule require for a database with ePHI?

The Security Rule's technical safeguards map cleanly onto a database. Here is each control and what it means at the data tier.

ControlCitationWhat it means for the database
Encryption at rest§ 164.312(a)(2)(iv)The stored data files and snapshots are encrypted, commonly with AES-256.
Access control and unique IDs§ 164.312(a)(1), (a)(2)(i)Every account is named and least-privilege; no shared "admin" login.
Automatic logoff§ 164.312(a)(2)(iii)Idle administrative sessions to the database time out.
Audit controls§ 164.312(b)The database logs connections and queries against ePHI, and those logs are reviewed.
Integrity§ 164.312(c)(1)Checks that data is not changed or destroyed improperly, such as checksummed backups.
Transmission security§ 164.312(e)(1)The app connects to the database over TLS, so data is encrypted in transit, not just at rest.
Backups and recovery§ 164.308(a)(7)Encrypted, automatic backups that you have actually tested restoring.

One more rule ties it together: § 164.316(b)(2)(i) says you keep compliance documentation for six years, and that includes your database log records and your backup tests. Our companion piece on HIPAA hosting security measures turns these citations into a full control checklist for the whole stack.

Managed database vs do-it-yourself

You have two broad paths for a HIPAA database. The first is a managed cloud database such as Amazon RDS or Amazon Aurora. Both are on the AWS HIPAA Eligible Services Reference, which means Amazon will cover them under its BAA. The key word is eligible, not automatic. You still enable encryption, restrict network access, require strong unique logins, and turn on logging. We cover that gap in detail in is AWS HIPAA compliant.

The second path is a database you run yourself on a server, such as MySQL, PostgreSQL, or Microsoft SQL Server. This gives you full control and full responsibility. You own the patching, the encryption setup, the backup jobs, and the log review. It is a fine choice for teams with the time and skill; it is a frequent source of audit gaps for teams without them.

Who is responsible for what?

Like every hosting arrangement, the database tier splits its duties between the host and you.

AreaHost's sideYour side
BAASigns the BAA covering the database serviceConfirms scope before loading any ePHI
EncryptionEncrypted storage and encrypted connectionsNot copying data into unencrypted exports or spreadsheets
AccessNetwork isolation, infrastructure logins, MFADatabase user roles and removing access when staff leave
LoggingEnables and retains database logsReviewing those logs and investigating odd queries
BackupsAutomatic encrypted backupsAsking for a restore test and confirming it works

Common database mistakes that fail an audit

  • A public-facing database. The database should never accept connections from the open internet. It sits on a private network and only the application reaches it.
  • Default or shared passwords. Each account is unique and strong, and the default admin login is changed or disabled.
  • Unencrypted backups. Backups carry the same data as the live database, so they need the same encryption. A stolen backup is still a breach.
  • Logs no one reads. Audit logging that is switched on but never reviewed satisfies the letter and misses the point; § 164.312(b) expects review.
  • No tested restore. A backup you have never restored is a hope, not a recovery plan.

If you would rather not build it yourself

The database is the least forgiving part of a HIPAA stack, because that is where the records are. If your team would rather build features than tune database encryption and review query logs, a managed host can own that layer. At HIPAA Compliant Hosting, our managed HIPAA cloud hosting provisions databases that arrive with encryption at rest, private networking, six-year audit logging, and tested encrypted backups, all under a signed BAA. We sell managed hosting, so weigh that disclosure as you compare. We also believe a team that understands where its ePHI rests makes safer calls, whoever runs the database. If you want a clear read on your setup, tell us what you are running.

Frequently asked questions

What is HIPAA compliant database hosting?

A database environment that stores ePHI under a signed BAA and meets the HIPAA Security Rule: encryption at rest, unique access control, audit logging, integrity checks, encrypted connections, and tested backups.

Does the database need to be encrypted under HIPAA?

Encryption is "addressable" under 45 CFR § 164.312(a)(2)(iv), meaning you implement it or document an equal alternative. For a database holding ePHI, no credible alternative exists, so treat encryption at rest as required. It can also qualify you for the breach notification safe harbor.

Is Amazon RDS HIPAA compliant?

Amazon RDS and Aurora are HIPAA eligible and covered under the AWS BAA, but not compliant on their own. You still enable encryption, restrict access to a private network, require strong logins, and turn on logging.

Can I host the database myself?

Yes. You can run MySQL, PostgreSQL, or SQL Server yourself, but then you own the encryption, patching, backups, and log review. Many audit gaps come from self-managed databases that skipped one of these.

Should the database be on the same server as the website?

For anything beyond a tiny site, keep the database on a private network that only the application can reach, never exposed to the public internet. Separation limits what a single compromise can touch.

Where to go from here

Map where your ePHI comes to rest, confirm the database tier is encrypted and private, and ask your host for a restore test in writing. To see how the database fits the rest of the stack, read our complete guide to HIPAA-compliant hosting, and for budget planning, our 2026 HIPAA hosting cost guide shows what a compliant environment typically runs.

This article is general information, not legal advice. Base your safeguards on a documented risk analysis specific to your organization, and confirm your obligations with qualified counsel. Regulatory details reflect the HIPAA Security Rule (45 CFR Part 164) as of June 2026; the December 2024 Security Rule NPRM is not yet final. Reviewed June 2026.

Sources