Security Rule

An Overview of the HIPAA Security Rule

The HIPAA Security Rule sets national standards for protecting electronic protected health information (ePHI). While the Privacy Rule covers PHI in any form, the Security Rule applies specifically to ePHI that a covered entity or business associate creates, receives, maintains, or transmits.

The core goals

The rule requires regulated organizations to ensure the confidentiality, integrity, and availability of all ePHI they handle. In plain terms:

Three categories of safeguards

The Security Rule organizes its requirements into three groups:

Safeguard typeExamples
AdministrativeRisk analysis, security management process, workforce training, contingency planning, assigned security responsibility.
PhysicalFacility access controls, workstation security, device and media controls.
TechnicalAccess controls, audit controls, integrity controls, authentication, transmission security.

Flexibility by design

The Security Rule is intentionally technology-neutral and scalable. A large hospital and a solo practice both must comply, but the rule lets each consider its size, complexity, technical infrastructure, and the costs and risks involved. There is no single mandated product or configuration.

Required vs. addressable specifications

Within the standards, implementation specifications are labeled either required or addressable. Required specifications must be implemented. For addressable specifications, an organization must assess whether the specification is reasonable and appropriate in its environment, and then either implement it, implement an equivalent alternative, or document why it is not reasonable and appropriate. "Addressable" does not mean optional.

Key point: The risk analysis is the foundation of Security Rule compliance. Nearly every other decision, from whether to encrypt a laptop to how often to review audit logs, should flow from an accurate, current assessment of risks to ePHI.

The role of the risk analysis

The administrative safeguards require a security management process, and within it an accurate and thorough risk analysis. This means identifying where ePHI lives, the threats and vulnerabilities that could affect it, the likelihood and impact of those threats, and the measures needed to reduce risk to a reasonable and appropriate level. Risk management is ongoing, not a one-time project.

How frameworks help

The Security Rule does not prescribe a specific framework, but resources such as NIST Special Publication 800-66 (which maps the rule to broader NIST guidance) and NIST SP 800-53 controls can help organizations structure their programs. These are voluntary aids, not additional legal requirements, but they offer a practical vocabulary and a way to demonstrate diligence.

Who must comply and with what data

The Security Rule applies to the same regulated population as the rest of HIPAA: covered entities and their business associates. Since the HITECH Act, business associates are directly responsible for the Security Rule's requirements, not merely contractually bound through an agreement. The rule reaches ePHI wherever it is created, received, maintained, or transmitted, which in modern environments means servers, laptops, mobile devices, cloud services, backups, and removable media. A frequent oversight is scoping the rule too narrowly, for instance focusing on the electronic health record while forgetting spreadsheets, email, imaging systems, or a backup drive that also hold ePHI.

Documentation and review

The Security Rule is not satisfied by controls alone; it expects organizations to document their policies, procedures, and the decisions behind them, and to retain that documentation. Required documentation must generally be kept for six years from when it was created or last in effect, made available to those responsible for implementing it, and reviewed periodically and updated as the environment changes. The evaluation standard reinforces this by requiring organizations to periodically reassess whether their safeguards still meet the rule in light of operational and technical changes. Good records are not bureaucratic overhead; they are how an organization demonstrates, after the fact, that its choices were reasonable and appropriate.

The following articles explore the safeguard categories, access controls, and encryption in more depth, along with proposed updates to the rule that organizations should monitor.