The HIPAA Security Rule divides its safeguard requirements into three categories: administrative, physical, and technical. The technical safeguards, codified at 45 CFR 164.312, address the technology and policy controls that protect electronic protected health information within systems, applications, and network transmissions. They apply to both covered entities and business associates.

Technical safeguards are often where organizations feel most uncertain about what HIPAA actually requires. Unlike administrative safeguards, which call for documented policies, or physical safeguards, which call for observable physical controls, technical safeguards interact directly with IT system configurations, software capabilities, and infrastructure decisions that not every compliance officer manages directly. This article breaks down what each technical safeguard standard requires, which implementation specifications are required versus addressable, and what OCR looks for when evaluating technical safeguard compliance.

Access Controls

The Access Controls standard at 45 CFR 164.312(a)(1) requires covered entities and business associates to implement technical policies and procedures for electronic information systems that maintain ePHI to allow access only to those persons or software programs that have been granted access rights.

Unique User Identification (required). Every user who accesses ePHI systems must be assigned a unique identifier used to track their activity in the system. Shared user accounts are not permissible where this specification is required. The unique identifier requirement is the technical foundation for audit logging and access accountability.

Emergency Access Procedures (required). Procedures must exist for obtaining necessary ePHI during an emergency. In a scenario where a system is unavailable or normal authentication methods cannot be used, the organization must have documented procedures for how authorized users can access critical ePHI while maintaining appropriate controls.

Automatic Logoff (addressable). Electronic procedures that terminate an electronic session after a predetermined period of inactivity. Most healthcare organizations implement automatic logoff as a standard control because unattended sessions displaying ePHI are a consistent source of impermissible access incidents.

Encryption and Decryption (addressable). A mechanism to encrypt and decrypt ePHI. Although this specification is addressable, any organization that declines to implement encryption must document that decision and the alternative safeguards in place. Given that unencrypted devices are among the most common sources of reportable breaches, encryption is effectively required for mobile devices, laptops, and any portable media containing ePHI.

Audit Controls

The Audit Controls standard at 45 CFR 164.312(b) requires covered entities and business associates to implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use ePHI. This is a required standard with no implementation specifications, meaning organizations must implement it but have flexibility in how.

Audit controls serve two primary compliance functions. First, they create an evidentiary record of who accessed what ePHI and when, which is essential for investigating potential incidents. When a breach investigation is triggered, audit logs are often the primary source of information about what happened and who was involved. Second, active review of audit logs serves as a monitoring function that can detect unusual access patterns before they result in a reportable breach.

Many organizations have audit logging enabled in their EHR systems but do not have a process for reviewing those logs on a regular basis. OCR has cited the absence of an audit log review process as a deficiency even when the logging capability itself was in place. The requirement is not just to generate audit logs but to have procedures that make use of them.

Integrity

The Integrity standard at 45 CFR 164.312(c)(1) requires covered entities and business associates to implement policies and procedures to protect ePHI from improper alteration or destruction. The standard has one addressable implementation specification: authentication mechanisms that corroborate that ePHI has not been altered or destroyed in an unauthorized manner.

Integrity controls are most directly relevant in clinical contexts where the accuracy of ePHI is critical to patient care. Unauthorized modification of diagnostic results, medication records, or treatment histories could cause direct patient harm, which is why HIPAA addresses integrity as a distinct safeguard requirement alongside confidentiality.

Technical controls that support integrity include cryptographic hashing, digital signatures, version control systems, and database logging that tracks changes to records. The appropriate control depends on the system, the sensitivity of the data, and the risk profile identified in the organization’s risk analysis.

Transmission Security

The Transmission Security standard at 45 CFR 164.312(e)(1) requires covered entities and business associates to implement technical security measures to guard against unauthorized access to ePHI that is being transmitted over an electronic communications network. There are two addressable implementation specifications under this standard.

Integrity Controls (addressable). Security measures to ensure that electronically transmitted ePHI is not improperly modified without detection until it is disposed of.

Encryption (addressable). A mechanism to encrypt ePHI in transit whenever deemed appropriate. Like encryption at rest, this specification is addressable, but the practical risk of transmitting unencrypted ePHI over networks makes encryption in transit an effective necessity for most organizations. Email containing PHI, file transfers, remote access connections, and web application communications all present transmission security risks if not encrypted.

The most common technical implementation of transmission security for ePHI is TLS encryption for web-based and API communications and secure email solutions such as S/MIME or encrypted email gateways for clinical communications. Organizations that send ePHI over unencrypted email channels, even when doing so for operational convenience, are not meeting the addressable transmission security specification unless they have documented an equivalent alternative safeguard.

Documenting Technical Safeguard Decisions

A consistent pattern in OCR enforcement actions is the absence of documentation for technical safeguard decisions, particularly for addressable specifications. An organization that evaluated the encryption specification, determined it was reasonable and appropriate, and implemented it but documented none of that process has no evidence to present to OCR about its deliberate compliance choices.

Technical safeguard decisions should be documented in the organization’s security policies, the risk analysis, and the risk management plan. The policy describes what the control is. The risk analysis provides the context that justifies the control decision. The risk management plan shows how the organization is addressing identified gaps. These three documents together create a defensible record of how the organization evaluated and implemented its technical safeguards.

Organizations that rely on their IT vendor or EHR system to manage technical safeguards without any corresponding internal documentation are in a vulnerable position. If OCR asks how encryption decisions were made, who reviewed audit logs, or how emergency access procedures were established, “our EHR vendor handles that” is not a compliant answer. The covered entity or business associate retains the compliance obligation regardless of what their systems or vendors do.