Security controls don’t exist in a vacuum. A firewall rule, an ACL, an access policy — each one is a response to a specific threat. If you’re deploying controls without first asking what you’re defending against and who might be attacking, you’re guessing. Threat identification turns that guesswork into a reasoned approach — and it’s a required input for any formal risk assessment process.
Mapping Data Flow
Before identifying threats, it helps to have a visual representation of how data moves through the environment. A Data Flow Diagram does exactly that. It shows the external entities interacting with your systems, the processes handling data, the data stores holding it, and the flows connecting them. Critically, it also shows trust boundaries — the lines separating what you control from what you don’t.
From a control perspective, the trust boundary is where you’d start thinking about firewalls, ACLs, and input validation. But internal flows matter too. The web application talking to the database is an internal flow, and if an attacker gains access to the application tier, unrestricted database access becomes a problem. A DFD makes those attack paths visible before an incident makes them obvious.
Threat Agents
A threat agent is anyone or anything capable of exploiting a vulnerability. The tendency is to think of this as external hackers — and they’re certainly on the list — but the full picture is broader and in many cases the more dangerous threats come from inside the organization. Risk assessments under 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. Usually the first threat that comes to mind but not always the most likely.
Malicious Insiders
Employees with legitimate access who misuse it intentionally. Harder to detect because their activity looks normal. Often motivated by financial incentive or grievance.
Negligent Insiders
Employees who don’t intend harm but create risk through poor practices — weak passwords, mishandling sensitive data, falling for phishing. Statistically the most common source of incidents.
Former Employees
Accounts not deprovisioned, credentials still valid, institutional knowledge of systems and processes. Access that persists after separation is a direct threat and a routine audit finding.
Executives and Privileged Users
Often have broad access and are frequently targeted by social engineering. Privilege without commensurate security controls is a significant risk surface.
Visitors and Contractors
Physical access to facilities, temporary network access, potentially unknown security posture. Third-party risk extends to anyone with a foot in the door.
Competitors
Motivated by corporate espionage — intellectual property, customer data, strategic plans. May operate through direct attack or through compromising a third party with access.
Nation-State Actors
Highly resourced, persistent, and patient. Relevant for critical infrastructure, government, and organizations with valuable intellectual property.
The point of this list isn’t to be exhaustive but to force the question: which of these are realistic threats to this specific environment? A small business isn’t a likely nation-state target. A healthcare organization absolutely needs to account for insider threats given the value of patient data. Context determines which threat agents deserve the most attention — and documented threat identification is what makes your control selection defensible when an assessor asks why you chose the controls you did.
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 DLP. Defending against external attackers means perimeter controls, patching, and monitoring. Different threats call for different responses, and trying to address all of them equally leads to oversights and bloated security budgets. In regulated environments many of these controls aren’t optional — frameworks like HIPAA, PCI DSS, and NIST prescribe specific requirements based on threat landscape. Compliance tells you the minimum. Threat modeling tells you if the minimum is enough.
Threat Identification in the Cloud
Cloud environments introduce a specific challenge: reduced visibility. On-premises, you own and operate every layer of the stack. In the cloud, the provider manages the physical infrastructure, the hypervisor, and in some cases the operating system and runtime. That’s the shared responsibility model — the provider secures the infrastructure, you secure everything you deploy on top of it.
This is where a DFD becomes even more 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. That boundary is where your security posture needs to be strongest, and where regulatory obligations like HIPAA and PCI DSS continue to apply regardless of who manages the underlying infrastructure.
The Visibility Gap
One of the most common mistakes in cloud adoption is assuming that because the provider is handling infrastructure security, the organization’s overall security 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, and in some cases more, because the attack surface is now internet-accessible by default. The shared responsibility model doesn’t transfer your compliance obligations to the provider.
Control Mapping
Threat identification is a required step in every major risk management framework before controls can be selected or risk can be assessed.
NIST SP 800-30 (Guide for Conducting Risk Assessments) 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 — you can’t assess the likelihood of a threat event without first characterizing the threat source.
NIST CSF ID.RA (Risk Assessment) requires that threats to the organization are identified and documented. ID.RA-3 specifically calls for threats both internal and external to be identified. The threat agent taxonomy above maps directly to what this function requires — a documented, contextualized list of realistic threat sources for the specific environment.
ISO 27005 (Information Security Risk Management) structures risk identification as identifying assets, threats, existing controls, vulnerabilities, and consequences. Threat identification is the second step in that sequence — you can’t assess which threats are relevant without first knowing what assets exist.
NIST RMF Step 2 (Select) requires selecting controls based on the security categorization of the system, which itself depends on understanding the threat environment. Control selection disconnected from threat identification produces a control set that may satisfy compliance checkboxes but doesn’t address the actual risks the organization faces.
The Point
Understanding your threat agents and mapping your data flows gives you the foundation for control selection grounded in actual risk rather than convention.
