Threat-modeling that actually drives tests

Most organisations treat threat modeling and penetration testing as separate activities. The threat model sits in a document nobody reads, while the pentest follows a generic checklist. This disconnect wastes resources and leaves blind spots.

The problem with disconnected threat models

A threat model created in isolation often ends up as a compliance artifact rather than a living security tool. It lists theoretical threats without prioritising them based on your actual attack surface. Meanwhile, penetration testers follow standard methodologies without understanding which assets matter most to your business.

Connecting threat models to test plans

The key is making your threat model the direct input for your penetration testing scope and methodology. Here's how we approach it at Cypra:

1. Asset-centric modeling

Start by identifying your crown jewels — the data and systems that would cause the most damage if compromised. For a manufacturing company, this might be production control systems and customer order databases. For a financial services firm, it could be transaction processing systems and client portfolios.

2. Attack tree decomposition

For each critical asset, build attack trees that map realistic paths an attacker could take. Each leaf node becomes a potential test case. This ensures your penetration test covers the scenarios that actually matter, not just the ones that are easy to test.

3. MITRE ATT&CK mapping

Map each branch of your attack trees to MITRE ATT&CK techniques. This provides a common language between threat modelers and penetration testers, and helps identify gaps in detection coverage.

4. Risk-ranked test prioritisation

Not all attack paths are equal. Rank them by likelihood and impact, then allocate testing time accordingly. A SQL injection path to your payment database deserves more attention than a theoretical physical access scenario.

Practical implementation

At the start of every engagement, we conduct a focused threat modeling workshop with the client's technical and business stakeholders. The output is a prioritised list of attack scenarios that directly becomes our test plan.

This approach consistently uncovers more business-critical vulnerabilities than checklist-based testing, because we're testing the paths that matter most to your organisation.

Key takeaways

• Connect your threat model to your pentest scope — they should be the same document
• Focus on assets, not just vulnerabilities — test what matters to your business
• Use MITRE ATT&CK as a common language between threat modeling and testing
• Prioritise by business impact — allocate testing time where it matters most
• Update continuously — threat models should evolve with your architecture