Project Maturity Check
A maturity check ensures that a TTModeler project reached a certain level, i. e., it is satisfactorily defined, internally consistent, and ready for review, audit, or export. This page describes all areas that should be verified before finalizing a threat model or generating reports.
Important
A threat model is never fully complete. It represents the best available understanding of a system at a given point in time. Because systems, requirements, architectures, and threat landscapes evolve, the threat model must be continuously reviewed, updated, and refined.
Threat modeling is an iterative lifecycle activity, not a one‑time deliverable. Throughout the entire product lifecycle - from initial design to deployment, maintenance, and decommissioning - the threat model must be maintained to ensure that identified risks, mitigations, and assumptions remain valid.
The maturity check is structured into the following sections:
- General Project Setup
- Analysis
- Modeling
- Risk Assessment
- Mitigation
- Documentation & Outputs
Each section contains concrete criteria that must be fulfilled for a project to be considered mature.
General Project Setup
A project is mature when its foundational information is defined and consistent.
- Project Information is filled out (name, description, participants).
- Project version reflects the current iteration.
Analysis Maturity
The analysis phase defines the context and assets that drive the modeling and risk assessment.
- All Assumptions are reviewed and validated.
- All relevant Use Cases are identified.
- For each use case requiring data flow analysis, a Data Flow Diagram exists.
- Assets are defined and classified according to protection goals (Confidentiality, Integrity, Availability, etc.).
- A System Overview including actors, external interfaces, and trust boundaries is created.
- Threat Sources including their capabilities are documented.
- System Threats are identified.
Modeling Maturity
The modeling phase must accurately represent the system architecture and its security‑relevant properties.
- All required Diagrams (hardware, software, data flow) are created.
- All diagram elements have their properties reviewed and updated.
- Elements that process, store, or transmit assets have assigned assets.
- All component‑specific Questionnaires are answered.
- Supply‑chain components and third‑party services are included in the model.
- No unused, unconnected, or orphaned elements remain.
- Cross‑diagram consistency is ensured (naming, interfaces, trust boundaries).
- Relevant regulatory or customer‑specific Checklists (e.g., CRA, IEC 62443) are selected if applicable.
Risk Assessment Maturity
The risk assessment must cover all relevant threats and provide a clear, justified risk picture.
- All (generated) attack scenarios have an applicability Status.
- Each scenario is linked to affected system threats and assets.
- Risk is evaluated (risk before mitigation).
- Remaining risk is optionally rated.
- Each scenario has the Treatment Status 'Passed'.
- Scenarios not passing treatment have a justification in the risk notes.
- No asset or interface remains without at least one evaluated attack scenario.
Mitigation Maturity
Mitigations must be defined, evaluated, and traceable to requirements.
- All applicable Countermeasures are defined.
- All (generated) countermeasures have an applicability status.
- Countermeasures are linked to the attack scenarios they mitigate.
- Mitigations are transferred or synchronized with the requirement engineering tool for Traceability (e.g., hyperlinks are used).
- Every scenario with “Mitigate” treatment has at least one assigned countermeasure.
Documentation & Output Maturity
Before finalizing the current project iteration, all outputs must be complete and consistent.
- The project change log is updated.
- No temporary placeholders (“TODO”, “TBD”, internal notes) remain.
- Required reports (Default Report or Export) are generated.