HIPAA's Security Rule — codified at 45 CFR Part 164, Subpart C — is organized into three categories of safeguards: Administrative, Physical, and Technical. Of these, Technical Safeguards (§ 164.312) are the ones that create the most confusion for engineering teams, because the regulation's intentional technology-neutrality means that it describes what to achieve, not how to achieve it.
This is a feature of HIPAA's design, not a bug. The regulation was written to remain applicable across technological change. But it means that when a software engineer asks "what do I need to build?" the answer isn't directly in the regulation — it requires interpretation.
This post walks through each technical safeguard specification, distinguishes required from addressable specifications, and provides concrete implementation examples for a cloud-hosted SaaS handling ePHI (electronic protected health information). We're focusing on implementation specifics that engineering teams can act on, not on legal interpretation of the regulation.
Required vs. Addressable: What the Distinction Actually Means
Before getting into specific safeguards, the required/addressable distinction needs to be clear. Under HIPAA, "required" specifications must be implemented. "Addressable" specifications must be assessed — if they are reasonable and appropriate for your organization's size, capabilities, and risk environment, they must be implemented. If they are not reasonable and appropriate, you must document why and implement an equivalent alternative measure.
We're not saying addressable specifications are optional. They're not. "Addressable" means "subject to risk assessment to determine appropriateness," not "optional if inconvenient." A Business Associate that skips an addressable specification without documented risk assessment reasoning is not in compliance.
In practice, for a SaaS company with the technical capability to implement modern security controls, the addressable/required distinction rarely results in not implementing a safeguard. The risk assessment usually concludes that the safeguard is reasonable and appropriate. The distinction matters primarily for documentation — you need to show you assessed the safeguard, not just that you implemented it.
§ 164.312(a) — Access Control (Required Standard)
The Access Control standard requires four implementation specifications:
Unique User Identification (required). Assign a unique name or number for identifying and tracking user identity. In a modern SaaS context, this means no shared accounts or shared login credentials for any user with access to ePHI. Every access event must be attributable to a specific individual. Service accounts and system accounts are a common gap — if a service account is used interactively by multiple engineers, that's not unique user identification.
Emergency Access Procedure (required). A documented procedure for obtaining necessary ePHI during an emergency. This is the "break-glass" procedure — a defined path for accessing ePHI under emergency conditions when normal access controls can't be followed. The procedure needs to be documented, tested, and auditable: if break-glass access is used, there should be a log of it and a follow-up review.
Automatic Logoff (addressable). Implement electronic procedures that terminate an electronic session after a period of inactivity. For web applications handling ePHI, this means session timeout on the application layer — not just on the IdP. A user who is idle for 15 minutes in a browser session should be redirected to re-authentication. The timeout period isn't prescribed; risk-based assessment should determine it. For clinical applications, 15 minutes is common. For administrative applications, 30 minutes may be defensible.
Encryption and Decryption (addressable). A mechanism to encrypt and decrypt ePHI. For cloud infrastructure, this means encryption at rest for all datastores containing ePHI, with key management that restricts access to encryption keys. AES-256 for data at rest and TLS 1.2+ for data in transit are the current technical standards that satisfy this specification.
§ 164.312(b) — Audit Controls (Required Standard)
Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI.
This is one of the most operational requirements in the Technical Safeguards, and one of the hardest to maintain continuously. "Record and examine" means two things: (1) logging must be enabled and retained, and (2) someone must actually review the logs.
For cloud infrastructure: CloudTrail (or equivalent) must be enabled for all accounts containing ePHI, with log retention long enough to support post-incident investigation. HHS guidance doesn't specify a retention period for audit logs, but six years is the HIPAA retention requirement for other ePHI documentation — a common defensible position for audit log retention is aligning to this same period.
The "examine" requirement is the part teams most frequently skip. Logs exist but nobody reviews them. A defensible implementation includes: a defined log review process (who reviews, what they're looking for, at what frequency), a record of reviews performed, and an escalation path for anomalous findings. For a small team, this might be a weekly log review check with findings documented in a ticketing system.
Consider a scenario: a health data integration SaaS at approximately $3.5M ARR, eleven employees, two years into their HIPAA compliance program. They had CloudTrail enabled across all accounts, logs retained in S3 with lifecycle policies, and SIEM alerts configured for a defined set of anomalous event patterns. What they didn't have was a documented log review process — logs were reviewed ad hoc when engineers noticed something, but there was no calendar-driven review, no record of reviews, and no documentation that the review process itself was operating. During a Business Associate audit, the lack of documented review cadence was cited as an addressable gap under § 164.312(b).
§ 164.312(c) — Integrity (Required Standard)
The Integrity standard requires implementing policies and procedures to protect ePHI from improper alteration or destruction. The addressable implementation specification is authentication mechanism — electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner.
In practice, this means: cryptographic integrity checking for stored ePHI at rest (checksums or hashes that would detect unauthorized modification), tamper-evident audit logs, and database activity monitoring that detects and alerts on unauthorized bulk modifications or deletions.
For backup systems containing ePHI: backup integrity verification — confirming that backup data is not corrupted and can be restored — is an integrity control. The test restoration process serves dual purposes: it verifies that the backup can actually be used for recovery, and it verifies that the data hasn't been corrupted or altered in the backup process.
§ 164.312(d) — Person or Entity Authentication (Required Standard)
Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed. This is the authentication standard, and for modern implementations, it requires multi-factor authentication for any access to systems containing ePHI.
The specification doesn't prescribe MFA — it requires that the authentication mechanism is sufficient to verify identity. But for any internet-accessible system handling ePHI, single-factor password authentication is widely considered insufficient given the current threat environment, and OCR (the HHS Office for Civil Rights) enforcement actions have reflected this position in breach investigations.
The evidence that satisfies this standard includes: IdP configuration exports showing MFA enforcement, session logs showing authenticated sessions with authentication method recorded, and documentation of how authentication requirements are enforced for all access paths to ePHI (including service-to-service authentication, not just human user authentication).
§ 164.312(e) — Transmission Security (Required Standard)
Implement technical security measures to guard against unauthorized access to ePHI that is being transmitted over an electronic communications network. Encryption of ePHI in transit is an addressable specification under this standard.
As with Access Control encryption, for any internet-accessible application, TLS encryption for data in transit is the baseline expectation. The specific evidence required includes: TLS configuration showing minimum version (TLS 1.2, with TLS 1.3 preferred), cipher suite configuration excluding known-weak ciphers, and certificate management records showing valid, current certificates.
For internal communications — service-to-service within a cloud environment, database connections from application to database — the addressable encryption specification applies. Whether unencrypted internal communications are "reasonable and appropriate" depends on whether the internal network itself provides sufficient isolation. For VPC-isolated traffic that never traverses the internet, an argument can be made. For any traffic that crosses a trust boundary, encryption is expected.
Evidence Collection for HIPAA Technical Safeguards
When Tenurex maps HIPAA Technical Safeguard controls, each specification maps to specific evidence artifacts. The evidence needs to demonstrate both configuration state and operating process:
- For Access Control: IdP MFA enforcement configuration export; emergency access procedure document with last test date; session timeout configuration; encryption configuration for all ePHI datastores
- For Audit Controls: Log retention policy and configuration; log review process documentation; sample of log review records from within the covered period
- For Integrity: Backup integrity verification records; database activity monitoring configuration; hash or checksum logs for sensitive ePHI data stores
- For Authentication: IdP authentication policy configuration; authentication logs for sampled dates; service account credential management documentation
- For Transmission Security: TLS scan results for all ePHI endpoints; certificate validity records; internal traffic encryption configuration
The pattern across all of these: configuration evidence proves the control exists; process evidence proves the control was maintained throughout the period. Both are required. A perfectly configured system with no documented review process has a gap. A well-documented review process applied to a misconfigured system also has a gap. The combination of configuration state and operational records is what satisfies the Technical Safeguards under sustained audit scrutiny.