Data Processing Agreement

Parties and roles

For personal data processed through the product, the customer is the controller and Toevan OÜ is the processor. The customer determines the purposes and means; Toevan processes only on the customer's documented instructions, of which this DPA and the Terms of Service are the initial set.

Customer-directed integrations are not sub-processing. Where the customer connects a third party of their own choosing (GitHub as the source of record, and Slack, Jira, Linear, or Kosli), Toevan sends data to that destination on the customer's instruction. Those providers are the customer's own processors under the customer's own agreements, not Toevan sub-processors. The same applies to the public Sigstore Rekor log, which the customer may opt into and which receives hash-only entries. This distinction is set out further on the Sub-processors page.

Subject matter and duration

The subject matter is the processing necessary to provide the service: connecting to the customer's repository, indexing and analysing source code, gating pull requests, and generating evidence. Processing continues for the duration of the subscription and ends on termination, subject to the deletion and return terms below.

Nature and purpose of processing

Toevan processes the customer's data to: index source code; construct the dependency graph; evaluate deterministic blueprints and constraints; gate pull requests; generate, sign, and store evidence and attestations; and, at the customer's option and per violation, generate suggested AI fixes. Processing is limited to what these purposes require.

Categories of personal data and data subjects

The service processes source code and its contents, which can contain personal data, and account data for the customer's users.

• Data subjects: the customer's engineers and other users who hold accounts, and any individuals whose personal data appears in the customer's source code, commit history, or test fixtures.
• Categories: commit author names and email addresses; any credentials, secrets, or tokens present in code; any personal data, including special-category data and PII, PHI, or PAN, that the customer's code or fixtures contain; and account identifiers (name, work email, authentication identifiers).
• Evidence contains personal data. Because evidence records capture what was analysed, they can include commit author identities and references to the personal data found in code. Toevan processes this only to provide the service and on the customer's instructions; the customer, as controller, holds the lawful basis for the underlying data.

Data-flow schedule (code egress)

This schedule is the authoritative statement of how the customer's source code moves through the service, and is identical in substance to the code-egress statement on the Security page.

Here is exactly how your source code moves through Toevan, and where it does not. The three paths below are the whole picture.

1. Deterministic analysis stays in your boundary

The core of the product is deterministic. Indexing, dependency-graph construction, blueprint evaluation, PR gating, and evidence signing all run on Toevan's own EU infrastructure (Hetzner, Helsinki). No third-party AI is involved in any of it. Your source code is processed transiently to produce the analysis and does not leave the Toevan boundary.

2. Optional AI features can send code-derived context to the LLM provider

Several optional AI features can send code-derived context, never your whole repository, to a large language model. Today these are: AI fix generation, which sends the code context for one specific violation; the architecture assistant and chat, which retrieve and send symbol identifiers (names, kinds, signatures, and paths) for the code your question touches; and, depending on configuration, code embeddings during indexing, which turn symbol text (names, kinds, paths, signatures) into vectors.

Today: these code-carrying calls route to OpenRouter, which routes them to Anthropic Claude models hosted in the United States. Code embeddings are the one exception whose destination depends on configuration: the default production configuration runs embeddings on an in-boundary EU model, and only a fallback routes them to the same provider. We state all of this plainly rather than imply code never moves.

Being implemented: all code-carrying calls (fix generation, the architecture assistant and chat, and any embedding calls that would otherwise leave the boundary) will route only to an EU-resident provider (Mistral, Devstral 2) under a zero-data-retention agreement, with no US fallback; if the EU route is unavailable the call fails closed rather than spilling over. Calls that carry no code may continue to use OpenRouter. The zero-data-retention agreement is pending signature; this route is not live yet.

Bring your own key (Team and above): you may configure your own LLM provider key, in which case these code-carrying calls use your own provider relationship, no code-derived context passes through Toevan's routing at all, and each routing decision is recorded in an audit log.

3. Evidence and attestations are yours, and verifiable offline

Evidence records and attestations are SHA-pinned and stored append-only in Toevan's EU store, and the same records are written to a toevan/evidence branch in your own repository, so a copy of the proof always lives where you control it.

Attestations are DSSE-signed with ECDSA P-256 (cosign-compatible) and can be verified offline with toevan audit verify and cosign verify-blob-attestation, with no call back to Toevan. They can optionally be anchored to Sigstore Rekor as hash-only entries: the existence of an attestation becomes publicly checkable, but your code and its content never do. Rekor anchoring is opt-in and off by default.

Sub-processors

Toevan engages the sub-processors listed on the Sub-processors page, which states each one's purpose, data categories, location, and status. The customer authorises these sub-processors by entering into this DPA.

Before adding or replacing a sub-processor, Toevan gives at least 30 days' advance notice by email, during which the customer may object on reasonable data-protection grounds. Email is the notice channel; subscribing to changes is described on the Sub-processors page. The binding wording of the objection-and-resolution process is [LAWYER].

International transfers

The customer's data is hosted in the European Union, which removes the transfer question for the deterministic analysis path entirely: it does not leave the EU.

The only paths that can transfer code-derived context outside the EU are the optional AI features: fix generation (the per-violation code context), the architecture assistant and chat (retrieved symbol identifiers), and, depending on configuration, code embeddings during indexing (the default production configuration runs these on an in-boundary EU model; a fallback routes them to the provider below). Today these code-carrying calls route to OpenRouter, which routes to Anthropic Claude models in the United States; the appropriate transfer safeguard for that path is [OWNER: confirm the transfer safeguard in place for the current OpenRouter to Anthropic US path, whether Standard Contractual Clauses or the provider data processing agreement].

EU secure provider path. An EU-resident route for all code-carrying (sensitive) calls is built into Toevan's own infrastructure and, when enabled, is enforced at the transport boundary that Toevan's own platform AI calls pass through: under this guardrail a code-carrying call resolves to an EU-resident provider (Mistral, Devstral 2) or, where the customer has configured one, the customer's own provider key, and fails closed rather than falling back to a US provider. While it is active, code-carrying calls that Toevan routes transfer no code-derived context outside the EU. The guardrail ships with a switch that is enabled together with the Mistral zero-data-retention agreement, which is pending signature; until that switch is enabled the current path above still applies, so this route is not live yet. Where the customer uses their own LLM key, no code-derived context passes through Toevan's routing and any transfer is governed by the customer's own provider relationship.

Technical and organisational measures

Toevan maintains the technical and organisational measures described on the Security page, which forms the TOMs annex to this DPA. In summary:

• Encryption. TLS at the public edge; column-level AES-256-GCM for sensitive credentials; envelope encryption with a wrapped key-encryption key for bring-your-own-key material; AES-256-GCM for OAuth tokens. Datastore-volume, backup, and integration-secret encryption are being hardened.
• Tenant isolation and access control. Shared Postgres schema with row-level organisation scoping enforced on every query; request-boundary authorization from organisation membership and audited support grants; fail-closed; a viewer read-only floor; per-organisation erasure.
• Credential handling. Customer credentials are validated live against the provider before storage and never returned to the client (only a masked last four characters are shown).
• Monitoring. There is no external error-tracking sub-processor. A self-hosted collector on Toevan's EU infrastructure, with SDK-level scrubbing of source, personal data, and secrets, is being implemented.

Retention of processed data

Toevan retains processed data only as long as needed to provide the service, on the following defaults. These are being made configurable knobs, and automated enforcement (auto-purge at the configured horizon) is being implemented; today evidence is immutable and retained for the subscription term.

• Product and customer evidence: three years by default. This is a floor, not a ceiling: on Enterprise it is configurable per customer and framework, and DORA-adjacent buyers who need five years or more can set that.
• Operational logs: 90 days.
• Security and audit logs: one year.
• Error-monitoring events: 30 to 90 days.
• Backups: rolling 30 days.

Account and website (controller) data retention, and the statutory retention of billing records, are covered by the Privacy Policy.

Personal-data breach notification

Toevan notifies the customer of a personal-data breach affecting the customer's data without undue delay, and in any event within 48 hours of becoming aware of it, and provides the information the customer reasonably needs to meet its own notification obligations. The binding wording of this clause and the information-to-be-provided list is [LAWYER].

Audit rights

The customer has the right to audit Toevan's compliance with this DPA, exercisable on reasonable notice and subject to confidentiality. The formal audit clause, including frequency, cost allocation, and the use of third-party reports, is [LAWYER].

As a supporting control, and not a replacement for these audit rights, the product's own evidence is offline-verifiable: the customer can independently verify signed evidence and attestations at any time using toevan audit verify and cosign verify-blob-attestation, without relying on Toevan.

Deletion and return of data

On termination the customer may request return of its data, and Toevan deletes the customer's data from active systems within a defined window, with erasure enforced per organisation. Backups age out on the rolling schedule above.

Evidence written to the toevan/evidence branch in the customer's own repository stays under the customer's control and is unaffected by deletion on Toevan's side, so the customer retains its proof after the relationship ends. The exact windows and the form of the deletion certificate are [LAWYER].

Processor obligations and confidentiality

Standard processor obligations apply: processing only on documented instructions, confidentiality commitments binding on personnel, assistance with data-subject requests and with the controller's obligations under Articles 32 to 36 of the GDPR, and prompt notice if an instruction appears to infringe data-protection law. The enforceable wording of these obligations is [LAWYER].

Liability and indemnities

The allocation of liability under this DPA, and any indemnities, are [LAWYER], and are read together with the limitation of liability in the Terms of Service.

Governing law

This DPA is governed by the laws of Estonia, and disputes are subject to the venue stated in the Terms of Service. The lead supervisory authority is the Andmekaitse Inspektsioon (the Estonian Data Protection Inspectorate).

How this DPA is provided

This DPA is published as a public, standard, signable document incorporated by reference into the Terms of Service, so a customer can review it during procurement without a request.

A signable PDF is available by printing this page to PDF: the print stylesheet renders a clean, chrome-free document suitable for signature. A hosted static PDF at a stable URL is planned; its location will be [OWNER: hosted signable DPA PDF URL, once generated].

Changelog

• v1.0.02026-08-25

  Initial draft: controller and processor roles with the customer-directed-integrations carve-out, subject-matter and purpose, data categories and subjects, the data-flow schedule (shared verbatim with the Security page), sub-processors with 30-day notice and a right to object, international transfers, the technical and organisational measures annex, retention defaults, a 48-hour breach-notice window, audit rights with offline verification as a supporting control, deletion and return, and Estonian governing law. Enforceable clause wording is marked [LAWYER] pending counsel.