Security Measures for HIPAA-Compliant Hosting: A CFR-Mapped Technical Checklist

HIPAA-compliant hosting needs encryption of ePHI at rest and in transit, unique user IDs, least-privilege access, audit logging and automatic logoff under 45 CFR § 164.312. It also needs tested backups under § 164.308(a)(7), six-year documentation retention and a signed Business Associate Agreement. Encryption, automatic logoff and contingency plan testing are addressable, which is not the same as optional. The Security Rule does not name products. It names outcomes, and each of the HIPAA hosting security measures below maps to a control you can implement and verify.

TL;DR: Quick answer

• Encryption at rest is an addressable specification under 45 CFR § 164.312(a)(2)(iv). On AWS that typically means AES-256 through KMS-managed keys on EBS, S3, and RDS, with the decision documented per § 164.306(d).
• In practice, transmission security under § 164.312(e)(1) and (e)(2)(ii) means TLS 1.2 or higher on every endpoint that carries ePHI. That includes internal hops behind the load balancer.
• Audit controls under § 164.312(b) require mechanisms that record activity in systems containing ePHI. Security Rule policies and documentation must be retained six years under § 164.316(b)(2)(i).
• A Business Associate Agreement is required by § 164.308(b) and § 164.504(e) before a vendor handles ePHI for you. You accept AWS's BAA self-service in AWS Artifact, and AWS lists more than 170 HIPAA eligible services (list updated October 15, 2026).
• Backups, disaster recovery, and emergency-mode operations fall under the contingency plan standard at § 164.308(a)(7). Testing and revision of the plan is addressable there, but an untested restore is hard to defend in any close review.

Which CFR sections govern each hosting security control?

The HIPAA Security Rule splits safeguards into administrative (§ 164.308), physical (§ 164.310), and technical (§ 164.312) categories. Hosting providers acting as Business Associates inherit obligations across all three. The table below maps each of the HIPAA hosting security measures to its CFR section and an implementation your Healthcare IT or DevOps team can verify.

For a plain-language walkthrough of the three safeguard categories themselves, see our guide to administrative, physical, and technical safeguards. For how these controls come together on a single machine, see HIPAA compliant server.

Encryption at rest: AES-256 with managed keys

Encryption at rest is addressable, not optional in the casual sense. Under § 164.306(d), a Covered Entity or Business Associate must implement an addressable specification if it is reasonable and appropriate. Otherwise, it must document why and adopt an equivalent alternative where reasonable and appropriate. AES-256 encryption is built into EBS, S3, and RDS, so it is hard to document a credible reason not to use it.

In practice, a defensible configuration has four parts. Turn on EBS encryption by default in every AWS Region you use, because it is a per-Region setting. Enforce bucket-level encryption on S3 buckets by policy. Create RDS instances with encryption enabled. AWS only lets you encrypt an RDS instance when you create it. To encrypt an existing one, restore it from an encrypted snapshot copy or use a blue/green deployment. Use KMS customer-managed keys with rotation enabled and key policies that limit decrypt permissions to specific roles. The database layer carries its own requirements; see our guide to HIPAA compliant database hosting for the RDS specifics. Encrypted ePHI that is lost or stolen generally qualifies for the breach notification safe harbor under §§ 164.400-414. That is the single strongest argument for doing this correctly.

Encryption in transit: TLS 1.2 or higher everywhere ePHI moves

Transmission security under § 164.312(e)(1) requires guarding against unauthorized access to ePHI transmitted over a network, and § 164.312(e)(2)(ii) names encryption as the mechanism. The current baseline is TLS 1.2 minimum, with TLS 1.3 preferred on patient-facing endpoints. That covers the public edge: load balancer listeners, CloudFront distributions, API endpoints.

The part teams miss is the internal leg. Terminating TLS at the load balancer and forwarding plaintext HTTP to backend instances is common. It is a risk decision to document in the risk analysis required by § 164.308(a)(1)(ii)(A), not an accident of default configuration. End-to-end TLS to the instance, or at minimum encryption within a tightly scoped private subnet with a written justification, is the defensible posture.

Access control: unique IDs, least privilege, and automatic logoff

Three technical specifications work together here. Unique user identification (§ 164.312(a)(2)(i)) means every administrator, developer, and service has its own identity. Shared SSH keys and a communal admin login break that rule, because the audit trail can no longer show which person acted. IAM least privilege puts the access control standard at § 164.312(a)(1) into practice. Use scoped roles instead of account-wide permissions, MFA on every human identity, and instance roles instead of long-lived access keys on production servers.

Automatic logoff (§ 164.312(a)(2)(iii)) applies to more than the patient-facing application. Application sessions should expire after a defined idle period, but so should SSH sessions (ClientAliveInterval), database consoles, and the AWS console itself. An EHR that logs users out after 15 minutes does not help if the DBA session to the production database stays open all week. The session-timeout side is covered in HIPAA automatic logoff.

Audit logging and the six-year documentation rule

Section 164.312(b) requires hardware, software, or procedural mechanisms that record and examine activity in systems containing ePHI. A working implementation has three layers. Infrastructure logs cover API calls (CloudTrail) and network activity (VPC Flow Logs). System logs cover auth and sudo activity. Application logs record who viewed which record, login failures and permission changes. Logs should ship to a separate account or bucket with write-once controls, so an attacker who compromises a server cannot erase their tracks. That also supports the integrity standard at § 164.312(c). Our guide to HIPAA audit logs covers what to record at each layer and who holds which log.

Retention trips people up. The six-year requirement at § 164.316(b)(2)(i) applies to Security Rule documentation: policies, procedures, risk analyses, and records of actions and assessments. The audit controls standard at § 164.312(b) sets no retention period for the logs themselves. Many organizations keep logs for six years anyway, because logs are the evidence behind those assessments. A 90-day retention setting with no archive leaves little to show an investigator. CloudWatch Logs keeps log data indefinitely by default, so set a retention period for each log group that matches your policy.

Backups and the contingency plan

The contingency plan standard at § 164.308(a)(7) requires a data backup plan, a disaster recovery plan, and an emergency mode operation plan. Testing and revision procedures are an addressable specification under the same standard. They are also the step that shows the plan works. Concretely: run automated daily backups encrypted with the same KMS discipline as production data, and keep copies in a second region. Write defined RTO and RPO numbers into the plan, and run a restore test on a schedule with the result documented. A backup that has never been restored is a hypothesis, and hypotheses do not appear in contingency plans that survive review.

The BAA chain: the contractual layer under the technical one

None of the controls above matter legally without the Business Associate Agreement required by § 164.308(b) and § 164.504(e). AWS offers its BAA self-service, and you accept it in AWS Artifact. Its HIPAA Eligible Services Reference names the services you may use with ePHI under that BAA. AWS lists 174 HIPAA eligible services as of its October 15, 2026 update. Eligible does not mean compliant. AWS says customers must still configure each service to meet HIPAA. Under the shared responsibility model, AWS secures the infrastructure and you configure everything in the table above. Whether AWS holds up its side is covered in our analysis of whether AWS is HIPAA compliant.

The chain extends past the cloud. Email vendors, monitoring tools with access to ePHI, and managed service providers each need their own BAA. A single unsigned link exposes the Covered Entity to the penalty tiers at 45 CFR § 102.3. Since January 28, 2026, the lower tiers run up to $73,011 per violation, with a calendar-year cap of $2,190,294. Our breakdown of HIPAA violation fines and penalties has the details.

Common misconfigurations found in audits

A structured HIPAA website audit is how these get caught on your own site.

• Encrypted volumes, unencrypted snapshots. EBS encryption enabled, but older snapshots and AMIs predate it, or S3 backup buckets lack enforced encryption.
• TLS at the edge only. Plaintext HTTP between the load balancer and instances with no documented risk decision.
• Shared credentials. One SSH key on every server, one admin login for the team, root account used for daily work.
• Logs that vanish. CloudTrail on, but logs stored in the same compromisable account with short retention and no integrity validation.
• Untested restores. Backups run nightly; nobody has performed a restore since the system launched.
• Missing subcontractor BAAs. A signed AWS BAA, but the transactional email service that sends appointment reminders containing PHI has none.
• Web-layer gaps. Hardened servers behind login pages that can still be framed by an attacker; see our clickjacking prevention guide for the headers that close that gap.

Frequently asked questions

Is encryption legally required by HIPAA?

Encryption is an addressable specification under § 164.312(a)(2)(iv) and § 164.312(e)(2)(ii). That means you must implement it if reasonable and appropriate. If it is not, you must document why and use an equivalent alternative where reasonable and appropriate, per § 164.306(d). For hosted ePHI in 2026, encryption is almost always the reasonable choice. HHS proposed on January 6, 2025 to require encryption of all ePHI at rest and in transit, with limited exceptions. It is still a proposal, and the federal regulatory agenda now targets a final rule in July 2027. Proposed requirements are not law yet; the current Security Rule still applies.

How long must HIPAA security documentation be kept?

Six years from the date of creation or the date it was last in effect, whichever is later, under § 164.316(b)(2)(i). This covers policies, risk analyses, and records of security decisions.

Does an AWS BAA make my hosting HIPAA compliant?

No. The BAA covers AWS's side of the shared responsibility model; you remain responsible for encryption settings, IAM, logging, backups, and application security. A BAA-covered account with public S3 buckets is still a breach waiting to happen. We set out who does what under a hosting BAA in a separate article.

What is automatic logoff under HIPAA?

An addressable technical specification at § 164.312(a)(2)(iii) requiring electronic sessions to terminate after a defined period of inactivity. It applies to admin and database sessions as much as to the patient-facing application.

Do small practices need all of these controls?

The Security Rule scales by what is reasonable and appropriate given size, complexity, and risk. But the standards themselves apply to every Covered Entity and Business Associate. The required scoping document is the risk analysis under § 164.308(a)(1)(ii)(A). That analysis shows how to scale each of the HIPAA hosting security measures above to your practice.

Where to go from here

These HIPAA hosting security measures are the technical core of a compliance-ready environment. The surrounding decisions about architecture, vendors, and cost are covered in our complete HIPAA-compliant hosting guide. To see what these controls add over an ordinary web host, compare HIPAA compliant hosting vs regular hosting.

If you would rather not run the servers yourself, our HIPAA compliant hosting team offers managed HIPAA cloud hosting on single-tenant AWS. Every plan includes encryption at rest and in transit, a web application firewall, a CloudFront CDN, six-year audit logging, and tested encrypted backups. Storage runs on Amazon EBS with 7-day snapshot retention. We sign a BAA within 24 hours of signup, before patient data moves. Our BAA covers the servers and services we run, so your email, EHR and form vendors still need their own. Your risk analysis and policies stay with you.

Managed plans start at $229 a month, billed monthly with no long-term contract (see pricing). Each plan is one server in one AWS availability zone, and a multi-zone design is quoted separately. Your first month has 4 hours of migration and configuration included. After that, extra work is $175 an hour, quoted before work starts. Our plan to migrate to HIPAA compliant hosting covers the switch. We sell this service, so weigh our view with that in mind.

This article is general information, not legal advice. Consult qualified counsel and base your specific safeguards on a documented risk analysis under 45 CFR § 164.308(a)(1)(ii)(A). Reviewed October 2026.

Sources

• 45 CFR § 164.312, Technical safeguards (eCFR)
• 45 CFR § 164.308, Administrative safeguards (eCFR)
• 45 CFR § 164.316, Documentation requirements (eCFR)
• HHS: The HIPAA Security Rule
• AWS HIPAA Eligible Services Reference (last updated October 15, 2026; checked October 20, 2026)
• AWS HIPAA Compliance overview
• AWS: Enable Amazon EBS encryption by default
• AWS: Encrypting Amazon RDS resources
• AWS: Working with CloudWatch Logs log groups and log streams
• Federal Register: HIPAA Security Rule proposed rule, 90 FR 898 (January 6, 2025)
• Unified Agenda: RIN 0945-AA22, final action July 2027
• Federal Register: Annual Civil Monetary Penalties Inflation Adjustment, 91 FR 3665 (January 28, 2026)