What is threat modeling?

Q: What does threat modeling produce?

A threat model produces four things: (1) an attack surface inventory — all entry points, trust boundaries, and data flows; (2) a threat list — what adversaries want and how they might get it; (3) a prioritized list of security gaps where the threat has no adequate defense; and (4) a set of countermeasure recommendations ordered by risk reduction. Most teams also produce a data flow diagram (DFD) that makes the trust boundaries and data movement visible. The threat model becomes the input for penetration test scoping.

01. what it produces

What a threat model gives you.

A threat model is not a document that sits in a drawer. Each output feeds a downstream activity: a test, a design decision, a remediation sprint.

Attack surface inventory

All entry points into the system, trust boundaries between components, and data flows between them. This is the foundation: you cannot find attack paths without knowing where data enters, where it goes, and what trusts what.

Threat list

What adversaries could want from your system and how they might pursue it. Structured against your actual architecture, not generic threat categories. For a SaaS product, this might be tenant data access, privilege escalation to admin, or billing manipulation. For a payment processor, it is CHD exfiltration and transaction manipulation.

Gap analysis

For each identified threat, which controls exist to prevent it, and how strong are they? Gaps are threats with no adequate defense. These drive the penetration test scope and the remediation backlog.

Countermeasure recommendations

Specific architectural or implementation changes ordered by risk reduction. Not generic "encrypt sensitive data" advice — specific to your architecture and the threats identified.

Threat modeling and penetration testing

A threat model tells you what to test. A penetration test without one is a tester working from first principles — finding what they find, in the order they happen to find it. That produces real findings. It may also spend time on lower-risk surfaces while higher-risk ones wait.

The difference is visible in scoping. A fintech company that models their cardholder data environment before a pentest will scope the test to include segmentation controls, payment API authorization, and the admin portal that can initiate refunds — because the threat model identified those as the paths most likely to produce the outcome an attacker wants. Without the threat model, scope often defaults to "the web application" without any systematic prioritization of which parts of the application carry the most risk.

Threat models also surface categories of risk that a pentest may not explore. Architectural flaws are one example: a design that requires granting database read access to a third-party analytics tool creates a trust boundary problem that a pentest might not exercise but a threat model flags immediately. If the analytics tool is compromised, what data is exposed? What can the attacker do with that access? A tester who scopes only to the application itself may never touch the analytics integration. The threat model would put it on the list.

The sequencing that produces the most value: threat model first, use it to scope the pentest, use pentest findings to validate and update the threat model. When the tester finds a vulnerability the threat model did not anticipate, that is a gap in the model. Add it, trace its implications, and update the control recommendations. The model should be a living document, not a one-time artifact.

In practice, many organizations run their first pentest before they have a threat model. The test reveals gaps they did not know to worry about, and the results become the starting point for modeling. This works, but the test is less targeted and may miss high-risk areas that neither the scope definition nor the tester's initial reconnaissance identified. If you are starting from scratch, the order matters: model first, test second, update the model with what the test found.

One practical note on cost: a well-scoped pentest is almost always faster than a vaguely scoped one. Testers who know exactly what to focus on spend their time on it. Testers who must reconstruct the architecture from scratch during discovery spend time on work the threat model would have done already. The threat model pays for itself in scoping efficiency before the test even starts.

STRIDE, PASTA, and other frameworks

Microsoft's STRIDE and OWASP's documentation cover the frameworks in detail — no need to restate them here. The short version: STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is a useful enumeration lens for walking through each component in your data flow diagram and asking what category of threat applies. PASTA (Process for Attack Simulation and Threat Analysis) maps threats to business impact, which is useful when the output needs to speak to risk appetite rather than just technical gaps.

The choice of framework matters less than doing it rigorously and updating it when the architecture changes. A STRIDE analysis done once and left to go stale is less useful than an informal threat review done consistently every time a significant architectural change ships. The output — attack surface inventory, threat list, gap analysis, countermeasures — is the point, not the framework that produced it.

For organizations that want threat modeling done regularly rather than as a pre-pentest event, the advisory retainer is the right structure. Architecture reviews and threat modeling sessions happen monthly as part of the retainer, which means the model stays current as the system evolves rather than being rebuilt from scratch before each engagement.

03. common questions

Frequently asked questions.

What does threat modeling produce?

A threat model produces four things: an attack surface inventory (all entry points, trust boundaries, and data flows); a threat list (what adversaries want and how they might get it); a prioritized list of security gaps where the threat has no adequate defense; and a set of countermeasure recommendations ordered by risk reduction. Most teams also produce a data flow diagram that makes the trust boundaries and data movement visible. The threat model becomes the input for penetration test scoping.

What is the difference between threat modeling and a risk assessment?

A risk assessment is broader — it surveys all organizational risk including operational, financial, compliance, and reputational risk. Threat modeling is focused specifically on technical attack paths: how could an adversary compromise this system? Threat modeling is one input to a risk assessment, covering the technical security risk component. Many compliance frameworks (HIPAA §164.308(a)(1), SOC 2, ISO 27001 clause 6.1) require a risk assessment; a threat model is how you produce the technical evidence for it.

When should we do threat modeling — before or after a penetration test?

Before, ideally. A threat model tells you what is most important to test, which means your penetration test scope covers the highest-risk areas rather than whatever the tester happens to find first. In practice, many organizations do their first threat model after a penetration test reveals gaps they did not know to worry about — which is fine, but the test is less targeted as a result. The most efficient sequence: threat model first, use it to scope the pentest, use pentest findings to validate and update the threat model.

→ related

Need a threat model or pentest scoping session?

30-minute scoping call covers your architecture, your threat model (if you have one), and how to scope a test that covers the highest-risk areas first.

Book a 30-min scoping call Advisory retainer

What is threat modeling?

What a threat model gives you.

Attack surface inventory

Threat list

Gap analysis

Countermeasure recommendations

Threat modeling and penetration testing

STRIDE, PASTA, and other frameworks

Frequently asked questions.

More on methodology and scoping.

Penetration testing

Advisory retainer

Red team operations

Red team objectives that test what matters

Need a threat model or pentest scoping session?