Threat modelling
Threat modelling is the practice of reasoning systematically about how a system could fail, who would benefit, and what would matter if it did. It is best started before you build, and repeated whenever the architecture changes, which is why most of it in practice happens on systems already in production.
A working session produces four things: a diagram of the system with its trust boundaries drawn, a list of what an attacker would want from it, a list of the ways they could get it, and a decision about each one. Structure comes from a mnemonic such as STRIDE or from an existing attack catalogue, but the structure is scaffolding. The output that matters is the set of decisions, including the risks the business chose to accept and why.
The common failure is treating it as a one off document produced at design time and filed. Architecture moves, a new integration arrives, an internal service is exposed to a partner, and the model no longer describes the system. Tying a review to the change that triggers it keeps the model alive and keeps the attack surface honest.
In practice the models we are shown are usually built after the fact, on estates that have been running for years, and that is a legitimate use rather than a compromise. When a session is run well, the questions a tester would ask are already written down before anyone connects, which is exactly the point of the design review and threat modelling training we run.