HIPAA Technical Safeguards: Implementation Guide for Health Tech

HIPAA's Security Rule requires covered entities and business associates to implement technical safeguards protecting electronic protected health information (ePHI). The Security Rule is technology-neutral by design — it specifies what outcomes you must achieve without mandating specific products. This flexibility means implementation decisions are yours, but so is the burden of demonstrating that your choices are reasonable and appropriate.

The technical safeguards standard (45 CFR § 164.312) contains four standards and nine implementation specifications. Understanding the addressable vs. required distinction is essential before diving into implementation.

Addressable vs. Required Specifications

Implementation specifications are either "required" or "addressable." This distinction is frequently misunderstood.

Required specifications must be implemented. There is no flexibility.

Addressable specifications require a different analysis: you must assess whether implementing the specification is reasonable and appropriate given your organization's size, complexity, technical capabilities, and risk to ePHI. If it is reasonable and appropriate, you must implement it. If it is not, you must document why and implement an equivalent alternative.

"Addressable" does not mean "optional." You cannot simply not implement an addressable specification without documentation. For most health tech companies, nearly all addressable specifications are in fact reasonable and appropriate to implement. The addressable designation accommodates organizations with unusual constraints — a small rural clinic has different capabilities than a health system.

Standard 1: Access Controls

Access controls limit ePHI system access to authorized users and software programs. This standard has four specifications.

Unique User Identification (Required)

Every user who accesses ePHI must be assigned a unique identifier. Shared accounts — a single login used by multiple nurses, a generic "admin" account — violate this requirement. Unique user IDs enable audit trail attribution: when an ePHI record is accessed or modified, you can identify which individual is responsible.

Implementation requirements:

Provision individual accounts for every person who accesses ePHI
Prohibit shared credentials in policy and enforce through technical controls
Implement account lifecycle management: disable accounts within 24 hours of employee termination
Enforce password policies or, preferably, eliminate passwords in favor of phishing-resistant MFA

Emergency Access Procedure (Required)

You must have a procedure for obtaining ePHI in an emergency. In a clinical setting, this means a "break glass" procedure that grants urgent access when normal authentication mechanisms fail or when the authorized user cannot access their account. The emergency access procedure must still maintain accountability — typically by logging that the emergency access was invoked, by whom, and for what reason.

For SaaS health tech companies, this often means a documented and tested administrative account procedure, with strict controls on when it can be invoked and mandatory after-action review.

Automatic Logoff (Addressable)

Systems should automatically terminate sessions after a period of inactivity. This prevents an unattended workstation or browser session from providing unauthorized access. Typical timeframes are 15 minutes for clinical workstations, 30 minutes for administrative systems. The appropriate timeout depends on the clinical workflow — overly aggressive timeouts in high-volume emergency settings create safety risks.

Web application implementation: Use session expiration tokens with sliding windows, enforce server-side session invalidation on timeout, and redirect to a lock screen rather than logout to minimize clinical disruption.

Encryption and Decryption (Addressable)

Mechanisms to encrypt and decrypt ePHI must be implemented where appropriate. For most health tech companies, "appropriate" means encrypting ePHI at rest on any storage system. Database encryption, filesystem encryption, and object storage encryption should all be enabled. Use AES-256 for data at rest.

Encryption keys must be protected as carefully as the data they protect. Use a key management service (AWS KMS, Google Cloud KMS, Azure Key Vault) rather than managing keys manually. Key rotation policies should be documented.

Standard 2: Audit Controls (Required)

You must implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use ePHI. This is a single required specification with no addressable sub-components — audit logging is mandatory.

What to Log

Minimum required logging:

User authentication events (logins, login failures, logouts)
ePHI record access (which records were viewed, by whom, when)
ePHI modifications (creates, updates, deletes with before/after values)
ePHI exports and downloads
Administrative actions (user account changes, privilege escalation, configuration changes)
System access from privileged accounts

Log Integrity and Retention

Audit logs must be protected from modification. Ideally, logs are written to an append-only store that the application cannot modify. Use centralized log management (a SIEM or log aggregation platform) with log integrity verification. Many organizations write audit logs to immutable cloud storage (AWS S3 with Object Lock, for example).

HIPAA does not specify a retention period for audit logs. However, the Security Rule's documentation retention requirement is six years from creation or last effective date. Retaining audit logs for six years is a defensible practice. Practical minimums: 90 days in hot storage for operational access, six years in cold storage.

Log Review

Generating logs without reviewing them provides limited security value. Implement automated alerting for suspicious patterns: multiple failed logins, access to records outside normal working hours, bulk ePHI downloads, access from unusual geographies. Regular log reviews by a security team or designated Security Officer should be documented.

Standard 3: Integrity Controls

The integrity standard requires mechanisms to protect ePHI from improper alteration or destruction. It has one addressable specification.

Mechanism to Authenticate ePHI (Addressable)

Implement controls to corroborate that ePHI has not been altered or destroyed in an unauthorized manner. This encompasses both accidental corruption and deliberate tampering.

Technical implementations:

Checksums and hashing: Hash ePHI records at rest and verify hashes periodically. SHA-256 or SHA-3 are appropriate algorithms. Store hashes separately from the data they protect.
Database integrity constraints: Use database-level constraints to prevent invalid data modifications.
Immutable audit trails: Append-only audit tables in the database prevent retroactive modification of access records.
Backup integrity verification: Verify backup integrity through periodic restoration tests. A backup that cannot be restored provides no protection.

For transmission integrity, see the transmission security standard below.

Standard 4: Transmission Security

ePHI transmitted over electronic communications networks must be protected against unauthorized access during transmission. This standard has two addressable specifications.

Integrity Controls (Addressable)

Mechanisms must guard against unauthorized modification of ePHI during transmission. TLS (Transport Layer Security) provides both confidentiality and integrity protection through message authentication codes. TLS 1.2 is the current minimum acceptable; TLS 1.3 should be the default for new implementations.

HSTS (HTTP Strict Transport Security) headers should be configured to force TLS for all connections. Certificate pinning can be considered for mobile applications handling ePHI. API-to-API communication should use TLS with mutual authentication (mTLS) for high-sensitivity data flows.

Encryption (Addressable)

For most health tech companies, encrypting ePHI in transit is unambiguously reasonable and appropriate. All ePHI transmission should use TLS 1.2 or 1.3. Email transmission of ePHI requires special handling — standard email is not encrypted end-to-end. If your product allows emailing ePHI, use a secure messaging platform that provides end-to-end encryption or forces TLS delivery with fallback to secure message pick-up.

Prohibited protocols: SSLv2, SSLv3, TLS 1.0, TLS 1.1. These are deprecated and vulnerable. Disable them at the load balancer and application server level. Configure cipher suites to exclude those with known vulnerabilities (RC4, DES, 3DES, MD5).

Business Associate Agreements

A Business Associate Agreement (BAA) is a legally required contract between a covered entity and any business associate that creates, receives, maintains, or transmits ePHI on their behalf. SaaS companies providing health tech services are typically business associates of the covered entities (hospitals, clinics, health plans) they serve.

A HIPAA-compliant BAA must include:

What the business associate will do: Description of permitted and required uses and disclosures of ePHI, limited to what is necessary for the contracted service.

Safeguards: Requirement that the business associate implement appropriate administrative, physical, and technical safeguards to protect ePHI.

Breach notification: The business associate must report breaches of unsecured ePHI to the covered entity without unreasonable delay and within 60 days of discovery. Most covered entities require 24-48 hour notification in practice.

Subcontractors: If the business associate uses subcontractors that handle ePHI, the business associate must ensure those subcontractors are also subject to BAAs. This means your cloud infrastructure provider, database vendor, and any other service that processes ePHI must either sign a BAA or be structured so they do not access ePHI.

Return or destruction: At termination, ePHI must be returned to the covered entity or destroyed.

Right to audit: The covered entity must have rights to audit the business associate's compliance.

Major cloud providers offer HIPAA BAAs: AWS, Google Cloud, and Microsoft Azure all provide BAAs for their covered services (not all services are covered — review the BAA scope carefully).

Practical Implementation Checklist

Access controls:

Every user has a unique account; shared accounts are prohibited
MFA is enforced for all ePHI system access
Session timeout is configured (15-30 minutes of inactivity)
ePHI is encrypted at rest (AES-256 minimum)
Key management uses a managed KMS service
Emergency access procedure is documented and tested

Audit logging:

All ePHI access events are logged with user, timestamp, and record identifier
Logs are written to append-only storage
Log retention is at least 6 years
Automated alerting is configured for suspicious activity
Log reviews are conducted and documented

Integrity:

ePHI records include checksums or hash verification
Backup integrity is tested quarterly
Database constraints prevent invalid modifications

Transmission security:

All ePHI transmission uses TLS 1.2 or 1.3
TLS 1.0/1.1, SSLv3, and deprecated ciphers are disabled
HSTS is configured on all ePHI-facing endpoints
API-to-API ePHI flows use TLS with authentication

BAAs:

BAAs are in place with all covered entity customers
BAAs cover all subcontractors that access ePHI
Cloud provider BAAs are in place for all services that process ePHI
BAA templates have been reviewed by legal counsel

Enforcement Reality

HHS Office for Civil Rights (OCR) enforces HIPAA. Penalty tiers range from $137 to $68,928 per violation, with annual caps per violation category from $34,464 to $2,067,813 (adjusted annually for inflation). Willful neglect that is not corrected carries the highest penalties.

OCR investigations are triggered by breach notifications, consumer complaints, and random audits. The most common findings in OCR investigations: inadequate risk analysis, missing or incomplete policies, lack of access controls, insufficient audit controls, and absent or outdated BAAs.

The risk analysis requirement (45 CFR § 164.308(a)(1)) is the most frequently cited HIPAA deficiency. A thorough, documented risk analysis that identifies ePHI flows, system vulnerabilities, and treatment decisions is the foundation of HIPAA compliance and the first thing OCR requests in an investigation.