The first document the Office for Civil Rights asks for after a breach report is almost never your privacy notice. It's your risk analysis. And the second is the risk management plan that shows what you did about the gaps the risk analysis found. If you cannot produce both with dates on them, the HIPAA Security Rule investigation stops being about the incident and starts being about your program.

This is a working guide for the person who owns that file: what the rule requires, who inside your practice is responsible, how often each obligation recurs, and what the evidence actually looks like when someone asks. No clinical content, no theory — just the operational shape of the rule.

What the HIPAA Security Rule Requires, in Plain Terms

The HIPAA Security Rule (45 CFR Part 160 and Subparts A and C of Part 164) applies to electronic protected health information only. Paper charts, faxes sitting in a tray, and verbal disclosures fall under the Privacy Rule. The Security Rule governs ePHI you create, receive, maintain, or transmit.

Four general requirements sit at §164.306. You must ensure the confidentiality, integrity, and availability of all ePHI you handle. You must protect against reasonably anticipated threats. You must protect against reasonably anticipated impermissible uses and disclosures. And you must ensure workforce compliance.

Everything else — three categories of safeguards, roughly two dozen standards, and their implementation specifications — exists to operationalize those four sentences.

The three safeguard categories

  • Administrative safeguards (§164.308). Risk analysis, risk management, sanction policy, information system activity review, a named security official, workforce clearance and termination procedures, access management, security awareness training, incident response procedures, contingency planning, periodic evaluation, and business associate contracts.
  • Physical safeguards (§164.310). Facility access controls, workstation use policies, workstation security, and device and media controls covering disposal, re-use, movement, and backup.
  • Technical safeguards (§164.312). Access control including unique user identification and emergency access, audit controls, integrity controls, person or entity authentication, and transmission security.

Two more sections get skipped constantly. §164.314 sets the organizational requirements for business associate contracts. §164.316 requires written policies and procedures and requires you to retain them — and the documentation of actions, activities, and assessments the rule demands — for six years from the date of creation or the date last in effect, whichever is later. HHS maintains the current regulatory text and guidance on its Security Rule professional resources page.

"Addressable" Does Not Mean Optional

This is the single most expensive misunderstanding in small-practice compliance. Implementation specifications are labeled either required or addressable. Required means you implement it, full stop. Addressable means you assess whether the specification is reasonable and appropriate for your environment — and then do one of three things.

  1. Implement it as written.
  2. Implement an equivalent alternative measure that achieves the same purpose.
  3. Document why neither is reasonable and appropriate, and document what you do instead to manage that risk.

Option three is not "we skipped it." It's a written determination, signed and dated, tied to a specific finding in your risk analysis. Encryption of ePHI at rest is addressable under §164.312(a)(2)(iv). A practice that leaves laptops unencrypted and has no written analysis explaining that decision has a Security Rule violation independent of whether a laptop ever goes missing.

Automatic logoff, encryption in transit, and data backup for portable media are also addressable. Unique user ID, emergency access procedure, audit controls, authentication, and media disposal are required — no analysis, no alternative.

The Risk Analysis Is the Anchor, and Most Practices Do It Wrong

§164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI your organization holds. Read that again: all ePHI. Not just the ePHI in your practice management system.

A compliant risk analysis starts with a full inventory of where ePHI lives. In a ten-provider practice, that list typically runs to twenty or thirty entries: the EHR, the clearinghouse connection, the imaging archive, the appointment reminder platform, the transcription vendor, the shared drive, the scanner that emails PDFs, the two front-desk workstations, six clinician laptops, the backup appliance, the cloud storage account someone set up in 2021, and the billing manager's phone with email on it.

For each asset, you identify threats and vulnerabilities, assess likelihood and impact, and record the resulting risk level. Then §164.308(a)(1)(ii)(B) requires risk management: reducing those risks to a reasonable and appropriate level, with a documented plan showing owner, remediation step, and target date.

Who does it and how often

Your named security official under §164.308(a)(2) owns the process. In a practice under fifty people, that's usually the practice administrator or the privacy officer wearing a second hat. The rule doesn't require an outside firm, but it does require accuracy and thoroughness, which means someone has to actually walk the building and interview staff.

Frequency: the rule says the risk analysis must be ongoing, and §164.308(a)(8) requires periodic technical and nontechnical evaluation in response to environmental or operational changes. Annual review is the defensible baseline. Trigger an off-cycle update when you add a major system, change EHRs, open a location, or experience an incident.

ONC and OCR jointly publish a free Security Risk Assessment Tool aimed at practices with fewer than fifty providers. NIST Special Publication 800-66 Revision 2 maps Security Rule standards to concrete implementation activities and is the closest thing to an official crosswalk; you can pull it from the NIST Computer Security Resource Center. If the manual approach is stalling, tools that automate risk analysis reports and the supporting policy set can compress the drafting work — but the asset inventory and the remediation decisions still have to come from someone who knows your operation.

The HIPAA Security Rule requires covered entities and business associates to:

  • Conduct a risk analysis covering all systems that create, receive, maintain, or transmit ePHI, and implement a documented risk management plan.
  • Designate a security official responsible for developing and implementing security policies.
  • Implement administrative, physical, and technical safeguards under §§164.308, 164.310, and 164.312, including access controls, audit controls, authentication, and transmission security.
  • Train the workforce on security awareness and apply a written sanction policy for violations.
  • Execute business associate agreements before disclosing ePHI to any vendor.
  • Maintain a contingency plan with data backup, disaster recovery, and emergency mode operation procedures.
  • Write policies and procedures and retain documentation for six years from creation or last effective date.

The Vendor Gap: Where Security Rule Failures Compound

§164.308(b)(1) and §164.314(a) require a written contract before you disclose ePHI to a business associate. The contract has to obligate the vendor to implement the Security Rule safeguards, report security incidents and breaches to you, ensure subcontractors do the same, and return or destroy ePHI at termination.

Pull the OCR breach portal and filter for incidents involving business associates. The pattern is consistent: a vendor gets compromised, and every practice that sent it data inherits a reportable breach. Whether OCR treats your practice as merely unlucky or as noncompliant often comes down to whether a signed, current agreement existed on the day the data moved.

Practical failure modes I see in vendor reviews:

  • An agreement signed in 2012 that predates the Omnibus Rule and never mentions subcontractors or breach notification timelines.
  • A vendor's terms of service with a "HIPAA addendum" that only the vendor signed.
  • A transcription service, an answering service, or a shredding company onboarded by a department head who never told the privacy officer.
  • A signed agreement that nobody can locate.

Fix the last three by keeping a single vendor register: name, service, ePHI accessed, agreement date, renewal date, and where the PDF lives. Fix the first two by reissuing. If you need current agreements fast, you can generate a signature-ready Business Associate Agreement through a six-step wizard and export it as PDF or DOCX — a one-time purchase, no subscription, which matters when you're papering eleven vendors in a week rather than one.

What Changed in 2025 — and What Hasn't

In January 2025, HHS published a notice of proposed rulemaking to substantially revise the HIPAA Security Rule. The comment period closed in March 2025. As of December 9, 2025, the proposal has not been finalized, and the current rule remains in force exactly as written.

The proposal is worth reading anyway, because it signals where OCR's expectations are heading. Among the significant proposed changes: eliminating the required/addressable distinction so that nearly all specifications become mandatory; requiring a written technology asset inventory and network map updated at least annually; mandating encryption of ePHI at rest and in transit with narrow exceptions; requiring multi-factor authentication; requiring vulnerability scanning and penetration testing on set intervals; and requiring covered entities to obtain written verification of business associate safeguards on a recurring basis.

Do not rebuild your program around a proposed rule. Do use it as a gap list. Asset inventory, MFA, and encryption are already defensible investments under the existing rule — if the final rule lands close to the proposal, you'll be ahead; if it doesn't, you've still reduced real risk.

A 90-Day Sequence If You're Starting From a Thin File

Days 1–30: Inventory and designation

Name the security official in writing, signed by an owner or the board. Build the ePHI asset inventory. Build the vendor register and pull every existing BAA into one folder. Identify which vendors have no agreement or an outdated one.

Days 31–60: Risk analysis and gap list

Complete the risk analysis across every asset on the inventory. Produce a risk register with likelihood, impact, and rating. Convert the high and medium findings into a remediation plan with a named owner and a target date for each item. Execute the missing business associate agreements.

Days 61–90: Policies, training, and drills

Adopt the written policies the rule requires — sanction policy, access management, workstation use, device and media disposal, incident response, contingency plan. Deliver security awareness training and keep the attendance roster with dates and signatures. Run one tabletop exercise on your incident response procedure and write a half-page after-action note. Test one backup restore and document the result.

What the Evidence File Looks Like When Someone Asks

Assume you have five business days to respond to an OCR data request. These are the artifacts that should already exist, dated, with version history:

  1. Current risk analysis with asset inventory and methodology.
  2. Risk management plan showing findings, owners, dates, and closure evidence.
  3. Written designation of the security official.
  4. The full policy and procedure set, with adoption dates and signatures.
  5. Training records: who, what, when, and the content delivered.
  6. Sanction policy and any sanctions applied.
  7. Signed BAAs for every vendor on the register.
  8. Contingency plan plus evidence of at least one backup restoration test.
  9. Information system activity review logs — evidence someone actually looks at audit logs, not just that logging is enabled.
  10. Incident log covering all security incidents, including those that did not rise to a reportable breach.

That last one gets overlooked. §164.308(a)(6) requires you to identify and respond to suspected or known security incidents and document the outcome. A phishing email an employee clicked and reported is an incident. Write it down, note what you did, close it.

None of these documents are hard to produce individually. They become hard when you try to produce all ten in a week, backdating nothing, under investigation. Build the file when nothing is on fire.

Start With the Two Documents Everyone Is Missing

If your program is incomplete, prioritize in this order: a real risk analysis, then current business associate agreements for every vendor touching ePHI. Those two account for a disproportionate share of what OCR finds and what breaches expose.

Pull your vendor list this week. For every name without a signed, current agreement on file, build a compliant BAA and get it signed before the next chart, claim, or reminder text goes out the door. It's the cheapest gap on the list to close, and the hardest to explain if you don't.