A hospital’s billing system gets hit with ransomware. A clinic laptop containing patient records goes missing from an employee’s car. A staff member emails a spreadsheet of lab results to the wrong address. Each of these scenarios lands squarely inside a single federal regulation: the HIPAA Security Rule. Understanding HIPAA Security Rule requirements is less about memorizing a checklist and more about grasping a structure — one built around three categories of safeguards, a distinction between what’s mandatory and what’s flexible, and an ongoing risk analysis that ties it all together.

This article walks through that structure using the U.S. Department of Health and Human Services (HHS) Office for Civil Rights (OCR) as the primary authority, since OCR is the federal office that interprets and enforces the rule. Nothing here is legal or compliance advice — organizations subject to HIPAA should consult qualified counsel or a compliance professional for guidance specific to their situation. This is general background information on how the regulation is structured.

What Is the HIPAA Security Rule, Exactly?

The Security Rule is a federal regulation codified at 45 CFR Part 164, Subpart C. It was issued under the authority of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and later modified by the HITECH Act of 2009, which expanded its reach to business associates and increased enforcement penalties.

Unlike the HIPAA Privacy Rule, which governs how protected health information (PHI) in any form — paper, verbal, or electronic — may be used and disclosed, the Security Rule applies specifically to electronic protected health information, commonly abbreviated ePHI. If a covered entity or business associate creates, receives, maintains, or transmits ePHI, the Security Rule’s standards apply to it.

At its core, the rule requires regulated entities to maintain “reasonable and appropriate administrative, technical, and physical safeguards” that:

  • Ensure the confidentiality, integrity, and availability of all ePHI they create, receive, maintain, or transmit
  • Protect against reasonably anticipated threats or hazards to the security of that information
  • Protect against reasonably anticipated impermissible uses or disclosures
  • Ensure workforce compliance with the safeguards

Those three properties — confidentiality, integrity, and availability — are defined functionally in the regulation itself. Confidentiality means ePHI is not made available to unauthorized individuals. Integrity means the data has not been altered or destroyed in an unauthorized manner. Availability means authorized users can access the information when they need it.

Who Must Comply With the Security Rule?

Two categories of organizations fall under the Security Rule.

Covered Entities

Covered entities include health plans, healthcare clearinghouses, and healthcare providers that transmit health information electronically in connection with transactions for which HHS has adopted standards (such as electronic claims or eligibility inquiries). This covers most hospitals, physician practices, pharmacies, insurers, and similar organizations that handle patient data electronically.

Business Associates

A business associate is a person or organization — other than a member of a covered entity’s own workforce — that performs functions or services on behalf of a covered entity involving the use or disclosure of PHI. Common examples include billing companies, cloud hosting providers, IT support vendors, and third-party administrators.

Before the HITECH Act, business associates were bound only by contract terms in a business associate agreement (BAA). HITECH extended direct statutory liability under the Security Rule to business associates themselves, meaning OCR can pursue enforcement action against a vendor directly, not just the covered entity that hired it. Covered entities are also expected to take reasonable steps to address known compliance problems with their business associates.

The Three Categories of Safeguards

The Security Rule organizes its requirements into three buckets, each governed by its own section of 45 CFR Part 164: administrative safeguards (§164.308), physical safeguards (§164.310), and technical safeguards (§164.312). Each safeguard category is built from “standards,” and many standards contain more granular “implementation specifications.”

Administrative Safeguards

Administrative safeguards make up the largest and arguably most foundational category. HHS describes them as the administrative actions, policies, and procedures used to manage the selection, development, and maintenance of security measures, and to manage workforce conduct with respect to protecting ePHI.

Key standards in this category include:

  • Security Management Process — the umbrella standard requiring risk analysis and risk management, a sanction policy for workforce members who fail to comply, and regular review of system activity records.
  • Assigned Security Responsibility — designating a single security official responsible for developing and implementing security policies.
  • Workforce Security — procedures to ensure appropriate access, including authorization, supervision, and termination procedures when employment ends or roles change.
  • Information Access Management — role-based processes for authorizing access to ePHI consistent with the Privacy Rule’s minimum-necessary principle.
  • Security Awareness and Training — ongoing training for all workforce members, including periodic security reminders and procedures for guarding against malicious software.
  • Security Incident Procedures — policies to identify, respond to, and document security incidents.
  • Contingency Plan — data backup, disaster recovery, and emergency mode operation plans to keep ePHI accessible during an emergency.
  • Evaluation — periodic technical and non-technical assessment of how well policies and procedures meet Security Rule requirements.
  • Business Associate Contracts — satisfactory written assurances, generally through a BAA, that a business associate will appropriately safeguard ePHI.

Physical Safeguards

Physical safeguards address the physical spaces, hardware, and media where ePHI lives. HHS defines these as physical measures, policies, and procedures that protect a covered entity’s electronic information systems, and the buildings and equipment that house them, from natural and environmental hazards and unauthorized intrusion.

The standards here cover:

  • Facility Access Controls — limiting physical access to facilities while ensuring properly authorized access is allowed, including contingency operations and facility security plans.
  • Workstation Use and Workstation Security — policies specifying the proper functions of workstations that access ePHI and physical safeguards for workstations that can access it, such as positioning screens away from public view.
  • Device and Media Controls — governing the receipt and removal of hardware and electronic media containing ePHI in and out of a facility, and their movement within a facility, including disposal and reuse procedures.

Technical Safeguards

Technical safeguards are the technology and related policies that protect ePHI and control access to it. The standards include:

  • Access Control — technical policies and procedures limiting access to ePHI to only those persons or software programs granted access rights, typically through unique user identification, emergency access procedures, automatic logoff, and encryption or decryption.
  • Audit Controls — hardware, software, or procedural mechanisms that record and examine activity in systems containing ePHI.
  • Integrity — policies and procedures to protect ePHI from improper alteration or destruction, including mechanisms to authenticate that data has not been tampered with.
  • Person or Entity Authentication — procedures to verify that a person or entity seeking access to ePHI is who they claim to be.
  • Transmission Security — measures to guard against unauthorized access to ePHI while it is being transmitted over an electronic network, such as encryption in transit.

Required vs. Addressable: What’s the Difference?

One of the more misunderstood aspects of the Security Rule is the distinction between “required” and “addressable” implementation specifications — and per OCR’s own FAQ guidance, “addressable” does not mean optional.

Required specifications must be implemented exactly as written, with no exceptions.

Addressable specifications give a regulated entity flexibility in how it meets the underlying standard. For each addressable specification, the organization must do one of the following, and document its decision:

  1. Implement the specification as written, if reasonable and appropriate.
  2. Implement an alternative measure that accomplishes the same purpose, if the original specification isn’t reasonable or appropriate for that organization.
  3. Document why neither the specification nor an alternative was implemented, if the underlying standard can still be met without it.

The determination of what’s “reasonable and appropriate” is supposed to be grounded in the organization’s risk analysis, its existing security infrastructure, the cost of implementation, and the specific risks the measure would address. In other words, addressable specifications shift the compliance burden from “did you install this exact control” to “did you make and document a defensible risk-based decision.”

Why Risk Analysis Sits at the Center

If there’s one requirement that OCR consistently flags as foundational — and consistently finds missing or incomplete in its enforcement actions and audits — it’s the risk analysis required under the Security Management Process standard.

A HIPAA risk analysis is not a one-time checkbox exercise. It’s meant to be an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI an organization creates, receives, maintains, or transmits. NIST Special Publication 800-66, “An Introductory Resource Guide for Implementing the HIPAA Security Rule,” is the primary technical reference organizations use to translate this legal requirement into a practical methodology. It walks through identifying where ePHI resides, cataloging reasonably anticipated threats and vulnerabilities, assessing current security measures, determining the likelihood and impact of potential threats, and assigning a risk level to guide remediation priorities.

Risk analysis feeds directly into risk management: once risks are identified, the organization must implement security measures sufficient to reduce those risks to a reasonable and appropriate level, and then revisit the analysis periodically — after a security incident, a significant change in operations or technology, or simply on a routine schedule — since the threat landscape and an organization’s own systems are always changing.

How the Security Rule Fits With the Privacy Rule and Breach Notification Rule

HIPAA’s data protection framework is often described as three interlocking rules, and it helps to see where each one starts and stops.

The Privacy Rule governs how PHI — in any form, not just electronic — may be used and disclosed, and it gives individuals rights over their own health information, such as the right to access and request corrections to their records.

The Security Rule, as covered throughout this article, narrows its focus to electronic PHI and prescribes the administrative, physical, and technical safeguards used to protect it.

The Breach Notification Rule, added following the HITECH Act, dictates what a covered entity or business associate must do after a breach of unsecured PHI occurs — including notifying affected individuals, HHS, and in some cases the media, within specific timeframes.

The three rules are meant to function together rather than in isolation: the Privacy Rule sets the boundaries for appropriate use and disclosure, the Security Rule provides the safeguards that keep electronic data from being compromised in the first place, and the Breach Notification Rule creates accountability and transparency when those safeguards fail. A gap in Security Rule compliance — a missing risk analysis, an unencrypted laptop, inadequate access controls — is very often what turns into the kind of incident that triggers Breach Notification Rule obligations.

A Framework, Not a Product

It’s worth being direct about something the compliance software industry sometimes obscures: there is no such thing as a government-issued “HIPAA certification,” and no single tool or vendor can make an organization “HIPAA compliant” on its own. The Security Rule is a flexible, scalable framework — deliberately written so that a small physical therapy practice and a multi-hospital health system can both meet its standards using safeguards appropriate to their size, complexity, and resources. Meeting its requirements is an organizational responsibility carried out through policy, training, technical controls, and documentation — most of it built and maintained internally or with the help of qualified legal and security professionals, not purchased off a shelf.

Frequently Asked Questions

What is the difference between the HIPAA Security Rule and the Privacy Rule?

The Privacy Rule governs how protected health information may be used and disclosed in any format — paper, verbal, or electronic. The Security Rule applies only to electronic PHI and requires specific administrative, physical, and technical safeguards to protect its confidentiality, integrity, and availability.

Are addressable implementation specifications optional under HIPAA?

No. Per HHS guidance, “addressable” does not mean optional. Organizations must assess whether the specification is reasonable and appropriate, implement it or a suitable alternative if so, and document their decision either way, grounded in their risk analysis.

Who has to comply with the HIPAA Security Rule?

Covered entities — health plans, healthcare clearinghouses, and healthcare providers conducting electronic transactions — must comply, along with their business associates, such as billing companies, IT vendors, and cloud hosting providers that handle electronic PHI on the covered entity’s behalf.

What is a HIPAA risk analysis, and why does it matter so much?

A risk analysis is an ongoing assessment of potential risks and vulnerabilities to electronic PHI’s confidentiality, integrity, and availability. It underpins nearly every other safeguard decision and is one of the most frequently cited deficiencies in OCR enforcement actions and compliance audits.

Does the Security Rule require encryption?

Encryption of ePHI, both at rest and in transit, is an addressable implementation specification, not a blanket requirement in every case. Organizations must evaluate whether encryption is reasonable and appropriate given their risk analysis, and if they choose not to encrypt, they must implement an equivalent alternative safeguard and document that decision.