Bearbeitungsreglement (VDSG Art. 5)

English summary. Under Art. 5 VDSG (the implementing ordinance to the revised Swiss Data Protection Act), a private controller must maintain a Bearbeitungsreglement — an internal processing regulation — for automated processing that either (a) involves frequent/large-scale processing of "besonders schützenswerte Personendaten" (the narrow, enumerated special categories under Art. 5 lit. c revDSG: health, intimate sphere, religious/philosophical/political/union views, genetic or biometric data, administrative or criminal sanctions, welfare-assistance measures), or (b) constitutes high-risk profiling under Art. 5 lit. g revDSG (automated evaluation of personal aspects used to assess something like a person's performance, financial situation, reliability, or behavior, in a way carrying a high risk to personality or fundamental rights). This document makes that determination explicitly for Stratify's financial-signal-delivery processing rather than leaving it silent, and — regardless of the determination — provides the full Bearbeitungsreglement content required by Art. 5, both because good governance doesn't wait for a legal trigger and because this document is part of Stratify's sales-enablement/readiness collateral for institutional counterparties. This is not an equivalent of any existing document; unlike PRIV-01/02/04/05/06 it is genuinely net new.

Der folgende Text ist auf Deutsch verfasst, da das Bearbeitungsreglement primär für den EDÖB und allfällige Schweizer Aufsichtsbehörden bestimmt ist — konsistent mit der bestehenden Konvention in docs/compliance/regulatory-roadmap-ch-eea.md und docs/compliance/dsgvo-data-flow.md, Deutsch für CH-Behörden-adressiertes Material zu verwenden.

1. Geltungsbereich

Dieses Reglement gilt für alle automatisierten Personendaten-Bearbeitungen von wait, what. Advisory (Controller of Record für das Stratify-Produkt, bis zur Gründung einer separaten Stratify AG/GmbH — register/facts.md "Entity") im Rahmen des Stratify-Produkts: Web, Mobile und B2B-API. Es ersetzt nicht, sondern ergänzt docs/compliance/dsgvo-data-flow.md, das die materielle Datenfluss-Map führt; dieses Reglement zitiert dessen §§2, 4–5, 9 statt sie zu duplizieren.

2. Schwellenwert-Bestimmung (Art. 5 VDSG) — die eigentliche Feststellung

Feststellung: Der Schwellenwert von Art. 5 VDSG ist zum heutigen Zeitpunkt (Pre-Seed, bewilligungsfreie Research-Publikation) nicht eindeutig erreicht. Begründung, Kategorie für Kategorie:

Art. 5 lit. c revDSG (besonders schützenswerte Personendaten): Finanz-/Anlagedaten fallen

nicht in die abschliessend aufgezählten Kategorien (Gesundheit, Intimsphäre, religiöse/ weltanschauliche/politische/gewerkschaftliche Ansichten, genetische/biometrische Daten, verwaltungs-/strafrechtliche Sanktionen, Sozialhilfemassnahmen). Die von Stratify verarbeiteten Daten — Mandat-Wahl, Signal-Zustellung, Abonnement-Status — sind Finanzverhaltensdaten, aber keine besonders schützenswerten Personendaten im gesetzlichen Sinn.

Art. 5 lit. g revDSG (hochriskantes Profiling): Profiling im Sinn der Norm setzt eine

automatisierte Auswertung persönlicher Aspekte pro betroffener Person voraus, die zu einer personalisierten Einschätzung führt. Stratifys Signale sind explizit 1:N — dieselbe Mandats-Empfehlung geht an alle Abonnenten eines Mandats, ohne individuelle Anpassung (dsgvo-data-flow.md §8, dieselbe Begründung, mit der dort bereits die DSFA-Pflicht nach Art. 35 DSGVO / Art. 22–23 revDSG verneint wird). Ohne Personalisierung liegt kein Profiling im Rechtssinn vor, erst recht kein hochriskantes.

Grössenordnung/"häufig": Selbst wenn eine der beiden Kategorien knapp erreicht würde, ist die

Verarbeitung nach Nutzerzahl, Datenvolumen und Reichweite (Pre-Seed, Schweiz-fokussiert) noch nicht in einer Grössenordnung, die "häufig" im Sinn der Norm auslöst.

Konkreter Auslöse-Punkt, der diese Feststellung kippt: Phase C des Produkts (README.md, "Phase C") führt eine MiFID-II-Suitability-Engine, KYC und Stripe-Connect-Pilot-Payouts ein. Sobald Signale personalisiert werden — d.h. eine Empfehlung wird als für diese eine Person geeignet dargestellt, gestützt auf deren Finanzlage/Risikoprofil — ist Art. 5 lit. g klar erfüllt, unabhängig von der Nutzerzahl. Als ergänzender, grössenbasierter Trigger — mangels verbindlicher EDÖB-Zahl als eigene, vorsichtige Schätzung, keine Rechtsauskunft — schlägt dieses Dokument 10'000 aktive Abonnenten vor: Ab dieser Grössenordnung ist "häufige" Bearbeitung im Sinn von Art. 5 lit. c plausibel, selbst ohne Profiling-Element, und ein Reglement sollte spätestens dann als verbindlich (nicht mehr freiwillig) behandelt werden. Diese Zahl ist ein Ausgangsvorschlag zur Bestätigung durch Antonios/externe Kanzlei, keine feste Rechtsgrösse. Der Auslöser fällt mit der ohnehin in dsgvo-data-flow.md §8 vorgesehenen DSFA-Reevaluierung bei Phase C zusammen und sollte im selben Schritt geprüft werden.

Bis zu diesem Auslöser führt Stratify dieses Reglement freiwillig — als Governance-Vorgriff und als Bestandteil der Sales-Enablement-Dokumentation gegenüber institutionellen Partnern, die ein solches Reglement sehen wollen, unabhängig vom gesetzlichen Zwang.

3. Zwecke der Bearbeitung

Entspricht den in PRIV-01 tabellierten controller-seitigen Aktivitäten; hier auf Reglement-Ebene zusammengefasst:

Abonnenten-Kontoverwaltung und Mandat-Wahl
Zustellung von Research-Signalen (E-Mail, Push, Web) gemäss gewähltem Mandat
Zahlungsabwicklung (via Stripe, ohne eigenen Karten-/IBAN-Zugriff)
Pilot-Verwaltung (verifizierte Strategie-Autoren)
Audit-Protokollierung als Compliance-Nachweis
Produkt-Analytics und Fehler-Telemetrie (PostHog, Sentry)

Rechtsgrundlagen im Einzelnen: dsgvo-data-flow.md §3.

4. Organisatorische und technische Massnahmen

Verweis auf dsgvo-data-flow.md §9 (Zusammenfassung) und PRIV-04 (technisches Detail-Dokument, das genau diese Massnahmen ISO-konform aufschlüsselt: RLS-Zugriffskontrolle, Append-only-Audit-Log mit SHA-256-Chain-Hashing, OTP-Auth-Parameter, Tailscale-only-Firewalling). Dieses Reglement dupliziert diese Details nicht, sondern verweist darauf — konsistent mit dem Wrapper-Prinzip der gesamten privacy/-Dokumentenreihe.

5. Datenflüsse

Verweis auf dsgvo-data-flow.md §4 (Signal-Lebenszyklus) und §5 (Subscriber-Lebenszyklus) sowie §6 (Drittlandsübermittlungen). Zwei Korrekturen sind bei jeder Lektüre dieser Abschnitte mitzudenken, da das Quelldokument sie noch nicht nachgetragen hat: Hosting-Prozessor ist selbst-gehostetes Supabase auf Hetzner (nicht Vercel); Transaktions-/Broadcast-E-Mail-Prozessor ist AWS SES eu-central-1 (nicht Resend) — register/facts.md.

6. Aufbewahrung und Löschung

Verweis auf dsgvo-data-flow.md §2 (Retention-Spalte pro Datenkategorie) und die tatsächlich implementierten Lösch-/Export-Pfade (register/facts.md, "Data subject rights — actually implemented"): apps/web/lib/admin/gdpr-export.ts (Export), eraseSubscriberData in apps/web/app/(admin)/subscribers/actions.ts (Löschung/Anonymisierung, Compliance-getriggert). Der Löschvorgang selbst wird im Audit-Log als gdpr.erasure.completed festgehalten — der Nachweis der Löschung bleibt bewusst erhalten.

7. Rollen und Verantwortlichkeiten

DPO / Privacy Owner (Antonios): Eigentümer dieses Reglements, verantwortlich für die

jährliche Re-Evaluierung des Schwellenwerts (§2) und für die inhaltliche Pflege von dsgvo-data-flow.md.

ISMS Owner / Security Officer (Toby): Verantwortlich für die technischen Massnahmen (§4,

PRIV-04) und deren Umsetzung im Code.

Volle RACI-Tabelle: governance/GOV-03-roles-and-raci.md.

8. Review

Jährlich, sowie unmittelbar bei: Erreichen des in §2 genannten Auslöse-Punkts (Personalisierung oder ~10'000 aktive Abonnenten), jeder Änderung an dsgvo-data-flow.md §§2–9, oder einem Phase-C-Reevaluierungs-Ereignis gemäss dsgvo-data-flow.md §8.