The HIPAA Security Rule Explained

What the Security Rule covers

The Security Rule applies specifically to electronic protected health information (ePHI) — PHI that is created, received, maintained, or transmitted electronically. Its three goals are to ensure the confidentiality, integrity, and availability of ePHI: that data stays private, remains accurate and unaltered, and is accessible when needed.

Crucially, the rule is technology-neutral and scalable. A small clinic and a large hospital both must comply, but the specific measures each implements can differ based on size, complexity, and risk. This flexibility is why ongoing HIPAA compliance is fundamentally a process of managing risk rather than installing a fixed checklist.

The risk analysis foundation

At the heart of the Security Rule is a required, documented risk analysis. Organizations must identify the threats and vulnerabilities to their ePHI, assess the likelihood and impact of each, and implement measures to reduce risks to a reasonable level. This is not a one-time exercise — it must be reviewed and updated as systems, threats, and the organization change.

Because every other safeguard decision flows from the risk analysis, regulators treat a missing or inadequate risk analysis as one of the most serious Security Rule failures.

Administrative safeguards

Administrative safeguards are the policies and processes that govern the security program, and they make up the largest share of the Security Rule. They include the risk analysis and risk management process, a sanction policy for violations, workforce security and access-management procedures, security awareness training, contingency planning, and periodic evaluation.

These safeguards establish who is responsible for security, how access is granted and revoked, how staff are trained, and how the organization prepares for and responds to incidents.

Physical safeguards

Physical safeguards protect the physical systems and environments where ePHI lives. They include facility access controls that limit who can enter areas housing systems, workstation use and security policies that govern how and where devices are used, and device and media controls covering the receipt, removal, disposal, and reuse of hardware and storage media.

Even in a cloud-first world, physical safeguards remain relevant: laptops, mobile devices, backup media, and office access all fall within their scope.

Technical safeguards

Technical safeguards are the technology controls that protect ePHI directly. They include access controls such as unique user identification and automatic logoff, audit controls that record and examine activity in systems containing ePHI, integrity controls that protect data from improper alteration or destruction, person-or-entity authentication, and transmission security to protect ePHI as it moves across networks.

Encryption appears here as a powerful, widely expected technical safeguard — addressable rather than strictly required, but strongly encouraged and often decisive in breach analysis.

Required vs addressable specifications

The Security Rule labels each implementation specification as either “required” or “addressable.” Required specifications must be implemented. Addressable specifications offer flexibility: you must implement the safeguard, implement a reasonable alternative, or document why the safeguard is not reasonable and appropriate in your environment.

Addressable does not mean optional — a common and costly misunderstanding. The correct approach is to make a deliberate, documented decision for each addressable specification, justified by your risk analysis.

Encryption and the Security Rule

Encryption is one of the most important addressable specifications. While the rule does not strictly mandate it, encrypting ePHI at rest and in transit dramatically reduces risk — and properly encrypted data that is lost or stolen is generally not considered a reportable breach. For most organizations, encryption is effectively a baseline expectation, and choosing not to encrypt requires a strong, documented justification.

Documentation requirements

The Security Rule requires organizations to maintain written policies and procedures and to document the actions, activities, and assessments their safeguards require. This documentation must be retained for six years, made available to those responsible for implementation, and reviewed and updated periodically. In practice, documentation is the primary evidence of compliance that auditors and regulators will request.

Security Rule and business associates

Business associates are directly liable for the Security Rule’s safeguards for the ePHI they handle. A cloud provider, SaaS platform, or IT vendor that maintains ePHI must conduct its own risk analysis, implement administrative, physical, and technical safeguards, and document its program — the same obligations as a covered entity for the data within its control.

How to comply with the Security Rule

Compliance starts with a thorough, documented risk analysis, followed by a risk-management plan that addresses the gaps it reveals. From there, implement administrative, physical, and technical safeguards proportional to your risk, write the supporting policies and procedures, train your workforce, and establish contingency and incident-response plans.

Because the rule expects ongoing management, schedule periodic reviews and re-run the risk analysis whenever systems or threats change. Automation can ease the burden of evidence collection and monitoring, but the underlying discipline — assess, safeguard, document, repeat — remains the core of compliance.

Why the Security Rule matters

The Security Rule is where most modern breaches are won or lost, because nearly all PHI now exists in electronic form. A strong, risk-driven security program protects patients from the consequences of data exposure and shields the organization from the financial and reputational damage of a breach. Its flexibility is a feature: it lets every organization right-size its protections while holding all of them to the same fundamental standard of diligence.

Contingency planning

The Security Rule requires organizations to plan for disruptions that could affect ePHI. Contingency planning includes data backup, a disaster recovery plan, and an emergency mode operation plan so that critical systems and access to ePHI can continue or be restored after an incident. Testing and revising these plans ensures they work when they are actually needed, rather than existing only on paper.

Access management and audit controls

Two technical safeguards deserve special attention. Access management ensures each workforce member has only the access their role requires, with unique identifiers, timely provisioning, and prompt revocation when roles change or employment ends. Audit controls record activity in systems containing ePHI so that access can be reviewed and anomalies investigated. Together they provide both prevention and accountability.

Regularly reviewing access rights and audit logs is one of the highest-value ongoing security practices, surfacing problems before they become incidents.

Workforce training and awareness

Security awareness training is a required administrative safeguard, and for good reason: people are both the first line of defense and a common point of failure. Effective training covers phishing recognition, password and authentication hygiene, safe handling of devices, and incident reporting. Periodic reminders and simulated exercises keep awareness high as threats evolve.

Scalability and flexibility

One of the Security Rule’s strengths is that it scales. A solo practitioner and a national health system both must comply, but the rule lets each implement safeguards appropriate to its size, complexity, and risk. This flexibility means there is no single “compliant” configuration — only a configuration that is reasonable and appropriate for your specific risk profile, justified by your risk analysis.