• Home
  • BVSSH
  • Engineering Enablement
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Practice : Threat Modelling Workshops

Purpose and Strategic Importance

Threat Modelling Workshops are collaborative sessions where cross-functional teams analyse systems to identify potential security risks, vulnerabilities, and trust assumptions. These workshops bring security thinking into the design phase, helping teams build safer systems by design.

By proactively anticipating threats and documenting mitigations, threat modelling improves architecture quality, fosters a security-first mindset, and aligns delivery teams with risk management goals - without slowing down innovation.


Description of the Practice

  • A threat model visualises a system, its components, data flows, and trust boundaries.
  • Teams ask structured questions such as: “What are we building?”, “What could go wrong?”, “What are we doing about it?”
  • Common frameworks include STRIDE, DREAD, PASTA, and kill chain analysis.
  • Workshops are typically run at key design points (e.g. new features, integrations, deployments) and include engineering, product, security, and operations.

How to Practise It (Playbook)

1. Getting Started

  • Choose a method that suits your team's familiarity (e.g. STRIDE for simplicity).
  • Schedule workshops at major design milestones or pre-release reviews.
  • Define the scope of each session - e.g. a feature, service, or integration.
  • Use diagrams (e.g. data flow, sequence, architecture) to ground discussion.

2. Scaling and Maturing

  • Train engineers and architects to lead or participate in workshops.
  • Use shared templates and tooling (e.g. Threat Dragon, IriusRisk, Microsoft Threat Modelling Tool).
  • Track findings and proposed mitigations as backlog items or architecture decisions.
  • Follow up during development to ensure mitigation strategies are implemented and tested.
  • Revisit threat models regularly as systems evolve.

3. Team Behaviours to Encourage

  • Make it inclusive - everyone’s input helps illuminate blind spots.
  • Treat it as design improvement, not a security audit.
  • Emphasise threat discovery over solution perfection.
  • Capture and share learnings to improve future workshops.

4. Watch Out For…

  • Turning workshops into compliance checkboxes with little reflection.
  • Too much focus on tools over conversation and critical thinking.
  • Lack of follow-up - models without mitigation are just drawings.
  • Security becoming siloed - missing perspectives from dev, ops, and product.

5. Signals of Success

  • Threats are discovered and mitigated early in the lifecycle.
  • Teams are confident in the security posture of their systems.
  • Security risks are reduced without blocking delivery.
  • Threat models are updated, maintained, and reused across the org.
  • Engineers feel empowered and skilled in threat thinking.
Associated Standards
  • Operational readiness is tested before every major release
  • Policy enforcement is automated across environments
  • Product and engineering decisions are backed by live data
  • Systems recover quickly and fail safely
  • Codebases consistently meet high standards of quality

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering