Every HIPAA covered entity and business associate has to do a security risk analysis. Most have a document with that title. When the Office for Civil Rights (OCR) investigates a breach, though, it still finds the same problem: the analysis covered some systems, not all the places ePHI lives, or it listed threats without rating them or linking them to fixes. "Failure to conduct an accurate and thorough risk analysis" is the finding that keeps appearing in OCR settlements.
The Security Rule never says "threat model", but it describes one: find every place electronic protected health information (ePHI) is created, received, maintained or transmitted, work out what could go wrong with each, rate it, and fix what matters. This post builds that analysis for a fictional clinic group: a data flow diagram of where its ePHI goes, a walk through OCR's risk analysis elements, an attack tree and a scored register its security official can sign.
The short version: HIPAA's risk analysis (45 CFR 164.308(a)(1)(ii)(A)) must cover all the ePHI you hold, wherever it is: servers, laptops, backups, interfaces and business associates. OCR's guidance lists the elements it expects: scope, data collection, threats and vulnerabilities, current measures, likelihood, impact, level of risk, documentation and periodic review. A threat model delivers all of them. The diagram is your scope and data collection, the attack tree is your threats and vulnerabilities, and the scored register is your level of risk, linked to the risk management decisions that 164.308(a)(1)(ii)(B) requires. "Addressable" doesn't mean optional, so record a decision for every addressable safeguard. Keep the analysis for six years, and update it when your systems change.
Where HIPAA stands on 2 November 2026
The Security Rule (45 CFR Part 164, Subpart C) has applied to most covered entities since April 2005. Its text hasn't changed much since then, but enforcement and expectations have.
| Date | What happened |
|---|---|
| 2005 | Compliance with the Security Rule required for most covered entities. The risk analysis is a required implementation specification from day one. |
| 2009 / 2013 | The HITECH Act and the Omnibus Rule make business associates directly liable for the Security Rule, including their own risk analysis. |
| Late 2024 | OCR starts its Risk Analysis Initiative, an enforcement effort aimed specifically at organisations whose risk analysis is missing or inadequate. Settlements under it have continued through 2026, including four ransomware cases announced together in April 2026. |
| 6 Jan 2025 | HHS publishes a proposed overhaul of the Security Rule: a written asset inventory and network map, a more detailed written risk analysis, mandatory MFA and encryption with few exceptions, and the end of the "addressable" category. |
| Jul 2026 | HHS's regulatory agenda moves the final Security Rule amendments from May 2026 to July 2027 and reclassifies them as a long-term action. Hospital groups have asked HHS to withdraw or scale them back. |
| Now | The existing Security Rule is what OCR enforces. The proposed rule is a strong signal of where expectations are heading, not a requirement. |
What the Security Rule actually asks for
Strip out the legal phrasing and the parts of the Security Rule that a threat model answers are these:
- Risk analysis: "an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability" of the ePHI you hold (164.308(a)(1)(ii)(A)). It's required, not addressable.
- Risk management: security measures that reduce those risks and vulnerabilities to a reasonable and appropriate level (164.308(a)(1)(ii)(B)).
- Information system activity review: regularly review audit logs, access reports and security incident reports (164.308(a)(1)(ii)(D)).
- Evaluation: a periodic technical and non-technical evaluation, and another one when environmental or operational changes affect the security of ePHI (164.308(a)(8)).
- Business associates: contracts that require them to safeguard the ePHI you share (164.308(b)(1) and 164.314(a)).
- Documentation: keep the analysis and the decisions in writing for six years from when they were created or last in effect, and review them periodically (164.316(b)).
Two words in the rule shape the work. All: the analysis covers every piece of ePHI, not only the EHR. Laptops, backups, interface engines, email, scanned faxes and the systems of business associates all count. And addressable: safeguards such as encryption (164.312(a)(2)(iv)) and automatic logoff are addressable, which means you must assess whether each is reasonable and appropriate for you, implement it if it is, and document why and what you did instead if it isn't. Silence on an addressable safeguard is a finding.
The example: Northfield Community Health
Northfield Community Health is a fictional group of six outpatient clinics in the US, with about 180 clinicians and 90,000 patients. It's a covered entity. Its EHR runs in its own small data centre, with nightly backups to a storage appliance on the same network. Patients use a web portal to read results and message their clinicians. Clinicians use clinic workstations and laptops, and reach the EHR from home over a VPN. An HL7/FHIR interface engine exchanges orders and results with an outside lab, and a billing clearinghouse, a business associate, receives claims.
This is the system drawn in ThreatTree's Healthcare EHR template, extended with the pieces most real organisations have and most risk analyses forget: the laptops, the backups and the clearinghouse.
Step 1: Draw where ePHI lives and moves
OCR's guidance starts with scope and data collection: identify where ePHI is stored, received, maintained or transmitted. A diagram does both at once, and it's easier to check for completeness than an inventory spreadsheet. Put a trust boundary around everything Northfield runs and another around its partners, because each boundary is a different owner and a different contract.
Three things the diagram makes plain that the old asset list didn't:
- Laptops are ePHI stores. Clinicians download reports and keep cached data. Each laptop is a small data store outside the data centre, which is why lost devices are one of OCR's most frequent breach categories.
- The backups are a complete copy of the EHR. They're in scope for confidentiality as much as availability, and they sit on the same network that ransomware would reach first.
- ePHI leaves through two partner interfaces. The lab interface is two-way, so it's an inbound path into the EHR as well as an outbound one.
Step 2: Walk OCR's risk analysis elements
Find threats the usual way first: walk each element and flow with STRIDE, thinking about confidentiality, integrity and availability of ePHI, which is the CIA triad the rule is written around. Then read the result against the elements OCR's risk analysis guidance lists. The last column gives the register IDs from Step 4.
| OCR element | Asks for | What Northfield's threat model supplies | Register |
|---|---|---|---|
| Scope | All ePHI the organisation creates, receives, maintains or transmits, on every medium | The trust boundary labelled "all ePHI in scope", including laptops, backups and partner interfaces. | None |
| Data collection | Where ePHI is stored, received, maintained or transmitted | Every flow on the diagram, with data stores tagged as holding ePHI. | None |
| Threats and vulnerabilities | Reasonably anticipated threats, and the vulnerabilities they could exploit | The attack tree in Step 3. Each leaf names a threat and the weakness it relies on. | H1 to H8 |
| Current security measures | What's already in place, and whether it's configured and used properly | Each register row records the existing control before the new treatment (for example, break-glass exists but nobody reviews its use). | H1 to H8 |
| Likelihood | The probability that each threat occurs | A likelihood score of 1 to 5 on every leaf. | H1 to H8 |
| Impact | The harm if it does | An impact score of 1 to 5, weighted by how many patients' records and which kind of harm. | H1 to H8 |
| Level of risk | Likelihood and impact combined, with a list of risks ranked for action | Likelihood × impact on a 5×5 risk matrix, sorted in the register. | H1 to H8 |
| Documentation | The analysis in writing | The diagram, tree and register exported as one PDF, dated, and kept for six years under 164.316(b)(2). | None |
| Periodic review | Updates as the environment changes | A yearly review plus the change triggers in Step 5. | None |
Four rows have no register entry, and that's fine. The scope and data collection elements are answered by the diagram itself, and documentation and periodic review are about the process. The table still lists them, because OCR reads a risk analysis looking for each element, not only the ones with problems.
Step 3: An attack tree for ePHI
Make the root what the Security Rule protects: ePHI disclosed, altered or made unavailable. That puts privacy breaches, tampering and ransomware outages in one tree, which is how OCR looks at a breach. Leaves are scored likelihood × impact on a 5×5 matrix.
The highest-scoring leaf isn't a hacker. It's a clinician with a valid login opening the chart of a neighbour, a colleague or a local celebrity. It's likely because the EHR gives every clinician full-chart access (flow 5) and nobody reviews access logs, and it's serious because each incident is a reportable breach. That's the insider threat HIPAA's information system activity review requirement exists for.
Two High leaves are classic web and identity problems. The portal leaf is an IDOR: change the record ID in the URL and see another patient's results. The phishing leaf matters because the VPN accepts a password alone, so one phished clinician gives an attacker the same full-chart access the insider has. And the ransomware leaf is scored on the backups, not the EHR. If the backups can be encrypted from the same network, the contingency plan in 164.308(a)(7) doesn't work.
Step 4: Score it and build the register
Every leaf becomes a row in the risk register, with the measure already in place, the treatment, an owner and the Security Rule sections it supports. H1, H4 and H5 come straight from the Healthcare EHR template. The other five are what Northfield added when it drew the rest of its ePHI.
| # | Threat | L × I | Treatment | HIPAA | Owner |
|---|---|---|---|---|---|
| H1 | Clinician opens charts outside their care team | 4 × 4 = 16 | Mitigate. Today: role-based access and a break-glass button nobody reviews. New: access limited to the patient's care team by default, break-glass with a reason, weekly automated report of break-glass use and VIP-chart access, reviewed by the privacy officer. | 308(a)(1)(ii)(D), 308(a)(4), 312(b) | Privacy officer |
| H2 | Phished login, no MFA on remote access | 3 × 5 = 15 | Mitigate. Today: VPN with password only. New: phishing-resistant MFA on the VPN and the EHR's remote access, and phishing training with reporting. | 312(d), 308(a)(5) | IT manager |
| H3 | Ransomware encrypts the EHR and its backups | 3 × 5 = 15 | Mitigate. Today: nightly backups on the same network and domain. New: immutable off-site copies with separate credentials, and a full restore tested twice a year against a target time. | 308(a)(7), 308(a)(6), 312(c)(1) | IT manager |
| H6 | Portal returns another patient's record | 3 × 4 = 12 | Mitigate. Today: login required but record IDs not checked against the session. New: server-side check that every record belongs to the signed-in patient or their proxy, and tests that request every endpoint as a second patient. | 312(a)(1), 312(d) | Portal vendor + IT manager |
| H4 | No mTLS or allowlist on HL7 connections | 2 × 5 = 10 | Mitigate. Mutual TLS on the lab interface, an IP allowlist for the lab's endpoints, and alerts on connections from anywhere else. | 312(e)(1), 312(d) | Integration lead |
| H5 | Crafted HL7 message exploits the parser | 2 × 5 = 10 | Mitigate. Patch the interface engine on the vendor's schedule, validate messages against the expected schema and run the engine with the least access it needs. | 312(c)(1), 308(a)(1)(ii)(B) | Integration lead |
| H7 | Clearinghouse breach exposes claims data | 2 × 4 = 8 | Transfer and accept. A business associate agreement that requires Security Rule safeguards and breach notice, yearly evidence of the clearinghouse's own risk analysis, and only the fields claims need. The residual risk is accepted by the security official. | 308(b)(1), 314(a)(1) | Security official |
| H8 | Stolen laptop holds unencrypted ePHI | 2 × 4 = 8 | Mitigate. Full-disk encryption enforced on every laptop, remote wipe, and automatic logoff. Encryption is addressable, but Northfield's decision is documented: it's reasonable and appropriate, so it's implemented. | 310(d)(1), 312(a)(2)(iv), 312(a)(2)(iii) | IT manager |
Section numbers are 45 CFR 164 (308 = administrative, 310 = physical and 312 = technical safeguards). H7 is the honest row. Northfield can't inspect the clearinghouse's systems or fix them. It can choose a clearinghouse with a credible security programme, write its obligations into the contract, send less data, and write the residual risk down with a name next to it. That's a valid risk treatment, as long as it's a decision rather than an omission. The same logic applies to every vendor on the diagram, as described in how to threat model third-party vendor integrations.
H8 shows why the encryption decision matters beyond the Security Rule. Under the Breach Notification Rule, a lost laptop whose data was encrypted to HHS's guidance standard isn't a reportable breach. The same laptop unencrypted is, along with notice to every affected patient.
Step 5: Keep it alive
A risk analysis written once and filed is what OCR keeps finding in its investigations. The threat model makes updates cheap, because you change the part of the diagram that changed and re-score the affected branch:
- Yearly. Review the whole model, re-score the leaves and take the register to leadership. The current rule doesn't set an interval, but a yearly review is what most auditors expect, and the proposed rule would require it.
- On change. A new EHR module, a telehealth vendor, a move to the cloud or a new way to reach ePHI gets a threat-model pass before go-live. That's your evidence for the evaluation in 164.308(a)(8). See when to re-threat model for the other triggers.
- After incidents. When a breach or near miss happens, add its path to the tree if it wasn't there. That's the lesson the next analysis must show.
- Activity review. The register says which logs matter. H1 needs break-glass and VIP-chart reports, H4 needs interface connection logs. That turns 164.308(a)(1)(ii)(D) from "we have logs" into "we review these, weekly, and here's who does it".
What threat modeling can't do here
- It can't make you HIPAA-compliant. It produces the risk analysis and the evidence for risk management. You still need policies, a designated security official, workforce training, sanctions, contingency plans, business associate agreements and the Privacy and Breach Notification Rules.
- It doesn't cover the physical and administrative safeguards on its own. Facility access, workstation placement and workforce clearance are part of the Security Rule. Some show up as threats on the diagram, but they need their own review.
- It doesn't replace your business associates' analyses. A clearinghouse or cloud provider has to do its own risk analysis. Your model shows the risk they bring to you, not whether they comply.
- It doesn't cover the device side of medical devices. If you make a device, the FDA's premarket requirements apply. See the FDA premarket threat model.
A checklist for your HIPAA risk analysis
- Draw every system that creates, receives, maintains or transmits ePHI, including laptops, backups, interfaces, email and business associates.
- Put a trust boundary around your organisation and one around each group of partners.
- Tag each data store that holds ePHI, and label each flow with what it carries.
- Find threats to confidentiality, integrity and availability on every element and flow, including insiders and outages.
- Record the security measure already in place for each threat before scoring it.
- Score likelihood and impact, and rank the risks.
- Give each significant risk a treatment, an owner and the Security Rule sections it supports.
- Write a documented decision for every addressable safeguard.
- Export and date the analysis, and keep every version for six years.
- Set the triggers: a yearly review, every significant change, every new vendor and every incident.
Sources, as of 2 November 2026: 45 CFR Part 164, Subpart C (164.306 to 164.316), HHS guidance on risk analysis, the proposed Security Rule amendments of 6 January 2025, Davis Wright Tremaine on HHS's updated rulemaking timeframes (July 2026) and Healthcare Innovation on OCR's risk analysis settlements. This post isn't legal advice. Check scope questions with your compliance team or counsel.
Frequently asked questions
Does HIPAA require threat modeling?
Not by name. The Security Rule requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of all the ePHI you hold (45 CFR 164.308(a)(1)(ii)(A)), and security measures that reduce those risks to a reasonable and appropriate level. A threat model of the systems that create, receive, maintain or transmit ePHI, with a diagram, scored threats and owned treatments, is a practical way to produce that analysis and keep it current.
How often do you need to do a HIPAA risk analysis?
The current rule sets no fixed interval. It requires the analysis to be reviewed and updated as needed, and an evaluation whenever environmental or operational changes affect the security of ePHI. In practice most organisations review it at least once a year and again before any significant change, such as a new system, vendor or way of accessing ePHI. The Security Rule update HHS proposed in January 2025 would make a review at least every 12 months explicit, but as of 2 November 2026 it isn't final.
What is the difference between a HIPAA risk analysis and risk management?
The risk analysis (164.308(a)(1)(ii)(A)) finds and rates the risks to ePHI. Risk management (164.308(a)(1)(ii)(B)) is implementing security measures that bring those risks down to a reasonable and appropriate level. Both are required implementation specifications, and OCR expects to see the link between them: each significant risk in the analysis should have a documented treatment, an owner and a status.
Do business associates need their own HIPAA risk analysis?
Yes. Since the HITECH Act and the 2013 Omnibus Rule, business associates are directly liable for complying with the Security Rule, including the risk analysis. A covered entity also needs to assess the risk its business associates bring, starting with a business associate agreement that requires the safeguards, and should draw each one in its own threat model as a dependency.
Is the HHS Security Risk Assessment Tool enough for HIPAA?
It can be a useful start for small and medium practices, but HHS says using it doesn't guarantee compliance. The SRA Tool is a questionnaire about safeguards. It doesn't map where your ePHI actually flows, so it can miss risks that only appear in the architecture, such as an unencrypted interface to a lab or backups reachable from the same network as the EHR. A threat model fills that gap and can sit alongside the questionnaire.