← Ataski · Trust & security · DPA · Subprocessors

This is the canonical English version. Native translations for DE / ES / FR / PT / RU are pending counsel sign-off.

Approved 2026-10-08

Vendor Management Policy

Owner: the founder. Approved: 2026-10-08. Review: annually, plus on every vendor addition or removal.

1. What counts as a vendor

Anything that processes Customer Data on Ataski's behalf is a sub-processor and must appear on the published list. Anything that does not touch Customer Data is a supplier, and is not listed — the list reflects what actually processes bytes, not what appears on an architecture diagram. Doppler is the worked example: it is in the long-term stack but sees no Customer Data today, so it is deliberately absent from the list. If it ever comes to process Customer Data, it is added to the list at least 30 days before the change that sends it any (§3, step 6).

2. The list is code

src/ataski/legal/subprocessors.py is the single source of truth. Each entry carries the vendor's legal entity name (customer counsel traces by entity, so Anthropic appears as "Anthropic, PBC", not "Claude"), the purpose in one customer-readable sentence, the country plus the data-centre jurisdiction where they differ, the vendor's own DPA URL, and the data categories that vendor actually sees — not everything we collect.

The tuple order is contract surface. The list is SHA-256 fingerprinted, and the fingerprint is stored on every DPA signature row, so a change is detectable against exactly what each customer accepted. Reordering counts as a change.

3. Adding a vendor

  1. Approval first. A new external service is a founder decision, recorded as an ADR (see the ADR-0044 / 0045 / 0046 / 0047 / 0048 vendor-approval series for the shape).
  2. Two standing constraints. Data vendors must be true pay-as-you-go — no monthly minimum (one-time deposits and free tiers are fine), per ADR-0035 — and nothing may put Ataski in a data-broker posture: no email-finder vendors, no aggregation or resale of contact PII, per ADR-0037.
  3. Back-to-back terms. The vendor's own DPA must be in force and its URL recorded in the entry. Where the vendor is outside the EEA, the transfer basis is covered by docs/legal/transfer-impact-assessment.md.
  4. Then edit the list, re-run the fingerprint test, move the effective date in ataski.legal.effective_dates, and paste the new digest there. A list change that leaves the date behind publishes a false "unchanged since".
  5. Notify. 30 days' prior notice by in-app banner and e-mail to the workspace admin, per Article 28(2)(a) general authorisation; the customer may object on reasonable grounds inside that window.
  6. Then, and only then, send it data. A new sub-processor is published on the list at least 30 days before it receives any Customer Data. The 30 days run from the day the updated list is live on /legal/subprocessors and the notice in step 5 has gone out — not from the ADR, the contract or the merge. The pull request that wires the vendor into running code is merged behind a flag that stays off, or is not merged, until that date has passed; an objection received inside the window is answered before the flag is turned on. This is the order the DPA promises, and the only one in which the notice means anything: a vendor that already holds the data cannot be objected to.

4. Removing a vendor

Same mechanics in reverse, plus: confirm deletion of the data the vendor held, and record it. The retention policy's "vendor-side copies" table is the statement customers rely on, so it moves in the same change.

5. Periodic review

Annually, walk the list and for each vendor record: is it still used; has its DPA or sub-processor list changed; has it published a current SOC 2 or ISO report, and is a copy on file; has it had a breach in the period. Roughly three hours for the sixteen vendors on the list today.

This review has never been performed. That is stated in the readiness map rather than hidden, and it is the cheapest open item on the list.

6. Vendor incidents

Every vendor is under a written DPA obliging it to notify Ataski of its own breaches. A vendor-side breach affecting Customer Data enters docs/legal/incident-response-plan.md at the triage step exactly like any other detection — the 72-hour clock to affected Controllers starts when Ataski becomes aware, not when the vendor finishes its own investigation.

7. LLM providers specifically

Anthropic is the only LLM provider and a sub-processor with prompt and completion content in scope (ADR-0111; OpenAI is not used and is not a sub-processor). Customer data is not used to train models; provider-side copies exist for abuse monitoring only, at most 30 days. That statement rests today on Anthropic's standard commercial API terms — obtaining a written no-training / retention confirmation and filing it is an open item, and it is what an enterprise questionnaire will ask for. Langfuse holds trace content and is disclosed as such; it is not an inference provider.

8. What customers can see

The whole list, at /legal/subprocessors, with its digest and effective date; the same vendors summarised on /trust (/security redirects there); and each vendor's own DPA linked. There is no private list.