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

HIPAA-compliant hosting requires encryption of ePHI at rest under 45 CFR § 164.312(a)(2)(iv) and in transit under § 164.312(e)(2)(ii), unique user identification, least-privilege access control, audit logging under § 164.312(b), automatic logoff, tested backups under the contingency plan standard at § 164.308(a)(7), six-year documentation retention, and a signed Business Associate Agreement. The Security Rule does not name products. It names outcomes, and each outcome maps to a specific control you can implement and verify in a hosting environment.

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).
• Transmission security under § 164.312(e)(1) and (e)(2)(ii) is met in practice with TLS 1.2 or higher on every endpoint that carries ePHI, including 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 any vendor touches ePHI; AWS signs one self-service through AWS Artifact and lists 150+ HIPAA Eligible Services as of May 2026.
• Backups, disaster recovery, and emergency-mode operations fall under the contingency plan standard at § 164.308(a)(7); an untested restore does not satisfy it in any audit that looks closely.

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 control to its regulation and a concrete implementation a 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.

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 reasonable and appropriate, or document why an equivalent alternative was used instead. Because AES-256 encryption is built into EBS, S3, RDS, and most other AWS HIPAA Eligible Services at no extra compute cost, it is difficult to document a credible reason not to use it.

In practice, a defensible configuration looks like this: default EBS encryption enabled at the account level, S3 buckets with bucket-level encryption enforced by policy, RDS instances created with encryption enabled (it cannot be added to an existing unencrypted instance without a snapshot-copy migration), and KMS customer-managed keys with rotation enabled and key policies that restrict decrypt permissions to specific roles. Encrypted ePHI that is lost or stolen generally qualifies for the breach notification safe harbor under §§ 164.400-414, which 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, and it is a risk decision that must be documented 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 are among the most common findings in HHS OCR investigations because they make the audit trail meaningless. IAM least privilege operationalizes the access control standard: scoped roles instead of account-wide permissions, MFA on every human identity, and no long-lived access keys on production instances (use instance roles).

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.

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 (CloudTrail for API calls, VPC Flow Logs for network activity), system logs (auth logs, sudo activity), and application logs (who viewed which record, login failures, 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, which also supports the integrity standard at § 164.312(c).

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. Many organizations reasonably keep audit logs for the same period because logs are the evidence behind those assessments, but a 90-day CloudWatch retention default with no archival tier satisfies neither the spirit nor an OCR data request.

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, and they are where most setups fail. Concretely: automated daily backups encrypted with the same KMS discipline as production data, copies in a second region, defined RTO and RPO numbers written into the plan, and 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 signs a BAA self-service through AWS Artifact and maintains a HIPAA Eligible Services Reference listing more than 150 covered services, but under the shared responsibility model AWS secures the infrastructure while the customer configures 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, which since January 28, 2026 run up to $73,011 per violation in the lower tiers and an annual cap of $2,190,294, as detailed in our breakdown of HIPAA violation fines and penalties.

Common misconfigurations found in audits

• 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), which means you must implement it if reasonable and appropriate or document an equivalent alternative per § 164.306(d). For hosted ePHI in 2026, encryption is almost always the reasonable choice.

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.

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).

Where to go from here

These controls 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. If you would rather have the encryption, IAM, logging, and BAA chain configured and maintained for you, hipaacomplianthosting.com provides managed HIPAA cloud hosting; that is our business, so weigh that disclosure accordingly.

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 June 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
• AWS HIPAA Compliance overview