Teil 1
Processor in der Control-Kette
Vendor-Governance beginnt nicht mit einer unterschriebenen DPA. Sie beginnt mit der Entscheidung, welcher Processor welche Datenkategorien zu welchem Zweck verarbeitet — und wie die Kette, die AI-Zusage und der Exit nachweisbar bleiben.
Typische Fragen sind:
- Welcher Processor ist materiell — Support-SaaS, HR-Cloud, KI-API, Warehouse-Host?
- Welche Datenkategorien und welcher Zweck stehen im Assessment, nicht nur im Vertragstext?
- Welche Subprocessor-Kette gilt heute, und wer erhält die Änderungsnotiz?
- Welche Training-, Logging- und Output-Zusagen gelten, sobald ein KI-Feature Tickets verlässt?
- Welcher Nachweis (SOC-Bericht, Config, Löschbeleg) gehört zu unseren Kategorien?
- Was passiert am Ausstieg — Rückgabe, Löschbeleg, Continuity — bevor der letzte Vertragstag kommt?
Wenn DPA, SOC2-PDF und Feature-Toggle auseinanderlaufen, gilt der Vendor als „geprüft“, Procurement hat das Zertifikat, und Tickets landen in einem US-Modellhost. Das Problem ist nicht das Vendor-Portal. Es ist der fehlende Vertrag zwischen Assessment, Subprocessor-Kette, AI-Zusage und Exit-Evidenz.
Gute Processor-Assurance macht die Control-Kette ausführbar — Assessment, Kette und Exit am selben Vendor, nicht am neuesten Zertifikat.
Anschluss an Compliance Essentials, Audit-Evidence Operating und Partner-Landschaft.
Weiter: Assessment-Baseline und Tiers.
Die Serie Vendor- & Processor-Assurance gibt dir den Einstieg und den roten Faden. Die folgenden Teile vertiefen Assessment-Tiers, Subprocessor-Ketten, AI-Assurance und Exit so, dass Zweck, Rollen, Entscheidungen und Nachweise im Alltag nachvollziehbar bleiben.
Ausgangslage
Support hat eine DPA mit dem Ticket-SaaS. Die Subprocessor-Liste steht „on request“. Der Vendor schaltet ein AI-Feature; Gesprächsnotizen gehen an einen Modellhost. Procurement heftet den SOC2 ab. Der Exit-Plan lautet: „Am letzten Tag CSV ziehen.“ Internal Audit fragt nach der Kette, nach Training-Zusagen und nach dem Löschweg. Teams kaufen dann ein Vendor-Risk-Tool oder taggen den Katalog dpa=signed — und der nächste Feature-Toggle verlässt den Assessment-Scope.
Was diese Serie klärt
- Orientierung: Processor-Assessment, Subprocessor-Kette, KI-Dienstleister-Assurance, Ausstieg-Evidenz (diese Seite)
- Vertiefung: Assessment-Baseline und Tiers
- Vertiefung: Subprocessor-Ketten-Evidenz
- Vertiefung: KI-Dienstleister- und Model-Assurance
- Abschluss: Ausstieg, Evidenz-Transfer und Kontinuität
Begriffe und Kürzel vor dem Lesen
- Processor — verarbeitet personenbezogene Daten im Auftrag; sitzt in der Kontrollregel-Kette, nicht daneben. Ein unterschriebener Vertrag ohne betriebenes Assessment lässt ihn außerhalb der Kette.
- Controller — bestimmt Zweck und Mittel; der Business Owner bleibt accountable, auch wenn der Processor die UI betreibt.
- Assessment-Tier — Tiefe und Wiedervorlage nach Datenrisiko — kein Einheitsfragebogen für jeden SaaS.
- Subprocessor-Kette — bekannte Unterauftragsverarbeiter inkl. Region, Zweck und Änderungsnotiz. „Aktuelle Liste auf der Website“ ohne Notice-Pfad ist keine Kette.
- KI-Dienstleister-Assurance — Zusagen zu Training, Logging, Eval, Output-Retention und Modellhost, sobald GenAI oder Modelle in Umfang sind. Gewöhnliches SaaS-Assessment reicht nicht.
- Ausstieg-Evidenz — Rückgabe, Löschbeleg, Continuity-Pfad und Nachweis-Transfer vor Vertragsende. CSV am letzten Tag ist kein Ausstieg.
- Datenschutzvertrag — vertragliche Pflicht; sie ersetzt weder Assessment noch wirksame Kontrollregeln noch den Ausstiegsübung.
Lesepfad
- Processor in der Control-Kette
- Assessment-Baseline und Tiers
- Subprocessor-Ketten-Evidenz
- AI-Vendor- und Model-Assurance
- Exit, Evidenz-Transfer und Kontinuität
Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Vendor-, Klausel- und Toolnamen durch eure Procurement-, Catalog- und Prozessquellen.
zdem Tickets an einen unassessierten Modellhost, weil Assessment, Subprocessor-Kette und Exit nicht am selben Vendor hängen. Ein SOC2-PDF oder ein Katalog-Tag ersetzt weder Tier noch Löschbeleg.
Lösung: Processor-Assessment, Subprocessor-Kette, AI-Vendor-Assurance und Exit-Evidenz als Produkte mit Owner führen. Der Business Owner akzeptiert Residualrisiko; Privacy und Vendor-Risk führen das Assessment; Procurement steuert Vertrag und Notice; Custodian verdrahtet technische Controls.
In einem Satz: Assessment, Kette und Exit binden, bevor der nächste Feature-Toggle oder der letzte Vertragstag den Processor entscheidet.
Produkte und Entscheidungen
Assurance braucht nicht „eine Vendor-Datenbank“, sondern geschnittene Produkte.
Processor-Assessment
Dieses Produkt beschreibt:
- Processor-ID; Datenkategorien; Zweck; Regionen; Assessment-Tier; Wiedervorlage; Residualrisiko; Business Owner; Review-Datum.
Entscheidungen:
- Welcher Processor ist materiell genug für welches Tier?; Wer darf ein Assessment schließen — Privacy, Security oder der fachliche verantwortliche Person?; Welcher Nachweis zählt für unsere Kategorien, nicht für das Marketing-Zertifikat des Vendors?
Subprocessor-Ketten-Produkt
Die Kette ist kein Website-Link. Sie ist Notice plus Scope.
Es benötigt:
- bekannte Unterauftragsverarbeiter; Zweck je Knoten; Region; Änderungsnotiz-Pfad; Ablehnung oder Akzeptanz mit Datum.
Entscheidungen:
- Welche Änderung muss vor Produktivdaten ankommen?; Wer darf eine Kettenänderung akzeptieren oder den Flow stoppen?; Welche „on request“-Liste gilt als Lücke, nicht als Nachweis?
AI-Vendor-Assurance
Modelle und GenAI erben nicht das SaaS-Assessment.
Entscheidungen:
- Darf der Dienstleister mit unseren Daten trainieren — ja, nein, anonymisiert mit welchem Beleg?; Welche Logs und Outputs bleiben beim Dienstleister, und wie lange?; Welcher Modellhost und welche Eval-Zusage gelten, bevor das Feature produktiv wird?
Exit- und Evidence-Transfer
Exit wird geübt, bevor der Vertrag endet.
Entscheidungen:
- Welche Daten und welcher Nachweis müssen zurück oder gelöscht werden?; Welcher Continuity-Pfad gilt für den Fachbetrieb?; Wer nimmt Löschbeleg und Transfer als erfüllt an — und welches Datum ist der Drill, nicht der letzte Vertragstag?
Wo Governance hängt
Zwischen DPA-Unterschrift und betriebenem Assessment
Der Vertrag öffnet die Tür. Ohne Tier, Wiedervorlage und Residualrisiko sitzt der Processor außerhalb der Control-Kette.
Zwischen SOC2-PDF und eigenen Datenkategorien
Das Zertifikat spricht über den Vendor. Es spricht nicht über eure Tickettexte, HR-Felder oder Modell-Prompts. Evidence muss auf den Scope gemappt sein.
Zwischen „aktuelle Subprocessor-Seite“ und Notice
Ohne Änderungsnotiz kommt der neue Modellhost nach dem Feature-Launch. Die Website von gestern ist kein Kettennachweis für heute.
Zwischen AI-Toggle und Model-Zusagen
Ein Häkchen in der Vendor-UI ist ein Scope-Wechsel. Ohne Training-, Logging- und Host-Zusage ist das Assessment veraltet, sobald das Feature lebt.
Zwischen letztem Vertragstag und ungeübtem Exit
CSV ziehen, während der Zugang schon sperrt, ist kein Continuity-Plan. Rückgabe und Löschbeleg brauchen einen Drill mit Datum.
Zwischen Platform-Admin und Vendor-Owner
Wer SSO und die Tenant-Config setzt, entscheidet nicht Residualrisiko, Kettenakzeptanz oder Exit-Erfüllung.
Rollen-Mapping
Data Owner (Business / Process)
Head of Support, HR-Lead oder benannter Process Owner ist accountable für Zweck, Residualrisiko und die Entscheidung, den Processor produktiv zu nutzen. Der Owner entscheidet nicht die Rechtsformulierung der DPA allein.
Privacy / DPO
Bewertet Verarbeitungszweck, Rechtsgrund und Processor-Rolle. Der DPO ersetzt nicht den Business Owner für die Nutzung und nicht Procurement für die Klausel.
Vendor-Risk / Steward
Privacy Ops, Security-, Risk- und Compliance-Team oder Vendor-Risk führt Assessments, Ketten, Wiedervorlagen und die Assurance-Akte. Stewardship braucht Kapazität, nicht die Restzeit zwischen Fragebogen und Audit.
Procurement / Vendor Manager
Führt Vertrag, DPA-Verhandlung, Notice-Klausel und kommerziellen Exit. Procurement delivered den Hebel; sie ersetzen nicht die fachliche Risikoakzeptanz.
Data Product Owner
Priorisiert Assessment-Releases, Ketten-Index, AI-Zusagen und Exit-Drills. Nutzen und Lieferbarkeit — nicht die Auslegung der Klausel.
Data Architect
Schützt Identifier und Datenkategorien über die Vendor-Grenze, Lineage in Subprocessor-Knoten und Breaking Changes, wenn dasselbe Produkt ein Modellhost wird.
Data Custodian
IAM, Platform und Integration setzen SSO, Scopes, Logging und technische Sperren um. Konfigurationsmacht ist keine Vendor-Verantwortung.
Audit / Assurance Consumer
Internal Audit und Control Owner empfangen die Akte. Sie erfinden keine parallele Spreadsheet-Kette.
Mini-Fall
Symptom: Der Datenschutzvertrag ist unterschrieben. Unterauftragnehmer werden nur „auf Anfrage“ genannt. Eine KI-Funktion sendet Notizen an einen Modellanbieter. Der Sicherheitsbericht liegt beim Einkauf. Für den Ausstieg ist nur „Tabellenexport am letzten Tag“ vereinbart. Das Audit fragt nach Dienstleisterkette, Trainingsnutzung und Löschweg.
Typischer Fehlstart: Dienstleister-Risiko-Plattform kaufen und dpa=signed taggen, ohne Tier, ohne Notice-Pfad und ohne Ausstiegsübung.
Vereinbarung: Assessment-Tier mit Kategorien, Zweck und Residualrisiko; Subprocessor-Kette mit Notice; KI-Zusagen (Training, Logging, Host) vor Feature-Produktiv; Ausstieg-Evidenz mit Rückgabe, Löschbeleg und geübtem Continuity-Datum.
Kritische Übergaben
| Von | An | Artefakt |
|---|---|---|
| Business Owner | Steward / Vendor-Risk | Zweck, Datenkategorien, Residualrisiko-Akzeptanz |
| Steward | Processor / Vendor | Assessment-Pack und Evidence-Request |
| Procurement | Steward | DPA, Notice-Klausel, kommerzieller Exit-Hebel |
| Steward | Platform-Custodian | Technische Controls (SSO, Scope, Logging, Sperre) |
| AI Product Owner | Steward | Training-/Logging-/Host-Zusagen vor Feature-Launch |
| Custodian | Steward / Audit | Config-Nachweis; Steward hält Exit-Drill und Löschbeleg |
Anti-Patterns
- Datenschutzvertrag unterschreiben und Assessment vergessen
- Subprocessor „irgendwann“ oder nur per Website nachziehen
- KI-Dienstleister wie normalen SaaS behandeln
- Sicherheitsbericht als Nachweis für den eigenen Umfang ablegen
- Ausstieg erst am letzten Vertragstag planen
- Platform-Admin als alleinigen Dienstleister-verantwortliche Person führen
- Fragebogen ohne Wiedervorlage und ohne Gap-Expiry
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.
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.
Schritt 1: Rahmen und Entscheidung klären
Top-5 Processor nach Datenrisiko listen. Zweck, Kategorien, Regionen, DPA-Status und bekannte Subprocessor aufnehmen. Assessment-Tiers skizzieren. Business Owner und Steward benennen.
Schritt 2: Control und Nachweis umsetzen
Ein Assessment für den riskantesten Processor produktiv schließen. Eine Subprocessor-Kette end-to-end mit Notice-Pfad dokumentieren. AI-Feature im Scope auf Training- und Host-Zusagen prüfen oder das Feature sperren.
Schritt 3: Testen und Ausnahmen sichtbar machen
Exit-Mindestartefakte für einen Pilot-Vendor benennen und einen Drill-Termin setzen (Rückgabe oder Löschbeleg-Test). Negativtest: Feature-Toggle ohne aktualisiertes Assessment muss eskalieren. Assurance-Akte gegenüber Audit lesbar machen.
Schritt 4: Messen und begrenzt ausrollen
Aufwand und Lücken messen. Nur bestandene Muster (Tier, Kette, AI-Zusage, Exit-Drill) auf einen zweiten materiellen Processor übertragen.
Exit-Kriterien
- Jeder materielle Processor hat Tier, Wiedervorlage, Owner und Residualrisiko.
- Subprocessor-Kette nennt Knoten, Region und Notice-Pfad — nicht nur „on request“.
- KI-Features haben Training-, Logging- und Host-Zusagen oder sind gesperrt.
- Ausstieg-Evidenz hat Drill-Datum, Rückgabe- und Löschweg — nicht erst den letzten Vertragstag.
- technischer Betreiber liefert Config-Nachweis; Business Owner bleibt für die Nutzung accountable.
