Threat identification is a required input to any formal risk assessment. NIST SP 800-30, ISO 27005, and HIPAA’s risk analysis requirement under 45 CFR 164.308(a)(1) all require that you identify and characterize threat sources before you assess likelihood or impact. Without it, your risk assessment is incomplete by definition and your control selection has no documented basis. When an auditor or OCR investigator asks why you implemented the controls you did, your answer should be backed by a documented threat analysis.
Mapping Data Flows First
Before identifying threats, you need to know what you’re protecting and how it moves. A Data Flow Diagram makes that concrete — it shows the external entities interacting with your systems, the processes handling data, the data stores holding it, and the flows connecting them. Most importantly, it shows trust boundaries: the lines separating what you control from what you don’t.
For a healthcare practice, a basic DFD shows patients as external entities, the EHR and Microsoft 365 as internal systems, the cloud providers hosting them across a trust boundary, and the flows between clinical staff, administrative staff, and each system. Every arrow on that diagram is a data flow that can be analyzed for risk. Every trust boundary crossing is where controls need to be strongest.
HIPAA’s risk analysis requires an accurate and thorough assessment of potential risks to ePHI. You cannot produce that without first knowing where ePHI exists and how it flows through your environment. A DFD is the tool that makes your ePHI scope explicit, and it’s the document that shows an OCR investigator you understood your environment before you assessed it.
Threat Agents
A threat agent is anyone or anything capable of exploiting a vulnerability. The full picture is broader than external attackers, and for most SMBs, the more likely threats come from inside the organization. NIST SP 800-30 and ISO 27005 both require explicitly identifying and characterizing threat sources before assessing likelihood or impact.
External Attackers
Opportunistic or targeted. Motivated by financial gain, espionage, or disruption. The most visible threat but not always the most likely for a small organization.
Malicious Insiders
Employees with legitimate access who misuse it intentionally. Harder to detect because their activity looks normal. In healthcare, accessing patient records without a clinical reason is a HIPAA violation regardless of intent.
Negligent Insiders
Employees who don’t intend harm but create risk through poor practices: weak passwords, mishandling PHI, falling for phishing. Statistically the most common source of healthcare breaches.
Former Employees
Accounts not deprovisioned, credentials still valid. Access that persists after separation is a direct threat and a routine HIPAA finding. Meridian Health Partners had active EHR credentials for multiple former employees at the time of assessment.
Privileged Users
Often have broad system access and are frequently targeted by social engineering. Privilege without commensurate controls is a significant risk surface, particularly for practice owners and administrators.
Vendors and Contractors
Physical or remote access to systems, potentially unknown security posture. Every vendor with access to ePHI is a business associate and requires a BAA. Third-party risk extends to anyone with a foot in the door.
The point is not to be exhaustive but to force the question: which of these are realistic threats to this specific environment? A small practice isn’t a likely nation-state target. But it absolutely needs to account for negligent insiders and former employees because those are the threats that show up most frequently in OCR breach reports for organizations of that size.
Once you know who the realistic threat agents are, control selection becomes logical rather than arbitrary. Defending against negligent insiders means security awareness training, MFA, and access controls. Defending against former employees means formal offboarding procedures and quarterly access reviews. Defending against external attackers means perimeter controls, patching, and monitoring. Different threats call for different responses, and documented threat identification is what makes your control selection defensible when an assessor asks why you chose the controls you did.
Threat Identification in Cloud Environments
Cloud environments reduce visibility. On-premises, you own and operate every layer of the stack. In the cloud, the provider manages physical infrastructure, the hypervisor, and in some cases the operating system. That is the shared responsibility model, where the provider secures the infrastructure and you secure everything you deploy on top of it.
This is where a DFD becomes especially valuable. Mapping data flows in a cloud environment forces you to identify what you actually control versus what the provider manages — and where your responsibility begins. For a covered entity, that boundary is where HIPAA obligations continue to apply regardless of who manages the underlying infrastructure. “Our EHR vendor handles that” is not a risk analysis.
The most common mistake in cloud adoption is assuming that because the provider handles infrastructure security, the organization’s overall posture is improved. It may be, but only for the layers the provider manages. The layers you’re responsible for still need the same rigor. Cloud infrastructure does not transfer your HIPAA obligations to the vendor. It changes who is responsible for which layer, and your BAA with that vendor must reflect that clearly.
Control Mapping
NIST SP 800-30 structures risk assessment as a four-step process: prepare, conduct, communicate, maintain. The conduct step requires identifying threat sources and threat events before assessing likelihood or impact. Skipping threat identification means the risk assessment is incomplete by definition.
NIST CSF ID.RA-3 specifically requires that threats both internal and external are identified and documented. The threat agent taxonomy above maps directly to what this control requires.
ISO 27005 structures risk identification as: identify assets, identify threats, identify existing controls, identify vulnerabilities, identify consequences. Threat identification is the second step — you cannot assess which threats are relevant without first knowing what assets exist.
HIPAA 164.308(a)(1) requires an accurate and thorough assessment of potential risks and vulnerabilities to ePHI. The Security Rule does not prescribe a methodology, but OCR has consistently held that a compliant risk analysis must identify reasonable and anticipated threats to ePHI — which requires the kind of documented, environment-specific threat identification described here.
The Point
Threat identification is a documented, environment-specific analysis that drives control selection and satisfies the threshold requirement of every major risk assessment framework. Without it, your controls exist without justification and your risk analysis exists without foundation.
