SCC-/Tool-Mapping auf reale Flows

SCC und Transfer-Tools in einem Vertragsordner helfen nicht, wenn niemand den Flow benennen kann. Mapping verbindet Rechtsinstrument und Betrieb.

Dieser Teil definiert den Mindestvertrag zwischen Instrument, Tool-Pfad und Flow — auf dem TIA-Takt aus Teil 2.

Anschluss an Data Sovereignty, Compliance Essentials und Deletion that sticks.

Vorher: TIA- und Transfer-Impact-Takt. Weiter: Multi-Cloud-Residency-Ausnahmen.

In einem Satz: Kein materieller Transfer ohne Instrument, Tool-ID, Zweck und Custodian-Nachweis am selben Flow.

Entscheidung

Jeder materielle Flow hat vor dem Betrieb:

1. Transfer-Instrument (SCC, Angemessenheit, Ausnahme — benannt);
2. Tool-/Pfad-ID im Stack;
3. Datenkategorien und Zweck;
4. Steward-Owner und letztes Mapping-Review;
5. Custodian-Nachweis, dass der Pfad dem Mapping entspricht.

Kein „SCC irgendwo“ — das Instrument zeigt auf diesen Flow, nicht nur auf einen Vendor-Namen.

Mapping-Workflow

1. Flow inventarisieren

Der Steward erfasst Quelle, Senke und Zwischenstationen je materiellem Flow: Support-Export, HR-SaaS, Backup, Telemetrie. Jede Station trägt Systemname, Region und Empfänger. Der Custodian liefert die Job- und Connector-Liste aus dem Stack, nicht aus der Architekturfolie. Wird eine Zwischenstation weggelassen, gilt der Transfer als „EU-intern“, während Tickets über einen US-Subprocessor laufen.

2. Instrument zuordnen

Legal/Privacy benennen das Instrument je Flow: SCC-Modul und Version, Angemessenheitsbeschluss oder dokumentierte Ausnahme. Der Steward schreibt Instrument, Datum und Vertragslink in die Mapping-Tabelle. Ein SCC für „alle Cloud-Transfers“ ist kein Mapping. Fehlt der Flow-Bezug, ist das Instrument formal vorhanden und betrieblich unbrauchbar — der Auditor findet ein PDF, keinen Pfad.

3. Tool-Realität prüfen

Der Custodian legt Config-Snapshots und laufende Jobs neben die Mapping-Zeile: welche Connectoren, Replikate und Support-Exporte existieren wirklich. Abweichungen landen in einer Gap-Liste mit Flow-ID. Ohne diesen Abgleich bleibt das Mapping eine Folie. Wird die Tool-Realität übersprungen, überlebt ein Schattenpfad den Review — und die TIA beschreibt einen anderen Stack.

4. Abweichungen schließen

Der Data Owner entscheidet je Gap: Schattenpfad stoppen, formalisieren (Instrument + TIA) oder befristet ausnehmen. Der Steward tracked die Gap-Liste; der Custodian setzt Block oder Freigabe im Stack um. Offene Gaps ohne Entscheidung sind kein Mapping. Wird dieser Schritt übersprungen, entsteht ein zweiter Transfer neben dem dokumentierten — genau der, den die Aufsicht im Incident zuerst findet.

5. Review

Jeder Tool-, Region- oder Zweck-Change löst Remapping aus — derselbe Trigger-Katalog wie im TIA-Takt. Der Steward setzt Review-Datum und Mapping-Owner; der Custodian liefert den neuen Config-Snapshot als Evidence. Mapping ohne Review-Datum veraltet wie eine TIA ohne Cadence. Wird das Remapping übersprungen, zeigt die SCC auf ein Tool, das den Flow längst nicht mehr trägt.

Handoffs

Anti-Patterns

• Ein Standardvertragsklauseln für „alle Cloud-Transfers“
• Mapping nur auf Folien
• Neue Tools ohne Remapping
• Zwischenstationen weglassen
• verantwortliche Person = „Legal-Ordner“

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Compliance Essentials
• Lernpfad — Compliance Essentials

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Drei Flows mit Instrument, Tool-ID und Zweck tabellieren.
2. Einen Schattenpfad suchen, dokumentieren und dem Data Owner vorlegen.
3. Mapping-Owner und Review-Datum je Zeile setzen.
4. Config-Snapshot als Evidence ablegen und mit der Mapping-Zeile verknüpfen.