of waiting to find vulnerabilities after development or deployment, teams assess how a system could be attacked and decide how to address those risks.

It is not a one-time document or a security tool. It is a structured process that examines the system, identifies potential threats, prioritises risks, and validates the controls in place.

This guide explains what threat modelling means, the main frameworks teams use, how the process works, and a simple example to help you understand it.

What Is Threat Modelling?

Threat modelling is a structured way to identify and assess security threats to an application, system, or environment. It helps teams ask four basic questions:

• What are we building?
• What could go wrong?
• What can we do about those risks?
• Have we addressed them effectively?

Threat modelling is usually most useful early in the development or design process, when teams can address security issues before they become expensive to fix. Microsoft also recommends using threat modelling during design to identify and mitigate security issues early.

Threat Modelling vs Vulnerability Assessment: What’s the Difference?

A vulnerability assessment looks at an existing system to find known security weaknesses, such as outdated software, misconfigurations, or exposed services. Threat modelling starts earlier and examines how an attacker could target the system based on its design, data flows, trust boundaries, and business requirements.

In simple terms, vulnerability assessment asks, “What is already vulnerable?”, while threat modelling asks, “What could go wrong, and how could an attacker exploit the system?” Both are important, but they serve different purposes. Threat modelling helps teams identify risks during design, while vulnerability assessments find weaknesses in existing systems.

How to Perform Threat Modelling: 5 Key Steps 

Threat modelling follows a structured process that helps teams understand the system, identify potential threats, prioritise risks, and validate security controls. The main steps are: 

Step 1: Map the System

The first step is to understand how the system works.

A simple data flow diagram can show:

• Users and external systems.
• Applications and services.
• Databases and other data stores.
• Data moving between components.
• Trust boundaries between different parts of the environment.

Trust boundaries are especially important because they show where data or access moves between areas with different trust levels.

For example, a web application may have a trust boundary between the public internet and the application server, and another between the application server and the database.

The diagram does not need to be complicated. It needs to accurately show the system and where trust changes.

Step 2: Identify Potential Threats

Once the team maps the system, it can identify what could go wrong.

A structured framework helps teams avoid relying only on assumptions or individual experience. One of the most widely used approaches is STRIDE.

STRIDE Framework

STRIDE is a Microsoft threat classification model that groups common security threats into six categories.

Threat	What It Means	Simple Example
Spoofing	Pretending to be another user or system.	Using a stolen session token to access an account.
Tampering	Changing data or code without authorisation.	Modifying a transaction during processing.
Repudiation	Denying an action when there is no reliable record to prove it.	A user changes data but the system does not record who made the change.
Information Disclosure	Exposing information to unauthorised users.	An API returns customer information that the user should not be able to access.
Denial of Service	Preventing legitimate users from accessing a service.	Flooding an application with requests until it becomes unavailable.
Elevation of Privilege	Gaining more access than the user or system should have.	A normal user gaining administrator access through a security flaw.

Teams can apply STRIDE to the different components, data flows, and trust boundaries shown in the system diagram. Not every threat will apply to every component.

Other Threat Modelling Frameworks

STRIDE is not the only way to approach threat modelling. The right method depends on the organisation, system, and required level of detail.

• PASTA: A seven-stage, risk-based approach that connects technical threats with business impact and attacker behaviour.
• Attack Trees: Start with an attacker’s goal and break it down into different ways to achieve it.
• VAST: Designed to make threat modelling easier to scale across large and agile development environments.
• Other approaches: Teams may also use asset-focused or attacker-focused approaches depending on their security requirements.

The important point is not to use a framework simply because it is popular. Choose an approach that your development, security, and business teams can actually use and maintain.

Step 3: Assess and Prioritise the Risks

A list of threats is not enough. Teams need to decide which risks require immediate attention.

A simple approach is to assess each threat based on:

• Likelihood of exploitation.
• Potential business impact.
• Ease of exploitation.
• Affected users or systems.
• Existing security controls.

Some organisations use formal scoring methods, while others use simple high, medium, and low risk ratings.

The result should be a prioritised list showing which threats need to be fixed before release, which need additional monitoring, and which risks can be accepted with a clear business decision.

Step 4: Decide How to Address Each Threat

Once the team prioritises threats, it needs to decide what to do with each one.

There are four common options:

• Mitigate: Add a security control or change the design to reduce the risk.
• Accept: Accept the risk after assessing its potential impact and documenting the decision.
• Transfer: Move some of the risk to a third party, contract, or insurance arrangement.
• Avoid: Remove the feature, component, or process that creates the risk.

The important part is to document the decision. A risk that is deliberately accepted is different from a risk that nobody identified or assigned to anyone.

Step 5: Validate the Controls

Threat modelling doesn’t end when the threat list is complete.

The team should check whether the planned security controls were actually implemented and whether they work as expected.

This is where threat modelling connects with technical security testing. For example, a penetration test or VAPT can help validate whether threats identified during the design stage can still be exploited in the actual environment.

A Simple Threat Modelling Example

Consider a customer login system for a financial services application.

The system includes:

• A user’s browser.
• A web application.
• An authentication service.
• A customer database.

The team creates a data flow diagram and identifies the trust boundaries between the public internet, the application, the authentication service, and the database.

The team can then use STRIDE to identify possible threats.

For example:

• Spoofing: Could an attacker bypass the login process or take over a user’s session?
• Tampering: Could an attacker modify session information?
• Information Disclosure: Could the login response reveal whether an email address exists?
• Denial of Service: Could repeated requests make the login service unavailable?
• Elevation of Privilege: Could a normal user gain administrator access?

The team then ranks these threats and decides which controls are required.

For example, it may add stronger session controls, rate limiting, generic login error messages, and stricter database permissions.

The important point is that these risks are identified during design rather than after an incident.

Why Threat Modelling Matters

Threat modelling helps organisations make security decisions before vulnerabilities become incidents.

It can help teams:

• Identify security risks early.
• Find weaknesses in system design.
• Prioritise security controls.
• Reduce expensive design changes later.
• Improve communication between development and security teams.
• Connect security risks with business impact.
• Validate that security controls address the identified threats.

Microsoft notes that finding security issues during design can make them easier and more cost-effective to address.

Threat modelling is also useful beyond software development. NIST describes it as a form of risk assessment that can be applied to data, applications, hosts, systems, and environments.

How Often Should Threat Modelling Be Done?

Threat modelling should not be treated as a one-time activity.

Teams should review the model when there are meaningful changes, such as:

• A new application or major feature.
• A change in system architecture.
• A new third-party integration.
• A change in data flows.
• A new cloud service.
• A major change in authentication or access controls.

For organisations using agile development, threat modelling can also be incorporated into the development lifecycle rather than being left until the end of a project. OWASP recommends performing it as early as possible in the software design process and revisiting it as systems change.

How We Support Threat Modelling

Threat modelling works best when it is connected to the rest of the security programme. Our team helps organisations identify threats during application and architecture reviews and then validate those risks through practical security testing.

We can help you:

• Build threat models for applications and systems.
• Identify threats using approaches such as STRIDE and attack trees.
• Assess risks based on business and technical impact.
• Review security controls and mitigation plans.
• Validate identified threats through penetration testing and VAPT.
• Connect threat modelling findings with wider security and risk programmes.

Our technical services team can help move identified threats from design discussions into practical security testing and remediation.

For organisations that want to connect threat modelling with broader governance and risk management, our GRC services can help track identified risks, assign ownership, and monitor remediation.

Conclusion

Threat modelling helps organisations identify security risks before they become security incidents. By mapping the system, identifying threats, prioritising risks, implementing controls, and validating those controls, teams can make security part of the design rather than adding it later.

Treat it as an ongoing process. As applications, integrations, data flows, and architectures change, threat models should be reviewed and updated to reflect the environment’s actual security risks.

FAQs

1. What is threat modelling in cybersecurity?

Threat modelling is a structured process for identifying potential security threats, assessing their risks, and deciding how to address them.

2. How is threat modelling different from vulnerability assessment?

Vulnerability assessment finds existing security weaknesses, while threat modelling looks at how an attacker could target a system based on its design, data flows, and trust boundaries.

3. What are the main steps in threat modelling?

The main steps are mapping the system, identifying threats, prioritising risks, deciding how to address them, and validating the security controls.

4. How often should threat modelling be performed?

Review threat models whenever there are major changes to the application, architecture, data flows, cloud services, or access controls.