Supplier / Sub-Processor Onboarding & Review Procedure

Covers both bringing a new sub-processor into stratify's stack and reviewing the ones already there. Grounded in register/suppliers.yaml (12 real entries, seeded 1 August 2026) and docs/compliance/dsgvo-data-flow.md §10, which already tracks DPA links for six processors.

1. When this procedure triggers

• Onboarding: any time code is about to call out to a new third-party service that will process

stratify data — a new npm/pip package that talks to an external API with subscriber, partner, or operational data, a new hosting/infra vendor, or a new analytics/telemetry destination.

• Review: on the recurring cadence in §3, and immediately whenever a supplier's role, region, or

DPA status changes (e.g. a hosting cutover, a vendor swap).

2. Onboarding a new sub-processor

1. Data-protection screening. Before integrating, determine: what data categories from

dsgvo-data-flow.md §2 would reach this vendor; what region it processes/stores in; whether it is a genuine sub-processor (touches personal data) or a non_data_vendor.

1. DPA execution. Obtain the vendor's standard Data Processing Agreement (most SaaS vendors

publish one, e.g. https://<vendor>/legal/dpa) or negotiate one. Confirm it is executed/on file before real subscriber, partner, or pilot data flows to the vendor — not after.

1. Cross-border-transfer check. If the vendor's processing location is outside the EU/EEA,

determine the transfer mechanism (Standard Contractual Clauses, adequacy decision, or the EU-US Data Privacy Framework where applicable) and record it. Mirrors the treatment already given to Apple/Google/Expo push routing in dsgvo-data-flow.md §6.

1. Register entry. Add a SUP-nnn entry to register/suppliers.yaml with role,

data_processed, location, dpa_in_place, dpa_date, scc_required, last_review, and next_review populated — not left as placeholders.

1. Sign-off. Per governance/GOV-03-roles-and-raci.md §2 ("Supplier / DPA review": Antonios

Accountable + Responsible, Toby Consulted), Antonios approves the vendor before it goes live against real data. Toby, as the person who actually writes the integration code, is consulted on the technical data path so the screening in step 1 is accurate.

1. Update the operational document. Once approved, the vendor should also be added to

dsgvo-data-flow.md §1 and §10 — the ISO register and the operational document should not diverge on which vendors exist, only on format.

3. Reviewing existing sub-processors

dsgvo-data-flow.md §10 already states DPA links are "quartalsweise" (quarterly) reviewed by Antonios. This procedure formalises that into concrete steps, run once per quarter:

1. Open register/suppliers.yaml. For every entry with dpa_in_place: true, confirm the DPA link

still resolves and the vendor relationship is still active; update last_review to the review date.

1. For every entry with dpa_in_place: unknown or false, this is an open action, not a stable

state — pursue the DPA (§2 step 2) or explicitly accept the gap with a documented reason and a next_review date.

1. Record the review outcome for each supplier (confirmed current / DPA obtained / still open) in

register/suppliers.yaml's last_review/next_review fields — this file, kept under version control, is the evidence trail (schema.md's "git commit history satisfies review history").

1. Cross-check the register against the real integration list in register/facts.md's sub-processor

table — a vendor swap in code (like Resend → AWS SES) should trigger a review even outside the quarterly cadence; this cross-check is how a swap like that gets caught before it goes three months undetected in the operational document, as happened with the current backlog (§4).

4. Immediate backlog — clear this on first run of this procedure

Two suppliers postdate dsgvo-data-flow.md's last documented review (2026-05-19) and have never been reviewed at all:

• SUP-002, Hetzner Online GmbH. Became the actual infrastructure host on 2026-06-03

(register/facts.md) — the physical/hosting layer for the entire production stack, including Supabase itself. dpa_in_place: unknown. Action: locate Hetzner's standard Auftragsverarbeitungsvertrag (available via the Hetzner customer console / legal pages), confirm it's executed, and record the date. This is not optional — Hetzner did not exist in dsgvo-data-flow.md's processor table at all before the cutover.

• SUP-003, AWS SES (`eu-central-1`). Replaced Resend as the transactional-email vendor

(apps/web/lib/email/ses.ts, confirmed via no resend package remaining in apps/web/package.json). dpa_in_place: unknown. Action: confirm AWS's standard DPA (part of the AWS Customer Agreement / AWS GDPR Data Processing Addendum, available via AWS Artifact) covers SES, and record it.

Both reviews should happen before, or as part of, the next dsgvo-data-flow.md revision (PLAN.md Phase 4 closes both stale references in the same pass). Until then, suppliers.yaml's next_review field for SUP-002 and SUP-003 stays marked urgent.

SUP-004 (Resend) is kept in the register as a decommissioned, historical entry for audit-trail continuity only — no action needed on it; do not treat its dpa_in_place: true as describing a live relationship.

5. Evidence this procedure produces

• register/suppliers.yaml, with last_review/next_review dates updated on every pass — the

register itself is the evidence, per schema.md.

• Any newly obtained DPA (link or document) recorded against the corresponding SUP-nnn entry.
• A dated note when a vendor is added, removed, or its role/region/DPA status changes.

6. Review

This procedure's own cadence: quarterly, aligned to the review it defines. Revisit immediately if Stratify AG/GmbH incorporates (changing the controller entity referenced in supplier contracts) or if a new region of operation is added.