Security work goes wrong most often not because someone missed a vulnerability, but because nobody ever agreed what was worth protecting.
Threat modelling is the conversation that fixes that. It is not a document, and it is not a tool you buy. At its simplest it is four questions, asked out loud, by the people who actually built the thing.
What are we working on? Draw it. Badly is fine. The value is not the diagram, it is the argument that breaks out while you draw it, because that is when someone says "wait, does that talk directly to the database?" and the room goes quiet.
What can go wrong? Not "what CVEs exist" — what would a person want from this system, and how would they get it. Money, data, disruption, or a foothold to somewhere better. Name the attacker by motive, not by nationality.
What are we going to do about it? Every finding gets one of four answers: fix it, reduce it, transfer it to someone whose job it is, or accept it. Accept is a legitimate answer. An unwritten acceptance is not — that is just a thing nobody mentioned.
Did we do a good enough job? Come back to it when the system changes, because the model was true about a system that no longer exists.
The regional version of this is worth stating plainly. A bank in Erbil and a bank in Frankfurt do not share a threat model. The Frankfurt bank worries about organised fraud rings and regulators. The Erbil bank worries about those too, plus a fibre corridor that one machine operator can cut, plus staff who use one phone for work and family, plus the fact that its firewall terminates both the internet edge and the remote-access VPN.
Copying a threat model written somewhere else is how you end up defending against the wrong thing very thoroughly.
Start with one system, not the whole estate. Take the thing that would hurt most if it stopped, spend an hour on it with the people who run it, and write down what you decided to accept. That last part is the part that survives staff turnover.