Key points
- The cheapest security work available: a design change costs hours, the same fix after launch costs weeks.
- Produces a living artefact — diagrams and an abuse-case register your team updates each quarter.
- Uses STRIDE plus attack trees, adapted to your architecture rather than a generic template.
- Outputs feed straight into your backlog as tickets with acceptance criteria.
Every vulnerability report contains findings that a two-hour design conversation would have prevented. Threat modelling is that conversation, held on purpose, written down, and turned into a prioritised list of controls before anyone writes the migration.
What the engagement covers
System decomposition
Data-flow diagrams covering every component, store, external dependency and the flows between them — drawn with your team, not from documentation that is out of date.
Trust boundary mapping
Where data crosses from untrusted to trusted, which component is responsible for validation at each crossing, and where that responsibility is currently assumed rather than assigned.
Threat enumeration
STRIDE applied per element — spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege — plus attack trees for the flows that carry money or personal data.
Abuse case register
Concrete misuse scenarios written as user stories, including the insider and the compromised-integration cases teams usually skip.
Control selection
A ranked list of controls with cost, effectiveness and the residual risk of skipping each one — so the trade-off is a decision rather than an accident.
Security requirements
The output written as backlog tickets with acceptance criteria, so security work is scheduled like everything else.
How it runs
-
01
Pre-read
Existing architecture material, ADRs and data inventory reviewed before anyone spends workshop time.
-
02
Diagram workshop
A 90-minute session where the system is drawn live with your engineers and product owner.
-
03
Threat enumeration
STRIDE and attack-tree analysis performed offline, then reviewed with the team.
-
04
Prioritisation
Risks ranked by likelihood and impact, and mapped to controls with an honest effort estimate.
-
05
Handover
Diagrams, register and backlog tickets delivered in editable form so the model stays alive.
-
06
Quarterly refresh
Optional: a short session each quarter to re-model what changed instead of letting the document rot.
What you receive
- Data-flow diagrams with trust boundaries (editable source files)
- Threat register with STRIDE classification and risk rating
- Abuse cases written as user stories
- Prioritised control list with effort estimates
- Security requirements as ready-to-import backlog tickets
- Architecture decision record for the choices made
Who this is for
- Products in design or major refactor
- Regulated domains: fintech, health, education
- Teams adding payments, AI features or third-party integrations
- Anyone about to rebuild authentication
Questions about this engagement
We have already built the product. Is it too late?
No. Modelling an existing system finds the structural gaps a point-in-time test cannot see, and it tells you which parts deserve testing budget first.
Who needs to attend?
One engineer who knows the architecture, one product owner who knows the rules, and anyone who owns infrastructure. Three people for ninety minutes is usually enough.
What do we get that we can maintain?
Editable diagrams and a register in your own tooling — Threat Dragon, draw.io or Markdown — plus a short guide to updating the model when the architecture changes.
Does this replace penetration testing?
No. Modelling predicts where weaknesses will be; testing proves which ones exist. Modelling first makes the test cheaper because the scope goes to the right places.