Threat modeling: this is how you map cyber threats before they strike

TL;DR: Threat modeling is a structured method for identifying security risks in systems and applications even before the first line of code is written. By systematically analyzing what can go wrong, which threats are realistic and which measures should be prioritized, you prevent costly vulnerabilities in production. NIS2 and the Cyber Resilience Act effectively make this approach mandatory for Belgian companies and software vendors by 2026.

Most companies don’t discover their vulnerabilities until it’s too late: during a pen test, after an incident or during a compliance audit. Threat modeling reverses that order. It maps threats during the design and planning stages, so you make security decisions when they cost the least and have the most impact. In this article, you will read what threat modeling specifically means, what frameworks are available, and why it has become indispensable for Belgian companies and software developers in 2026.

What is threat modeling and how is it different from a pen test?

Threat modeling is a systematic process in which you analyze the security of an application, system or network by answering four key questions: what are we building, what could go wrong, what are we doing about it, and is the result sufficient? The result is a structured overview of all potential threats, associated risks, and measures to mitigate those risks.

The fundamental difference from a penetration test is in the timing and approach. A pen test is detective: ethical hackers look for vulnerabilities in a system that is already built. Threat modeling is preventive: it identifies threats before they get into code. Both are valuable, but they complement rather than replace each other.

Why that distinction matters? According to research by IBM and the NIST, the cost to fix a security flaw increases exponentially as a project progresses. A vulnerability you fix in the design phase costs a fraction of what the same flaw would cost in production (estimates range from 6x to 100x more expensive). For a Belgian software company, that can mean the difference between a profitable project and a financial debacle due to emergency patching and reputational damage.

In practice, threat modeling and pentesting work best as a tandem. Threat modeling determines the strategy (where are the biggest risks?), a pen test validates the implementation (are those risks actually mitigated?).

The four most widely used threat modeling frameworks compared

There are dozens of frameworks for threat modeling, but four of them are particularly relevant for Belgian companies and software developers. The choice depends on your context: do you build software, manage IT infrastructure, or need to demonstrate privacy compliance?

STRIDE, originally developed by Microsoft, is the most widely used framework because of its simple structure. Each component of your system is analyzed for six threat categories directly linked to security properties such as authenticity, integrity and confidentiality. For development teams starting out with threat modeling, STRIDE is often the logical entry point.

PASTA (Process for Attack Simulation and Threat Analysis) takes a different approach: it starts from business objectives and works through seven phases toward concrete attack simulations. That makes PASTA particularly suitable for organizations that want to link threat modeling to their NIS2 compliance journey.

LINDDUN deserves special attention. Developed at KU Leuven, this framework focuses specifically on privacy threats. For Belgian organizations that need to demonstrate GDPR compliance, LINDDUN provides a structured way to identify privacy risks as early as the design phase. It is a rare example of a Belgian framework gaining international recognition.

OWASP Threat Modeling offers the most flexibility and aligns with the broader OWASP ecosystem that many development teams are already familiar with. Where STRIDE employs rigid categorization, OWASP is adaptable for modern architectures such as cloud applications, APIs and distributed systems.

The threat modeling process in five steps

Threat modeling need not be a weeks-long process. A structured session of half to a full day already yields concrete results. The process follows five logical steps.

Step 1: Define the system. Map out what you want to protect. That starts with a system diagram (also called a Data Flow Diagram) that visualizes all components, data flows, trust boundaries and external dependencies. For software teams, this is often the architecture diagram supplemented by information about what data is stored and processed where.

Step 2: Identify threats. Apply a framework (STRIDE, PASTA or other) to systematically analyze what might go wrong. This is not brainstorming by feel, but a methodical walk-through of each system component. With STRIDE, you ask yourself for each component: can someone impersonate someone else (Spoofing)? Can data be manipulated (Tampering)? And so on.

Step 3: Prioritize risks. Not every threat is equally critical. Use a prioritization model such as DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) to assign a score to each threat. This is essential for SMEs with limited budgets: you want to focus your resources where the risk is greatest.

Step 4: Determine mitigations. For each prioritized threat, define concrete measures: a technical control, a process modification or a deliberate risk acceptance. Document why you are or are not mitigating certain risks.

Step 5: Validate and repeat. A threat model is not a one-time document. With every significant change to the system (new feature, new integration, architecture change) repeat the analysis. Integrate threat modeling into your secure development lifecycle so that it becomes a regular part of the development process.

When is threat modeling mandatory? NIS2, CRA and ISO 27001

Threat modeling is not literally mentioned by name in the Belgian NIS2 law or the Cyber Resilience Act. But the requirements of both laws are hard to comply with in practice without a structured threat analysis.

NIS2 (Law of April 26, 2024): Article 21 requires essential and significant entities to take “appropriate and proportionate technical, operational and organizational measures” based on a risk analysis. That risk analysis must consider security in acquisition and development of systems, supply chain security and incident handling procedures. Threat modeling is the most effective way to meet these requirements at the application and system level.

In addition, the Belgian NIS2 law explicitly places responsibility on the governing body. Directors must approve cybersecurity risk management measures and can be held personally liable. Threat modeling here acts as a tool for due diligence: it demonstrates that management has proactively assessed risks. Read more about fines and director liability in our NIS2 guide.

Cyber Resilience Act (CRA): The CRA, effective December 2024, specifically addresses products with digital elements. Manufacturers and software vendors must conduct a security risk assessment during the design and development phase. The CRA also requires a Software Bill of Materials (SBOM), a machine-readable inventory of all software components including open-source libraries. Threat modeling uses the SBOM as input to evaluate the risks of external dependencies. The first CRA notification requirements are effective Sept. 11, 2026.

ISO 27001 and CyberFundamentals: CCB’s CyFun framework requires demonstrable risk analysis at the “Important” and “Essential” levels. Threat modeling refines the overall CyFun risk analysis by identifying specific technical threats that generic controls may not cover.

Threat modeling for SMEs: feasible or only for large companies?

A common objection among Flemish SMEs: “Threat modeling is something for large companies with a dedicated security team.” This is no longer true. Modern frameworks and tools have significantly lowered the threshold.

The key is proportionality. An SME with 80 employees does not need to set up a months-long threat modeling program. A focused half-day session, facilitated by an outside specialist, already provides a concrete threat overview for the most critical systems. The OWASP Rapid Developer-driven Threat Modeling (RaD-TM) project is specifically designed to accelerate the process through reusable “threat templates” and a simplified six-step process.

In addition, AI-driven tools are increasingly supporting the process. Platforms can automatically recognize patterns based on system diagrams that indicate specific threats and make real-time recommendations for security controls. According to recent data, deploying AI in security workflows can lead to significant savings in data breach costs.

Belgian SMEs also have a financial advantage. Through the VLAIO Cybersecurity Improvement Program, you can receive up to 50% subsidy on professional guidance, including threat modeling sessions. On top of that, the VLAIO SME Portfolio offers 45% subsidy (small enterprises) or 35% (medium-sized) on cybersecurity advice.

The ROI speaks for itself. The average cost of a data breach worldwide is about $4.88 million (IBM, 2024). A threat modeling session that catches one critical vulnerability in the design phase saves a multiple of the investment.

How Cyberplan deploys threat modeling

Cyberplan combines threat modeling with application pentesting and SDL consulting into an integrated approach. The team of 22 certified ethical hackers (OSCP, CISSP, CEH, CISM) maps threats, validates mitigations through targeted pen testing, and guides development teams in structurally building in security.

That combination is crucial. Threat modeling without validation remains theory. Pentesting without prior threat analysis is shooting with hail. The power is in the coupling: the threat model determines what is being tested, the pentest confirms whether the mitigations are working.

Wondering how threat modeling fits into your security strategy? View the threat modeling service or schedule a no-obligation consultation.

Frequently asked questions about threat modeling

What does threat modeling cost for an SME?

The cost depends on the scope and complexity of the system. A targeted session for a web application usually starts at a few thousand euros. Through the VLAIO SME portfolio, you can get up to 45% of those costs back as a subsidy, thus limiting the net investment.

How often should you update a threat model?

Update your threat model after every significant change: a new feature, an architecture change, a new third-party integration or a change in the threat landscape. For most SMBs, this means at least annually and with major releases.

Can our development team do threat modeling itself?

Yes, provided the team is trained in the methodology. Frameworks such as OWASP RaD-TM are specifically designed for developers to perform threat modeling independently. For the initial session and training, guidance from an outside specialist is recommended.

Does threat modeling replace a pen test?

No. Threat modeling and pentesting are complementary. Threat modeling identifies threats in the design phase (preventive), a pentest validates whether the built system is resistant to attacks (detective). Both are necessary for a complete security approach.

Is threat modeling mandatory under NIS2?

NIS2 does not mention threat modeling literally, but it does require risk analysis as a basis for security measures and “security in systems acquisition and development.” In practice, structured threat analysis is the most effective way to meet these requirements.

What is the difference between STRIDE and OWASP Threat Modeling?

STRIDE works with six fixed threat categories and is best suited for traditional software development. OWASP Threat Modeling is more flexible and provides better support for modern architectures such as cloud applications, APIs and microservices. Both are valid choices; the context determines which framework fits best.