Architect · Secure by design
We do not sell you a workshop and a PDF. We stand up threat modelling as a working practice: your priority systems modelled with your engineers in the room, a design review process with named triggers and sign-offs, and a threat library your team keeps building after we step back.
Scope agreed in writing before any work. No obligation.
Every design lands on one senior engineer's desk and waits. The practice never scales because it lives in one head. We turn the implicit method into an explicit process your whole team can run, with security judgement spent where it matters.
SOC 2, ISO 27001, and serious customer security reviews all reach the same question: how do you secure systems at design time? A working threat modelling practice, with records, is the answer that holds up. A policy that says you do it is not.
New agency, new trust boundaries, new failure modes. Teams shipping LLM features need the design review muscle most at exactly the moment their old process stops fitting. We tailor the method to cover model, data, and tool-call risks alongside the classics.
What you are commissioning
One named engagement from the Architect track backs this page. What it includes and what you hold at the end are fixed in the service schedule before work starts.
Architect track3–5 weeks
A working threat modelling practice: your systems modelled, your engineers trained on the method, and a design review process that keeps running after we leave.
Best for engineering organisations that need design-time security to become routine, not a heroic one-off.
Includes
Deliverables
The method
Training on a fictional pet store does not transfer. We model your two to four highest-priority systems, with the engineers who own them in the room, so the method is learned on architecture people actually care about.
STRIDE-per-element as the spine, tailored to your stack and tiering: what triggers a review, how deep each tier goes, and who signs off. The output is a process document your team follows, not a methodology lecture.
Threats and mitigations from the first models are generalised into a reusable library, so the second team starts from precedent instead of a blank page. This is the difference between a practice and a series of events.
The last fortnight is deliberately ours-to-yours: your security team facilitates, we observe and coach. We leave when the practice runs without us, and the playbook stays either way.
Where the platform fits
The practice works on whatever tooling you have. Teams that want the models to live with the architecture, feed controls and risk, and carry sign-offs run it on Alvor's Secure by Design module; the engagement does not require it.
Questions
Both, in sequence. The first models are facilitated by us with your engineers contributing the system knowledge; by the final models your team is facilitating and we are coaching. The goal is a practice you own, not a dependency on us.
STRIDE-per-element as the foundation, because it is teachable and produces consistent results, with privacy (LINDDUN-style) and AI-specific extensions where your systems need them. The methodology is tailored during the first week; you are not buying a template.
Two to four priority systems in a typical 3–5 week engagement, depending on their complexity and your team's availability. Breadth is deliberately capped: the objective is a repeatable practice and a seeded library, not a heroic sweep of the whole estate.
Yes. Threat modelling records are direct evidence for design-time control obligations: controls commensurate with threats across the asset life-cycle under CPS 234, and secure development controls under ISO 27001 Annex A. The process document and completed models are written to be shown to an auditor or regulator.
One conversation, then the scope and the price in writing. Your enquiry arrives already marked for threat modelling.