ZF/blog/hipaa-security-rule-requirements
HIPAA8 min readMay 8, 2025

HIPAA Security Rule Requirements

The HIPAA Security Rule defines the safeguards covered entities and business associates must implement to protect electronic PHI. Here is what each safeguard requires and how to operationalize it.


Security Rule Structure

The HIPAA Security Rule (45 CFR Parts 160 and 164, Subparts A and C) sets requirements for protecting electronic PHI (ePHI). The rule applies to covered entities and business associates equally. It is organized into three categories of safeguards plus organizational requirements:

  • Administrative safeguards: Section 164.308. Policies, procedures, and management actions
  • Physical safeguards: Section 164.310. Physical access and equipment controls
  • Technical safeguards: Section 164.312. Technology-based controls
  • Organizational requirements: Section 164.314. BAAs and group health plan documentation

Each safeguard has standards (the high-level requirement) and implementation specifications (specific actions). Specifications are either "required" or "addressable" but addressable still requires implementation or documented alternative.

Reference the HIPAA framework guide for the complete Security Rule structure.

Administrative Safeguards

Administrative safeguards (Section 164.308) cover the policy and process side of security. Nine standards:

  1. Security management process: Risk analysis, risk management, sanction policy, information system activity review
  2. Assigned security responsibility: Designated security official
  3. Workforce security: Authorization, supervision, termination procedures
  4. Information access management: Access authorization, modification, establishment
  5. Security awareness and training: Periodic training, security reminders, malware protection, log-in monitoring, password management
  6. Security incident procedures: Response and reporting
  7. Contingency plan: Backup, disaster recovery, emergency mode operation, testing, applications and data criticality analysis
  8. Evaluation: Periodic technical and non-technical evaluation
  9. Business associate contracts: BAAs with all business associates

The administrative safeguards drive the majority of the documentation work. Each standard typically requires a written policy, an operating procedure, and evidence of operation.

Physical Safeguards

Physical safeguards (Section 164.310) cover physical access and equipment controls. Four standards:

  1. Facility access controls: Contingency operations, facility security plan, access control and validation procedures, maintenance records
  2. Workstation use: Policies on appropriate use of workstations
  3. Workstation security: Physical safeguards for workstations accessing ePHI
  4. Device and media controls: Disposal, media re-use, accountability, data backup and storage

For cloud-native organizations, most physical safeguards inherit from the cloud provider. Document this inheritance through your cloud provider's BAA and their HIPAA compliance attestation.

For organizations with offices or any physical PHI handling, physical safeguards require active operation:

  • Visitor logs and badging
  • Workstation positioning to prevent shoulder surfing
  • Locked screens when stepping away
  • Secure disposal procedures for paper PHI and storage media
  • Hardware inventory tracking

Technical Safeguards

Technical safeguards (Section 164.312) cover technology-based controls. Five standards:

  1. Access control: Unique user identification (required), emergency access (required), automatic logoff (addressable), encryption and decryption (addressable)
  2. Audit controls: Hardware, software, and procedural mechanisms that record and examine activity in systems containing ePHI
  3. Integrity: Mechanism to authenticate ePHI (addressable)
  4. Person or entity authentication: Verify identity of person or entity seeking access
  5. Transmission security: Integrity controls (addressable), encryption (addressable)

The technical safeguards are where most security engineering effort goes. Practical implementation:

  • Identity provider with MFA: Satisfies unique user identification and authentication
  • Encryption everywhere: AES-256 at rest, TLS 1.2+ in transit. Despite "addressable" status, encryption is the modern expectation.
  • SIEM with PHI access logs: Audit controls plus integrity monitoring
  • Session timeouts: Automatic logoff after period of inactivity
  • Database integrity controls: Hashing, checksums, or other integrity verification

Addressable vs Required Specifications

HIPAA Security Rule has two specification types: required and addressable. The distinction is often misunderstood:

  • Required specifications: Must be implemented as specified. No alternative permitted.
  • Addressable specifications: Must be implemented as specified, OR you must document why the specified implementation is not reasonable and what alternative reasonable measures you implement instead.

"Addressable" does not mean "optional." It means "flexible." If you choose not to implement an addressable specification as written, you must:

  1. Document why the standard implementation is not reasonable for your environment
  2. Document the alternative measure you implement to address the standard
  3. Show the alternative is reasonably equivalent

For example, encryption is addressable. If you choose not to encrypt PHI at rest, you would need to document why ("production database is in an isolated network with strict access controls") and what compensating measures you have. In practice, encryption is so standard that documenting non-encryption almost always fails the reasonableness test.

Treat addressable specifications as required unless you have strong, specific reasoning for an alternative.

Frequently Asked Questions

HIPAASecurity RuleePHISafeguards

Related Articles