Skip to content

Project Completeness Check

A completeness check ensures that a TTModeler project is fully 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.

The completeness 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 complete.

General Project Setup

A project is complete when its foundational information is defined and consistent.

  • Project Information is filled out (name, description, participants).
  • Project version reflects the current iteration.

Analysis Completeness

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 Completeness

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 Completeness

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 Completeness

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 Completeness

Before finalizing the project, 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.