Subprocessor-Ketten-Evidenz

Die Subprocessor-Liste im Vertrag ist tot, wenn niemand die echte Kette und Regionen kennt. Audit fragt nach Nachweis, nicht nach Absicht: welcher Dienst Daten sieht, in welcher Region, zu welchem Zweck — und wer eine neue Stufe in der Kette freigegeben hat.

Dieser Teil fordert Ketten-Evidenz auf der Assessment-Baseline aus Teil 2.

Anschluss an Compliance Essentials, Audit-Evidence Operating und Partner-Landschaft.

Vorher: Assessment-Baseline und Tiers. Weiter: AI-Vendor- und Model-Assurance.

zu welchem Zweck — und wer eine neue Stufe in der Kette freigegeben hat.

Lösung: Für Tier-1/2-Processor gelten eine aktuelle Subprocessor-Liste mit Zweck und Region, eine Änderungsnotiz mit Steward-Review, ein Flow-Mapping, eine Data-Owner-Entscheidung bei Ablehnung oder Ausnahme und die Custodian-Bestätigung der Residency-Claims.

In einem Satz: Keine Tier-1/2-Nutzung ohne aktuelle Kette, Regionen, Change-Notiz und nachweisbare Residenz.

Entscheidung

Für Tier-1/2-Processor gilt:

1. aktuelle Subprocessor-Liste inkl. Zweck und Region;
2. Änderungsnotiz mit Frist und Steward-Review;
3. Flow-Mapping (welche Daten erreichen wen);
4. Ablehnung/Exception mit Data-Owner-Freigabe und Ablauf;
5. Custodian bestätigt technische Erreichbarkeit/Residency-Claims.

Keine stille Nachziehung neuer Subprocessor in den Produktivbetrieb.

Ketten-Workflow

1. Vertrag vs. Betrieb

Steward legt Vertragsanhang und tatsächliche Integrationen nebeneinander. Artefakt ist eine Abgleichstabelle: Name, Zweck, Region, zuletzt gesehen, Quelle der Beobachtung. Der Custodian bestätigt, welche Endpunkte, Webhooks und Speicherorte im Stack wirklich existieren. Wird der Abgleich übersprungen, bleibt die Vertragsliste eine Absichtserklärung — und Audit findet die echte Kette in Logs, nicht im Ordner.

2. Regionen und Zwecke

Jede Zeile braucht beides: wofür der Subprocessor Daten sieht und wo er sie verarbeitet. Steward führt die fachliche Zweckzeile; Custodian prüft Residenz- und Admin-Pfade. Fehlt eines von beiden, ist die Kette unvollständig: Transfer- und Zweckbindung lassen sich nicht belegen.

3. Change-Prozess

Neue oder geänderte Subprocessor stoppen den stillen Go-live. Steward bewertet die Notiz gegen Tier und Flow; der Data Owner lehnt ab oder genehmigt eine befristete Ausnahme. Ohne diesen Gate zieht der Vendor die Kette nach, und das Assessment aus Teil 2 ist überholt, bevor die Wiedervorlage fällig ist.

4. Evidence packen

Die Kettenakte trägt Datum, Quelle, Reviewer und nächste Prüfung — plus Snapshot der Vendor-Liste, nicht nur den Link „siehe Website“. Custodian legt Config- und Residenz-Nachweise bei. Fehlt der Snapshot, ist die Evidence am Audittag schon veraltet.

5. Incident-Pfad

Wenn ein Subprocessor bricht oder eine Region driftet, muss die Notify-Kette stehen: Steward an Data Owner, an gebundene Consumer, an Privacy. Artefakt ist ein einseitiger Incident-Pfad mit Kontakten und Frist. Ohne ihn beginnt die Suche nach Zuständigkeit erst, wenn die Aufsicht schon fragt.

Handoffs

Anti-Patterns

• „Subprocessor siehe Website“ ohne Snapshot
• Änderungen nur jährlich lesen
• Flow unbekannt, Vertrag bekannt
• Ausnahme ohne Ablauf
• Kettenpflege nur durch Procurement

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. Für einen kritischen Processor Vertragsliste und Betriebsintegrationen vergleichen.
2. Change-Notice-Frist und Steward-Owner setzen.
3. Eine Region-/Zweck-Zeile je Subprocessor ergänzen.
4. Ausnahmeweg einmal testen.