Based on the original article, “Threat modelling at the FT”, published by FT Product & Technology on Medium.
In this case, the Financial Times described how it embedded structured threat modelling into the day-to-day work of its engineering organisation. What makes the story notable is not simply the use of the Elevation of Privilege card game, but how it was positioned: as a practical mechanism to shift behaviour, strengthen cross-functional collaboration, and produce tangible security outcomes in a complex, evolving technical estate.
Context: A heterogeneous engineering landscape
The FT’s technology estate spanned modern cloud-native services, legacy components, data pipelines, publishing systems, subscription platforms and third-party integrations. Teams differed significantly in:
- Architectural domain knowledge
- Technology stacks and deployment models
- Security maturity and prior exposure to threat modelling
- Terminology and mental models of risk
As in many product-led organisations, security processes had historically relied on checklists, design reviews and periodic audits. These controls provided baseline coverage, but they struggled in three predictable ways:
-
Abstraction drift - Generic checklists rarely reflect the specifics of a service’s data flows, trust boundaries or business logic.
-
Engagement fatigue - Reviews can become performative if engineers experience them as gatekeeping rather than collaborative risk exploration.
-
Missed emergent risks - Rapid architectural evolution (microservices, APIs, SaaS dependencies, CI/CD automation) introduces threat patterns that static review artefacts do not easily capture.
For senior technical leaders, this is the central tension: governance must scale, but security insight is inherently contextual. The FT recognised that a different interaction model was required.
Reframing threat modelling as a collaborative exercise
Rather than introducing heavier documentation or more formal sign-offs, the FT adopted a facilitated, game-inspired session built around Elevation of Privilege (EoP). Crucially, the game mechanics were not the objective; they were a catalyst.
The format included:
-
A pre-prepared system diagram, agreed in advance, showing components, integrations and data flows.
-
A cross-functional group of at least three participants, typically spanning engineering, product and security.
-
A facilitator who explicitly set expectations: this is not a compliance check, and it is not a blame exercise. It is a structured exploration of how the system could fail under adversarial pressure.
The system diagram functioned as a shared artefact, effectively the “board”. Each EoP card (mapped to STRIDE categories) introduced a concrete attacker scenario, such as credential reuse or tampering with data in transit. Participants were asked not whether the threat category applied in theory, but where it might realistically manifest in their architecture.
This subtle shift, from abstract category to architectural anchor, changed the tone of the discussion. Engineers reasoned about real services, real APIs, and real identity boundaries.
What actually changed in practice
From an engineering leadership perspective, three behavioural changes were particularly significant.
1. Engineers developed adversarial fluency
Threat modelling often fails because it requires engineers to “think like attackers” without scaffolding. The EoP prompts provided that scaffolding. Instead of asking, “What are the threats?”, the facilitator presented a concrete provocation.
Over time, teams became more comfortable tracing attacker pathways across services, identifying trust boundary violations, and questioning implicit assumptions (e.g. “This internal service is trusted” - but why?).
This is not merely educational; it improves design quality. Architectural conversations begin to include abuse cases alongside happy paths.
2. Cross-role dialogue improved
Security and engineering frequently operate with different mental models: one risk-oriented, the other delivery-oriented. By grounding discussion in a diagram owned by the team, the session redistributed authority. Security did not “audit” the system; instead, the team collectively interrogated it.
Facilitators made deliberate space for quieter contributors, reducing dominance by senior voices. In distributed sessions, the format was adapted for remote collaboration, demonstrating that structured engagement can survive beyond the physical room.
For senior leaders, this highlights an important principle: psychological safety is not incidental to security effectiveness - it is foundational.
3. Insights were operationalised
A common failure mode in threat modelling is the “interesting workshop” that generates no durable change. The FT avoided this by converting session notes directly into actionable backlog items, tracked in systems such as Jira.
This translation step matters:
- Identified threats became tickets.
- Mitigations were estimated and prioritised.
- Security work entered the same planning cadence as feature development.
This integration into normal delivery tooling prevented threat modelling from becoming theatre. It became a source of engineering work, visible and measurable.
Strategic implications for senior technical leaders
The FT case is not about adopting a specific card game. It is about embedding a repeatable cognitive practice. Several deeper lessons emerged:
Threat modelling must be situational.
Static control frameworks are necessary but insufficient. As architectures evolve, especially in cloud-native, API-driven environments, teams need a method to interrogate new trust boundaries and integration patterns.
Facilitation is a technical leadership skill.
The quality of output depended heavily on framing, neutrality, and inclusion. Organisations seeking to replicate the model should invest in developing internal facilitators rather than outsourcing the practice entirely.
Security adoption accelerates when it produces insight, not paperwork.
Engineers engaged because they learned more about their own systems. The exercise surfaced hidden coupling, undocumented assumptions, and overlooked data paths. That intrinsic value sustained participation.
A more mature view of game-based methods
There is sometimes scepticism about “gamification” in serious engineering contexts. The FT experience suggests a more nuanced interpretation.
The game mechanics provided:
- A bounded structure (time, prompts, turns).
- A psychologically safe format for raising uncomfortable scenarios.
- A way to equalise participation.
The seriousness of the output was not diminished. On the contrary, the structured prompts enabled more systematic exploration than unstructured brainstorming.
For senior engineering managers and heads of security, the takeaway was clear: the value lies in disciplined facilitation and integration into delivery workflows, not in novelty.
Conclusion
The Financial Times’ approach demonstrates how threat modelling can evolve from a compliance artefact into a collaborative engineering practice. By combining:
- Shared architectural artefacts
- Structured adversarial prompts
- Inclusive facilitation
- Direct conversion to backlog work
the organisation strengthened both security posture and cross-functional relationships.
For technology leaders operating in complex, fast-moving environments, this case illustrates that scaling security awareness is less about adding controls and more about improving how teams think, together, about the systems they build and the ways those systems can fail.
