Scope of this overview

terep is designed as a B2B, API‑first backend used by organizations to model systems, ingest Data Flow Diagrams (DFDs), build a System Knowledge Graph and generate STRIDE threat models. In most cases, terep acts as a processor (or service provider) on behalf of its customers, who remain controllers of their own data.

• • Applies to use of terep by customer organizations and their authorized users.
• • Focuses on backend and product‑related data; other websites or marketing properties may have separate notices.
• • Intended as illustrative content rather than a complete privacy policy.

Categories of data processed

The specific data processed in terep depends on how each customer configures and uses the platform. Typical categories for a threat modeling and STRIDE backend include:

• • Account and workspace data – names, work email addresses, roles and workspace metadata.
• • Authentication & access data – identifiers required to manage login, JWTs and role‑based access controls.
• • Modeling and system data – system definitions, DFD JSON, threat model snapshots and System Knowledge Graph metadata, as provided by customers.
• • Operational telemetry – audit logs, configuration changes, generation of threat snapshots, and workflow activity related to modeling and reviews.
• • Integration metadata – limited information necessary to connect to CI/CD systems, repositories, diagram exports or other tooling.

Customers should avoid sending sensitive personal data to the platform unless this is explicitly covered by agreement and necessary for the intended use.

How data is used

terep processes personal data primarily to deliver and secure the service, in line with customer instructions. Illustrative purposes include:

• • Providing access to workspaces and modeling capabilities appropriate to each user's role.
• • Sending operational notifications about modeling workflows, snapshot generation or platform changes (where configured).
• • Maintaining audit logs and security telemetry to help customers evidence activity and reviews over time.
• • Operating, maintaining and improving the platform in line with contractual terms.

Legal basis & roles

Under frameworks such as the GDPR, terep generally acts as a processor or service provider to its customers. Customers, as controllers, are responsible for establishing a lawful basis for their use of the service.

• • Processing is typically based on performance of a contract with customer organizations.
• • terep may also process certain data to comply with legal obligations or pursue legitimate interests related to security and service reliability.
• • Roles, responsibilities and data protection commitments are set out in the applicable Data Processing Addendum and customer agreement.

International transfers & sub‑processors

terep may rely on cloud infrastructure and service providers located in multiple regions. Customers can review and, where applicable, negotiate specific data residency needs during the sales and onboarding process.

• • Use of sub‑processors is governed by written agreements with appropriate safeguards.
• • Where applicable, standard contractual clauses or equivalent transfer mechanisms are used for cross‑border transfers.
• • A current list of core sub‑processors is typically made available through documentation or customer portals.

Individual rights

Data protection laws may grant individuals certain rights (such as access, correction or deletion). As a processor, terep generally acts on instructions from the customer controlling the data.

• • Individuals should first contact the organization that provided their data to terep.
• • Where required, terep will reasonably support customers in responding to rights requests.
• • Additional information is normally documented in the Data Processing Addendum and customer agreement.

Retention

Data is retained for as long as necessary to provide the service, comply with legal obligations and support customers' security and audit needs, subject to configuration and contractual terms.

• • Customers may configure certain retention approaches (for example, how long DFDs, threat snapshots or logs are kept), where available.
• • Backups and archives may contain data for additional periods in line with disaster recovery practices.