HIPAA Security Rule Controls: Administrative, Physical, and Technical Safeguards
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
HIPAA Security Rule Controls: Administrative, Physical, and Technical Safeguards
The HIPAA Security Rule (45 CFR Part 164, Subpart C) is the engineering specification inside HIPAA. Where the Privacy Rule tells you what you can do with protected health information, the Security Rule tells you how to protect electronic protected health information (ePHI) — the subset of PHI that lives in your databases, object stores, message queues, and laptops. The rule organises controls into three safeguard categories: administrative (§164.308), physical (§164.310), and technical (§164.312). Each category contains a list of standards, and each standard contains "required" and "addressable" implementation specifications.
This article walks through the three categories with the citations a compliance officer or security architect needs at hand, and translates each requirement into the actual control engineering teams build on AWS, Azure, GCP, or in their own data centres. The Security Rule is intentionally technology-neutral — it does not name specific encryption algorithms or vendors — but the implementation has hardened around well-known patterns over the past decade.
Required vs Addressable: The Most Misunderstood Distinction
Before the safeguards themselves, the implementation-specification flag matters. Under §164.306(d), a covered entity or business associate must implement every "required" specification as written. For "addressable" specifications, the entity must do one of three things: implement the specification as written, implement an equivalent alternative measure that achieves the standard, or document why the specification is not reasonable and appropriate for the entity and what alternative was implemented (or why no alternative was implemented).
The most expensive misreading of HIPAA is treating "addressable" as "optional." Lahey Hospital (2015 OCR settlement, $850,000) and the University of Washington Medicine (2015, $750,000) both lost laptops containing ePHI that were not encrypted, and the resolution agreements specifically cited the absence of documented decisions about the addressable encryption specification. If you choose not to implement an addressable specification, the documentation of that decision is the control — and it must survive an OCR audit.
Administrative Safeguards (§164.308)
Administrative safeguards are the policies, procedures, training, and governance practices that make the rest of the rule work. There are nine standards in §164.308.
| Citation | Standard | Engineering translation |
|---|---|---|
| §164.308(a)(1) | Security management process | Risk analysis, risk management, sanction policy, information system activity review |
| §164.308(a)(2) | Assigned security responsibility | Named Security Official (often the CISO or HIPAA Security Officer) |
| §164.308(a)(3) | Workforce security | Authorisation, clearance, termination procedures — the IAM lifecycle |
| §164.308(a)(4) | Information access management | Access authorisation, establishment, modification — least-privilege RBAC |
| §164.308(a)(5) | Security awareness and training | Annual training, phishing simulations, password practice |
| §164.308(a)(6) | Security incident procedures | Documented IR plan, response, reporting, post-incident review |
| §164.308(a)(7) | Contingency plan | Backup, disaster recovery, emergency mode operation, BCP testing |
| §164.308(a)(8) | Evaluation | Periodic technical and non-technical review of safeguards |
| §164.308(b) | Business associate contracts | Written BAA with every vendor that touches ePHI |
The §164.308(a)(1)(ii)(A) Security Risk Analysis is the most-cited finding in OCR enforcement. Of the resolution agreements published between 2018 and 2023, more than two-thirds named "failure to conduct an accurate and thorough risk analysis" as a violation. A real risk analysis is not a checklist — it inventories every system, application, and dataset that creates, receives, maintains, or transmits ePHI; identifies threats and vulnerabilities to each; assesses likelihood and impact; and feeds the §164.308(a)(1)(ii)(B) risk management plan that drives remediation.
Need expert help with hipaa security rule controls?
Our cloud architects can help you with hipaa security rule controls — from strategy to implementation. Book a free 30-minute advisory call with no obligation.
Physical Safeguards (§164.310)
Physical safeguards protect the facilities and devices that house ePHI. There are four standards in §164.310.
- §164.310(a) Facility access controls — contingency operations, facility security plan, access control and validation, maintenance records. The cloud-equivalent is the SOC 2 / ISO 27001 attestation from the IaaS provider, augmented by your own controls for any on-prem device.
- §164.310(b) Workstation use — written policies for the use of workstations that access ePHI: where they may be used, what software runs on them, automatic locking.
- §164.310(c) Workstation security — physical safeguards for those workstations: cable locks, secure rooms, screen privacy filters in patient-facing areas.
- §164.310(d) Device and media controls — disposal, media re-use, accountability (a chain-of-custody log for portable media), and data backup and storage.
For pure cloud deployments, the IaaS provider handles the bulk of facility-level safeguards under their BAA. The covered entity or business associate is still responsible for endpoint device security — the CISO whose ePHI lives in AWS still answers for the laptop a developer plugged a USB drive into. Endpoint encryption (FileVault, BitLocker), MDM, and DLP are how engineering teams actually meet §164.310(d).
Technical Safeguards (§164.312)
The technical safeguards are the controls implemented in software and infrastructure. Five standards apply.
- §164.312(a) Access control — unique user identification (required), emergency access procedure (required), automatic logoff (addressable), encryption and decryption (addressable). In practice: SSO with MFA, break-glass IAM roles, idle-session timeouts, AES-256 at rest.
- §164.312(b) Audit controls — hardware, software, and procedural mechanisms that record and examine activity in systems containing ePHI. CloudTrail, Azure Activity Logs, GCP Cloud Audit Logs, plus application-level access logs feeding a SIEM.
- §164.312(c) Integrity — protection of ePHI from improper alteration or destruction. Database integrity constraints, immutable audit logs, hash-verified backups, write-once-read-many (WORM) storage for retained records.
- §164.312(d) Person or entity authentication — verifying that a person or entity seeking access is the one claimed. MFA for human access, mTLS or signed JWTs for service-to-service.
- §164.312(e) Transmission security — integrity controls and encryption for ePHI transmitted over a network. TLS 1.2 minimum (TLS 1.3 strongly preferred), with encryption of data in motion classified as addressable but treated by OCR as effectively required since the 2009 HHS guidance on encryption safe harbour.
The 2009 HHS Guidance to Render Unsecured PHI Unusable, Unreadable, or Indecipherable established that ePHI encrypted to NIST-approved standards is not "unsecured PHI" for breach-notification purposes. This created a strong de facto requirement: encrypt with AES-256 at rest and TLS 1.2+ in transit, and a lost laptop or intercepted message stops being a notifiable breach. Most CISOs treat this as the most valuable single control in the rule.
The Risk Analysis Loop That Holds It All Together
Every safeguard above traces back to the §164.308(a)(1)(ii)(A) risk analysis. The risk analysis identifies what controls you need; §164.308(a)(1)(ii)(B) risk management implements them; §164.308(a)(8) periodic evaluation tests whether they still work; the cycle repeats. A mature HIPAA programme runs this loop annually for the full estate and continuously for high-risk systems.
The output is a documentation package: a current asset inventory of ePHI-containing systems, a threat-and-vulnerability register, a risk register with treatment decisions, evidence that controls are operating, and the periodic-evaluation reports. When OCR opens an investigation, this package is what they ask for first. Organisations that have it pass; organisations that do not, settle.
Mapping Cloud Controls to the Security Rule
Modern AWS, Azure, and GCP services map cleanly onto Security Rule requirements when configured correctly. AWS provides a BAA (it is signed via AWS Artifact, not negotiated separately), and HIPAA-eligible services include EC2, S3, RDS, EKS, Lambda, and dozens more. Azure and GCP offer equivalent BAAs and HIPAA-aligned service catalogues. The compliance gap is rarely in what the cloud provider does — it is in how the customer configures their account: public S3 buckets, IAM users with full admin, RDS instances without encryption, ELBs serving TLS 1.0.
How Opsio Helps
Opsio implements HIPAA Security Rule controls end-to-end on AWS, Azure, and GCP, working alongside compliance officers and CISOs. Our PHI protection services cover the §164.308 administrative-safeguard documentation set, the §164.312 technical control build (encryption, audit logging, access controls, automatic logoff), endpoint and physical-safeguard guidance for §164.310, and the risk analysis that holds the whole programme together. We integrate the engagement with managed detection and response services for continuous monitoring of ePHI environments and with ISO 27001 certification readiness for enterprises for organisations that want a single control framework satisfying both regimes.
About the Author
Group COO & CISO at Opsio
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.