Achieving a difficult goal like having a useful, always updated Threat Models requires resources and a good strategy. Requires also to divide the big challenge in smaller step, assess progress and, in the first place define the ultimate goal. To perform those activities a maturity models is the right tool. It defines the goal as the target maturity. It also defines a series to intermediate goals in the form of lower to higher maturity targets, and is fundamental to assess the advancement and the overall quality/maturity of the Threat Models. There are some great maturity models, for example OWASP SAMM, that helps assessing the maturity of different practices across secure development lifecycle (https://owaspsamm.org/model/design/threat-assessment/). I've personally worked on them with great results. But the granularity and details of the parameters to assess the maturity of secure design and threat model is not enough for defining a specific strategy for successfully Threat Model
Threat model steps Every entry in the following data will have an ID that can be referenced in the TM itself or by the tools processing the TM data. It is advisable to use unique identifiers in the breaded scope (company/product/component). For example, an ID would then have a structure similar to PPP.SSS.NNN where PPP is the project or product name, SSS is the section and NNN is the sequential inside the analysis. This is just a basic idea of an identifier that should help also to compose different TM into one by avoiding collision of IDs and to reference the same architectural components. Scope definition High-level security requirements/compliance level This will consist of a list of descriptive requirements. High-level security requirements are those that would exist before designing the software itself and are often business-related. Compliance like PCI-DSS, ISO-XXX, FEDRAMP, are examples of high-level security requirements that are better to capture at the beginning of the TM. ID