The Security Rule is the part of HIPAA that protects electronic protected health information — ePHI. It lives at 45 CFR Parts 160 and 164, Subparts A and C. The Privacy Rule covers PHI in every form. The Security Rule narrows the scope to electronic data and tells you exactly what to do about it.
Three categories of safeguards. Administrative. Physical. Technical. Every covered entity and business associate must implement all three. That includes hospitals, dentists, health plans, clearinghouses, and the IT vendors, billing companies, and cloud hosts that touch their data.
Here's the thing most teams miss: the Security Rule is scalable. A solo therapist and a 30,000-employee hospital both have to comply, but the controls don't have to look identical. The rule uses two specification types — Required and Addressable — to flex with your size, complexity, and risk. Addressable doesn't mean optional. It means you assess it, document it, and either implement it or implement an equivalent alternative.
Before you build a single safeguard, you owe yourself one document: the risk analysis. It's required, it's enforceable, and it's the single most common gap the Office for Civil Rights finds during audits. Skip it and the rest of your compliance work is unmoored. Do it well and your hipaa compliance program has a defensible foundation.
This guide walks through what the rule actually requires, how Required vs Addressable plays out in practice, where the Security Rule overlaps the hipaa breach notification rule, and what happens when you get it wrong. If you're studying or building a program from scratch, start with our HIPAA practice test to gauge your knowledge.
The Security Rule has been in effect since 2005 with the original effective date for most covered entities. The 2013 Omnibus Rule expanded its reach to business associates with direct liability. Smaller updates have followed — most recently around penalty inflation adjustments and proposed rulemaking on cybersecurity requirements. The core architecture has remained stable for nearly two decades. Once you understand the framework, the updates rarely surprise you.
Fair warning: the rule is dense. Section 164.308 alone runs nine standards with twenty-plus implementation specifications. We're going to keep the language plain and the structure tight. Read it once. Bookmark the safeguard tables. Come back when an auditor knocks. The investment in understanding pays back the first time someone hands you a vendor questionnaire and asks for your encryption posture.
The Privacy Rule governs every form of PHI: paper charts, faxes, voicemails, conversations in elevators. The Security Rule applies only to ePHI — data created, received, maintained, or transmitted electronically. Same statute. Different scope. Different controls. Read more on the hipaa privacy rule if your team mixes the two up.
What it is — Policies, procedures, and human controls. The biggest of the three categories.
Security Management Process — Required. Risk analysis, risk management, sanction policy, information system activity review.
Assigned Security Responsibility — Required. You must name a Security Official. One person. Not a committee.
Workforce Security — Authorization, clearance, termination procedures. Most are Addressable.
Information Access Management — Required. Access authorization and modification standards.
Security Awareness and Training — Required for the standard itself; specific implementation specs (password management, malware protection) are Addressable.
Security Incident Procedures — Required. Identify, respond to, document, and mitigate suspected or known incidents.
Contingency Plan — Required. Data backup, disaster recovery, emergency mode operation, testing, criticality analysis.
Evaluation — Required. Periodic technical and non-technical evaluation against the standard.
Business Associate Contracts — Required. Written agreement with every vendor that touches ePHI. See business associate agreement.
What it is — Physical protections for facilities, workstations, and devices. The category people forget.
Facility Access Controls — All four implementation specs are Addressable: contingency operations, facility security plan, access control and validation, maintenance records.
Workstation Use — Required. Policies that specify proper functions, manner, and physical attributes of workstations accessing ePHI.
Workstation Security — Required. Physical safeguards for workstations — privacy screens, locked rooms, kensington locks, server cages.
Device and Media Controls — Disposal and media re-use are Required. Accountability (tracking) and data backup and storage are Addressable.
Real-world example — Wiping a hard drive before disposal is Required. Logging the serial number of every laptop assigned to clinical staff is Addressable. You assess whether you need it based on your risk profile.
What it is — Technology and the policy governing it. This is where IT teams live.
Access Control — Unique user ID and emergency access procedure are Required. Automatic logoff and encryption/decryption are Addressable.
Audit Controls — Required. Hardware, software, and procedural mechanisms that record and examine activity in information systems containing ePHI. No exceptions.
Integrity — Standard is Required. The implementation spec — mechanism to authenticate ePHI — is Addressable.
Person or Entity Authentication — Required. Verify that the person or entity seeking access is the one claimed. Passwords, biometrics, tokens, MFA.
Transmission Security — Standard is Required. Integrity controls and encryption during transmission are both Addressable.
Encryption nuance — Encryption is Addressable, not Required. But if you skip it and have a breach of unencrypted ePHI, OCR will ask why. The safe harbor under the hipaa breach notification rule only applies to encrypted data.
Two groups. Covered entities and business associates. The Security Rule applies to both with nearly identical obligations after the 2013 Omnibus Rule expanded direct liability to vendors.
A covered entity is a healthcare provider that transmits health information electronically in connection with certain transactions, a health plan, or a healthcare clearinghouse. Hospitals, doctors' offices, dentists, pharmacies, nursing homes, Medicare, Medicaid, private insurers, HMOs — all covered entities. Self-funded employer health plans count too.
A business associate is anyone who creates, receives, maintains, or transmits ePHI on behalf of a covered entity or another business associate. Cloud providers. Billing companies. IT contractors. Shredding services that handle electronic media. Software vendors. Translation services. Lawyers and accountants who see PHI. The list keeps growing as healthcare digitizes.
Subcontractors of business associates count too. If a billing vendor uses a cloud host, the cloud host is also a business associate — and needs its own signed BAA with the billing vendor. The chain runs all the way down. Each link must have a written agreement with the link above it.
Direct liability matters here. Before 2013, only covered entities faced OCR enforcement under the Security Rule. After the Omnibus Rule, business associates face the same penalty tiers, the same audit risk, and the same breach reporting obligations. A small IT shop serving a clinic is just as exposed as the clinic itself if ePHI is lost on their watch.
Group health plans get specific carve-outs. Plans with fewer than 50 participants administered by the employer have lighter obligations. Self-insured plans, mixed funding arrangements, and TPA relationships create their own complexity — and the Security Rule still applies to each ePHI-touching path through that web. Map the data flow before mapping the controls.
Administrative safeguards take the largest share of effort — about half of the Security Rule's implementation specs sit in this bucket. They're the policies, the training, the access management, and the named security official. They're also where most organizations actually fail. Writing a policy is easy. Following it, evidencing it, and updating it as your environment changes is the hard part.
Each administrative standard breaks down further. The Security Management Process alone contains four required implementation specs — risk analysis, risk management, sanction policy, and information system activity review. Miss any one of them and you've missed the entire standard. OCR's audit protocols spell out exactly what evidence they expect for each spec, and the evidence is granular: dated documents, signed acknowledgments, log review records, sanction memos when staff are disciplined for HIPAA violations.
Implement them. Document them. No flexibility on whether — only on how. Examples: risk analysis, audit controls, unique user ID, workstation security policies, contingency plan.
Assess whether the spec is reasonable and appropriate for your environment. Three valid outcomes: implement as written, implement an equivalent alternative, or document why neither is needed and what compensating controls cover the gap.
Addressable does not mean optional, voluntary, or 'skip if inconvenient.' OCR has cited dozens of organizations for treating Addressable specs as optional. Every Addressable decision needs a written, risk-based justification in your file.
Physical safeguards get neglected because they feel old-school. Server rooms with badge readers. Privacy screens on laptops in waiting areas. Locked filing cabinets — yes, even in an electronic world, paper printouts of ePHI count once they exist. Device and media controls — how do you wipe a hard drive before sending the laptop to e-waste? That answer needs to be a documented procedure.
Mobile devices have made physical safeguards harder. A nurse's tablet, a physician's smartphone, a billing clerk's laptop — every one of them is a moving server room. The Security Rule still demands you account for these endpoints. Mobile device management software, remote wipe capability, screen lock policies, and inventory tracking all sit at the intersection of physical and technical controls. Skip the inventory and you don't even know what to protect.
Technical safeguards are where IT teams concentrate. Unique user IDs. Audit logs. Encryption. Multi-factor authentication. Automatic session timeouts. Transmission security via TLS or VPN. The technical pillar is also where you'll spend the most on tools — SIEM systems, identity providers, MDM platforms, encryption key management.
The three categories interlock. A perfect technical safeguard fails if the administrative side never trained staff on it. A well-trained workforce can't compensate for missing audit controls. You build all three or you build none. Our deep guide on hipaa training covers the workforce piece in detail.
The misunderstanding around Addressable specs has caused more enforcement actions than almost any other piece of the rule. OCR has been explicit: Addressable does not mean optional. The implementation specification must still be evaluated against your environment. Three valid responses exist. Implement as written. Implement a reasonable equivalent alternative that achieves the same objective. Or determine — through documented risk analysis — that the spec is not reasonable and appropriate, and that the standard can still be met through other compensating controls already in place.
Encryption is the textbook Addressable example. The Security Rule lists encryption of ePHI at rest and in transit as Addressable. A solo dentist with one server in a locked closet might justify not encrypting the local database — and document the compensating physical and administrative controls. A multi-state hospital network cannot make the same case. Same spec. Different risk profile. Different conclusion. Both legal — if both are documented.
The danger comes when organizations read 'Addressable' and stop reading. They skip it. They don't document anything. Then a laptop is stolen, OCR opens an investigation, and asks for the risk analysis that explains why the device wasn't encrypted. There is no document. There is no justification. Now there's a settlement.
Auto-logoff is another classic Addressable trap. The spec is short and reasonable: terminate an electronic session after a predetermined time of inactivity. Most EHRs ship with this enabled. Most organizations leave the default in place. But the spec is Addressable, not Required — so when the auto-logoff timer was set to 8 hours instead of 15 minutes because clinicians complained, you owe a documented justification and a compensating control like physical workstation security. Without that file, OCR sees the long timeout, sees the breach, and starts counting violations.
The risk analysis is the cornerstone of the Security Rule. Without it, every Addressable decision in your program is groundless. With it, your decisions are defensible — even if some of them turn out to be wrong in hindsight.
A real analysis covers every system, every workflow, every vendor, every device that touches ePHI. It identifies threats and vulnerabilities specific to your organization. It rates likelihood and impact. It produces a risk register. And it drives the risk management plan that prioritizes mitigation.
Update it whenever something material changes. New EHR vendor. New office location. Major staffing changes. New regulatory guidance. New threat — ransomware in healthcare is a perfect example of why the analysis must be a living document. Annual review is the floor, not the ceiling.
Documentation matters as much as analysis. OCR investigators will ask for the written report, the methodology, the risk register, and the management plan. They will compare dates against the incident timeline. They will look for evidence the plan was executed — not just drafted. A polished PDF on the shelf is worth less than a messy spreadsheet that shows real ongoing work.
NIST SP 800-66 is HHS's recommended guidance for conducting a HIPAA risk analysis. It's not mandatory — the rule is technology-neutral — but auditors recognize the methodology. NIST 800-30, the broader federal risk-assessment framework, also maps cleanly to Security Rule expectations. Pick a methodology, name it in your policy, and apply it consistently. Switching frameworks every other year looks like you're shopping for the answer.
Both rules sit under HIPAA. Both are enforced by OCR. Both apply to covered entities and business associates. But they cover different ground and require different controls.
The Privacy Rule governs every form of PHI — paper, oral, electronic — and focuses on uses, disclosures, patient rights, and notice of privacy practices. The Security Rule narrows the lens to ePHI only and focuses on administrative, physical, and technical safeguards. A patient's right to access their record is a Privacy Rule matter. Encrypting that record on your server is a Security Rule matter.
Read both. Train your staff on both. Most workforce violations involve a Privacy Rule disclosure failure, not a Security Rule control gap — but the Security Rule failures cost more when they happen because they tend to involve large data sets and trigger the breach notification process. The two rules also operate together at the incident stage: a Security Rule gap creates the breach, and a Privacy Rule obligation governs the notice that follows.
The minimum necessary standard is a Privacy Rule concept that has practical Security Rule implications. Role-based access controls — a Security Rule technical safeguard — are how you implement minimum necessary at the system level. The two rules don't just coexist; they require each other to function. A privacy policy that says only billing staff see financial PHI is hollow if every user in the EHR has access to the billing module.
The Security Rule and the Breach Notification Rule operate together. A Security Rule failure — missing encryption, weak access control, failed audit logging — is often what allowed the breach to happen in the first place. The Breach Notification Rule then dictates what you do afterward: notify affected individuals within 60 days, notify HHS, and — for breaches affecting 500 or more individuals — notify media outlets in the affected state.
Encrypted ePHI gets a safe harbor. If lost or stolen data was encrypted using HHS-approved standards, the incident may not qualify as a breach at all. This is the practical reason encryption — though technically Addressable — is treated as effectively required by most counsel. Skipping it removes the safe harbor entirely.
Document everything. Incident logs. Investigation findings. Notification copies. Mitigation steps. A clean incident response file can shave six figures off a settlement when OCR concludes the breach was small and the response was strong. A messy file does the opposite. Repeat hipaa violation penalties stack quickly when documentation is absent.
The four-factor risk assessment under the Breach Notification Rule loops back to Security Rule controls. You evaluate the nature and extent of the PHI involved, the unauthorized person who used or received it, whether the PHI was actually acquired or viewed, and the extent to which risk has been mitigated. Strong Security Rule audit controls give you data to answer factor three. Strong access controls limit the population that could have viewed the data. Strong incident response procedures speed factor four. The Security Rule controls aren't just compliance — they're the evidence you'll need to defend your breach analysis.
OCR enforces the Security Rule through the HIPAA Enforcement Rule, which sets four civil money penalty tiers based on the entity's level of culpability. Penalties adjust for inflation annually, so the dollar figures climb slightly each year. The tier ranges below reflect 2024 adjusted amounts.
Tier 1 applies when the entity did not know — and by exercising reasonable diligence would not have known — about the violation. Tier 2 covers violations due to reasonable cause and not to willful neglect. Tier 3 covers willful neglect that was corrected within 30 days of discovery. Tier 4 covers willful neglect that was not corrected — the most severe category.
Penalties stack. Each affected record, each day of noncompliance, and each implementation spec gap can count as a separate violation subject to the same tier. A single stolen unencrypted laptop containing thousands of patient records can produce thousands of violations from one incident. Annual caps apply per category but multiple categories can be assessed simultaneously, so total exposure across categories scales fast.
It's the part of HIPAA that protects electronic patient health information. It requires three categories of safeguards — administrative, physical, and technical — and applies to every covered entity and business associate. Think of it as the cybersecurity layer of HIPAA. The hipaa privacy rule covers paper, conversations, and every other PHI format. The Security Rule narrows the focus to anything digital.
ePHI only. Electronic protected health information. The rule lives at 45 CFR Parts 160 and 164, Subparts A and C, and applies exclusively to PHI that is created, received, maintained, or transmitted in electronic form. Paper records, faxes, and spoken disclosures fall under the Privacy Rule, not the Security Rule. For the full definition of what counts as protected health information, see our PHI explainer.
Administrative, physical, and technical. Administrative includes risk analysis, workforce training, security incident procedures, and contingency planning. Physical covers facility access, workstation security, and device and media controls. Technical handles access control, audit controls, integrity, authentication, and transmission security. All three are required for every covered entity and business associate. The depth of implementation scales with the size and risk profile of the organization.
Required specifications must be implemented as written. No flexibility on whether — only on how. Addressable specifications must be evaluated against your environment. You have three legal responses: implement as written, implement an equivalent alternative, or document why neither is reasonable and what compensating controls cover the gap. Addressable is not optional. Treating it that way is the most common OCR audit finding.
Technically Addressable, not Required — but practically essential. Encryption of ePHI at rest and in transit is the safe harbor under the Breach Notification Rule. Lost or stolen encrypted data may not qualify as a reportable breach. Unencrypted data offers no such protection. If you don't encrypt, you must document a risk-based justification — and OCR rarely accepts the justification after an incident occurs. Most counsel treats encryption as effectively required.
Two groups: covered entities and business associates. A covered entity includes healthcare providers, health plans, and healthcare clearinghouses. A business associate is any vendor, contractor, or partner that creates, receives, maintains, or transmits ePHI on behalf of a covered entity. Cloud providers, billing companies, IT vendors, lawyers, accountants — all are business associates if they touch ePHI. Every business associate must have a signed business associate agreement.
Annually at minimum, and whenever something material changes. A new EHR vendor, a new office location, a merger, a significant staffing change, a new threat vector — any of these triggers a refresh. OCR has cited many organizations for analyses that were two, three, or five years old. The risk analysis is treated as a living document because the threat environment is a living thing. Schedule the next review on your calendar before this quarter ends.
Four tiers, ranging from $137 to $2,067,813 per violation depending on culpability. Tier 1 covers unknowing violations. Tier 2 covers reasonable cause. Tier 3 covers willful neglect corrected within 30 days. Tier 4 covers willful neglect uncorrected. Penalties stack — each affected record and each day of noncompliance can count as a separate violation. Annual caps apply per category but multiple categories can be assessed simultaneously. See hipaa violation penalties for real-world settlement examples.