HIPAA Security Rule Guide

Most HIPAA Security Rule failures are not exotic technical gaps but a missing or shallow risk analysis, followed by safeguards nobody can show were chosen for a reason. The Security Rule, 45 CFR 164.302 to 164.318, sets the administrative, physical and technical safeguards that covered entities and business associates must apply to electronic protected health information (ePHI). This guide covers each safeguard, what "addressable" really means, risk analysis, business associate agreements, breach notification, enforcement and the status of the proposed update published in January 2025. It is written for security, compliance and IT teams at providers, health plans, clearinghouses and their vendors.

Key takeaways

• Risk analysis comes first. OCR calls it "the foundational element" of compliance and keeps settling cases where it was missing.
• Addressable does not mean optional. Under 164.306(d)(3) you either implement the specification, or document why it is not reasonable and appropriate and implement an equivalent alternative where reasonable.
• Business associates carry the rule directly. Vendors handling ePHI must comply themselves and flow the same terms down to subcontractors.
• Encryption changes breach outcomes. Notification duties apply to unsecured PHI, so ePHI encrypted in line with HHS guidance is outside them if lost or stolen.
• The proposed update is not law yet. As of 16 October 2026 the January 2025 proposal sits on the regulatory agenda as a long-term action with final action listed for July 2027, and the current rule remains in effect.

Who the Security Rule covers and how it differs from the Privacy Rule

The rule applies to covered entities (health plans, health care clearinghouses and health care providers that transmit health information electronically in HHS standard transactions) and to their business associates. It protects ePHI, defined as protected health information "that is maintained in or transmitted by electronic media". HHS states that it "does not apply to PHI that is maintained or transmitted on paper or verbally". The difference between the three HIPAA rules:

The rules overlap: an EHR role broader than the job needs is a minimum necessary problem and an access authorisation problem under 164.308(a)(4). Build one access model for both.

How the rule is structured: standards, specifications and flexibility

• General requirements, 164.306(a): ensure the confidentiality, integrity and availability of all ePHI; protect against reasonably anticipated threats and impermissible uses or disclosures; ensure workforce compliance.
• Flexibility, 164.306(b): choose measures considering your size, complexity and capabilities, technical infrastructure, cost, and the probability and criticality of risks. That is why the rule names no products or password rules.
• Required and addressable, 164.306(d): required specifications must be implemented. For each addressable one, assess whether it is reasonable and appropriate in your environment. If it is, implement it. If not, document why and implement an equivalent alternative measure if reasonable. The documentation is the control; an undocumented "we decided not to" is a finding.
• Documentation, 164.316(b)(2): keep policies, procedures and records of required actions for six years from creation or the date last in effect, whichever is later, and review them periodically.

The safeguards at a glance

Every standard is mandatory. The labels below show whether each implementation specification is Required (R) or Addressable (A) in the current text of 45 CFR Part 164 Subpart C.

Unique user identification and emergency access are both Required: shared clinical logins fail the first, untested break-glass accounts the second. See the Break-Glass Account Guide.

Risk analysis and risk management

Risk analysis (164.308(a)(1)(ii)(A)) must be "accurate and thorough", and risk management (164.308(a)(1)(ii)(B)) must reduce the risks it finds to a reasonable and appropriate level. OCR's guidance lists the elements it expects, drawing on NIST SP 800-30:

1. Scope and data collection: all ePHI in every system and location, including laptops, cloud services, medical devices and backups. In practice, an asset inventory plus a data flow map.
2. Threats and vulnerabilities: identify and document reasonably anticipated threats and the vulnerabilities they could exploit.
3. Current measures: assess existing safeguards and whether they are configured and used properly.
4. Likelihood, impact and risk level: assign a level to every threat and vulnerability combination.
5. Documentation and review: no format is mandated and no frequency is set, but the process "should be ongoing". Update it after a new EHR, a merger, a cloud migration or an incident.

The usual enforcement finding is a missing or partial analysis. In February 2026 OCR announced a $103,000 settlement with Top of the World Ranch Treatment Center after a phishing attack exposed ePHI of 1,980 patients through a workforce email account; OCR found no accurate and thorough risk analysis and described it as the 11th action under its Risk Analysis Initiative. An analysis that leaves out email, file shares or vendor portals will not stand up, because that is where breaches start.

NIST SP 800-66 Rev. 2 (February 2024) is the most practical companion: it gives key activities and sample questions for each standard, and NIST's Cybersecurity and Privacy Reference Tool maps the rule to NIST CSF subcategories and SP 800-53 Rev. 5 controls.

Business associates and BAAs

• Who is a business associate: anyone that creates, receives, maintains or transmits PHI for a covered entity: EHR and billing vendors, cloud hosting, managed IT and security providers, and many AI tool providers. Their subcontractors are business associates too.
• Contract terms, 164.314(a): the business associate must comply with the Security Rule, ensure subcontractors agree to the same terms, and report security incidents, including breaches of unsecured PHI. HHS sample provisions add returning or destroying PHI at termination where feasible, and note that the sample language alone may not make a binding contract.
• Contracts are not assurance: a BAA records obligations, it does not prove controls. Ask for independent assessments, MFA and encryption details, incident contacts and sub-processors.
• Third-party assessments: HITRUST r2 is a tailored, risk-based certification valid for two years, with an interim assessment after year one, built on a framework that maps to HIPAA. It is useful vendor evidence but does not replace your own risk analysis.
• Vendor remote access: remote support accounts are among the highest-risk access paths in healthcare. See the Third-Party Access Guide.

Breach notification

An impermissible use or disclosure of PHI is presumed to be a breach unless a documented risk assessment shows a low probability that the PHI has been compromised. The assessment must consider at least four factors: the nature and extent of the PHI involved; the unauthorised person who used it or received it; whether it was actually acquired or viewed; and the extent to which the risk has been mitigated. HHS guidance names encryption and destruction as the methods that make PHI "secured".

The burden of proof sits with the covered entity or business associate, so keep the assessment and copies of notices. Sixty days is an outer limit, and state laws or contracts may be shorter. In ransomware cases, disk encryption may not help if the attacker reached ePHI while volumes were mounted, so assess what they could actually read.

The proposed Security Rule update

HHS issued a notice of proposed rulemaking (NPRM) on 27 December 2024, published in the Federal Register on 6 January 2025 (90 FR 898, RIN 0945-AA22), with comments due by 7 March 2025. As read on 16 October 2026, the latest Unified Agenda entry on reginfo.gov lists it under "Long-Term Actions" with final action dated 07/00/2027, HHS's NPRM page says "the current Security Rule remains in effect", and neither page shows a final rule. Agenda dates are targets, so check the Federal Register before relying on this section.

Most proposed items are already good practice, so building towards them now is low regret whatever the final text says.

Enforcement and penalties

OCR usually resolves investigations through resolution agreements with corrective action plans. Civil money penalties follow four culpability tiers in 45 CFR 160.404(b)(2), introduced by the HITECH Act for violations on or after 18 February 2009. The figures below are the unadjusted amounts in the regulation; current inflation-adjusted figures are published in 45 CFR part 102.

Public Law 116-321 (5 January 2021) requires HHS to consider whether an entity had recognised security practices, meaning NIST approaches or those issued under section 405(d) of the Cybersecurity Act of 2015, in place for at least the previous 12 months. Keep evidence of when each was adopted.

How to implement

1. Inventory first: list every system, SaaS application and vendor touching ePHI, with data flows including email, backups and integration engines. Reconcile against procurement and the BAA register.
2. Run the risk analysis: follow the OCR elements and have the risk owner sign the result.
3. Decide every addressable specification: record "implemented", or the reason and the alternative. Revisit decisions not to encrypt laptops, media or backups first.
4. Close high risks with quick wins: MFA for remote access, email and privileged accounts; removal of shared accounts; leaver access removal within a defined time; tested offline or immutable backups.
5. Pilot technical changes: roll out automatic logoff, MFA and new EHR roles in one department first, measure clinical impact and help desk calls, then expand. Keep the previous configuration ready to restore if a change blocks care.
6. Fix contracts: update BAAs with notification timeframes shorter than 60 days and request assurance evidence.
7. Test and evaluate: run restore tests, ransomware and vendor breach tabletops, and a periodic evaluation under 164.308(a)(8), then feed results into the risk analysis.

Decision guidance by organisation size

• Small practices and start-up vendors: flexibility lets you choose simpler measures, not skip standards. A hosted EHR, cloud email with MFA, full disk encryption and a documented risk analysis cover much of the rule. Put your managed service provider under a BAA.
• Mid-sized providers and plans: the gaps are usually inventory, logging and vendor access. Centralise EHR, identity and email logs and review clinical access quarterly.
• Large systems and business associates at scale: map the rule to NIST CSF 2.0 or SP 800-53 so one evidence set serves HIPAA, insurers and customers. Add HITRUST r2 only if customers demand it.

Detection and measurement

Audit controls (164.312(b)) require mechanisms "to record and examine activity" in ePHI systems, and information system activity review (164.308(a)(1)(ii)(D)) requires you to review those records. Log EHR record access, identity provider sign-ins and MFA events, privileged actions, email forwarding rules, remote access sessions and backup results. Useful metrics:

• Risk analysis currency: days since the last full update, and share of ePHI systems in scope of it.
• MFA coverage: percentage of remote, email and privileged accounts using MFA.
• Encryption coverage: percentage of endpoints, removable media and backups encrypted.
• Leaver access removal time: median hours from termination to account disablement.
• Restore success: share of restore tests meeting the target recovery time.
• BAA coverage: share of ePHI vendors with a current BAA and assurance evidence on file.

Where identity fits

Several of the Required specifications are identity controls: unique user identification, emergency access, person or entity authentication, termination procedures and access authorisation. Non-human identities matter too: interface engine accounts, API keys and backup service accounts often hold broad ePHI access with no owner. Clinician access patterns, tap and go, EPCS and patient identity are covered in the Healthcare Identity Security Guide; connected devices in the Medical Device Security Guide; and service accounts in the Service Account Security Guide.

Framework mapping

NIST publishes official mappings through SP 800-66 Rev. 2; this table is a practical summary.

Common failure patterns

• Partial risk analysis: covering the EHR but not email, file shares, backups or vendor portals, as in the February 2026 phishing case above.
• Addressable treated as optional: no encryption on laptops or backups and no written rationale or alternative, which turns a lost device into a reportable breach and a compliance finding.
• Remote access without MFA: the Change Healthcare breach began with a single remote access login without MFA and became the largest US healthcare data breach.
• Logs collected, never reviewed: audit controls on, no activity review, so snooping and compromised accounts go unnoticed.
• BAA as paperwork: contracts signed without knowing which vendors hold ePHI or checking their controls.
• Untested contingency plans: domain-joined backups encrypted along with production, never restored at scale before the incident.

Practitioner checklist

• Maintain an inventory and data flow map of every system and vendor that touches ePHI.
• Complete an accurate and thorough risk analysis, signed by the risk owner, and update it after major changes.
• Record a decision and rationale for every addressable specification.
• Encrypt ePHI on endpoints, removable media, backups and in transit wherever feasible.
• Enforce unique user IDs, MFA for remote, email and privileged access, and tested emergency access.
• Remove leaver access within a defined time and review access to ePHI systems at least quarterly.
• Collect and actually review EHR, identity, email and remote access logs.
• Hold current BAAs with every business associate, with notification terms and assurance evidence.
• Test restores and run incident tabletops, including a business associate breach scenario.
• Track the proposed Security Rule update and keep documentation for six years.

Standards and references

• eCFR: 45 CFR Part 164 Subpart C, Security Standards for the Protection of Electronic Protected Health Information
• HHS: Summary of the HIPAA Security Rule
• HHS OCR: Guidance on Risk Analysis Requirements under the HIPAA Security Rule
• HHS: Breach Notification Rule
• Federal Register: HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (proposed rule)
• HHS OCR: HIPAA Security Rule NPRM Fact Sheet
• Reginfo.gov: Unified Agenda entry, RIN 0945-AA22
• NIST: SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide

Related NHI Mgmt Group resources: Healthcare Identity Security Guide · Medical Device Security Guide · Ransomware Prevention Guide · Incident Response Guide · Identity Security Regulatory Map. This guide summarises the HIPAA Security Rule, the related breach notification duties and the status of the proposed update as of 16 October 2026, and is not legal advice.