HIPAA Security Rule: administrative, physical, and technical safeguards

By Sam Rivera, Founder, SentinelPanda · May 1, 2026 · 3 min read · HIPAA

The 18 standards in the Security Rule are the spine of any HIPAA program. Knowing what is required versus addressable is the difference between a clean audit and a tense conversation with OCR.

Three categories, 18 standards, two kinds of specifications

The Security Rule (45 CFR Part 164 Subpart C) groups its requirements into administrative safeguards (9 standards), physical safeguards (4 standards), and technical safeguards (5 standards). Each standard has implementation specifications that are labelled either required (you must implement it as written) or addressable (you must implement it, document why it is not reasonable and appropriate for your environment, or implement an equivalent alternative).

A common misreading is that "addressable" means "optional." It does not. Addressable means flexible in how you implement, not whether you implement. Skipping an addressable specification without documented justification is a finding.

Administrative safeguards (the 9 standards)

Security management process — risk analysis, risk management, sanction policy, information system activity review.
Assigned security responsibility — a named security official (often the CISO).
Workforce security — authorisation/supervision, workforce clearance, termination procedures.
Information access management — isolating clearinghouse functions, access authorisation, access establishment and modification.
Security awareness and training — periodic security reminders, malware protection, log-in monitoring, password management.
Security incident procedures — response and reporting.
Contingency plan — data backup, disaster recovery, emergency mode operation, testing and revision, applications/data criticality analysis.
Evaluation — periodic technical and non-technical evaluation against the Security Rule.
Business associate contracts — written contracts (BAAs) with each business associate.

Physical safeguards (the 4 standards)

Facility access controls — contingency operations, facility security plan, access control and validation, maintenance records.
Workstation use — appropriate use policies for workstations that access ePHI.
Workstation security — physical safeguards for all workstations that access ePHI.
Device and media controls — disposal, media re-use, accountability, data backup and storage.

Technical safeguards (the 5 standards)

Access control — unique user identification, emergency access procedure, automatic logoff, encryption and decryption.
Audit controls — hardware, software, and procedural mechanisms that record and examine activity in systems that contain ePHI.
Integrity — mechanisms to authenticate ePHI (protect from improper alteration or destruction).
Person or entity authentication — verify that the person or entity seeking access is the one claimed.
Transmission security — integrity controls and encryption when ePHI is transmitted over an electronic network.

Required vs addressable in practice

About half of the implementation specifications are required and half are addressable. The required ones are operational hard constraints (have a security official, do a risk analysis, sign BAAs, run incident procedures). The addressable ones give you room to make engineering trade-offs (encryption at rest, automatic logoff timing, audit retention windows) — provided you write down the trade-off.

Encryption is the classic addressable specification: not strictly required for ePHI at rest, but failing to implement it means you carry the burden of documenting why an equivalent alternative is sufficient, and you lose the safe harbour from breach notification if encrypted data is exfiltrated. In practice, every modern implementation encrypts ePHI at rest.

Mapping safeguards to the work you already do

For a SaaS vendor that already runs a SOC 2 or ISO 27001 program, the Security Rule is mostly satisfied by the controls you already operate — access control, audit logging, encryption, incident response, backup, BCP, training. The HIPAA-specific delta is usually: a documented risk analysis sized to the safeguard standards, signed BAAs with every downstream vendor that touches ePHI, and explicit references to the safeguard standards in your control catalogue. SentinelPanda's 59-control HIPAA library maps every safeguard standard to the controls you may already have in place for other frameworks.

HIPAA Privacy vs Security Rule HIPAA Security Rule risk analysis