HIPAA Security Rule Technical Safeguards: Complete List and Requirements

The HIPAA Security Rule technical safeguards define how you protect electronic Protected Health Information (ePHI) with technology. This guide breaks down each safeguard—what is required versus addressable—and shows practical ways to implement controls, verify effectiveness, and document compliance.

Access Control Standards

What the standard requires

You must implement technical policies and procedures so only authorized people or software can access systems that create, receive, maintain, or transmit ePHI. Design access based on least privilege and clear, role-based rules.

Required implementation specifications

• Unique user identification (Required): Assign a distinct ID to every user to enable accountability, targeted access, and auditability.
• Emergency access procedure (Required): Establish and test processes to obtain necessary ePHI during emergencies without compromising security.

Addressable implementation specifications

• Automatic logoff (Addressable): Terminate or lock sessions after inactivity to limit exposure from unattended workstations or stale connections.
• Encryption and decryption (Addressable): Use strong cryptography to protect ePHI at rest within applications and databases; manage keys securely and support timely decryption for authorized use.

Practical controls to consider

• Role-based access control with least privilege and segregation of duties.
• Multi-factor authentication for privileged or remote access.
• “Break-glass” access tracked by policy when urgent access to ePHI is needed.
• Automated provisioning and prompt deprovisioning tied to HR events.

Evidence to maintain

• Access control policy, role matrix, and approval records.
• Lists of unique user IDs, periodic access reviews, and revocation logs.
• Emergency access procedure tests and after-action reports.
• System configurations showing automatic logoff and encryption settings.

Audit Controls Implementation

What the standard requires

You must implement hardware, software, and procedural mechanisms to record and examine activity in systems that contain or use ePHI. The goal is to detect inappropriate access, support investigations, and prove compliance.

Designing effective audit logging

• Log who accessed what ePHI, when, from where, and what actions occurred (view, create, modify, delete, export).
• Capture application, database, operating system, and network device logs; include cloud service audit trails.
• Time-synchronize systems and protect logs from alteration.

Monitoring and response

• Centralize logs for correlation and alerting on suspicious patterns.
• Define thresholds (e.g., excessive failed logins, off-hours data exports) and escalation paths.
• Conduct routine audit reviews and document follow-up actions.

Evidence to maintain

• Audit logging standard, retention schedule, and tamper-protection methods.
• Alert rules, review checklists, and incident tickets tied to audit findings.
• Reports demonstrating periodic audits and remediation activities.

Integrity Assurance Measures

What the standard requires

You must protect ePHI from improper alteration or destruction. Integrity controls ensure data remains accurate, complete, and trustworthy across its lifecycle.

Mechanism to authenticate ePHI (Addressable)

• Use hashing, checksums, or digital signatures to detect unauthorized changes.
• Apply database integrity constraints, application-level validation, and versioning.
• Leverage immutable or write-once storage for critical records and logs.

Supporting controls

• Secure configuration management and code signing for clinical apps.
• Verified backups and routine restore tests to prevent loss or corruption.
• Change control with peer review and automated integrity checks.

Evidence to maintain

• Integrity policy, data validation procedures, and configuration baselines.
• Hash/signature verification logs and change-management records.
• Backup verification results and exception reports.

Person or Entity Authentication Procedures

What the standard requires

You must verify that a person or entity seeking access to ePHI is who they claim to be. Strong authentication mechanisms reduce the risk of unauthorized use of valid accounts.

Authentication mechanisms

• Something you know (passphrase), have (security key, OTP), or are (biometric); implement multi-factor for elevated risk scenarios.
• Certificates or tokens for system-to-system and device authentication.
• Secure password policies and credential lifecycle management.

Operational practices

• Identity proofing at onboarding and immediate revocation at separation.
• Controlled use of service and API accounts with rotation and logging.
• Adaptive authentication for remote or anomalous access.

Evidence to maintain

• Authentication policy, MFA scope, and enrollment logs.
• Credential issuance and revocation records.
• Reports on failed logins, lockouts, and authentication-related incidents.

Transmission Security Requirements

What the standard requires

You must guard against unauthorized access to ePHI during electronic transmission. Protect data in motion across internal networks, public networks, and remote connections.

Integrity controls (Addressable)

• Use message authentication codes or digital signatures to detect in-transit tampering.
• Enable TLS session integrity checks and strict certificate validation.

Encryption (Addressable)

• Encrypt data in transit with modern protocols (for example, TLS for web and APIs, IPsec or TLS-based VPNs for tunnels, and S/MIME for email).
• Ensure strong cipher suites, certificate management, and secure key exchange.

Edge scenarios to address

• Remote access for telehealth and mobile apps; enforce encrypted channels and device safeguards.
• Messaging and file sharing; restrict unencrypted channels when ePHI is present.
• Third-party connections; require contractual and technical controls for secure exchange.

Evidence to maintain

• Network encryption standards, configuration screenshots, and test results.
• Certificate inventories and key management procedures.
• Periodic penetration test and vulnerability scan reports focused on data in transit.

Addressable Implementation Specifications

How to evaluate “addressable” controls

Addressable does not mean optional. You must assess whether the specification is reasonable and appropriate in your environment, implement it if it is, or implement an equivalent alternative that achieves the same purpose. Document the rationale and decision.

Decision criteria

• Risk to ePHI if not implemented.
• Technical feasibility and operational impact.
• Cost proportionality relative to the risk.
• Availability of equivalent alternative measures.

Documented outcomes

• Implemented as written (with configuration details and validation).
• Implemented with an equivalent alternative (mapping to the safeguard’s objective).
• Not implemented due to infeasibility, with compensating controls and timeline to revisit.

Reassessment triggers

• System or architecture changes, new threats, audit findings, or vendor updates.
• Periodic reviews aligned to your risk management cycle.

Compliance Documentation Practices

What to document

• Policies and procedures for all technical safeguards, with version history.
• Enterprise risk analysis, risk register, and remediation plans.
• System inventory, data flows for ePHI, and vendor/BAA records.
• Technical standards (access, logging, encryption and decryption, integrity controls, authentication mechanisms) and proof of implementation.

Operational records

• Access reviews, user provisioning/deprovisioning, and emergency access tests.
• Audit review logs, incident tickets, and corrective actions.
• Backup/restore tests, change control approvals, and exception justifications.

Retention and accountability

• Retain required documentation for at least six years from the date of creation or last effective date.
• Assign owners for each safeguard and schedule recurring reviews.

Conclusion

By implementing access control, audit controls, integrity protections, person or entity authentication, and transmission security—and by handling addressable items through documented, risk-based decisions—you build a defensible HIPAA compliance posture. Strong documentation ties your technical safeguards to day-to-day operations and proves that ePHI is protected.

FAQs

What are the required technical safeguards under HIPAA Security Rule?

The Security Rule requires implementation of five technical safeguard standards: Access Control, Audit Controls, Integrity, Person or Entity Authentication, and Transmission Security. Within Access Control, unique user identification and an emergency access procedure are required; automatic logoff and encryption and decryption are addressable. For Integrity, the standard is required, while the “mechanism to authenticate ePHI” is addressable. For Transmission Security, the standard is required, with integrity controls and encryption as addressable specifications.

How should addressable specifications be assessed by covered entities?

Conduct a risk analysis to determine whether the addressable control is reasonable and appropriate. If yes, implement it. If not, implement an equivalent alternative that achieves the same protective purpose, or document why it is not feasible and what compensating controls you use. Record the decision, rationale, configuration, and a timeline to revisit as conditions change.

What mechanisms ensure ePHI integrity?

Use cryptographic hashes, checksums, and digital signatures to detect tampering; enforce database constraints and application validation to prevent improper changes; enable versioning and immutable storage for critical records; and verify backups via routine restore tests. Together, these integrity controls preserve accuracy and completeness of ePHI.

How is person or entity authentication implemented?

Implement multi-factor authentication for higher-risk access; manage strong passwords and rotation; issue certificates, keys, or tokens for systems and devices; and apply adaptive checks based on context. Pair authentication mechanisms with unique user identification, timely provisioning and revocation, and monitoring to ensure only the right users and systems access ePHI.